Model Train-related Notes Blog -- these are personal notes and musings on the subject of model train control, automation, electronics, or whatever I find interesting. I also have more posts in a blog dedicated to the maintenance of the Randall Museum Model Railroad.
2023-11-24 - SDB: First Trolley Automation Test, ContinuedCategory SDB
The Software Defined Blocks project uses an ESP32 with sensors to emulate block activations for a train model railroad.
The first prototype automation test has been overwhelmingly problematic:
- At first, I could not get the ToF sensor to reliably detect the engine. It would seem to work, then most of the time it would not detect a decreasing distance as the trolley was approaching till it was right next to the sensor.
- At the same time, my mere presence a couple feet on the side would influence the result. That’s not good.
- The response time in JMRI seems extremely slow.
Let’s detail that last one.
“On the paper”, I wanted the distance to be measured “in a straight line” such that it would trigger 3 blocks: 0-200 mm would be block A, 200-400 mm would be block B, and 400-2000 mm would be block C (about 8 and 16 inches thresholds for our friends with these units). Experimentation by looking just at the output of the sensor on the embedded display seemed to indicate that it should work fine.
Then I created virtual sensors in JMRI, and configured SDB to send JSON commands to JMRI.
That’s when things derail a bit. It sure works, but there’s a clear delay. For example the engine leaves, the distance increases, and the engine crosses the 200 mm distance mark. But by the time the corresponding block is seen changed in JMRI, the engine is already at the 400 mm distance mark…
I’ll need to look into that later. Why is it so slow? Could be SDB, could be the wifi, could be JMRI. Or even all of the above.
In between, I tried a couple variations and settled on one that mostly works: I create two virtual blocks which are overlapping. Block A covers 0-300 mm (~12 inches) and block B covers 200-2000 mm (anything above 8 inches). That seems to be more reliable. When the engine leaves, the block A→B transition happens sooner. When the engine comes back, the block B→A transition happens farther from the end, giving the engine more time to stop if needed.
The other experiment I made is to not place the sensor straight and aligned with the track. From my notes, I know the sensor detects within a cone-shaped scope. I can place the sensor a bit more on the side of the track, pointing away from the aisle where I may be working. This way it has less chance to detect me. It also means the object detected as a slightly more “sideways” motion than coming straight at the sensor, which I know is something helps a lot for regular IR sensors.
So in the end, I got something that seemed to work. I left my prototype ESP32/sensor there to try it during the next day’s automation. It failed in interesting ways.
Right now, this is in the early stages of experimentation. This is my “MVP” (minimum viable product) test bed.
So far the conclusions are:
- SDB as in “ESP32 with sensors connecting via wifi to JMRI” works.
- Even though the code for SDB is not feature complete yet, the code structure seems good and adequate.
- The ToF sensor is disappointing and subpar for this application due to the geometry of the environment (too close to the track).
For this specific automation project, I think I’ll go back to a regular current-sensing block sensor.
The next step is to support NCE BD20 sensors with SDB and then install that physically on site.
I will leave the actual ToF-sensor based automation in place though in between.