Locodoco/Position Tracking: Unterschied zwischen den Versionen

Aus LaborWiki
Wechseln zu: Navigation, Suche
Keine Bearbeitungszusammenfassung
 
(5 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 17: Zeile 17:


== Protocol ==
== Protocol ==
Waypoint transmitters emit the code at a rate of 38400 bit/s. At each sequence, the waypoint transmitter sends out 24 bits containing its unique ID (16 bits) plus 8 additional bits that consist of the type of protocol and checksum. The overhead from the uart protocol adds 6 more bits (1 parity + 1 stop bit for each Byte sent).
[[Datei:Locodoco irtest.jpg|thumb|right|200px|Test setup for the position tracking system]]
[[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:
In detail, the sequence looks as follows:
   [ 2b protocol type, 2b output number, 4b xor checksum | 16b ID Code ]
   [ 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) and 32 bits are sent at each broadcast, the maximum speed at which the system can reliably (receiving >= 2 beacons while passing the point) receive information is 6m/s (=21.6 Km/h). - which is more than enough, even for the fastest trains.
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 ==
The type field contains the type of beacon (or message). The following 2 types are currently defined:


'''This Page is part of the [[Locodoco]] Project.''' [[Locodoco|Return to the Locodoco main page »]]
0x1 UUID beacon
0x2 Management command
 
=== UUID beacon ===
The UUID beacon contains a unique ID, which is freely assignable by the user.
 
=== Management command ===
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.
 
 
{{LocodocoNavigation}}

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
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