# Arail development project



## Brandon (Jul 6, 2011)

Abstract: Arail (Yet to be decided name but "Another Railway", "Automated Railway" are some possible full names) is a development project underway by myself (and possibly others in the future) to create a new method of controlling a railway that combines different features than what have been traditionally offered in the hobby. The end goal is a railway that can fully run itself by the press of a single toggle button (to start and stop including bringing trains out of sheds and parking them inside as well) with other possible options of adding custom control of a railway by taking control of a one or more consist(s) to using predefined time tables and using real-time sensor data to know what is going on around the railway and for the software to react intelligently (eventually sophisticated AI) to events.

Mentality: The more prototypical a railroad is the more interesting it would be to some modelers. Prototypical railroads often operate quite differently (in terms of hardware) than what a sophisticated model railway does but with recent advances in micro computers it is now possible to have railway that can know down to an eighth of an inch where every train is at every moment and for it to think for itself and make choices on its own which can allow someone to do anything from run the entire railway by a push of a button to allowing people to become an engineer and be given all their orders by Central Control for what their train should do for the next hour, day, week or month and for modelers having to possibly contend with other computer controlled locomotives on the rails that could be higher or lower priority on the lines. 


Goals: KISS (keep it simply stupid) is primarily the first goal. A well built API will allow countless different methods to control a railway. Open Standards and Software will allow anyone to get involved to help make this better for everyone.


Why not use XXXX: There are a lot of different software and hardware options in the hobby but they are primarily non-prototypical tools to simulate some prototypical behavior and have many limitations. If we take DCC and JMRI as an example, DCC was a great idea but it's 30 years old and is often slow to accept change which can sometimes be more in favor of what people making money want rather than what an individual modeler wants. Using DCC over wireless connections is limited and provides no method of sending location data back in a wireless controlled railway. DCC also lacks any method of locating a train to millimeters without very expensive equipment that needs regular calibration which takes fun out of being able to 'just run a train'. JMRI was built around dcc to help make some functions of modeling easier but as Arail is to take a whole new approach to a railway, a new foundation that's not surrounded with 30+ years fixes and patches it is a more optimal choice to start fresh (however Arail-Loco would support operation from a JMRI system).


Software in Arail: Software will consist of a software "client" (Arail-Loco) that runs on a mini computer of each locomotive (or a trailing car) and other Arail-Server applications that send commants to a locomotive.


Arail-Client: 

Arail-Loco: This client software waits for a connection from a controlling piece of software and controls the physical hardware in the locomotive. XML can be sent containing more basic commands like: or 1 to other TBD instructions of how to reduce speed based on more realistic details such as slope at the current section of track and the number or types of cars (loaded vs unloaded coal cars) and so on. This will allow someone to use either a phone, tablet or JMRI to control a single train and also for more sophisticated server software (Arail-AIControl) to manage an entire railway if desired. 



Arail-Servers: 
Arail-ControlTest: This will be Arail-Test which will be a simple server that sends commands to a locomotiveHardware to run a short test of all available features of the locomotive or consist.

Arail-ControlBasic: This will be a non AI server controller that will run all desired trains on a railway and keep them from colliding but will not support any AI or more advanced layout functions (This will be used to create a server that exposes design flaws while allowing for me to enjoy the railway until I can develop a very complex server to do amazing things). This Arail server will work for the majority of modelers who 'just want to see their trains run' and want multiple trains running themselves at once including sharing mainlines, going different directions, and so on but aren't as interested in very realistic operation, time schedules, or don't want to spend any time "configuring" software other than measuring the distance from a sensor (ie: rfid sensor) to the front of the train and to the back of the train. In this server you can also take control of a locomotive and watch all the other trains either avoid your train or require you to avoid others depending on what operation mode you're in (obviously Arail-ControlBasic will make it hopefully impossible for any track to collide unless you _try_ to rundown another slower (ax in max speed) train that's fleeing to a siding or another line)

Arail-ControlAI: This likely be a full re-write of Arail-AutoBasic that you can configure things like "coal loading plant at X position in the track", configure what cars are in your consist so it simulates loading all coal cars, where passenger terminals are and how often you want trains to stop at them, and so on and press "go" and watch the railway learn how to possibly operate your particular railway to whatever goal is. Imagine deciding what trains you want to run that day, what time schedules you know are tough to make, and then adding a massive through consist of a coal load at the busiest "time of the day". I should note that 100% realism isn't the goal or even a realistic possibility but working towards it is a new area modelers haven't been able to do with multiple moving trains and one person before.



Software: 
Licensing: First, the code will be OSS (Open Source Software) and released under the GPL license (GPL licensing basically makes it so everyone has a right to get it,, look at, modify and be able to talk about it, redistribute any changes they make and no company or person can take something that others wrote, in whole or part, and withhold anything they might do from everyone else either).

Language: At this point the server will be written in Perl as it can be easily changed and run on different platforms. There's a slight chance Arail-ControlAI could be C or C++ but unless performance becomes an issue I think perl/apache/mysql would provide for the fastest development and for others who can handle learning a little programming to maybe learn a new skill and do some specific things they like.
Data communication: XML/soap'ish 

