Most of what I have written about model trains on this blog was about one layout on one table. A LocoNet master switch, an Arduino LocoNet interface, a DCC packet analyzer. In 2021 I built an ESP32 LocoNet command station board. All of it assumed there was one command station, one computer, one person in charge.

Hive-Rail is my new project, and it starts from the opposite end. What if the layout is a dozen people's modules, bolted together for a weekend, and nobody owns the whole thing?

I came up with the design, I write the software and the wiki, and I'm building the hardware for it. It has been open source on GitHub from day one, so this post is as much an introduction as a progress report.

The FREMO problem

FREMO meetings work like this: everybody builds modules to a shared standard, you bring them to a hall, and for a few days they become one big layout. Trains run to a timetable on a fast clock, drivers walk along with their FRED throttles, and a dispatcher (the Zugleiter) keeps the whole thing from turning into a demolition derby.

Technically, that layout usually hangs off one central system. Which works fine, right up to the moment it doesn't: one short on a turnout in the far corner, and the whole hall stops.

The idea behind Hive-Rail is that every cluster of modules gets to be its own power district, with its own command station and a small Hive-Rail node next to it. The nodes find each other on the network and work together as one layout. There is no central server. A hive doesn't have one either, hence the name.

Train tracking that outlives its computers

The core of the design fits on one line, and I put it at the top of the README:

Distributed train tracking that keeps working until the last mesh node dies.

Programs like Rocrail, iTrain or TrainController track trains on one computer that knows the whole track plan. Hive-Rail splits that job up. Each node follows the trains in its own district, block by block, including trains somebody is just driving by hand without a route. Every node keeps a copy of where all trains are. And when a train crosses into the next district, its identity goes with it.

The nice consequence: if one node dies, the others still know where its trains were. When it comes back it asks the mesh for its trains and carries on, so nobody has to walk around placing locos again. If everything but one node goes down, that last node still has the picture of the whole layout.

There are a few rules in the design I refuse to bend:

• The network is never the primary protection. Every booster protects itself. The network only tells the neighbours.
• Stop is the default. A border signal only shows proceed while fresh, positive information says it is safe. No news means red.
• Two boosters never feed the same rail at the same time.
• Everything has exactly one owner. A train belongs to the node whose track it is physically standing on. Every other copy is read-only.

That last one sounds bureaucratic, but it is what keeps a network split from producing two nodes that both think they are driving the same loco.

Crossing the border

The hard part is the border between two districts. A train has to leave one booster and enter another without both of them feeding the same rail, and without the train losing its name on the way.

Each border track gets a transfer block with both rails cut, an edge block with occupancy detection in front of it, and a latching relay that decides which side feeds the transfer block. The receiving node acts as the referee. Before a train gets on, the sending node has to say which train it is. It knows from its own tracking, or from the loco register if only one loco can be there. If even that doesn't settle it, the signal stays red and a human gets asked. That is how a FREMO station does it anyway: you announce a train to the next station before it may leave.

This part is still on paper and in the simulator. I want it bench-tested with real decoders and a real relay before it goes anywhere near a layout.

Speaking the languages that already exist

I didn't want to invent yet another protocol that nothing else understands. The nodes talk to each other with RocNet messages, Rocrail's own protocol, carried over Zenoh, a small peer-to-peer pub/sub system that finds peers on the network by itself. Anything a RocNet tool like Rocrail should understand goes as plain RocNet. Hive-Rail's own bookkeeping, like heartbeats and the loco register, goes on its own keys.

At the edges, each node plugs into whatever the module owner already has:

• DCC-EX over USB or WiFi, which I expect most clusters to use
• LocoNet centrals like the Intellibox, over a serial port or a GCA101 LocoBuffer-UDP
• Rocrail or JMRI, connected over LocoNet over TCP

Written in Rust, native everywhere

