Wirelessly controlled model train network feasibility

I’m currently planning a model train layout and need some advice before I start buying parts. There will eventually be dozens of locomotives, so I must plan for that. I know that this is a fairly in-depth idea, so I’ll lay out the framework of what I’m trying to do first… The main thing I need help with is to figure out how to control the trains wirelessly (see #5).

Each locomotive will have the following:

  1. A teensy 3.6 + prop shield - this is necessary since it is (as far as I can find) one of the only boards with polyphonic audio support from an SD card, which is important for realistic sounds. I plan to use the 3.6 instead of the 3.2 because it has support for three I2C devices, three SPI devices, and it has a built in SD card.

  2. 11.1V lipo battery + 3.3V DC/DC step down for teensy and 12V DC/DC step up for motor (step up depends on train’s motor, may not be needed)

  3. Motor controller (such as this http://www.robotshop.com/en/10a-5-30v-dual-channel-dc-motor-driver.html) will vary based on the engine, but the premise is the same since it will be used in conjunction with the prop shield’s motion sensors to control the speed of the locomotive.

  4. RFID reader such as the RC522. This will allow the locomotive to determine its location by reading RFID chips placed around the track. In theory, the locomotive could be scripted to do certain things at specific locations (such as blowing a whistle at a crossing or following speed limits).

  5. Wireless controller. This is the part I need assistance figuring out what to use… The wireless controller on each locomotive must be able to interface with a central controller separate from the locomotives (could be a PC, android phone, or another teensy). The central controller would constantly read RFID values from each train on the layout so that it can send movement instructions. The central controller would ideally be able to tell each engine to reach a certain location on a loop of track by having it move until it reads a certain RFID value. It must also prevent collisions by telling trains on the same loop to stop, slow down, or divert to a siding if they are within a certain range of another train (distances between the RFID readers could be measured and hard coded into the central controller so that it can calculate collision risks). The central controller must also be able to send out manually inputted commands which should be the most straightforward of these tasks. Clearly, this central controller’s job could get quite complicated with two or three dozen trains running, so I think it would be ideal to run it off a PC if possible. TL;DR the central controller (pc, phone, or teensy) must be able to constantly read and write values to several dozen wireless devices (one per train).

Q’s
I know there are multiple methods of wireless communication such as Bluetooth, Bluetooth LE, wifi, and radio. All of this will likely occur within a 4000sq ft space, and all of those methods should work within this range. I am thinking wifi would work best; I know that multiple devices can be connected to a network unlike Bluetooth which requires pairing and radio that requires specific signals that may interfere easily. So, what would you all recommend looking into for this? Xbee, Zigbee, esp8266? I do not have any experience with wireless control and haven’t found any examples of such an extensive setup (most tutorials involve only two devices communicating between each other), so all advice is appreciated (even if you think its totally impossible to do what I’m trying to do).

Thank you for reading!

I am using nRF24L01+ transceiver modules for wireless control of battery powered 00 Gauge trains. I'm guessing you are using a much bigger Gauge but they should work fine. What Gauge are you working with?

The basics of the two-way wireless communication I am using are in the second example in this Simple nRF24L01+ Tutorial. I have an Arduino base unit connected to my PC and it can communicate with each of the locomotives in turn, several times per second.

I have considered using WiFi with ESP8266 modules (which have a complete microprocessor as well as the WiFi) but I have not convinced myself that they would be any better and I remain suspicious that they might not perform as well due to collisions between the messages from the different units or due to other WiFi activity in the area. Also, the programming of the WiFi stuff would be more complex than the nRF24 unless you are already familiar with web programming and, particularly, UDP.

I have no immediate interest in onboard sound but, if I had, I thing a small MP3 module would probably meet my needs. The big problem is acquiring the sound files.

And, while I have no interest in DCC myself, it is perfectly possible to use a wireless system to send signals for a standard DCC chip.

I have no experience of RFID but I wonder if it is necessary to remain stationary, or nearly so while detecting a chip. My plan is just to put Light Dependent Resistors (LDR) between the sleepers that will be triggered by a train blocking the ambient light. The PC should be able to figure out which train it is as it will have set the route.

...R

Hey Robin, thanks for the response so soon! I completely forget to mention it, but I am using O gauge, so there should be plenty of room for this stuff. 00 is similar in size to HO, if I remember correctly - that would certainly be a tight fit!

The nRF24L01 looks very promising, thank you for bringing that device to my attention. From what I can tell in your tutorial and some videos I just watched, the coding seems much more straightforward than anything else I've looked at. They are so cheap on amazon, it's like 10 for $12! If the central unit can communicate with each locomotives several times per second, that should be more than enough. Now, you did state in your tutorial that they are limited to 6 pipes, so I would assume that means you are only able to listen to 6 locomotives at once? That's not bad, even if I needed to have a couple hooked up. If I understand correctly - with the teensy's 3 spi ports, I could have 18 engines running off one central teensy controller.

For the RFID reader, I did watch this tutorial on the RC522 specifically (since its super cheap) First Look: RC522 RFID Reader/Writer ($4 on eBay) - YouTube
It appears as though the reader picks up the UID rather quickly. I found this article which seems to indicate that RFID technology can pick up 300 tags/second, though I am skeptical that this would apply to the RC522... Products & Solutions | HARTING Technology Group

As far as sound goes, you are very right about the difficulty in finding sound files! I had almost given up on the idea until I stumbled upon this motherload a couple weeks ago: https://retired.sounddogs.com/results.asp?Type=1&CategoryID=1053&SubcategoryID=43
The low quality versions sound decent and are free, so I figure it's at least somewhere to start. My dream is to visit the N&W 611 in Roanoke and take some real recordings, if they would let me haha. There are already some very good sound solutions on the market, but personally I enjoy the challenge of making it my own and having full control over all aspects of the locomotive.

Again, thank you... I think that the nRF24L01 will work for what I'm trying to do.

Perhaps more than you'd want to bite off but, some make a hobby of building train horns

dougp:
Perhaps more than you'd want to bite off but, some make a hobby of building train horns

HAHA I think my car needs one of those for driving through Pittsburgh.

snowskijunky:
I plan to use the 3.6 instead of the 3.2 because it has support for three I2C devices, three SPI devices, and it has a built in SD card.

You are aware that I2C is a bus; you can hook up up multiple devices to one bus 'talk' to them individually using addresses. Similar for SPI, although that requires one extra line (pin) per device to select it.

sterretje:
You are aware that I2C is a bus; you can hook up up multiple devices to one bus 'talk' to them individually using addresses. Similar for SPI, although that requires one extra line (pin) per device to select it.

Ok, I didn't quite put those things together. I suppose this means I may be able to share the SPI/I2C pins used by the prop shield then.

Unfortunately buying the external SD reader is $10 anyway, so I think I might as well go with the 3.6, unless there is some advantage the 3.2 would have that I'm unaware of.

So wait, does that mean I would be able to talk to multiple SPI devices at once via I2C connections?

No, SPI and I2C are different buses.

Arduino SCL  -------+----------------+-------
                    |                |
                    |                |
Arduino SDA  -----------+----------------+---
                    |   |            |   |
                    |   |            |   |
                  +-------+        +-------+
                  | RTC   |        | IO EXP|
                  +-------+        +-------+

The above has a RTC (e.g. DS3231) and an IO expander (e.g. mcp23017) connected to the same I2C bus.

I have no idea what a propshield is; there might be specifics that make it require the complete bus for itself (although it defeats the purpose of a bus and I have no idea what those requirements might be).

snowskijunky:
Now, you did state in your tutorial that they are limited to 6 pipes, so I would assume that means you are only able to listen to 6 locomotives at once?

That is a common misconception. In fact I just use one pipe and can communicate with lots more than 6 locos.

I will expand on that if you wish.

...R

sterretje:
No, SPI and I2C are different buses.

Arduino SCL  -------+----------------+-------

|                |
                    |                |
Arduino SDA  -----------+----------------+---
                    |  |            |  |
                    |  |            |  |
                  +-------+        +-------+
                  | RTC  |        | IO EXP|
                  +-------+        +-------+



The above has a RTC (e.g. DS3231) and an IO expander (e.g. mcp23017) connected to the same I2C bus.

I have no idea what a propshield is; there might be specifics that make it require the complete bus for itself (although it defeats the purpose of a bus and I have no idea what those requirements might be).

Ok, thank you for the explanation. I just realized that PJRC has an SPI library which should be very helpful for dealing with this. The prop shield is basically just a board with motion sensors, gyroscope, magnetic field sensors, and an amplifier all on board. It does connect to the 3.2's I2C and SPI buses, but I think the necessity of this depends on what features of the board are being used.

Robin2:
That is a common misconception. In fact I just use one pipe and can communicate with lots more than 6 locos.

I will expand on that if you wish.

...R

Ok, but there is a dedicated pipe for reading and one for writing (1 and 0 in your tutorial) if I understand correctly?

If you would like to elaborate on that, I would certainty appreciate it! Your tutorial is already a fantastic start though.

Think of the pipes as 6 shelves onto which the mail for different residents in an apartment block can be placed. All the letters come through the one mail slot (the radio receiver listening on Channel N) and when they fall on the floor someone picks them up, looks at the name of the recipient (the address the message was sent to) and puts them on the correct shelf (the pipe that has been assigned the same address as the message) or shreds them if they are for a recipient who lives in another block (i.e. if they are for an address that is not assigned to any of the pipes on this nRF24)

The real purpose of the pipes is to sort incoming messages into different slots which can help with recognizing where a particular message has come from. Personally I would prefer to include an ID code within the message as that allows for many more than 6 sources to be identified. There are also extended ways to use the nRF24 in a network and the pipes may be an essential part of that. But the network system will be slower - it is intended for situations where some of the nRF24s are out of range and need to communicate via an intermediary.

Note also that the 6 pipes do NOT allow 6 messages to be received at the same time. If two or more nRF24s transmit on the same channel at the same time both messages will be garbled.

The way my second example uses the ackPayload system it is not even necessary to put an ID inside the message. The master sends a message to the slave and receives back data as part of the automatic acknowledgement. The reply can only have come from the slave the message had been sent to.

There is only 1 writing pipe (pipe 0) and in my examples I have used pipe1 for listening, but that is not actually necessary. I could have used pipe 0. The way I did it reflects my journey of learning about the nRF24.

Hope this makes sense but feel free to ask more questions.

...R

Just wanted to say thanks again and that I just recently got everything hooked up, your demo program using the ackpayload concept appears to be working first try (fingers crossed, no issues!). Ended up going with the nrf24l01+Pa+Lna for some extra umph if I decide to go with an outdoor layout in the future. Will report back with some videos of the train once its finished, around christmas most likely. Cheers!

snowskijunky:
Will report back with some videos of the train once its finished, around christmas most likely.

You must be a lot faster at doing stuff than I am :slight_smile:

Thanks for the update.

...R

Robin2:
You must be a lot faster at doing stuff than I am :slight_smile:

Thanks for the update.

...R

@Robin2 turns out I'm not haha! I had finished it over christmas, but the teensy fried so I decided to re-do everything much more cleanly. I made this video just demoing my current functionality: https://www.youtube.com/watch?v=C7qy0MdIsFA&t=57s Its kinda boring considering all I have for a "layout" is a straight track on the floor of my apartment with only one locomotive, but I didn't want to edit it to make it more entertaining since it is mainly just a demo.

Here's some pictures from the build process as well: Model Train Control System - Album on Imgur
I think there is a picture in there of my first version with all the wiring stuffed into the tender... you can see why I redid it.

Cheers!

Hi,
Looks very impressive, the HMI needs steam pressure, water level and brake vacuum gauges.
I like the party party party bit at the end..lol

Tom.... :slight_smile:
(GWR, Gods Wonderful Railway)

TomGeorge:
Hi,
Looks very impressive, the HMI needs steam pressure, water level and brake vacuum gauges.
I like the party party party bit at the end..lol

Tom.... :slight_smile:
(GWR, Gods Wonderful Railway)

Thank you! And yes, I have considered doing that. I think it would be really cool to have a realistic control mode like train simulator. The main thing that stopped me was limited screen real estate. With a 5 inch screen like most phones, the app is already super packed with gauges and dials. So I think I'd have to get a bigger screen, like on a tablet. I think multiple tabs in the app would be too annoying to keep switching between to monitor gauges.

snowskijunky:
Thank you! And yes, I have considered doing that. I think it would be really cool to have a realistic control mode like train simulator. The main thing that stopped me was limited screen real estate. With a 5 inch screen like most phones, the app is already super packed with gauges and dials. So I think I'd have to get a bigger screen, like on a tablet. I think multiple tabs in the app would be too annoying to keep switching between to monitor gauges.

Everybody wants to do a cheesy app for their smarty phone.. :o :o

Build a down sized control cab, in real life not a HMI, with the appropriate levers and gauges and sits on the bench/table.
Or a control panel with throttle, brake and gauges etc.

Example Case;
I made a robot controlled with my Samsung Tablet, was so boooring...
Better and more fun with mechanical joystick.

Just an idea.. Tom... :slight_smile: