Locodoco/Position Tracking

In other model railroad automation systems, track occupation detection is usually done by occupancy detectors that measure the resistance of the two rails - with magnets and reed contacts - or infrared light barriers. These devices either need some additional wiring back to the controller to give feedback or send their information back to the track - however they all aren't as portable and require extensive (and visible) modifications.

Since the Locodoco onboard decoder for the locos utilizes a radio transmitter anyway, it is possible for a loco to send this piece of information back to the controller itself. The locos are equipped with an infrared transceiver which makes them able to read the codes that the waypoint transmitters emit.

view from the bottom: Attiny45 (left), 78L05 (right) and a bridge rectifier on the right

A waypoint transmitter consists of a tiny AVR microcontroller that continuously transmits the same sequence of bits while it is turned on. An infrared LED connected to one of the AVR's output drivers can be installed in turnouts and normal track to mark a position.

The waypoint transmitter fits underneath (or better said into) a single track brick of the standard LGB track and is visually almost completely hidden (just the transmitter diode peeking out). It consists of an infrared transceiver, an Attiny45 (or pin-compatible processor), a voltage regulator (78L05) and some capacitors. The device is designed to be powered by the track, which also makes it suitable for "mobile" track layouts.

Given the distance of two waypoints is known and the speed of the loco is constant, one can measure how fast the loco is running. When making this distance very small, slight accelleration or decelleration of the loco running over the two points may be interpolated or ignored. The Waypoint Transmitter has some additional unconnected pins, which may be used for additional transmitter diodes sending a different code.

Waypoint transmitters emit the code at a rate of 4800 bit/s. At each sequence, the waypoint transmitter sends out 2 bits containing the message type, 14 bits containing the unique ID or command, plus 16 additional bits that consist of the crc16 checksum. The overhead from the uart protocol adds 8 more bits (1 start + 1 stop bit for each of the 4 Bytes).

In detail, the sequence looks as follows:

[ 2b TYPE | 14b UUID | 16b CRC16 ]

Assuming the range at which the loco passing the waypoint transmitter is in the correct position for receiving the sequence is 1cm (d in Fig. 1), 40 bits are sent per beacon at each broadcast, then the maximum speed at which the system can reliably receive information is 0.96m/s. Note that we have to assume that at least 5 Bytes (50bits on the channel) have to be transferred correctly so the receiver may reliably detect them.

Management commands are primarily used to support operational security. These commands may instruct locomotives to reduce their speed in front of a steep curve or stop immediately when accidentally entering a section with a dead-end.

The 16bit CRC16 checksum provides a fair amount of error detection and is easily computable on microcontrollers. Falsely detected messages may thus be discarded by the microcontroller at the receiver side right away. With 16 Bits of payload, all possible payloads have exactly one valid CRC16 sum (bijective mapping). In other words: A message may be "reconstructed" from a given CRC sum and vice versa. This allows for repairing messages with a probability of approximately (1 - (2^n)/65536). If, for example, 2 Bits of the payload were flipped, the original message may be restored with 99.99% certainty.

Because it is rather improbable that a message is garbled in the middle of a transmission, the signal level on the UART level is kept high (idle) for a fixed amount of cycles to let the receiver re-synchronize and detect the start of a transmission reliably.

Since there is no fixed start or endpoint of messages (i.e. a preamble) and the transmission is continuously repeated, the receiver may only identify a valid message by checking its CRC sum and the type field. This is done by storing all received data in a cyclic buffer and then checking whether the CRC sum matches at the suspected start offset in the buffer.