Locodoco/Position Tracking: Unterschied zwischen den Versionen

Aktuelle Version vom 19. Juni 2012, 08:37 Uhr

Intro[Bearbeiten | Quelltext bearbeiten]

Fig. 1: Waypoint transmitters in the track

First prototype of the Waypoint transmitter built into the track

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.

Waypoint Transmitter[Bearbeiten | Quelltext bearbeiten]

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.

Speed measurement[Bearbeiten | Quelltext bearbeiten]

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.

Protocol[Bearbeiten | Quelltext bearbeiten]

Test setup for the position tracking system

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.

Type field[Bearbeiten | Quelltext bearbeiten]

The type field contains the type of beacon (or message). The following 2 types are currently defined:

0x1 UUID beacon
0x2 Management command

UUID beacon[Bearbeiten | Quelltext bearbeiten]

The UUID beacon contains a unique ID, which is freely assignable by the user.

Management command[Bearbeiten | Quelltext bearbeiten]

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.

Message detection & error handling[Bearbeiten | Quelltext bearbeiten]

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.

Synchronization[Bearbeiten | Quelltext bearbeiten]

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.

Locodoco Project | Position tracking system | Loco decoder | Webinterface

@@ Zeile 18: / Zeile 18: @@
 == Protocol ==
 [[Datei:Locodoco irtest.jpg|thumb|right|200px|Test setup for the position tracking system]]
-Waypoint transmitters emit the code at a rate of 4800 bit/s. At each sequence, the waypoint transmitter sends out 32 bits containing its unique ID (16 bits) 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).
+[[Datei:Locodoco irtest2.jpg|thumb|left|200px|Test setup for the position tracking system]]
+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:
-   [ 16b UUID | 16b CRC16 ]
+   [ 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.
-=== Protocol Type ===
+== Type field ==
-The Protocol Type field for the above protocol is filled with binary zeroes (<code>00</code><small>b</small>).
+The type field contains the type of beacon (or message). The following 2 types are currently defined:
-=== Output numbers ===
+x1 UUID beacon
-The output numbering scheme allows for using up to 4 outputs (LEDs) on the same waypoint transmitter. This may be useful for turnouts (even 3-way turnouts or crossings). Output numbers are encoded in binary (LSB first), counting from 0 (<code>00</code><small>b</small>) to 3 (<code>11</code><small>b</small>).
+x2 Management command
-=== Checksum ===
+=== UUID beacon ===
-The Checksum is the 4-bit XOR product over the ID, the output number and the protocol type field. The protocol type and the output number are interpreted as an entire 4-bit block:
+The UUID beacon contains a unique ID, which is freely assignable by the user.
-Here's the pseudocode for the checksum generation:
+=== Management command ===
- checksum = ((protocol_type << 2) | output_number) ^ id[15..12] ^ id[11..8] ^ id[7..4] ^ id[3..0]
+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.
+== Message detection & error handling ==
+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.
+== Synchronization ==
+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.
-<code>id[b..a]</code> denotes the bits of the id field a to b (inclusive). Bits are always counted LSB first (therefore 0 is the rightmost - 15 the rightmost).
 {{LocodocoNavigation}}