Hardware: Currently the first goal is to use a micro computer (simulating someone listening for commands and operating the controls on a locomotive), a wireless connection (as this is what prototypical railways use for communication), and a RFID reader (simulating the eyes of the engineer reading mile posts and knowing where he's at). IR, block detection, reed switches, and other sensors will likely not be supported because if a cheap, reliable, and simple method can be found to do everything we need, then by following the KISS mantra, adding support for other complex sensors that offer less data wouldn't make supporting and maintaining the project as easy or fun for us as we'd rather be outside running the railroad than inside sitting at a computer writing code.


Location Hardware: I've purchased several $10-$15RFID readers from ebay and actually have had better than expected results so I have no douvt RFID will be the key choice for tracking consists.

Mini Computer: Raspberry-pi is currently the best choice. For $25 you get a 700mhz 128MB computer with 2 usb slots and it uses about 1Watt of power. If it has the ability to run a full OS and Desktop + DVD videos it's more than enough for what we'd need on board a loco (or trailing car)

Motor Control: TBD Maybe Gertboard, Teensy, or a USB servo controller and a car or boat ESC? (This would provide a 5VBEC we'd need to run the raspberry-pi but I've not found 5 cell ESC's for trains that are under $50. Thoughts?

Lighting: Gertboard, pic, usb controller+servo relay? Or something else, Thoughts?
Smoke: Gertboard, pic, usb controller+servo relay? Or something else. Thoughts? 

Sound: The raspberry-pi has stereo out. Since trains are technically mono sound you could run two different types of locomotives in a single consist and get two different train sounds.


Well, that's it for now...


----------



## Brandon (Jul 6, 2011)

Arail-Loco XML... 

Arail-Loco will allow you to either send an xml config to it when an Arail-Control connects to it (in case Arail-Loco is running in a trailing car and you connect it to different locomotives) or if you always use a particular Arail-Loco client with single engine it will in this case just operate as the last loaded XML file it got. 

I'm working on the Arail-Loco client and would like to get input on what information people think is needed, wanted, or fits into a 'wouldn't ever effect anything but it would be fun to have kept with the locomotive/consist". 

Here is what I have come up with so far. Please, please, please critique this. Just make sure you comment if it's "needed" "wanted" or "would be nice to have the information "saved" with the locomotive but it's purely for logging/data record and wouldn't affect operation in any way". Everything I have other than the and are need or wanted (Imagine Aral-ControlAI knowing which locomotives have people in them so when it puts consists together it knows to put the train with people in it at the front of the consist or send the unit to "staging" to have someone put a figure in it. I know this is a 'out there' idea but it's an idea that may spark an idea in someone else that could be really nice. 


```
SD-45     SD-45             UP     1024     Test Loco     4     1     1     0                   20      1000      .3      3      1                       pin1       4       0                   pin2       4       0                   pin3       4       0                   pin4       4       0                   pin5       4       0                             audioLeft                             pin6                        pin7
```


----------



## Greg Elmassian (Jan 3, 2008)

I'm looking forwards to what you will come up with. 

I can't say I agree with all of your reasoning, like not using DCC because it's 30 years old, and then you program in Perl, invented in 1987.... ha ha... 

And there are ways to do bidirectional communication wirelessly... 

And there are reasons that track power is used, because it eliminates the wireless hardware, saves money, and eliminates rf interference... 

The main reason I responded is this paragraph: 

Mentality: The more prototypical a railroad is the more interesting it would be to some modelers. Prototypical railroads often operate quite differently (in terms of hardware) than what a sophisticated model railway does but with recent advances in micro computers it is now possible to have railway that can know down to an eighth of an inch where every train is at every moment and for it to think for itself and make choices on its own which can allow someone to do anything from run the entire railway by a push of a button to allowing people to become an engineer and be given all their orders by Central Control for what their train should do for the next hour, day, week or month and for modelers having to possibly contend with other computer controlled locomotives on the rails that could be higher or lower priority on the lines. 

In the first sentences you seem to embrace prototypical behavior... but then you talk about a train thinking for itself and making it's own choices... definitely not prototypical. 

I kind of got lost after that because your second sentence has 134 words! 

But, let's see what you come up with. Please keep us abreast of your developments, especially any low cost hardware that allows positioning to 1/8" and works wirelessly. 

I'd love a system with the capability you describe (even though I will keep track power)... 

Greg


----------



## Brandon (Jul 6, 2011)

Like all people I have my own views on things, and they could be wrong or far off but in the world of discovery and science sometimes wrong ideas and good ideas turn out the opposite but you never know unless you try and follow it through. With this I'm sure things I may consider to be wrong or bad wouldn't be seen the same way by others and that's fine and vice verse, but don't shoot us down before we have a chance to stretch our winds and see what happens.  I'm also not looking to have Arail ever get into 'this is better than that' by any means at all, I'm just trying to come up with a way to run a fully automated railway the way I've thought of that might work well. 
DCC is great for many things but based on my own personal thoughts I feel DCC lacks some features that are critical (in my opinion which could be wrong or not the same as what others think) and I've come up with some other hardware options that I think would work better for what I'd like to do in my own yard. 

If you're curious about why I'm not a fan of DCC I can go over those, but obviously that would be off topic and not appropriate to get into a discussion on here as this thread is about the development of yet another way to do railway control. 

To note, you could run track power and DCC with Arail but that is a layer of complexity that isn't at the top of my todo list or part of what I believe would follow the KISS mantra. And of course no software is perfect so there will always be cut corners where needed until more time can be put into development or problem solving of ideas. I could note that I plan to have others use track power and use their locomotives while mine would run battery and all I'd need to do is put a car with the tracking hardware in the visiting locomotive and the software would know where it's at all the time and would route my trains around that visiting train. Or someone could still use DCC on their own layout with Arail and if they wanted to write modify the software they could also use Arail-ControlAI to control DCC trains but you'd still need a way of getting accurate location data back to Arail-ControlAI but that's a topic that would be better discussed once the basics of Arail are done and working. I'd love to design and build everything at once but this is a hobby for enjoyment and thus I can only do so much at a time. I'm writing this as GPL so someone like yourself who enjoys DCC could take everything I do and cut out the pieces I feel are important and add your own parts to do it as DCC and create a who new project called DCCArail which if it were better adopted than what I do you could pretty much wipe Arail off the map but I still could do what I wanted with what I wrote and no one could stop me from enjoying my railway the way I wanted. I hope this shows I'm not against any technology and I believe in letting all technologies have their chance, but I hope this project doesn't get harassed for being 'different'.



P.S. I'm not the greatest at English, its usage, or readability. I do my best and hope those who are interested in what I'm doing don't get too frustrated with my writing. I apologize in advance as it's not that of an English scholar. 
P.S.S. Greg, it appears you have PM's turned off, if you're interested in receiving responses on the items you brought up please send me a PM on how I can reply outside of this thread.


----------



## Greg Elmassian (Jan 3, 2008)

Note that I was not espousing DCC, just saying your reasons to exclude it don't have a lot of "bite" so to speak. 

Yes, if you look at my signature, you will see in BOLD red letters that I do indeed have my private messages off and to use regular email... can't make it more obvious without breaking forum rules for animated gifs ha ha! 

Nothing wrong with your English, just very long sentences should normally be broken into shorter ones. It conveys the thought better and keeps the point centered. 

The interesting part is where the ideas translate into hardware that makes sense and is available. Will be looking forwards to that. In the short term, you might very well adopt some DCC hardware to facilitate your higher level control system. 

Regards, Greg


----------



## DKRickman (Mar 25, 2008)

I've seen similar developments in the smaller scales, and VERY similar arguments against "old" technology like DCC. My thoughts are the same here. You need to (in my humble opinion) consider the user interface and automated control systems as separate from the actual train control technology. A properly designed system ought to be modular, and work with what people already have, rather than adding yet another incompatible control system into the mix. With DCC and JMRI, perhaps with a new form of train detection (not necessarily DCC) you could do much the same job, and not have to design a new system from scratch. 

Remember that that 30+ year old technology has had 30+ years to work the bugs out. And it's still not perfect. Really think you can do better out of the gate? 

I also respectfully submit that you do NOT need to know where every train is to within 1/8" at all times. Even the prototype doesn't know that. All you need is to know whether a train is in a given segment, and when it is approaching certain fixed locations. That makes the problem a good bit easier to solve.


----------



## Terl (Jan 2, 2008)

Brandon 

OK so I got lost in your technical jargon, but was intrigued with the hopes of using computing power for control and accurate knowledge of where things are. So here are some ideas that you may have the knowledge to develop. Model railroading has long been fascinating because the animation the moving trains give a model scene. It was possible all these years because of the low tech, simple KISS principle, the rails keep the flanged wheels on the track. What has been lacking is the next level of animation needed. The realistic animation of road traffic including cars, trucks, horse drawn vehicles, and their stopping, starting, independent turning, etc. Slot cars have been around along time but fall short on realism. I have seen battery powered vehicles following a buried magnet iron wire which look pretty good on a clean inside model railroad, but if some technology could be developed to control vehicles in our dirty garden railroad environment, it could be revolutionary. The next level of animation which would add alot would be the motion of living people and animals. Depiction of computer drawn beings in movies shows that we have the computer simulation down, what needs to be done next is to translate that to 3 dimensions and in miniature. 

I'm not sure if your ideas could be applied to these needs, I'm just mentioning them as the next steps that could revolutionize model railroading. 

The best of luck to you. Whatever you do I appreciate the amount of work involved and the technical expertise. 

Terl


----------



## Brandon (Jul 6, 2011)

Posted By Terl on 02 Jan 2012 02:32 AM 
Brandon 

OK so I got lost in your technical jargon, but was intrigued with the hopes of using computing power for control and accurate knowledge of where things are. So here are some ideas that you may have the knowledge to develop. Model railroading has long been fascinating because the animation the moving trains give a model scene. It was possible all these years because of the low tech, simple KISS principle, the rails keep the flanged wheels on the track. What has been lacking is the next level of animation needed. The realistic animation of road traffic including cars, trucks, horse drawn vehicles, and their stopping, starting, independent turning, etc. Slot cars have been around along time but fall short on realism. I have seen battery powered vehicles following a buried magnet iron wire which look pretty good on a clean inside model railroad, but if some technology could be developed to control vehicles in our dirty garden railroad environment, it could be revolutionary. The next level of animation which would add alot would be the motion of living people and animals. Depiction of computer drawn beings in movies shows that we have the computer simulation down, what needs to be done next is to translate that to 3 dimensions and in miniature. 

I'm not sure if your ideas could be applied to these needs, I'm just mentioning them as the next steps that could revolutionize model railroading. 

The best of luck to you. Whatever you do I appreciate the amount of work involved and the technical expertise. 

Terl I've thought about this for years... Having other objects moving on their own, carriages, cars, people, etc, is not simple and each would most likely require different mechanisms to work so there isn't a solution for all except hiring kids to play with them while you operate the railroad.  The magnet+wire idea is popular and there are other tricks. You should take a look at Miniatur Wunderland in Germany, they have lots of videos online and some talk about how they do things. That's by far the most realistic modeling I've seen that encompasses all types of movement including trains. The idea of using AI to move people in a city isn't that compllex to do in AI but making the objects to move is most complicated part and although what will be Arail-ControlAI uses the same principles it's not closely related to what this project would be. VictorSpear on here could probably point you in the direction of small robotics that can act autonomously (carriages, cars, people and bikers) moving and stopping and in fact a central control wouldn't be needed, just sensors on each device to make sure where they're wanting to go isn't another object. Powering those would be trickier too but there's no reason you couldn't have cars and bikes driving around on their own using battery power. Also if each device can make its own choices and doesn't need to communicate with a server the cost and complexity to develop the system goes down very quickly. I think you can buy robotic kids for under $50 each that are basically car parts with a few sensors to make sure it doesn't run into a wall. Kids toys are even getting to this point where you can turn them on and they drive on their own. I was in Hallmark during some Christmas shopping and even they had the kids cars that you can draw a line with a pen and place the car over it and the car follows the line, I think it was $10 or something. I imagine in a few years some toy maker will have a toy that can be modified to follow hidden wires under things and when it reaches another trigger sensor it stops and can make choices if it wants to go one direction or another. Of course if you want to get the kit robots you can do that now but it's not 'toy' cheap.

Oh, one other thing, I have thought about using projectors for background scenery. If you take a ride on some of Disney's attractions and know the fact that some things shown are multiple projects in series it shows what can be done. Indiana Jones does this quite a bit as do some of the other dark rides like Pooh and the old People Mover with the Tron sequence... Now days the thing is using high powered projectors and 3D mapping to give things like the castles and It's A Small World a completely different look and feeling and it takes into account how to shade edges that aren't straight on so that depth can be removed or added. I do believe though that this has less appeal for modeling as we want to see real objects and not projections that wouldn't work as well during the day.


----------



## Tom Lapointe (Jan 2, 2008)

I've got to chime in here on this a bit myself. As Greg said, DCC has had 30 years to "work the bugs out", & DCC decoders (often pre-installed in locomotives) are available *"off-the-shelf". *This isn't the case for *most *proprietary control systems - the only ones which have been at least reasonably successful (aside from DCC) in large scale are DCS, Aristo's "Revolution", & RCS. If you're talking producing a new standard, you're looking at high developmental costs for *any *sort of *mass production. *









Also, a lot of what you're referring to (in terms of *prototypical operation) *aren't applicable in many model railroad situations, *particularly in large scale. *I did notice your referral to the closest "real world" model railroad to what you're describing, *"Miniature Wunderland" *layout in Germany, which has a computerized control center that could make NASA Mission Control *jealous. *











Note especially that the Minatur Wunderland layout is *HO scale, *& occupies a *HUGE *







building. (Let's not even go into what it







* must have cost **$$$$$$$ *to build!).

Most *Large Scale layouts *(my own included) are positively *tiny *be comparison; the trains, being far larger than HO, also require correspondingly larger areas for equivalent track plans. My own railroad has a mainline run of @ 160 feet, with a trackage total of @ 300 feet if I include all my passing sidings, yard, & industrial trackage. Most of the time, I'm running narrow-gauge prototypes, usually slow, geared logging locomotives like Shays (typical prototype operating speed for a Shay: *10 ~ 12 MPH. *







). Operating at that prototypically slow speed, it takes a Shay an average of @ 5 minutes to make a full lap around my mainline. I *am *considering some form of automated operation for when we have visitors, but it will be limited to having 2 or *at most 3 slow-moving trains, *at least one operating in an "opposing" direction, pass one another automatically via sidings on a *single-track mainline. *

Another *major *large-scale consideration is that many of the layouts (mine included) are *outdoors. *







The greatest consideration is that *any *electronics installed outdoors have to be in *weather-proof housings. *As well as moisture-proofing concerns, the electronics are also subjected to *temperature extremes *














that are not encountered in indoor model railroad situations. Detection schemes such as infrared and optical are usually *unusable *







outdoors due to *(real) *variable lighting conditions. This also makes doing some of the (admittedly impressive







) types of animation such as Miniatur Wunderland does impractical from a *reliability *standpoint.

That last point - *RELIABILITY *(or *lack thereof! *







) is a *HUGE CONSIDERATION *in *any sort of model railroad automation. *I have more than a bit of a clue on the subject, having formerly worked in the industrial electronics field (maintaining CNC machine tool equipment) - and the power levels large-scale locomotives require tend to lean more in that direction than HO equipment. Automating *especially *an *outdoor* large-scale railroad means dealing with many variables which are *not *encountered on an indoor model railroad; not only do we have to deal with rain, but also snow (Aristo-Craft sells a large-scale wedge snow plow which works reasonably well), leaves, dirt & animals







as well. Just keeping *track & roadbed *maintained for reliable operation in that situation is enough of a job in itself; if they aren't reliable, adding automation to the mix will only make things *worse. *Just a bit of friendly, constructive criticism to let you know what you might be getting into.







*Tom*


----------



## astrayelmgod (Jan 2, 2008)

Brandon -- 

You keep referring to the "KISS mantra". but I don't see one thing about this that is simple. All I can say is, I look forward to seeing what you do with it.


----------



## astrayelmgod (Jan 2, 2008)

I'll start by picking on your choice of computer. I see a raspberry pi has 8 GPIO lines. I think this immediately invalidates your KISS plan. In a real product, there would be many more GPIOs, to say nothing of PWM, and interrupt inputs.


----------



## Brandon (Jul 6, 2011)

Posted By Tom Lapointe on 18 Feb 2012 10:02 PM 
I've got to chime in here on this a bit myself. As Greg said, DCC has had 30 years to "work the bugs out", & DCC decoders (often pre-installed in locomotives) are available *"off-the-shelf". *This isn't the case for *most *proprietary control systems - the only ones which have been at least reasonably successful (aside from DCC) in large scale are DCS, Aristo's "Revolution", & RCS. If you're talking producing a new standard, you're looking at high developmental costs for *any *sort of *mass production. *









As embedded computers become less expensive while increasing in feature sets there is no need to develop any hardware as someone can use what's readily available. This means no proprietary hardware and functionality that is only limited by software. In the world of open development, hardware and software, there is no need for high development costs for any sort of mass production. 


Also, a lot of what you're referring to (in terms of *prototypical operation) *aren't applicable in many model railroad situations, *particularly in large scale. *I did notice your referral to the closest "real world" model railroad to what you're describing, *"Miniature Wunderland" *layout in Germany, which has a computerized control center that could make NASA Mission Control *jealous. *









Agreed, but getting 'closer' to real world does mean everything from using realist acceleration and braking performance based on locos real world specs and load to how communication works. For a technology person like myself, dcc track communication is a 'hack' imho and not how I would like my railroad to function (but there's no reason someone couldn't use what I develop to run a DCC setup), RF to me is a more 'realistic' approach and thus closer. However it is scale and won't ever be like full scale in all ways but a nice thing about being someone who's writing some or all of the code is I can add what I want to see. Also anyone who wants to add what their $.02 can download the code and do as they wish as well, I wouldn't stop them as that would slow down innovation. I've been part of OSS software development on dozens of projects for nearly 20 years, I never get tired of watching projects grow from what a group of people can do when it's a hobby.


Miniature Wunderland is amazing, if only they had a way to share what they've developed at a price that people could afford and they could support (having something that works is only half the product, writing documentation, keeping it updated, and having to not break other peoples stuff you can't test is the hard part). But as much as using any of their code would be, I can respect their choice to keep it in-house.




