Precision, accuracy and time synchronization - etemu/satar GitHub Wiki
The accuracy of any logged events depends on various factors mostly based on hardware setup and network topology.
One Satar Node
In a typical race situations, the participants are racing against each other and their result is determined by their run time in relation to their racing class. Good precision with enough spacing between the participant's run times is preferred over accuracy. Relative values should be precise and with low deviation, but absolute values are not of much interest.
Calculating the accuracy for a given Satar-chain starts at the hardware instrumentation which supplies the node with real life information, i.e. a start gate with a release switch, a light barrier, pressure plate, RFID tag receiver.
Most industrial single-beam safety light barriers are waterproof (IP67) and suitable for dusty environments, for example:
- ABB's Spot 35 T/R transmitter/receiver (0 - 35 m, EN 954-1, ISO 13849-1)
- SenSick WL160 reflex (-P440, 0 - 2 m)
The latter has got a polling rate of more than 1 kHz and a reaction time of less than 0.5 ms. Those figures are not really of any interest for a timekeeping system, again because we are not after accuracy, but rather a high precision. Repeatability or deviation is most important. The repeatability of the mentioned SenSick WL160 light barrier is better than 0.5 ms = 0.0005 s.
The timekeeping instrument is connected to a Satar node. An ISR (Interrupt Service Routine) at the controller's port pin is enabled whenever a signal change is happening, with a repeatability of ( 1 / F_CPU x prescale ). A typical value would be 4 µs = 0.000004 s for a CPU frequency of 16 Mhz and a quantization of 4 µs.
No further deviation is introduced after this point - The event is now a digital number, saved with a precision of 1 µs = 0.000001 s.
Counting all delays together, we have a worst case deviation of approximately 0.0005 s + 0.000004 s = 0.000504 s = 0.504 ms. In most cases, there are at least two timing instruments attached, i.e. a gate switch at the start and a light barrier at the finish line - A value of 1 ms seems realistic.
Drift is assumed to be linear and neglected.
Two or more Satar Nodes
Further deviation is introduced with the fact, that both nodes have their own clock and both clocks have a drift and are not in sync. Trivia: There are no clocks without drift, not even the best clocks in the universe are without drift, e.g. Glonass/GPS.
Everything comes down to crystal/resonator deviation at the MCU. The frequency source has got a drift which is not constant and changes with temperature, supply voltage, age and stress/load. If we work with multiple nodes, then there should be either a high accuracy (absolute timing with no drift - because drift integrates to a high deviation over time) or a synchronization between the nodes' clocks. The former is almost impossible, even with a drift of 1 ppm from a rubidium clock the drift would accumulate to a precision of worse than 0.1s in less than a day. So the later is the way to go. If we achieve a good periodic sync between the nodes, the race results should be precise and consistent, even after a long time.
SatarNodeHelpers/NodeTimetravel contains a model of the synchronization algorithm. Tests with two Arduino UNO boards, one with a crystal, one with a ceramic resonator, gave the following results:
| delta reported by node 1 | delta reported by node 2 | delta of both deltas |
|---|---|---|
| 2720125 | 2720115 | 10 |
| 2722703 | 2722705 | -2 |
| 2725317 | 2725313 | 4 |
All values in µs (1 x 10^-6 s).
They were both reset simultaneously and started with a delta of 3000 µs. A quite constant cumulated drift of 868 ppm was measured over an interval of 1 hour between both nodes. Note that this does not say anything about their accuracy: One node could drift -1000 ppm and the other one -1868 ppm, or both just +/-434 ppm. The third column shows that each node has got a pretty good clue of the other's time. Their deltas do not deviate more than 16 µs = 0.000016 s in this particular network topology with a sync interval of 3 s. If the drift is linear, we can interpolate and extrapolate with low deviations.