One of the biggest challenges in this project is ensuring the start signal is reliable and timely—that is, the finish line (which keeps track of timing) is informed by the start line when a racer enters the course in a manner that works 100% of the time and is not heavily delayed, as this could reduce the accuracy of timing.
The Xbees are good for basic wireless transmission, but simply using them in transparent mode guarantees very little. There is no guarantee data will make it to the receiver, no guarantee that data that does arrive is fully intact, and no guarantee data will arrive quickly. If these features are needed as is true in our project, they must be implemented in software. For the timing gate, we are developing a custom communication protocol to include just the features we need. A preliminary specification is given below.
Data is packetized for transmission. In our protocol, packets are anywhere from 16-32 bits. Each packet can serve one of two purposes: data or control. The data packets are those that accomplish the devices primary function—starting a timer. Control packets ensure the start and finish lines are connected and properly calibrated to ensure times are accurate. Each type of packet will use its fields differently
Data Packet Contents
Length- The length field specifies how many bits are in the content field. It ranges from 1 to 16.
Type- The type field is a binary number from 0000-1111 (0-15). This is what indicates the purpose of a packet. The packet could be a signal to start a timer because a racer has entered the course, or it could be a packet requesting an acknowledgment from the finish line as soon as possible to calculate the delay in the connection, or it could simply be a packet requesting a response to ensure a reliable connection is established.
Content- The content field holds data relevant to the packet type. For a data packet, it could be empty, as there is no data to send beyond the fact that a racer has started. For a control packet, it could contain the delay that has been calculated between the start and finish lines so the finish line can take this into account when calculating times.
CRC (cyclic redundancy check)- A CRC is a type of checksum that ensures the integrity of the data in the packet. It comes from a mathematical calculation performed on the binary representation of the packet. If the packet changes, the CRC will change. When the packet is received, the CRC is performed again. If it doesn't match the transmitted CRC, the packet is discarded. In a more complicated protocol, the packet might be requested again if dropped, but for the purpose of our lightweight protocol, this is unnecessary. The only vital packets in our system are the packets that start the timer, and their transmission can be near guaranteed simply by sending them multiple times.
Delay Calculation Process
Throughout this post, I have hinted at a system to synchronize the start and finish line. It is quite difficult to have millisecond precision wirelessly, since packets take time to transmit. Instead, the device will periodically determine the delay between the start and finish lines. Then, the finish line will add this delay to the finish times to make them accurate. Below is a rough outline of how this delay will be calculated.
Start Line illuminates a red LED to inform user to wait for sync process to finish before continuing. Then, a packet is sent to the finish line, requesting a response as soon as possible. The start line simultaneously starts a timer
Finish Line receives packet, and sends a response packet as quickly as possible back to start line
Start Line receives response packet and stops timer. Start line divides the timer value in half and stores this value. This is the approximate time it takes a packet to travel from the start line to the finish line. Start line illuminates green line to show device is ready for racers to start
Every time the Finish Line receives a racer start packet, the approximate delay is sent along as well. The finish line adds this delay time to the racer's final time to ensure all times are accurate.
This process is redone periodically to ensure timing is accurate. The hope is that even with this rudimentary calculation will improve the accuracy of the device to the point where it is a valid option for timing alpine ski races.