I write Hive-Rail in Rust. The same code builds into one native program for Linux, Windows and macOS: no runtime to install, no virtual machine, just an executable. GitHub builds and tests it on all three, every beta release ships a ready-made executable for each, and there are Debian packages for PCs (amd64) and ARM boards like the Raspberry Pi (arm64).

That matters at a FREMO meeting, where every module owner brings whatever laptop they have. A Windows PC and a MacBook join the same mesh as equals; my own test bench is exactly that. The nodes that live under the layout are meant to be Raspberry Pi or Orange Pi boards running the Linux build.

The small end runs natively too: the ESP32 lite node is its own firmware, built on zenoh-pico, Zenoh's C library, and speaks exactly the same messages as the Rust nodes. To the rest of the mesh it's just another district.

The hardware

My 2021 ESP32 LocoNet command station board got a second life as the first prototype of the Hive-Rail node board. It runs stock DCC-EX with a Hive-Rail add-on: an OLED with the fast clock, district power and mesh status, stop and go buttons, status LEDs, and a LocoNet buffer.

Board v2 is drawn up with two ESP32s, one running DCC-EX and one running the Hive-Rail "lite node". It is all through-hole and plug-in modules on purpose. When something blows up at a meeting, you pull it out and plug in a new one in seconds instead of getting the hot-air station out.

The lite node already runs. On 31 October an M5StickC, that tiny ESP32 stick with a screen and two buttons, joined the mesh as a district of its own. One button switches its district's power or fakes a short circuit. Double-press the other for a global emergency stop, triple-press it to get everything going again. It uses about 6% CPU and has about 177 KB of heap to spare, which leaves room for what the real board needs to do.

Where it actually stands

Let me be clear about this, because the README is: this is an early beta. It has not driven a train on real track. It is not a safety system, and you should not hook it up to a live layout.

What works today:

• power on and off per district, with shorts and power states shown on every node
• a global emergency stop and a global go that undoes it
• one fast clock for the whole mesh, written to LocoNet so Rocrail and throttles follow it
• one loco register for the whole layout, with throttle numbers so a FRED gets its loco back when you plug it in on another module
• driving DCC-EX, and on 30 October a test against a real Intellibox I and IB-Switch through a GCA101
• a layout simulator with a web view: modules drawn as SpDrS60 panel tiles, trains running between stations, station boards, overtaking

That last one is the most fun to look at, so here it is:

That's the whole bench layout: three districts, each in its own colour, six trains, and on the right what every train is doing and every event on the mesh. Zoom in on a station and you get what you'd put on a screen next to it:

RE 4401 is coming into Adorf on track 1, its route lit yellow, and the board below lists the next arrivals with their tracks. The station lamps are on because it's 06:04 on the fast clock and still dark.

All of this comes from module files. Every owner describes their modules once (track, blocks, sensors, turnouts, signals), and Hive-Rail works out the districts, borders and routes for each meeting from them. You draw a module in the module editor, from SpDrS60 tiles on a 50 mm grid:

And the Zugleiter gets a screen of their own, with every district, the fast clock and the loco register of the whole layout:

In the run these screenshots come from, the M5StickC wasn't switched on, so the dispatcher only lists the MacBook and Windows nodes. The simulator stood in for the middle district.

The longest test so far: three districts (my MacBook, the M5StickC, and a Windows PC), six simulated trains, about twenty minutes of shorts, stops and clock changes thrown at it. Only the trains in the district with the fault stopped, and they carried on afterwards. Which is exactly what it is supposed to do.

What's next is the real thing: following trains block by block, handing them across borders, and bench tests with real relays and decoders. That's the order, because I want the timing measured before anyone trusts it.

Have a look

Hive-Rail is my project and I build it in the open. Everything is open source under the Apache 2.0 license:

• Hive-Rail on GitHub
• The Hive-Rail wiki, with the full design: architecture, the RocNet mesh, the node board, module files and the border handoff

If you run FREMO modules, or you have ever had a whole hall go dark because of one short, I would love to hear what you think.