May I suggest more than one magnet per train to differentiate them.
Simplest way: number of magnets corresponds to train ID. Small space between magnets (calculated from Hall sensor refresh rate and max train speed). Count number of Hall sensor trips (maybe with debounce) within some time period (calculated from the minimum train speed during crossing and the magnet spacing).
Disadvantage: Train minimum speed must be reasonable. Requires n(n+1)/2 magnets, or 36 for 8 trains.
More reliable way: two columns of magnets, slightly offset, spaced as above. Two Hall sensors in a row under the track. Col 1 is clock. Col 2 is data. Whenever Hall 1 (clock) goes high, read Hall 2 (data) (maybe for a short period for debounce). To keep things simple and stay away from speed assumptions, put the same number of clock magnets on all trains: log2(train count), rounded up, for example 4 for 16 trains.
Disadvantage: Requires twice as many Hall sensors. Requires about log2(N)1.5 magnets per train, so 96 magnets for 16 trains, as opposed to 16 for the original method. Those tiny neodymium magnet bars are cheap, though.
BONUS: Train speed measurement. Speed is the clock magnet spacing divided by time between clock Hall trips. Now you can run a Pi algorithm (e.g. PID) to move trains at a target speed regardless of load, at least in the regions with Hall sensors.
If you are willing to assume the train speed is constant while passing the sensors and do more complex signal analysis on the Pi, the intermediate clock magnets can be removed, reducing the magnet count to N(2 + log2(N)0.5)=64.
If you wanted to avoid the clock thing, you could probably do something like this.
Have two rows of sensors set up like this:
* * * * * * * *
* *
When both of the second row of sensors are high, read an 8 bit binary number from the first row of sensors. This allows you to have up to 255 different IDs with 10 magnets per train. First row is data, second row is alignment. Fast moving trains might have issues with this kind of setup though.
Similar to an old conveyor system on an Eshed Robotech system. There were 5 bits for each carriage encoded using magnets which rode the conveyor giving you 32 addresses. As the carriage passed into a station a pneumatic cylinder extended to trap it so it would stop above the sensors. If that carriage was to be processed at that station it would be picked off by a robot and placed in a dock.
If you're going to do columns, seems like you could save on magnets by putting exactly one magnet, either in column A or B.
Though if you do that, you'd need to worry about ambiguity from trains going different directions along the track. With your scheme, you have to figure out which column is the clock, but that's doable because it's the one with all 1s. (If the data is all 1s, then it's not clear but which column is which. You can still figure out the train number but not which way it's going.)
With my solution, I suppose you could just add a leading pair of magnets in both columns, which adds two magnets (and the space for them) to the cost.
Also, I'm not a hardware guy, but it seems like magnet polarity matters for hall effect sensors. So maybe you could so something like a single column of magnets but flipped north up or south up depending whether you want to indicate a 0 or a 1. I'm not sure whether you'd need two hall effect sensors (in opposite orientations) or a different type of hall effect sensor.
If anyone curious about railway modelling, I think, the game "Rolling Line" is an interesting simulation of it, including VR support, it is available in Steam.
There was a model railway show in London in the mid 70s that my grandfather took me to.
The least decorated layout there was the most interesting, as it was computer controlled. Even better, a small child could program it by writing instructions on paper and handing them to the controller who then put them into the computer
For a 10 year old, this was magical! This may have triggered my interest in computers
Bit off-topic but my friend uni’s RTOS course was all about train scheduling, which seems like a fun way to teach it (not sure if it was Hornby 00 Gauge like this)
Sounds like the infamous Trains of CS452 at the University of Waterloo. There's a class the ruins people; it seems they do nothing but live in a lab for three months.
They walk away having written a bare-metal real-time operating system, so I guess that's something. I stuck to the less soul-destroying classes.
If you're interested in reading more, there's a student's write-up of the course here:
* Impressions [0]
* Optimizing The Kernel [1]
* The 72-hour bug [2]
* Train Tracking [3]
Notably, QNX started as a CS 452 project.
I'm not too sure about the future of that course. The last I heard (Winter 2019), the professor, Bill Cowan, had decided to stop teaching. Last term, they were clearing out the CS 452 lab and were moving the trains elsewhere. I had wanted to take the course then, but unfortunately the course wasn't being offered, and it was my last term before graduating.
Thanks for these links. As a UW CS alum who didn't take the CS452 and now regrets it a little bit, this was fascinating reading – especially when he gets to the modelling aspects (last link).
I took the course in 2018 and can say it was my favourite CS course I've taken. It's considered "soul destroying", not because it's hard or not fun but because of the sheer amount of hours you have to spend in the lab. Unless you're experienced in the domain or really smart (neither for me), you're probably spending many many hours in the lab almost everyday if you're trying to do well in the course. For me personally, I wouldn't say it was soul destroying and I'd say the skills you learn from the course are invaluable.
I remember that company, much airtime in the TV show https://www.bbc.co.uk/programmes/m00037sz
which was focused upon Hornby and most insightful. Rails had there own design of train coming out for some model that was a gap in the market, whilst Hornby was secretly working on their own version and both came to market around the same time.
Might of been in part one, but if you're even remotely into model trains or just a passing fascination into them, well worth a watch. But a most enjoyable documentary and a style that will fit even the non-train buffs abound.
The host is James May of Top Gear and The Grand Tour. He does a lot of quirky documentaries for the BBC like "Big Trouble in Model Britain." It's two episodes and pretty interesting and I have minimal interest in model trains.
Simplest way: number of magnets corresponds to train ID. Small space between magnets (calculated from Hall sensor refresh rate and max train speed). Count number of Hall sensor trips (maybe with debounce) within some time period (calculated from the minimum train speed during crossing and the magnet spacing). Disadvantage: Train minimum speed must be reasonable. Requires n(n+1)/2 magnets, or 36 for 8 trains.
More reliable way: two columns of magnets, slightly offset, spaced as above. Two Hall sensors in a row under the track. Col 1 is clock. Col 2 is data. Whenever Hall 1 (clock) goes high, read Hall 2 (data) (maybe for a short period for debounce). To keep things simple and stay away from speed assumptions, put the same number of clock magnets on all trains: log2(train count), rounded up, for example 4 for 16 trains. Disadvantage: Requires twice as many Hall sensors. Requires about log2(N)1.5 magnets per train, so 96 magnets for 16 trains, as opposed to 16 for the original method. Those tiny neodymium magnet bars are cheap, though. BONUS: Train speed measurement. Speed is the clock magnet spacing divided by time between clock Hall trips. Now you can run a Pi algorithm (e.g. PID) to move trains at a target speed regardless of load, at least in the regions with Hall sensors.
If you are willing to assume the train speed is constant while passing the sensors and do more complex signal analysis on the Pi, the intermediate clock magnets can be removed, reducing the magnet count to N(2 + log2(N)0.5)=64.