Note especially that the Minatur Wunderland layout is *HO scale, *& occupies a *HUGE *







building. (Let's not even go into what it







* must have cost **$$$$$$$ *to build!).

Most *Large Scale layouts *(my own included) are positively *tiny *be comparison; the trains, being far larger than HO, also require correspondingly larger areas for equivalent track plans. My own railroad has a mainline run of @ 160 feet, with a trackage total of @ 300 feet if I include all my passing sidings, yard, & industrial trackage. Most of the time, I'm running narrow-gauge prototypes, usually slow, geared logging locomotives like Shays (typical prototype operating speed for a Shay: *10 ~ 12 MPH. *







). Operating at that prototypically slow speed, it takes a Shay an average of @ 5 minutes to make a full lap around my mainline. I *am *considering some form of automated operation for when we have visitors, but it will be limited to having 2 or *at most 3 slow-moving trains, *at least one operating in an "opposing" direction, pass one another automatically via sidings on a *single-track mainline. *

Another *major *large-scale consideration is that many of the layouts (mine included) are *outdoors. *







The greatest consideration is that *any *electronics installed outdoors have to be in *weather-proof housings. *As well as moisture-proofing concerns, the electronics are also subjected to *temperature extremes *














that are not encountered in indoor model railroad situations. Detection schemes such as infrared and optical are usually *unusable *







outdoors due to *(real) *variable lighting conditions. This also makes doing some of the (admittedly impressive







) types of animation such as Miniatur Wunderland does impractical from a *reliability *standpoint.

That last point - *RELIABILITY *(or *lack thereof! *







) is a *HUGE CONSIDERATION *in *any sort of model railroad automation. *I have more than a bit of a clue on the subject, having formerly worked in the industrial electronics field (maintaining CNC machine tool equipment) - and the power levels large-scale locomotives require tend to lean more in that direction than HO equipment. Automating *especially *an *outdoor* large-scale railroad means dealing with many variables which are *not *encountered on an indoor model railroad; not only do we have to deal with rain, but also snow (Aristo-Craft sells a large-scale wedge snow plow which works reasonably well), leaves, dirt & animals







as well. Just keeping *track & roadbed *maintained for reliable operation in that situation is enough of a job in itself; if they aren't reliable, adding automation to the mix will only make things *worse. *Just a bit of friendly, constructive criticism to let you know what you might be getting into.







*Tom* 


Constructive criticism is always and highly appreciated. I do have an Aristo plow and plant o run during winter. Electronics outdoors are a huge concern, I can't tell you how many threads I've read about various failures from switches to ballasting that will affect the ability to run an automated layout. For me, I'm choosing to have no electronics outside of the train shed with the exception of signals one day. All switches will be pneumatic controlled but many will rely on typical solenoid but this gets abstracted to the software control. Due to potential quirks with ir, magnets and other sources I've elected to use RFID for tracking as some tags are waterproof (in glass) and will last for as long as the track (30+ years). In my design, a loco or a car somewhere in the consist would need enough room to fit a credit card sized computer, an extension board for controlling the loco (probably the size of an altoid can as well) and the RFID electronics (size of an altoid can as well). In G scale this is very doable in most locos and cars. The main constraint will be a battery which if you're using for loco power would be very large, otherwise a 2cell lipo would provide countless hours of use between recharges. This would allow as well for a loco to be track powered, with the "sensor car" reading and the track providing loco power. This is the simplest yet most versatile way of doing an automated railway I've come up with yet, and it could still evolve.


astrayelmgod: It's not simple as a functional goal but the hardware and hopefully software architecture (not number of lines of code) I'm hoping to keep as simple as possible. As for GPIO's, take a look at the "gertboard". It provides about 64 GPIO's, pwm, 2 motor drivers (the L6203 IC that can do up to 48V @ 5A and 4A RMS). Gertboart will be $10-$20 or so. And for people that use an RCS esc, they could by a $20 usb servo controller and use RCS's electronics to run a train as well. The software for automation won't care what you're using for driving various things except on setup you might need to specify it's an RCS receiver and what pins are connected to what outputs (lights, smoke, etc) so it turns the right things on.


I'll also note that I do plan on running consists of 3-5 SD-45's which obviously will be over 5A but I plan to have 8+ trailing cars for electronics and some will be for up to gertboard max of 5A and 1 or 2 trailing cars will use gertboard GPIO's to control additional IC's that can handle over 15A for those longer and more substantial load requirements. I'll also modify my SD-45's at some point to have everything inside, but only after I find a good way of accessing batteries in a SD-45 without a screw driver being involved.


Thanks for all the info, it does help me to second think choices and see what everyone things of my proposed ideas.


----------



## Brandon (Jul 6, 2011)

Grrrr. mls put my comments to Lapointe inside of his quote box, so there's more there than just my reply to astrayelmgod. I should also note that gertboard is a product that's being designed to specifically increase the number of GPIO's by an individual who's closely associated with the R-pi project.


----------



## SteveC (Jan 2, 2008)

Posted By Brandon on 19 Feb 2012 09:16 AM 
Grrrr. mls put my comments to Lapointe inside of his quote box, so there's more there than just my reply to astrayelmgod. {snip...}[/i] Brandon

I'm really not trying to be critical, but since that is where you typed your text (i.e. within the quote) just where did you expect it to be displayed?


