So knowing what I now do about the IoTT channel progress, how would it affect the South Downs railway?
Firstly: if I started from scratch, the South Downs railway might be a lot different.
- The EX-CSB1 + Red hat looks like it would make a fine command station; the added Power shield boards would make good boosters. So the Digitrax command station and boosters would not be needed.
- The DCC critters look like they would make good replacements for the Digitrax PM42 modules. The FET switched output, rather than relay switched output, would lead to silent operation.
- The Yellow Hat modules would be credible alternatives for control panels. However they'd need additional code to add an ALM for interlocking with Traincontroller
- The Blue Hat signal controllers might be suitable, but the need to drive available N scale model signal leads is a possible complication
However, replacing working electronics on the existing railway isn't that simple. What will I actually do?
Well, the "Brown hat" plus LocoNet interface and IoTT stick makes an excellent gateway for 3rd party communications. It will replace a locobuffer; it will allow smart phone throttles to be used; and it will provide a MQTT broker gateway. Ihave assembled Brown hats ready to go, together with a Raspberry pi with installed MQTT broker.
Replacing the PM42 with LocoNet critters is a possible change. However the physical assembly of my railway electronics might mean they don't fit.
Any new control panels will use a Yellow Hat, with MQTT communications.
Train detection is as yet an unsolved problem. I have 10 Digitrax BDL168 boards and it isn't clear that replacing them would be wise. Occasionally I get "stuck on" detectors (typically on the short detection sections at the "stop sensor" at the end of a block). A technology that avoided that would be good. I'm unconvinced about "train side" sensing for N scale: I don't see how it would fit even if the communication were build into the decoder and miniaturised.
Watch this space!
Hans Tanner began his video series by introducing the idea of using MQTT as an alternative communication medium to wired LocoNet. He used its message transport capability so that LocoNet messages could be sent to an MQTT broker through a gateway, and the broker would then distribute them to client devices that had expressed an interest in the topic. The MQTT broker could be a public one, in the cloud; or a private one running on (for example) a raspberry pi on your own WiFi network.
4 years on, the range of options has expanded substantially. LocoNet messages can still be broadcast to an MQTT server. DCC can also be broadcast to an MQTT server, allowing the command station to operate devices with no wired connection. There are then two additional servers available in the IoTT stick to add further protocols:
- LocoNet over TCP, to allow clients written for it (eg JMRI) to get their LocoNet traffic over a TCP/IP connection;
- WiThrottle server, to allow smartphone throttle apps to control locomotives.
So what makes sense to use? My railway PC already has three USB Locobuffer devices; perhaps there could be a reduction. For example:
- Have an IoTT stick with a LocoNet interface and BrownHat. This will provide a LooBuffer replacement.
- The same IoTT stick acts as a gateway to a Raspberry pi based MQTT server. This allows other IoTT modules to get LocoNet traffic via the broker
- The same IoTT stick provides a withrottle server
This seems to me the most appropriate communication options; I'll see how it gets on. I've easily been able to assemble a working BrownHat after buying PCBs from China, and 3D printing the case. There are only 2 resistors and a capacitor to assemble, plus through-hole connectors.
Interestingly, and as described in an earlier video, there is no standard for use of MQTT for model railway traffic. JMRI uses a different approach, so it can't connect to LocoNet via an IoTT stick gateway.
Hans Tanner's approach is to have a combination of three types of module: a layout "interface" (currently DCC or LocoNet), a microcontroller "IoTT Stick" and function "Hat". The combination allows many types of device to be created.
The central element is the IoTT stick: this is a programmed M5Stick with an ESP32 processor and WiFi interface. The stick software supports all modules, and has a web based configuration interface.
Hans Tanner's IoTT modules based on the IoTT Stick are as below. Video 111 gives a good summary.
|
IoTT Stick |
M5StickC: ESP32 with display |
|
IoTT Stick+ |
M5StickC Plus 2: ESP 32 with display |
|
DCC Interface |
Opto isolated DCC interface. Connects to the stick using the Grove port. |
|
LocoNet Interface |
Bidirectional LocoNet interface. Connects to the stick using the Grove port. |
|
BrownHat |
USB interface; adds Locobuffer-like function to an IoTT stick with LocoNet interface |
|
BlueHat |
For signalling And possibly other LED output. Drives a string of WS2812 Neopixel drivers. Can drive appropriately for signals, and for CTC display. |
|
YellowHat |
Controller for CTC panels. Drives a string of WS2812 Neopixel drivers, and has 32 inputs. Each input can be touch, logic level or analogue input. |
|
BlackHat |
Knob and switches for smartphone throttle |
|
GreenHat |
Servo accessory decoder with 16 servo outputs; 2 LED outputs and 2 inputs per servo. Bounce and hesitation effects. |
|
PurpleHat |
Train-side sensor for precise speed and distance measurement. Allows train speed matching, |
|
RedHat |
Extends the DCCEX stack based system to turn it into a LocoNet based command station. |
|
Tinkerface |
Module for LocoNet / DCC experimentation with Arduinos; also used as pat of Silverhat booster. |
|
Support board: Powershield |
5A track output for DCCEX stack |
|
Support board: Pulse Driver |
3 channel Pulse and high voltage level driver to allow tortoise and solenoid point motors to be driven from a GreenHat. |
|
Support board: Nano DCC Critter |
Development module, for experimentation. A board capable of being a DCC "fuse", command station or booster, DCC decoder or speed controller. DCC in / DCC out / Arduino Nano |
Before the IoTT stick and "hat" concept there were some earlier modules:
|
Early work |
ESP8266 Node MCU 1.0 processor |
|
LocoNet Gateway |
Connection to LocoNet |
|
YellowBox |
Controller for CTC panels |
|
BlueBox |
Controller for signalling; uses NodeMCU 32S with ESP32 processor. Modular design. |
There are over 150 videos in the channel when I write this. Topics are revisited periodically. I've put this table together to try to group them. Bear in mind I've only watch a third of them so far - this may contain errors!
|
100 |
Summary. Read first! |
|
45, 77, 84, 110, 150 |
Development project review |
|
1, 3 |
Loconet gateway interface, running on 8266; MQTT broker |
|
2, 4, 6 |
LocoNet toolbox, viewer on phone using NodeRed |
|
7, 8 |
Wifi throttle |
|
9-12 |
CTC panel; “Yellowbox” |
|
13-16 |
Signalling system; “Bluebox” |
|
17-19, 25 |
DCC Servo decoder & switch machine decoder using Arduino nano; SPI LED string for output state display |
|
20, 21, 23, 24 |
Signalling, ABS and CTC basics; Data model, ABS, CTC algorithms for Arduino signalling system |
|
22, 26 |
Converting signals to neopixels; Neopixel LEDs for garden landscaping |
|
27, 28 |
Description of his Arduino libraries for DCC, LocoNet and MQTT; run on ESP32 on a NodeMCU-32S module |
|
29, 30 |
Universal control panel, with Neopixel LEDs and library to drive pixels. |
|
31, 32 |
Arduino sketch for NodeMCU-32S (ESP32) that performs configurable role of Yellow box (CTC) Bluebox (signal) and LocoNet gateway. Web based configuration. |
|
33, 35, 36, 46, 68 |
“At point” sensor ideas. High resolution block detection using a LIDAR sensor; train ID using an RFID reader; axle counting using an IMU sensor. Review of two commercially available block detectors. |
|
34 |
Experimental DIY booster |
|
37-40 |
More detection research: Trackside sensors, current detectors, railcom vs transponding. Key differences in applications for “at point” & “in area” sensors. |
|
41-43; 59; 120, 125, 135, 139 |
IoTT stick M5 & Grove port. This explains the new processor family and the interfaces available. |
|
59, 62-64, 73 |
IoTT stick DCC and LocoNet interfaces to railway |
|
44, 129 |
BlueHat signal controller: drives a string of Neopixel LEDs for lighting effects. |
|
58, 60, 65-67, 74 |
GreenHat servo decoder: a 16 channel servo decoder with bounce and hesitation effects. |
|
47, 50, 70-72, 127 |
YellowHat CTC panel controller. Drives a string of Neopixel LEDs, and has 16 analogue or digital inputs. |
|
48, 49, 53 |
MQTT: the Internet of Things message broker that enables an alternative message transport mechanism. |
|
51, 52, 56, 57 |
Smartphone throttle, DCC viewer, LocoNet viewer: these are updates to some of the earliest videos. |
|
54 |
Switch decoder power stage: adds 3 output channels with high voltage/high current capability for solenoid and Tortoise-type point motors. |
|
55 |
Driving semaphore signals with servos |
|
75, 76 |
LocoNet man in the middle, allowing intervention between LocoNet input device and command station. |
|
78 |
3 channel high current driver for the GreenHat servo accessory decoder |
|
80 |
Voice control from a microcontroller |
|
79, 85, 89, 95, 97, 99, 101 |
Redhat++ command station; A LocoNet extension to the DCC-EX project. |
|
81, 82, 83 |
Technologies for absolute position detection of model trains. GPS sensing; Hall effect sensor for wheel "distance travelled" measurement and IMU sensing to measure the track geometry. Looks at another position detection system. |
|
87, 88 |
Track measuring |
|
90, 91, 116 |
Speed matching & profiling |
|
93, 94, 96, 122, 123 |
PurpleHat. This is a "train side" sensor which measures position and speed of the sensor using inertial and magnetic sensors. |
|
103, 104, 105 |
Current meter: this work identifies an issues with DCC-EX current measurement, and provides a significant improvement. |
|
106 |
BrownHat USB interface. This gives a USB serial interface to the IoTT stick, giving it LocoBuffer-type capability alongside its other capabilities. |
|
107-109, 114, 121 |
Power Shield: this is a high current track output board for the DCC-EX stack. |
|
111, 112 |
IoTT architecture overview. This is worth watching as a "catch up" as some aspects have developed as the work progressed. The 1st video covers the modules; the second the communication methods. |
|
118-120 |
Adding LEDs |
|
113, 117, 124, |
Making a command station |
|
126, 128 |
DCC Booster research |
|
134, 136, 143, 144, 145 |
Silverhat booster |
|
133, 137 |
Tinkerface module: primarily part of Silverhat booster, and as an Arduino shield for LocoNet & DCC |
|
138, 141 |
DCC power supplies |
|
146, 147 |
Signalling without block detectors. this sets out a long term plan, using Purplehat (trainside) measuring technology to find position within a block. |
|
148 |
Nano DCC Critter: a board capable of being a DCC "fuse", command station or booster, DCC decoder or speed controller. DCC in / DCC out / Arduino Nano |
|
149 |
DIY Turntable driver |
|
151 |
Building your own boards: detailed instructions for purchasing & assembling. |
|
152 |
EX-CSB1. Using the newest DCC EX board with a Red hat shield to make a complete LocoNet command station. |
Hans Tanner's "Internet of Toy Trains" youtube channel is fascinating. See www.myiott.org as a starting point. He has taken modern concepts for message exchange and applied them to existing railway control systems, resulting in much greater flexibility.
The core concept for his ideas is: the information to operate the railway can be exchanged using an MQTT ("Mosquito") message broker. He has created several versions of a gateway from LocoNet to an MQTT broker; from there it can be accessed via many other kinds of device. He has demonstrated a smartphone as a message viewer and throttle, and several additional electronic modules. It means that a CTC type panel needn't have a LocoNet cable; instead it can have a WiFi connection to an MQTT broker. Processing logic and some forms of display can be implemented using NodeRed.
How will I use this? No idea yet, but it will fit in somewhere!
Github: https://github.com/tanner87661
Setting up an MQTT Broker
I've set up an MQTT broker "mosquitto" on a raspberry pi. It needs no user interface, so it can be a "displayless" pi. Follow the guidance of this web page: https://randomnerdtutorials.com/how-to-install-mosquitto-broker-on-raspberry-pi/
It site behind a firewall on a private network. I've allowed anonymous access and started external access with these two lines added to /etc/mosquitto/mosquitto.conf:
listener 1883allow_anonymous true
That's enough that an MQTT client on my android phone can access the broker.
Setting Up Node Red
Similarly, Node Red acts like a server. Even though it has a GUI, it is accessed through a web browser; so the program can run on a displayless Raspberry pi.
Follow the instructions on the Node Red web page to install to the raspberry pi:https://nodered.org/docs/getting-started/raspberrypi
After installation you will need to install Node-Red-Dashboard; after that Hans Tanner's code can be imported.
https://github.com/tanner87661/IoTT-SmartPhoneToolbox
Hans Tanner's code has evolved since the smartphone toolbox code was produced. He has changed the MQTT topics in the current M5stick code. Three topics are available:
- IoTT_LNPing (devices send a "ping" message every 3 minutes)
- IoTT_LNEcho
- IoTT_LNBroadcast (this is the "normal" topic to use)
The MQTT input node needs to be configured for the MQTT broker address (in my case "localhost") and for the M5 stick the topic needs to be changed from "lnIn" to "IoTT_LNBroadcast".
Opce "deploy" has been clicked, the flow will publish a web page at address xxx.xxx.xxx.xxx:1880/ui and can be viewed on a smartphone
(xxx.xxx.xxx.xxx is the IP address where your Node-Red server runs)