In the last post I introduced the basic building block of my layout control system — the Layout Control Node or LCN. An Arduino board equipped with a wireless communications device constitutes a basic LCN.
In this post I describe the standard hardware components I use when assembling a functional LCN. I’ll also talk about the layout power bus you will need to support an LCN network.
The Arduino Board
The NANO is my standard LCN microcontroller.
The NANO works well for LCNs for a number of reasons:
- Its a space efficient design that has a built-in UART for USB Serial monitoring and programming
- It has the same capabilities as an UNO.
- Its an older, popular board design, so it is readily available inexpensively; there are also some new variants that include built-in communications devices.
- It is a 5 volt board; for model railroading purposes, the 5 volt boards work best with most peripherals.
Can you use a different board? Sure. I use a Mega 2560 in one situation because the sketch requires a great deal of memory, but that is the only instance. Everywhere else I use a Nano with peripheral devices as needed. As you follow along I think you will see that I gain an lot from standardizing on the NANO.
I have selected the nRF24L01 radio as the LCN wireless communications device. It is a high performance, ultra low power transceiver that works in the 2.4 GHz range. These are really inexpensive, costing a $1 or less each in a modest quantity [Amazon, Aliexpress].
With all the interest in IOT (Internet of Things) these days, most people gravitate to IP-based WIFI devices when they think of wireless communications. All of my early experiments were with WiFi and wired Ethernet using the TCP/IP protocol.
IP technologies have been around a while, so the parts are mature and reliable. But the processing demands of the protocol introduce noticeable lag on the relatively slow micro-controllers we use (relative to Intel or Apple computers), particularly with traditional shields that rely on the micro controller for message processing.
ESP01, ESP12 and ESP32 from Espressif systems represent a significant improvement in Arduino IP communications; essentially they are microcontrollers with WiFi built in. They perform well and would be viable on a layout. Their main drawback is they have relatively few general purpose IO pins so they aren’t a complete substitute for a standard Arduino. Also, they do not support high speed serial wire protocols — like I2C or SPI — so their ability to communicate with other Arduino’s by wire is limited to standard serial data rates.
That said, the ESP01 [Amazon with programmer, Amazon bulk, Aliexpress] would be the right choice for a basic LCN if you went IP, and with careful coding performance will be fine.
All IP devices suffer from a common problem — relatively high power requirements. The specifications for WiFi are for standard computing devices seeking to connect within a few hundred feet of an access point, which takes power. When using a lot of these devices, having to supply 100 – 300 mA to each one, in addition all other power loads, represents a significant burden on a layout. Wired Ethernet is the worst offender, causing load and heat problems with every shield I tried. WiFi is better, but still power hungry.
For these reasons, LCNs are not an ideal context to use either WiFi or wired Ethernet. What an LCN needs is short range but very fast communications. It need only reach nearest neighbors to guarantee it can send and receive freely. Because a mesh network requires nodes to cooperate to pass messages, overall transaction speed on each hop is what matters the most.
In contrast to ESP devices, the nRF24L01 does not have a built-in protocol stack; instead relatively simple protocols are implemented in software libraries on the attached microcontroller. What the nRF24L01 offers is fast transmission speeds up to 2Mbps, ultra low power consumption of 12 mA when transmitting and about 26 μA in standby (you read that right – 26 micro amps). It is a 3.3 volt chip; power is easily supplied by the Nano’s 3V3 aux power output so there is no need for a separate 3.3v supply.
The radio connects via SPI, using 2 dedicated pins on the NANO in addition to shared SPI pins, providing rapid Arduino-to-radio communication. All IO lines are 5 volt tolerant, so level shifting is not required.
The software implementation creates a self-healing mesh network that does not require a router and can support over 3000 nodes. You read that right, too. More about that in an upcoming post.
The small size of the NANO makes direct connection to pins difficult, and there is no way to easily mount a NANO to a substrate on its own. Fortunately, a large selection of “IO Expansion” boards are available to solve both problems. These are boards, a little larger than a NANO, that have headers to receive a NANO and either terminal blocks or pin headers to give access to NANO pins. They usually include mounting holes.
NANO IO Expansion boards are readily available and come in a number of common configurations. Some simply hold the NANO, have screw terminal blocks for connections and a couple of mounting holes. Others have additional connectors, including power jacks and 3-pin headers for servos. Finally, a subset have a header ready for a communications device of some kind, such as an nRF24L01 or ESP01.
I’ve chosen an IO Expansion board that includes an nRF24L01 header along with terminal blocks and a power jack. It is marketed under “Emakefun” name and available on Amazon. Other brands are available on Aliexpress.
Power & Wiring
Your LCNs and the devices they run will need power. DCC users could, I suppose, tap into track power, rectify it and use a DC-to-DC Buck Converters or some other power regulator to get the voltage right.
Before doing that, I’d want to add up all the potential loads to see if I might be pushing the limits of the DCC system, which is quite possible. I’d also want circuit breakers on every track feed to prevent shorts on the rails from shutting the entire system down.
The better solution for safety and power management is to have a Layout Control Bus or LCB that is independent of the track bus. The layout control bus should be powered by an independent DC power supply with sufficient capacity to handle the intended load.
The NANO is a 5 volt device, and the microcontroller can be powered from USB. However, when powering the board from an external power source other than USB, you have to provide power in the 7 to 12 volt range.
For powering LCNs, you should supply 12 volts DC power. For model railroaders that is a convenient voltage because many of the accessories we might work with, including most stall-motor turnout machines, require 12 volts DC.
You will also need a 5 volt supply. This power is for logic devices other than your Arduinos, and for servos, steppers and other 5 volt motors you might use for turnouts and layout animation.
So I recommend a 3 wire Layout Control Bus: 12 volt, 5 volt and Ground.
The easiest way to supply the LCB is with a multi-voltage power supply like a Mean Well RD-125A, or something like it.
You could also use 2 DC power supplies, and tie the two grounds together. Smarthobby LLC has a selection of appropriate single voltage power supplies. You’ll find similar products everywhere electronics are sold. The advantage of two power supplies is you can tailor current capacity to your actual needs.
I use converted computer power supplies which gives me an additional 3.3v power option. So I have a 4 wire LCB in addition to the 2 wire track bus:
Using A Basic LCN
What can you do with a basic LCN and no additional devices?
Quite a bit, actually. At this point you have 8 analog pins and 8 digital pins (3 PWM) available. Keeping the native current limits of a NANO in mind, a basic LCN could service two servos, monitor a few buttons/switches and a run a few leds. So a single basic LCN could reasonably support a small layout zone with a main track plus a siding, 2 turnouts, 2 signals and a small local control panel to control the turnouts.
A second basic LCN can serve as Master Node and provide wireless command access to the first, and to additional LCNs as you add them, creating a mesh network of LCNs.
A basic LCN can do a lot on its own, but it needs peripherals to overcome pin count and current limitations to handle any significant number of servos, lights or buttons/switches. Block occupancy detection, well within the capabilities of an LCN, requires CT sensors on block feeders. To fully manage track and turnout power, a peripheral is needed to control polarity reversing relays.
In the next post I’ll go over essential peripherals you’ll need to empower LCN’s to service your layout.
21 thoughts on “Basic Layout Control Nodes”
Very good series!
Although I don’t agree with you about the ESP12 and ESP32; they have I2C and SPI on-board and they have also lot’s of memory available, next to the WiFi, and are much faster.
The only ‘problem’ might be the 3.3 Volt, but there are several peripheral boards available for 3.3 Volt that have the same functionality as the 5 Volt versions.
And you can use the Arduino IDE to program those systems as well, just add the correct library to the IDE.
Hope we don’t have to wait too long for the next part of the series.
Hi – Getting caught up and wading through the spam to get to the real comments! Thanks for visiting and taking the time to comment.
I actually started with ESPs and only came to the nRF radios later. The ESP’s are great if you need full web / IP functionality. At one point on the test loop I had an ESP running a web server for control. Works, but slow because of the overhead. For the simple job of having a control panel communicate with a turnout controller, all that IP/Web functionality is unneeded.
Finding the nRF’s was a breath of fresh air — straight forward radio communication with only limited protocol overhead. For uncomplicated communication, the difference in performance is amazing. Also, the power difference — 12 mA transmit on nRF vs. around 300 mA transmit for WiFi, is nontrivial when you scale up to a full layout.
Robin, thanks for all the information you’ve posted here. I am planning a small N scale layout that will use DCC++ on an arduino and JMRI on a Pi. Additionally, I want to control about 14 servos for turnout and grade crossings, have block occupancy detection on 10 blocks, include local pushbuttons and LEDs for the 10 turnouts, control some LEDs for the grade crossings and also have around 15 IR sensors.
I am planning on using a PCA9685 to control the servos. CTs for occupancy detection, but not sure if I need to put together detector boards and an interface board and run 10 current signals through the Mayhew Labs ADC Shield, or if there is some simpler option using a ready made MUX board.
I’m guessing that I will need at least two Arduinos to accomplish all of this and would like to have one dedicated to DCC++ and the other to the rest of the stuff, so I am planning on a Mega for the stuff and an Uno to run DCC++, but reading this post made me think that going with several Nanos in a wireless mesh might be easier.
I don’t have much experience with Arduinos, so this will be a learning experience for me.
Ultimately, I want to be able to do some automation with the trains, that is why I want occupancy detection and the IR sensors. Not planning on any signaling.
Again, thanks for posting what you are up to – it is very helpful.
In the post titled, “When MEGA is the answer”, you said that you can successfully read CT sensors with the Arduino built-in ADC. At the end of this post you mention your LCN can handle block occupancy detection, but don’t provide the details.
I am in the layout planning stage and am interested in how you achieved that because if the Mayhew Labs ADC board and associated MUX and interface boards can be eliminated that would simply things and save some money.
Thanks for posting all the info – this is a great resource.
Sorry it has taken me so long to approve and respond to your post. The spam has gotten out of control … but I’m getting caught up again.
More coming on block detection. Yes, you can do this with the Arduino ADC. For general info on using CT sensors, see Current Sensing and Occupancy Detection for DCC. See also recent comments on that post regarding the resistor value required for high sensitivity detection.
When using the Arduino ADC on a Nano, Mega or Uno, noise can become an issue because of the shared ground connection used by the sensors. The Mayhew labs shield supports differential readings isolating both sides of the connection to each sensor, which is one reason it works so well.
One of the ways to reduce the noise is to use MUX’s to isolate the connections before reading. But noise is really only an issue when trying to detect low current flows around 1 microamp — the sensitivity you need to detect resistor wheels.
This is amazing work! Can your mesh network be interfaced with JMRI?
In theory, yes. In practice, not easily … yet.
The issue with JRMI is having a connector to work with. Connectors allow JRMI to talk to other systems. So, for now you would need a protocol emulator standing between JRMI and the mesh network … the easiest route looks like using the DCC++ connector (an arduino-based DCC emulation system), and creating a DCC++ interface that can perform the translation. Since DCC++ is out on a public license, this would be the most available lever for intermediating between the systems.
One really interesting side effect of that approach is that your could go all the way to full automation since you now have a way to run DCC itself from your control panel! A non-trivial task to be sure, but doable with those tools.
Are you willing to share your arduino code for the LCN’s? Or at least, the radio communication part, rather than the things that are specific to your applications.
The radio software, including the mesh network, is open source/public domain. A great place to find an explanation and links to the code is here: https://howtomechatronics.com/tutorials/arduino/how-to-build-an-arduino-wireless-network-with-multiple-nrf24l01-modules/
That takes care of the basic mechanics of communication. The next step is to devise a protocol for conveying information. I’m working on an initial version of a standard protocol to use over the mesh network. I’ll put that out when its been through enough testing that I feel it will be reliable.
Just came across your website and you are doing exactly what I’m trying to do.
When you have the NRF24L01 Sketches done, is there a way I can have a copy
I’ll post some code and information on the subject soon.
Thanks for turning me on to the LCN. I’ve been playing around with them for a couple of days now and I believe this is the solution I was looking for. I like the ESP8266, but it seemed like overkill for the price, and they have a limited number of digital ports. I’m looking forward to seeing how you implement them.
I’d be quite interested on how you repurposed a computer power supply. I have a few laying around and looking for a way to make a 3,5,12 V bus.
There are various sources of info on the web on how ATX power supplies are wired and can be converted. Here are a couple:
First a warning: Computer power supplies contain BIG capacitors; these can be dangerous, holding large charges for long periods of time, don’t attempt to modify a PS if you do not know how to discharge the capacitors and avoid injury.
ATX power supplies are “switching” power supplies that are turned on by shorting a particular lead. Also, you will need a high wattage burden resistor (something like a 10 watt, 10 ohm resistor … look at the information to get the correct sizing).
Have you managed to get JMRI talking through the NRF24L01 yet?
I haven’t tried, primarily because I have insufficient documentation for JRMI to be able to create the necessary connector. I wouldn’t try to get JRMI to use the radio, I think that would be a waste of time. What I would do is fashion a connector node that can communicate with JRMI over a Serial connection.
It would be doable if JRMI was a well-documented system. But its not, and therein lies the problem.
Thanks for your wonderful work and for sharing it with us. Just a general note about something I have recently experienced. The cloned Arduinos have had issues with the USB-Serial port chips and have had to change the cloned chipset for another. The older cloned chips no longer work with the latest windows drivers and the ones with new chips require a new driver, for which I have had issues on both Windows and Mac (Catalina). The maker of the original USB-Serial chip has clamped down on the clones, which is impacting consumers…For now I am buying genuine Arduino boards. i wonder if anyone else has had these issues and been able to resolve them? Colin
There is an issue with some designs where an independent USB chip is attached to the Processor — the NANO, UNO and MEGA are prime examples. Remember that the Arduino is actually open hardware so the official schematics are published and easily obtained. When you examine the designs, you discover that the USB chip is a major issue in the overall design of the board.
The issue comes from the fact that the designs call for a high end USB chip with advanced features that, as far as I can tell, cannot be used because many pins on the chip remain unconnected in the design. In fact, only “standard” connections, replicated on nearly any USB chip, are used. The advanced features make the chip quite expensive.
WTF? Why would you put a chip loaded with features you can never use on the board? We’ll never know for sure, but I believe that answer has to do with providing minimal 3.3v compatibility on 5 volt boards. It turns out that the 3.3 volt pin on the boards is supplied by the USB chip. The choice of chip in the official design has something to do with that.
Why use a $4 chip to supply 3.3 volts when a $.25 Linear regulator will do the job nicely and cheaply? You got me, but its the design feature that messes with anyone trying to create a low cost clone, and the USB chip becomes the Achilles heal of the whole thing. What the cloners try to do is substitute a simpler, less expensive USB chip, and this is where thing go wrong. If the chip is made by FTDI, then it will be fine. Other brands are another matter, however, and they are the ones using the alternative driver.
Still, you shouldn’t be having trouble with basic serial connectivity. I’m on the most recent version of Win 10 — I’m having no issues with USB connections to clones. You may be having other USB issues that are affecting Arduino access, I would review everything that uses USB for possible conflicts. Also, as far as I know all Arduino boards are USB 2.0; make sure you are using USB 2 ports.