----------



## astrayelmgod (Jan 2, 2008)

All I could find on the Gertboard were press releases. It isn't a product yet, so "$10-20" is at best a SWAG. Be that as it may, you still have a CPU board, an IO board, an external memory card for program storage (as there is none on the CPU board (SDRAM doesn't count)), some mechanical method for tying all that together, and a power supply. Suddenly, it isn't $25; it's probably three times that, at least. Plus, it is quite large. Yes, large. I see you favor SD-45s which is much larger than anything I can run on my layout, but even then you are talking about using trailing cars for electronics. Fine, but that needs some way to connect together, which all drives the costs up even more. And an awful lot of GRR'ers won't be able to use it because it just won't fit in their (small) steam locos. A solution that would have a wider potential market would have all the CPU, memory, IO, power control, and interface on one board the size of a business card. One board. One.


----------



## Tom Lapointe (Jan 2, 2008)

OK, another point; you're talking 800 feet of feet of track (more than double what I've got, nice if you have the space available.







). You're talking running loco consists of *3 ~ 5 SD-45's *







- I would expect a *single SD-45 to draw at least 2 (probably more like 5) amps by itself, *if you're pulling a *prototypically long enough train *(I'd expect to see consists of *at least 100 cars *







in that case!). The closest train I own to what you're talking is my USA Trains' New Haven "Merchants Limited" streamliner







