[Sinergy2]

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.

[cweagans]

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.

[MisterTea]

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.

[adrianmonk]

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.