- which has a pair of USA Train's Alco PA's (comparable in size to the SD-45's; twin-motored, 6-axle locos.







The train itself is only *5 *cars long; but they are *5 very heavy aluminum passenger cars, weighing in @ 20 pounds apiece. *







Since our property is partially on a hillside, my mainline has a ruling grade of 3%; those PA's *struggle *







to lug that *100 pound *consist upgrade. (Note that in the photos below, I'm showing a *4 rather than 5 car *consist; I've had trouble with *stripping axle gears *







in the PA's due to the train's weight, so often omit one coach to make life a bit easier for them):




























Even running the 5 car consist, running on straight analog DC track power, I measured the total current consumption of the entire train (including the *full lighted *passenger cars) at *7.5 *amps. (This was prior to installing DCC decoders - Digitrax DG-583S's in each PA, & a Phoenix P5 sound card in the lead PA). 


Another comment you made I found somewhat flabbergasting - you say your system will require *8-plus *







*trailing cars for electronics?!?! *







On my USA streamliner, *all electronics are totally enclosed in the Alco PA's. *The lead PA has the most in it, with the *entire *Phoenix sound system (the P5 sound card, heavy-duty 3" speaker with a large magnet, volume control up / down switch, and serial programming jack) *totally enclosed within *_*just *_*the fuel tank. *(Making the sound system an entire easily removable module). On both PA's the Digitrax decoders are installed centered on the loco chassis' floor, with huge amounts of room to spare. Sorry to "bust your bubble"







, but Arail sounds like a giant step backwards.

















Tom


----------



## Brandon (Jul 6, 2011)

Posted By astrayelmgod on 19 Feb 2012 10:16 AM 
All I could find on the Gertboard were press releases. It isn't a product yet, so "$10-20" is at best a SWAG. Be that as it may, you still have a CPU board, an IO board, an external memory card for program storage (as there is none on the CPU board (SDRAM doesn't count)), some mechanical method for tying all that together, and a power supply. Suddenly, it isn't $25; it's probably three times that, at least. Plus, it is quite large. Yes, large. I see you favor SD-45s which is much larger than anything I can run on my layout, but even then you are talking about using trailing cars for electronics. Fine, but that needs some way to connect together, which all drives the costs up even more. And an awful lot of GRR'ers won't be able to use it because it just won't fit in their (small) steam locos. A solution that would have a wider potential market would have all the CPU, memory, IO, power control, and interface on one board the size of a business card. One board. One. 
Yes, $10-$20 is projected cost, but these guys know their IC's and costs quite well. For 'tying it all together' a $2 usb hub will do that (unless you're just using the r-pi for location tracking (no power control) then the 2 usb ports on the r-pi are all you need, no usb hub. Power supply is a sub $5 BEC used for model airplanes/cars/boats (since I plan to use 4-5 cell LIPO's, this works very well). Last I checked a 4AH lipo was about $40 and being an electric flyer for many years, I've seen the price drops about 30% per year. My goal was to have a solution sub $100 per consist. I have yet to decide how I'll wire things up, but I do know I'll be simulating MU and airbrake connections for use to control separate motive power, individual lighting control, smoke, and sound between a trailing car and loco(s) and daisy chain it through them. I won't personally be using the current connector (forget the type) used by Aristocraft because it simply isn't a large enough gauge wire to handle 10+ amps over it's 18 gauge wire without potential problems, so I'll re-wire most all my locomotives except my RS-3's and some fa-1's that only have one headlight and I'm not a huge fan of smoke so most FA1's won't get support for smoke. BTW, from my tests of my locos, fa1's use .6-.8amps (no load, and I have about a dozen fa1's from REA to present day aristo versions) and .7 to 1.1amps (16 car load, mixed car type and axle type) for motor control (no need to add lights or smoke to this number as these will be run off the l6203 motor IC). SD-45's/-9's use 1.3A-1.7A no load and 1.9A-2.4A for a 23 car load. Thus my _theory_ is the gert would be usable by many people but of course not all. 

I also am aware that what I'm doing won't work for many large scalers but you do have to remember that my #1 goal isn't to create something for everyone or replace anything on the market but to create a way that I can personally run my railroad how I want to and this is my proposed method, mainly because nothing on the market allows location tracking down to the accuracy I want, accuracy far beyond what most modelers would every want in a garden railroad. The biggest limitations I saw in large scale is software and hardware and everyone is at the mercy of the DCC organization or another companies proprietary device. No company gives modelers the ability to modify the software in devices to add features they want. Hardware in DCC and even the revolution are very limited when compared to a full computer with a usb port. I've worked in the embedded linux field for many years and unless you're selling millions of units it's almost always cheaper and faster to throw more hardware at the problem than work in specialized SDK's that are less robust than commonly used environments. If aristo had a usb port for communication with off the shelf devices and drivers and they opened their software for others to expand I'd not be doing this project. Also if I were a electronics guru I'd consider making my own DCC decoder that did support RFID or other location tracking but I don't, I have to rely on the skills I do have and that I enjoy using since this is a hobby. 

Even if no one ever used what I did I still think sharing what I am doing here might help someone else on a related type of project. I also think that over the next 100 years model trains will need to evolve or they will become a thing of the past. I really like the idea of watching a coal train move every minute or so to simulate a full train being loaded with coal (and maybe one day I will make a working loader as well) and trains stopping at stations based on time schedules. I also like the challenge of making everything work so I don't have to touch a control and I can see it all work as I had spent years building and tinkering with things until I can do that one day.


----------



## Brandon (Jul 6, 2011)

Posted By Tom Lapointe on 19 Feb 2012 11:28 AM 


Even running the 5 car consist, running on straight analog DC track power, I measured the total current consumption of the entire train (including the *full lighted *passenger cars) at *7.5 *amps. (This was prior to installing DCC decoders - Digitrax DG-583S's in each PA, & a Phoenix P5 sound card in the lead PA). 


Another comment you made I found somewhat flabbergasting - you say your system will require *8-plus *







*trailing cars for electronics?!?! *







On my USA streamliner, *all electronics are totally enclosed in the Alco PA's. *The lead PA has the most in it, with the *entire *Phoenix sound system (the P5 sound card, heavy-duty 3" speaker with a large magnet, volume control up / down switch, and serial programming jack) *totally enclosed within *_*just *_*the fuel tank. *(Making the sound system an entire easily removable module). On both PA's the Digitrax decoders are installed centered on the loco chassis' floor, with huge amounts of room to spare. Sorry to "bust your bubble"







, but Arail sounds like a giant step backwards.
















Tom 




Tom, I went over the current usage of locos in my last post reply, but bascially it's lower than you're thinking (not by much) and the motor controller is on a separate circuit than the lights and since the lights will be a relay to a 5v 20+A BEC I doubt I'd ever max that for lighting, smoke, or other accessories.  But this also requires you separate out the lighting circuit(s) and smoke circuits from the motor circuits on a loco. I'm guessing I'll have a 2 wire connection for the motors a 6-12 pin connection for lights, smoke, and sound. I have yet to do research to find the needed gauge of wire to run everything and what connectors will support the wattage needed. I'm hoping that I can fit these connections in bundles that appear to be MU and/or airbrake lines.

The "8 trailing cars" comment was the number of the trailing cars I'd make, but only 1 is needed per consist. having 8 trailing cars would allow me to run 8 different consists on the track at once.


Arail will be a step backwards in many areas, I will fully admit that, especially size requirement. But there are always trade offs with different solutions. Honestly if DCC supported RFID or any other locating down to less than an inch (or even a foot) of accuracy I'd use it, but my railroad would require over 50 blocks and that's just a scary thought for long-term reliability. And since knowing where each locomotive is, is the most important thing in an automated railroad that missing feature in DCC, revolution, mts, etc are what force me to find another way to control consists, and the best thing I've come up with is what I've talked about here. I'll spend hundreds or thousands of hours on this project over the years so obviously it would be cheaper for me to get a second job with that time if it were just a matter of buying more expensive hardware if it existed. 


You do have to admit that this isn't a unrealistic method and that it would work for some people, especially those who already stick a battery in a trialing box car or coal hopper... A brand new, sub $100 solution that will give all the same features found in the revolution and most in DCC feature sets but that the modeler will have full access to the software, hardware, the ability to expand hardware, and location support with only a need of about 8 cubic inch requirement isn't really that bad at all. It also doesn't lock someone into a specific handset. For those that want to use a pda, tablet, computer, or anything else they can. They're only limited by what they do, not what a for profit company says their customers can do. 

Anyway,


----------



## astrayelmgod (Jan 2, 2008)

"...#1 goal isn't to create something for everyone or replace anything on the market... " 

OK, that wasn't my first impression. 

I guess it's safe to say that I don't share your aversion to creating new hardware. Considering the vast quantity of custom software you envision, complete custom hardware would be much, much less than 0.001% of the effort. 

"No company gives modelers the ability to modify the software in devices to add features they want. " 

Yes, take my word for it; there are several really, really good reasons for that.... 

Well, as I said before, I look forward to seeing what you do with this.


----------



## Brandon (Jul 6, 2011)

I just finalized my raspberry-pi order this morning as well as a pololu 18v7 usb motor controller so in about two weeks I'll have actual hardware to play with so development will continue again. 

Over the past few months I've done a lot of research about prototypical railroad operations, model operating sessions, hardware, software and I've come to the conclusion that trying to model too much prototypical data in G scale just isn't too feasible with G scale products so to make ARail simpler some of the prototypical ideas I had (fully realistic braking based on which cars are attached, slope of the track, etc) isn't likely to make it into ARail for some time if ever. I think that's not something 90% of people would ever take the time to setup for a garden railroad. Also as useful as RailML is I don't think hardly anyone would use that either so for now it'll be removed from the design. 

I hope to report by the middle of June to have the following done: 

ARail client features: 
Bootable SD card image for others to download and play with 
Forward, backwards movement with adjustable momentum setting 
Automatic (on movement) and manual Whistle, Bell, and air brake release sounds working (No engine sounds yet, still haven't found a good source of or way to play repeating sounds in perl without odd sound pauses in a test script) 
RFID tag reading and feedback 
Bonus: 
Control of lights (might just be LED's depending on if I've taken time to redo a locos incandescent lights) 

ARail Web Server features: 
Basic web interface to control locomotives 
Support for movement functions and selecting momentum rate 
Manually request sound signals to be played.


----------



## Brandon (Jul 6, 2011)

Very, very, very, ugly and crude diagram of the parts and wiring...


----------



## Brandon (Jul 6, 2011)

My Raspberry-pi is here, unfortunately this is a very busy week but at least I'm the holdup instead of hardware now.


----------



## Brandon (Jul 6, 2011)

Great news, over the weekend I completed about 90% of the client software. Besides some problems with the r-pi's alsa bcm2835 kernel driver dieing after a bit of hard use (lots of horn and bell testing) and not being able to dmix multiple audio channels (driver limitation, will be fixed somewhat soon I imagine) it's working very well. 

I've decided to have tcp/telnet and websocket api's for the client. tcp/telnet is hack friendly so writing controlling application will be as simple as it gets. Websockets will also allow direct control from any device just by pointing a web browser to the IP address of a locomotive. 

There are about 40 functions/status fields for the locomotives, everything from input voltage of the track or battery to realtime smph. Each function for lights, smoke, and couplers can be customized per locomotive and if you want to change a horn, just drag-n-drop a sound file for a different horn-long.wav or bell.wav file via smb (windows share) and you're done. 

I've also been working on the server for aRail, starting with the 'learning' piece that will lets you pick a locomotive to run around a track and learn rfid tags and figure out where switches are automatically. I don't have a tach yet so detecting distances isn't done yet (the pololu 18v7 doesn't let you watch voltage/amps so this fuzzy idea for detecting speed isn't possible thus a tach will be needed), or just grab a yard stick and measure the distance between each rfid tag manually). 

Anyway, I thought some of you might be interested to hear that the client is mostly done, no more vaporware. It's kind of fun to telnet into a locomotive and have it move and play any sound I want. I want to get a circuit built so I can start controlling lighting via using the aristocraft plugnplay socket that directly connects to the r-pi... 

If anyone wants to write code or do circuit work contact me through PM. I know a few people were interested but maybe they'd like to see a bit more before getting involved, but I really could use some EE help since that's out of my comfort area.


----------



## VictorSpear (Oct 19, 2011)

Brandon,

I'm sure opening a simple tcp/Telnet socket to each loco would'nt be very useful besides manual checking/testing once in a while or for pushing a file or two. In production you may prefer to use it for remote troubleshooting like the field technicians do and not for persistent comms ? You wouldn't want to build a whole app based on telnet connects. Inherently you are now looking at a point-to-point protocol besides the issues that require an always-on socket could constrain you to be track power always, since you wouldn't have the low power wake/sleep mode for battery ops. With websockets gaining based on the IETF adoption it offers a better point-to-multipoint approach and should soon be a standard in all browsers. I've used *phpwebsockets *for this with switching/lights and prefer node.js+socket.io - but you still need to build the management gateway to handle socket crashes, dropped sockets/auto reconnects, daemon and polling feedback, broadcasting,..... The wss forums are full of these issues so it would be good to check the specific use cases you may be adopting.


Since your controller will need to manifest as a client and you now need a 'server', the interesting use case would be to send only the right feedback from the right loco to the right controller (assume 2 guests) and this means parsing and introspection of the incoming messages. Testing with 2+ locos running is where the work is. Some msgs will need to be ignored, some acted on and some relayed. And this means you now need a PC for the server ! There are few who have built a whole business around Wsocket gateways - Kaazing and Pusher to name a few. You may want to check the features that they claim they are providing and issues they are addressing.


In fact your work may have just started  For example, If you are using DHCP, and you most certainly have to if you plan on 'guests' who don't know your network, you will need to broadcast the server's address using avahi/bonjour for zero config...or ...are you planning something else? 



Cheers
Victor


----------



## Brandon (Jul 6, 2011)

Telnet would be for debug/testing, not normal operations. Since the locomotive is headless it's nice to have a quick way of getting into the program to check stuff and it's not too difficult to support this.

Normal communication between client/server will be a simlpe tcp socket. I considered REST and others but that's something new to me and I read up some on it the other week and decided (don't recall why) it wasn't the best choice for me personally. 

It will be interesting to see what the power usage is, the r-pi isn't exactly power friendly like a revolution or arduino. ... Actually, since you know circuits well, is it possible to use large capacitors to provide power for moving a locomotive about 2-3'? I'd actually go track power and avoid batteries if I could have a dead section of track in a reversing loop that's longer than a locomotives wheelbase.


For handling connections between locomotive clients and server(s) my approach is to allow many servers connect to a locomotive. This way a server could be monitoring the position and stats of a loco and controlling its movement but if someone wanted to take manual control, upon a new server issuing a command, the server that was controlling the loco would be notified something else had taken control and the server would wait for it to be assigned control back before it started issuing new commands. This would allow any number of people to control 1 locomotive at once and when someone else took control the person would get feedback that another person/server had issued commands.

A PC shouldn't be needed, I plan on making it possible for a single r-pi to run a client and server. In my setup though, I will likely have the r-pi that's controlling the switch points run the server for various reasons. 

I looked at phpwebsockets but it didn't appear to support the newest 76 standard and I couldn't get the example server to work. I figured I'd tackle that in a few months in case the standards were more set by then. I know web sockets will have a lot of growing pains and I have other things I can work on until then.  Hence a telnet socket.


I know I've just started, but I've made faster progress then I was expecting. For under $100 I do have a 'linux' enabled locomotive that I can tell it to move or play any sound I want, not bad for a few hours of work.  

The r-pi's will be dhcp but I've yet to decide how to do communication. I may hardset the network on the r-pi's to attach to a "train" ssid and dhcp and use upnp or something to detect trains. Worst case I require the aRail server to run on a set ip of 192.168.0.199 by default unless someone wants to ssh in and change the default server IP. No upnp or other things that may have problems with weird router setups. I'll take a look at avahi/bonjour, those are new to me but I have a guess what they do by your comment and those may be a good option. I may need a way to pull data rather than drag-n-drop via a smb server for updates, though I'm not sure yet what data will need to be pulled that handling over a tcp socket wouldn't solve itself.


I think the next project piece I'll be putting time into is the mechanism to learn a railroads rfid tags and switch points so the server can auto populate data about the railroad. I think this should expose design problems the quickest.


----------



## VictorSpear (Oct 19, 2011)

Hopefully you will use SSH/22 at least instead of telnet, even for debugging. You don't want to expose open telnet/tcp ports (especially telnet, circa 1969) in your garden railway - no fence would be high enough for the kids to climb up. How are your tests faring with hanging all those peripherals off the r-Pi's usb host given the rating it has ? I'd be interested to know if you got the Alsa to dmix for polyphonic (chuff,bell,horn,pumps...) while simultaneously throttlling the pololu driver+ trigger the rfid reader and pump the smoke. What does 'top' display for the kworkers and is it swapping ? How many threads ? Which Wifi dongle are you using and does it suppor the ad-hoc? Did you rebuild the squeeze ?

Best.
Victor.


----------



## Brandon (Jul 6, 2011)

I don't have plans for any sort of ssl atm but if there becomes a need it can be added later without much trouble. If I were to use ssl for any communication it complicates network snooping for debugging and would require more processing power from the r-pi. I just don't see the pro's outweighing the con's, especially right now. For myself I run 6 vpn's at my home, 2 are for wireless and I'll add a 7th for the railroad. If someone wants to take the time to break wireless encryption just to hi-jack a train then I won't stop them, I'd laugh, re-image the sd cards and then consider ssl at that point. 

People can always hop a fence but there's 9 ip cameras around my property and if they wear masks, break into the train shed which will be tied into the home security, and get away I'll just call it a bad day and move on. Security is an idea, if someone wants something enough and has the resources you can't stop them, physical or virtual... 

Tests are going fine, I have the rfid reader and pololu connected to the r-pi however I haven't tested what ma is being pulled but I'm only using a 1A usb source. I've heard reports of the r-pi using 300ma-500ma depending on load and the rfid should be 80ma during read and the pololu I have no idea, wifi dongle should be about 60ma during tx/rx. The only thing missing is the audio amplifier which is running off the BEC so it won't ever put a load on the r-pi. 

I haven't played with alsa/dmix much since I've found a pretty big alsa bug that renders the driver dead until you reboot. Once that gets fixed then I'll play with alsa and dmix again. I'm currently using wav files for sound but there's no reason I couldn't use a frequency generator in dmix for sounds but right now it's pretty easy to use sound samples from openVBE for testing ATM. This does mean I'm not making engine sounds and adjusting the frequency of the wav depending on engine speed. Yeah, there's a lot still left to do for sound... I'm a bit dissipointed in what the pololu reports, you only have vin from the power source but the pololu doesn't report vout to the motor, you only have a value from -3200 to 3200. The JRK give you current and integrates with rpm counter electronics but they're double the cost. I'm kind of waiting to see what your experiments show for tracking...  

The r-pi isn't a speed daemon but it's more than enough for what either of us would be doing. The slowest point is disk access but I'm using a class 4 and plan to get a class 10 to hopefully solve this w in vim takes about 3 seconds). 

top - 18:45:40 up 49 min, 1 user, load average: 0.40, 0.33, 0.32 
Tasks: 63 total, 1 running, 62 sleeping, 0 stopped, 0 zombie 
Cpu(s): 0.3%us, 1.0%sy, 0.0%ni, 98.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st 
Mem: 190836k total, 57588k used, 133248k free, 7780k buffers 
Swap: 0k total, 0k used, 0k free, 31392k cached 
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 
1051 pi 20 0 2608 1164 932 R 1.0 0.6 0:00.13 top 
1041 pi 20 0 9480 1512 980 S 0.3 0.8 0:00.09 sshd 
1 root 20 0 2076 712 620 S 0.0 0.4 0:00.63 init 
2 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kthreadd 
3 root 20 0 0 0 0 S 0.0 0.0 0:00.04 ksoftirqd/0 
4 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0 
5 root 20 0 0 0 0 S 0.0 0.0 0:00.05 kworker/u:0 
6 root -2 0 0 0 0 S 0.0 0.0 0:00.48 rcu_kthread 
7 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 khelper 
8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kdevtmpfs 
9 root 20 0 0 0 0 S 0.0 0.0 0:00.00 sync_supers 
10 root 20 0 0 0 0 S 0.0 0.0 0:00.00 bdi-default 
11 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kblockd 

Bogomips are about 700, decent for the price point. 

wifi dongle is an old linksys a/b in b mode I had sitting around, it won't be what I put in the loco. 

Not using ad-hoc. 

Didn't rebuilt squeeze. 

I'm still curious on your EE knowledge if there's an inexpensive way of being able to power a locomotive for 3+ seconds, can caps provide enough power for running trains this long or do you know of a solution for what I mentioned in my previous post?


----------



## VictorSpear (Oct 19, 2011)

There's plenty of inexpensive SuperCap variations you can implement. Price is a factor in some designs, but how do you know your cap 'holdup' critical time will be only 3+ seconds in the dead spot ? normal load operations? What about the loco in front that's holding you up  

The dmix is not enabled by default in some embedded dists. 

When you find time: It looks like the ToPs you posted don't appear to have your 'Perl' scripts running ? Can you set it to loop spin the Pololu at fast varying pulses simulating an up throttle/down throttle continuosly ? With the pololu being polled you should see just for that pid, CPU at 9-20% with that Perl process. Then toggle all the other functions including lights in 500ms cycles. You may find it useful to get these readings in the early stages and watch that loaded usb host approach the 500mA draw. When does the polyfuse trigger and with what peripherals strung ? I feel you will need and should switch instead to a powered smart-hub as a colleague smoked his Pi recently. Regarding the Vout fdbk - that's why they called it the pure and SimpMotCtrller 

Cheers
Victor


----------



## Brandon (Jul 6, 2011)

Okay, did a little reading up, so 1J = 1W/S and considering an SD-45 can use up to 40 or so Watts and a battery the size of a C cell is .6J I don't see how it's possible to use capacitors to power a locomotive for 3+ seconds, you'd need about 120 C battery battery sized capacitors and that won't fit in a locomotive... As for knowing it should be 3 seconds, if I know where the dead track section is and all locomotives are location aware I can keep them from 'sitting' in those areas but you're right, 3 seconds may not be enough but 10 seconds should be more than enough to travel 2'-3'. 

I was running aRail, here's another top where it actually hits towards the top for cpu usage: 


asks: 69 total, 1 running, 68 sleeping, 0 stopped, 0 zombie 
Cpu(s): 7.2%us, 2.3%sy, 0.0%ni, 90.2%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st 
Mem: 190836k total, 80844k used, 109992k free, 9948k buffers 
Swap: 0k total, 0k used, 0k free, 43708k cached 

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 
1225 pi 20 0 2708 1168 932 R 1.3 0.6 0:00.29 top 
1206 pi 20 0 10520 6616 1948 S 0.6 3.5 0:02.60 aRail-Client.pl 
1138 pi 20 0 10240 1608 988 S 0.3 0.8 0:00.89 sshd 
1 root 20 0 2076 712 620 S 0.0 0.4 0:00.95 init 
2 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kthreadd 
3 root 20 0 0 0 0 S 0.0 0.0 0:00.12 ksoftirqd/0 

I'm use io:select for sockets and rfid input which is very effecient and I am poling the smc via SmcCmd -s which uses mono every 2 seconds. The r-pi really has quite a bit of processing power and I'm not using any of those perl modules that help with threaded apps at the cost of overhead. 

Here's a top with SmcCmd -s running: 

top - 22:05:18 up 3:22, 3 users, load average: 0.30, 0.30, 0.24 
Tasks: 69 total, 2 running, 67 sleeping, 0 stopped, 0 zombie 
Cpu(s): 8.8%us, 1.6%sy, 0.0%ni, 89.3%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st 
Mem: 190836k total, 81340k used, 109496k free, 9948k buffers 
Swap: 0k total, 0k used, 0k free, 43708k cached 

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 
1884 pi 20 0 6064 2200 1532 R 8.2 1.2 0:00.25 SmcCmd 
1883 pi 20 0 2708 1168 932 R 1.3 0.6 0:00.10 top 
1151 pi 20 0 9480 1512 980 S 0.3 0.8 0:00.06 sshd 
1 root 20 0 2076 712 620 S 0.0 0.4 0:00.99 init 
2 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kthreadd 
3 root 20 0 0 0 0 S 0.0 0.0 0:00.13 ksoftirqd/0 
5 root 20 0 0 0 0 S 0.0 0.0 0:01.04 kworker/u:0 
6 root -2 0 0 0 0 S 0.0 0.0 0:01.37 rcu_kthread 

The SmcCmd -s takes about 2 seconds to return because of how mono has to build the environment each time. If this becomes resource intensive I can use the smc usb libraries for more effecient control or just modify the smccmd source to hack a little program that writes to a file ever .1s with device stat so mono doesn't have to load the environment all the time. So in short, I have a lot I can optimize but there's no need yet other than improving the program in general. 

I don't have lights working off the gpio pins (I'm waiting to do work on gpio pins until I get someone to verify the circuit I posted to make sure I'm not missing anything (fuses or other stuff to prevent damage) and until I have several r-pi's on my desk in case one gets fried. I'll stick to software/rfid/motor control where it's unlikely I'll damage a r-pi until they're not back ordered for 2 months. 

I do plan on using a powered usb hub, maybe sooner than later, the model A only has 1 usb port which gives me no choice when that comes out... Also I don't plan on stress testing the r-pi's polyfuse.  One reason I went with the pololu is it has quite a bit of design in it to reduce the changes of frying the usb port/host computer if something went wrong vs using an RC boat or car ESC which I've had fry receivers when they go bad in my model planes. My r-pi probably has been up for more than 100 hours with no signs of any problems at all with all the devices connected. 

Yup, simpleMotorController. Just keep up the good work on your tachometer..  I'm still waiting for you to find a lens that would allow an ir or laser mouse to be used for tracking movement.  Or something else sub $10 that doesn't require attaching to a motor shaft.


----------



## VictorSpear (Oct 19, 2011)

Okay I simply thought you were looking to keep the Pi powered and the socket/wifi dongle on during bad spots ? If the wifi bounces, your 'tcp socket' is gone ethereal, then all control gone. Then the Pi reboots. What is the reboot time anyway ? Angstrom is planned 10 secs, actual 13 to 18 by the time all interfaces are up. Anyway there is an error in your calc for the SD45 for 3 seconds holdup - Will send you a simple rule-o-thumber later.

Also finally see the expected 8 to 9% of CPU in the TopS but the single SmcCmd at 2 seconds round trip is not real world! An ipod touch slider for example can request 128 speed steps in 0.25 seconds and some ordinary digital pots about the same. Messages will simply flood in the socket queue while waiting for SmcCmd. You may see 18 to 22% even optimized, so this should give you the reason to do the CPU load simulating if you are considering forking other processes like tach, synchronized sound loops, updating the handheld display in real time....I agree you still will have HorsePower though.

Cheers
Victor


----------



## VictorSpear (Oct 19, 2011)

A simplistic checker for UltraCap sizing. Change to your requirement and overestimate. Commercial offerings with safety and protection circuits + temp sensing cutoff are still expensive and may not fit your needs.











Cheers,
Victor


----------



## Greg Elmassian (Jan 3, 2008)

top - 12:27:52 up 53 days, 17:51, 15 users, load average: 0.35, 0.45, 0.41 
Tasks: 2517 total, 1 running, 2516 sleeping, 0 stopped, 0 zombie 
Cpu(s): 0.5%us, 0.2%sy, 0.0%ni, 99.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st 
Mem: 198332588k total, 187589632k used, 10742956k free, 275372k buffers 
Swap: 204799992k total, 121496k used, 204678496k free, 161008896k cached 

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 
1 root 20 0 19328 1244 956 S 0.0 0.0 0:05.61 init 
2 root 20 0 0 0 0 S 0.0 0.0 0:00.44 kthreadd 
3 root RT 0 0 0 0 S 0.0 0.0 0:00.83 migration/0 
4 root 20 0 0 0 0 S 0.0 0.0 3:08.40 ksoftirqd/0 
5 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/0 
6 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/0 
7 root RT 0 0 0 0 S 0.0 0.0 0:00.14 migration/1 
8 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/1 
9 root 20 0 0 0 0 S 0.0 0.0 0:29.03 ksoftirqd/1 
10 root RT 0 0 0 0 S 0.0 0.0 0:02.94 watchdog/1 
11 root RT 0 0 0 0 S 0.0 0.0 0:00.14 migration/


----------



## VictorSpear (Oct 19, 2011)

Plenty of capacity here to run JMRI+MERG+Amtrak+.... . What is the server used for ?

Victor


----------



## Greg Elmassian (Jan 3, 2008)

Runs everyday inventory, sales, accounting for our company. Bought it recently. IBM unit with 4 10-core Xeons, and a s-load of ram... there are two 640 gigabyte high iops SSD drives... access time is 0.4 milliseconds 

Just having some fun, about a $70k machine. 

Greg


----------



## Brandon (Jul 6, 2011)

I wonder if I still have stat dumps from when I did software integration for some clusters... Back in the late 90's it didn't matter that a system only had 2GB of ram when there were up to 1024 nodes in some of the clusters we built for customers. I don't miss all the cross wiring on the Myrinet controllers though... Kind of funny to think too that they net booted off of 3.5" floppy drives, no SSD back then...


----------



## Brandon (Jul 6, 2011)

So an update on aRail... 

I've done a bit more work on the client. Most work follows the 90% takes 10% and the last 10% takes 90% of the time. 

All functionality for the pololu speed controllers and setting the dozen or so limits and making it work seamlessly to someone on a frontend is completed. Setting adjustments can be done via telnet or editing an XML. Save/load of xml configurations for both the locomotive and other hardware is done too. There's also a tool that auto configures a new pololu smc to useful specs built in. 

Tonight I've been working on light controls. With this has come a bit of redesign of the client to mainly move data from being in a session (gone on reboot) to being stored with locomotive data (ie, if you power down a locomotive and turn it back on, it knows you had certain lights, sounds, and other aux functions set certain ways. I've also written a test function to test lights, couplers, etc for debugging yet will bypass things like couplers if it was known to be connected to cars when it was last powered off to reduce the chance of decoupling cars during a test. 

I expect to have all the logic for handing lights, sounds, and movement finished so if you request to start movement or change directions the right lights and sounds get played before the train actually starts moving. I also have a second r-pi in transit to help development of the server and keeping locomotives from colliding. 

I haven't yet ordered any breadboards or parts for an inbetween board that will connect the r-pi to the dcc headers on aristo locomotives, I'm still trying to learn EE and don't trust myself yet at all to handle this. I'm also putting it off in hopes that someone much more qualified than me might take up this project.


----------



## Brandon (Jul 6, 2011)

Finished gpio work on the r-pi for lights, smoke, and couplers. I've coded in two types of ditch lights, one relies on a low side connection for on and a second for fading and the other method controls a left and right ditch light directly. USA trains would use the first method as their ditch lights are circuit based for cross fading and other others would use the second method as ditch lights require a modification of locos since aristocraft doesn't support cross fading ditch lights. Both work well I might add. 

The client(loco) now starts and goes through a test phase (lights, sound, couplers, etc) on 'boot up' and then gives a short horn blow to indicate the loco is ready for control. The state of a loco can also be saved between sessions so if you leave a loco in a certain state, when you go out to run the railroad again the loco knows where it left off, what functions (lights, smoke, etc) were being used previously and it resumes where it left off. 

I'm going to have to think what the next thing will be. There are still some sound issues on the r-pi that I'm probably going to wait for others to debug and solve so now I'll be back working on the server side to write the 'learn the track' code and running the locomotives. 

Still looking for an ee guy to give some comments on circuits and such...


----------



## IPTRAIN (Jun 1, 2012)

Hello Brandon

I was very encouraged to read your articles on using radio mobile technologies to replace legacy DCC technologies - time has come now for a paradigmen change.

Actually, I am working since 2010 implementing TCP/IP technologies via WiFi to control my GardenRailway. See some movies on Youtube below:

WiFi controlled GardenRailway (by Google G1 - Android) - 2010


.... with Ditch Lights implemented 


... with Battery Backup, Decoupling and Macro Programming ("Learn Functionality" - train the Loco - it will repeat inifinitely) 

Connection is set up via TCP/IP (Telnet) - either in ADHOC or INFRASTRUCTURE Modus. 


In Germany we are now a Project Group (40 people) who have identified a supplier producing the technology we need according to our requirements. 


We have just got the prototypes back to test - having been successfully approved last week! (MC Board, Motor Driver Board, LED Driver Boards via TWI or direct, Step Down Transformer, WiFiBoard (not visible on photo), etc.)


----------



## Brandon (Jul 6, 2011)

Very cool. Do you have any specs listed somewhere? Trains don't need much cpu power, the r-pi is overkill but I'm sure I can put the wait cycles to use on video or something else, time will say. 

How many amps on the motor controller, does it do BEMF, what sort of oops protection does it have? How many ma do the led circuits support, how many accesories, smoke units and so on? Any links to software and/or api for it? I wouldn't mind helping and using other projects, but location awareness is mandatory in my end goal...


----------



## IPTRAIN (Jun 1, 2012)

Hello Brandon,

thank you! - Yes, you're right! To support Streaming from the Lococ ARM technology is the right recommendation. This is not supported yet - we have to swap the MC-Board therefore. This is not real problem, as our approach is highly modularized.

The motor controller is able to do fairly 12 Amps permanently and 150 Amps Peak! What stands BEMF for?

It is protected against shortage and overtemperature - faults are signaled and can be resetted. It is motor driver technology similar to Pololu (but it is rebuild - not originally - not copied, but half the price







!!!)


We can do 0.5 Amps each LED output (MOSFET technology) - 16 output are per IC provided - we can address 4 of them on the I**C Bus. So we cann address 48 LEDs with 255 steps of brightness each - independently.



A fancy Proof of Concept from a Dashbord implementation. The LED chaining is Software driven. 


The MC board provides 54 Input/Output Channels on 6 ports - free to configure. Amps for accessories depends on driver boards you're using. One driver board is ULN 2803 based (8 output channels), 1 Ampere each For smoke (24 Volts this should be sufficient). 



We have 6 PWMsources - we need 2 for Decouplers, 2 for the motor controls (one per truck ond double trucks) - each is controlled individually as we use Hall Sensor technology in the gear box to measure the motor rounds per second. 

So we can synchronize 2 motors in a loco als when they vary as to production tolerances.In addition we are going to implement control algorithm which will allow to synchronize a pulling Locos with pushing Locos at the end of the composition whithout risking a derailment on long trains.Of course we synchronize via WiFi as each Loco is equipped with a WiFi receiver.

Another 2 PWMs are available for Pantograph control - just an example. 


It is our goal to provide a full electronic component set as shown before at a street price not more than 99 US- Dollar a Loco - fully WiFi and funtionally equipped.



At the moment we have arrived at a 150 Dollar level - most expensive the WiFi module. But using ARM technology we can use a WiFi USB Dongle - than 99 US Dollar is reality.











Regards, 

Karl


----------



## Brandon (Jul 6, 2011)

BEMF = back EMF. Basically the motor controller cuts power to the motor for a very small amount of time and reads the feedback the motor gives (as it's now a generator) to determine the speed of the motor. Back EMF is used on many model railroad decoders but not on the pololu. 

I imagine the motor controller and all modules are i*c bus based? 

$99 per loco was my goal, I'm about $90 for the r-pi, pololu, sd card, usb wifi dongle, usb hub, usb rfid reader, BEC, speaker amplifier and I was hoping to finish the lighting and smoke board for under $5. Then there's the battery cost on top of that which varries. 

You're only missing the ability for a camera and I also am curious what you're doing for sound and speaker amplification. 

Is there a website with more information on this project and possibly source code? It's too bad that I've about finished (I use this term in the sense of features and not in all possible polished software ideals) the aRail client but if you have a platform that can do everything I need I'd be willing to jump on board and do development to it if it helps out you and myself. Like I said before though I'd need to be able to read rfid tags and the cheap readers are usb keyboard input types.


----------



## IPTRAIN (Jun 1, 2012)

Hello Brandon,

I would say, in some points you're ahead - especially related to usin ARM technology already. 

No - we are not using BEMF, we only sensor by Halls Sensors the RPM of the motors. 


As a possible sound engine we consider this one: Cost are 5 - 6 US-Dollar each - purchasing a lot of 100 pieces - not a problem . Sound size is not limited - as to the use of SD-cards.


The idea of RFID tags I am also pursuing. There is an Japanes ingeneer who holds a patent on this - but in a reverse application: The sensor is fixed in the track, the tags are glued to the locos. I thinks the reverse order is not covered - he has forgotten to request this patent, as in those times the WiFi technology (Back Channel) was not available for him. I have identified a cheap board (RFID Test Board to get experience) to do some research how to integrate this technology in our project at best. The readers code can easily be implemented - also OpenSource code is available - as to my recollection.



Unfortunately - up to now, all documentation is in German. At the moment I have no chance to translate - need to drive the project as all other people are waiting for me. We are going to "WiFi modify" a so called "Swiss Crocodile".


----------



## Brandon (Jul 6, 2011)

Not a bad price for that audio controller, too bad it doesn't have an amplifier built in to power a typical G scale locomotive. 

I really should learn German... Unfortunately us Americans are a bit behind in the idea of multi lingual during early education. If the docs are german I can babelish it and then refer to a friend who is German for translating the rest. 

Even if there's an api or tcp socket calls are based around I could at least go back and see if I can't make mine compatible that way. I could then write the server to work with both our systems. Not a promise but I'd be willing to take a look. 

My project isn't anywhere except an SD card and backups to server in another physical location that I often backup some items to that I wouldn't want to lose. I could forward it over, there's not much to it yet, especially the server stuff. Send me a pm with your e-mail if interested... I'd publish it somewhere else but it's not done enough for non-developer eyes and if no one is really working on it except myself then it's not worthwhile yet to maintain a code repository for it.


----------



## Brandon (Jul 6, 2011)

More polishing of the client. It now goes through a startup sequence, blinks lights, plays horns and so on as it's initializing. 

Also I've completed most of the learning intelligence for aRail-Server. Just tell the server to go into learning mode and specify the mac address of the loco you want to use and it runs and detects all the rfid's, track, and organizes it all including detecting switches (if you change the switch while it's running). The learning code has a code segment I'm calling my 'flux capacitor', I had started some really complex stuff for learning and suddenly it hit me and it can learn any track regarldess complexity and keep track of paths in about 15 lines. Also if the train is entering an end of line just press enter and the train changes directions and marks the segment EOL (also useful for making a loco go down a new switched route but it knows if it's at EOL passing a segment it already knows about but in reverse direction or if it's a new path off a switch (including 3,4,5, etc way switches). 

I still have yet to write any code for automated train running (just manual control right now) or support for adding things like max speed limits to some areas, clearance data, whistle marks, stations, coal and other loading/unloading zones etc but the framework for all this is there in the data structures. 

Of course saving/loading all data is already done, so you can load up certain railroad personalities (day, night, certain route sessions, etc).


----------



## VictorSpear (Oct 19, 2011)

Are the loco ditch lights just blinking on/off or gracefully cross-fading with PWM controllable duty cycle ?

Cheers,
Victor


----------



## Brandon (Jul 6, 2011)

Victor: The ditch lights for aRail will support three methods. Using capacitors and 1/0 and controlling each side independently, controlling each side via PWM, and controlling on/off and a separate circuit that pwm flashes(this is what USA trains has their circuits wired to do). 

Just an update on the project: 
All the learning code is done for the server. 
You can now create consists and add locomotives and cars 
* When specifying cars you just say how long a segment of cars is and it's position in the consist (0 for beginning or 1 behind a single locomotive pulling the consist) 
* When adding a locomotive you specify the loco's mac address, position in the consist (0 for lead of train, 1 for second slot, and say 5 for a mid-consist loco and 9 for a trailing locomotive), and if the locomotive is facing forward or backward. 
* Calculation location by rfid is combined from all locos that report rfid since each location of rfid can be calculated for a consist. 
Support for running consists (Limited to the same types of engines (I don't have any AI in yet that auto varies power levels for each loco depending on gearing and load yet) 
Locomotives report status (in consist, if the consist is in "setup" mode it flashes the forward direction light so you can make sure they're all going to run in the same direction.... good thing right... 

Next steps will be to run consists and work on avoidance logic. To be honest, I'm not sure when this will happen. I'll start laying track next month and I'll probably be waiting until I have track laid and RFID tags in place. I have a test track setup but it's kind of boring since it's so small, I can't exactly run 5 trains on 1 track. Also the raspberry-pi's are still back ordered. I had 2 until a couple days ago when a friend needed one badly for a work project of his. It won't be until Late July or August before I am likely to get another. 

On the same note of hardware, I've been quite impressed by this: http://www.ringengineering.com/RailPro.htm I spoke with the owner the other week by phone and he does have plans for G scale in the next year. Faster if he gets more requests as he does 'what people are asking for' and he's got an accessories module he's finishing up for the next couple months. Also, this device can (and he does for development) control it via a usb RF dongle. He is considering making an API available soon as well. What impresses me the most about this setup is the cost, the design, and the consisting. It auto-load balances locomotives regardless of gearing or voltage require. If he produces a G scale radio and usb dongle I'll write an API if I have to for myself so I can run it from his handset or have it run via a computer and AI. No sense trying to build up hardware myself if he has a solution that's the same cost and better suited, though I'll miss no "Linux Inside".


----------



## Brandon (Jul 6, 2011)

After about 2 years, my layout is nearing completion so I'm back to looking at moving forward again with development.

Hardware has not moved forward much which caused me to debate on reversing engineering the Revolution and adding an i2c or spi rfid reader to their receiver or rolling my own hardware. I changed jobs recently and am the only software developer on a team of 12 zigbee firmware engineers so it would only be a couple hours to have all revolution RF transmissions sniffed, probe out the hardware bus communication and disassemble a board and get all the details. This would let me know if they're doing uart to i2c (very likely on a small board like this), spi, or some other method. We know the new receivers store sound so it could not be doing direct uart i2c communication. In short a few guys want to pull a revolution apart just to see what someone did with the TI zigbee chip.

The other option is still the Raspberry Pi. It's actually going to be cheaper to do the Raspberry pi and you get a lot more functionality at the cost of a higher wattage (couple hundred micro amps). Right now I'm looking at the Ri-pi model A, pololu motor controller (far better than the Revolution as well), sainsmart relay for smoke/led, spi rfid reader, a usb wifi dongle and an SD card in total come to $85. Did I mention the Ri-pi model A also has a camera?  What fun would that be to have what the loco see's on your phone display...

For the server/controller I'm doing clippard solenoids, sainsmart relays, ri-pi model B and a pridopia 32 channel i2c gpio board to control the solenoids. 

Mostly all straight forward with libraries for everything already written. I just need to get the layout finished and pneumatic switches installed so I can start developing on a working layout and let the development continue...


----------



## Martan (Feb 4, 2012)

The Pi is an expensive solution for a locomotive node, not to mention kind of large physically. A single micro controller and an Xbee series 1 gives you 802.15.4 bi-directional wireless, servo control, mosfet/relay control and input sensing (for RFID, speed, current, temp, etc) in a much smaller footprint. Also, by supporting servo control pulses, you can use a cheaper ESC instead of the Pololu.


----------



## Brandon (Jul 6, 2011)

I don't follow your comment. A xbee radio is $20 alone and shields are at minimum another $10 with a good one around $25 making xbee a higher cost with less functionality. At $25 for the pi, which for me makes development easier, faster and nearly unlimited future features, it works pretty well, but all the support could be done another way too, just preference... and if you do an xbee based system for a locomotive let me knits and I'll try one out. 

One thing too that people don't know is xbee is not very reliable. It also does not do well with changing signal strength(ie moving trains) and and using repeaters isn't a solution as you can't force packets to take a specific route by the protocol spec design. Point to point it's okay but I do software development for zigbee and basing my choices based on ten years of company experience.  The revolution uses a TI zigbee chip and they still haven't worked out all the quirks that come with the protocol on real world implementations but wifi is more refined imo.

The reason for the pololu motor controller (NOT an esc) is it has far better precision and ramping than any esc I've seen so far. If you know of an esc that can do scale 1mph crawls let m know! So far all car and boat esc's I've used in my other hobbies are far from acceptable.


----------



## VictorSpear (Oct 19, 2011)

Au contraire - we have had good results with Xbee mesh on the high seas with man overboard conditions and stormy 7+ feet wave heights plus the rescue watercraft moving at very high speeds in all directions. 

Point-to-point as in the simple wifi models is not the ideal Use Case for Xbee or Synapse if not using its low power/sleep optimization capability in the hover/mesh mode. So the design configuration is important to look at for best results. No size fits all.

VIc


----------



## Martan (Feb 4, 2012)

Pardon my tone if it seemed abrupt. Just seems like an expensive solution. From Mouser, the Xbee is $19 and an Attiny 1634 SOIC is a buck and a half. Of course there are a few extra dollars for sockets and the boards but it still clocks in at about $25. As far as speed, turning off the ACK gives me 7ms packet times for 25 byte payloads. This results in very smooth servo control. But whatever works for you...


----------



## Brandon (Jul 6, 2011)

Nice thing about Moores law is that if it takes you a few years to finish your railroad, technology improves. I thought I'd post that a few weeks ago I signed up on the kickstarter for C.H.I.P. It's a 40mmx60mm in size, has 1ghz CPU, 512MB ram, 4GB SSD, wifi,8 pin gpio, usb and camera ports. As you can imagine this is exactly what I'm looking for, minus a motor controller. The two missing items are the RFID or NFC chip (for location management of a consist) and a motor controller for movement, but the board can do SPI and i2c or these two devices could be run off of USB.

Anyway, it's nice to see size and prices dropping. Even using a $34 pollolu motor controller each locomotive would be under $50 in hardware to run now, compared to about $90 that I was looking at a couple years ago.


----------



## Martan (Feb 4, 2012)

Yes, I like it too. Xbee series one is down to $17


----------

