PHASES
Measurements collected by sensors go through several phases until they are analyzed and results get available:
- Phase 0: an event occurs in reality; this is the phase that will be beyond what we can access. For all times. Events happen in reality at some point in time. No observer will ever be able to detect this at the same point in time, and error free.
- Phase 1: sensor detects an event; this is the phase a technical sensor detects an event has occurred. This can be the time some contact is closed or some GPS chips receives a satellite broadcast. As mentioned for phase 0, phase 1 will always show some latency against the real world event.
- Phase 2: sensor data is transmitted to a consumer (like LapTimer); this is the process of transferring the information from event detection up to the point in time the measurement arrives in LapTimer. This will always include some protocol overhead: the sensor will convert the measurement into some data (using some encoding) and place it as payload into some envelope transmitted to the receiver. The receiver in turn will unpack the envelope and decode the data into a format it can process. Sample: data transmitted from a GPS mouse to a smartphone by Bluetooth. On top of the time required for transmission, the so called sensor update rate hits in. Instead of transmitting data when it is available, sensors will often use some fixed rate to do their processing and transmission of data. Sample again: the internal GPS of a smartphone is operating at a rate of 1 Hz. This means it will submit a measurement up to a second late (compared to phase 0). Higher update rates improve the latency introduced by phase 1.
- Phase 3: preprocessing of measurements; this phase is separated from the general processing phase 4 because it is a distinct and conceptional important phase in LapTimer. A data recording system like LapTimer receives measurements from various sensors. These sensor's characteristics can differ for phase 0 to 2 by a magnitude. Sample: IMU chips measuring acceleration at a high update rate using a chip built into the smartphone will do phases 0 to 2 within some milliseconds while an external GPS mouse with all the time from satellites broadcasting their sync signal to the earth, receiving data, processing it, transmitting it can easily require 2 seconds until data arrives in LapTimer. In addition, not all measurements come with a timestamp representing an approximation of the time the event occurred in reality. So what needs to be done in phase 3 is aligning all incoming measurements to a common time line and fusing data where appropriate. Fusing includes interpolation to align data recorded at different update rates to one universal rate. By default, LapTimer uses the GPS rate for this. The universal rate (named Storage Rate in LapTimer) can be tweaked if necessary. Search for "sensor delay" here on the forum on more information. Before passing data on to the next phase, information for a point in time needs to be completed for all sensors in LapTimer. The result is placed into a queue consumed by phase 4.
- Phase 4: processing fused data and storing results; this is the heart of LapTimer where passing triggers is detected and data is stored in lap chunks. For more information on this phase have a look into the Trigger Logic and Train the Trainer documents available on http://www.gps-laptimer.de/documentation. The later describes the miracle how a 1 Hz GPS receiver can be used to derive timing accuracy of 0.02s!
- Phase 5: display results to user; this is simply displaying results to users in "real time". This phase is separated because it is what you experience when racing. LapTimer beeps when having passed s/f, this is done in phase 5. Displaying the lap time once a lap has been completed is in this phase too.
DISCUSSION
All of phases 1 to 5 add latency compared to what happens in phase 0. You as a driver will have a pretty good feeling for phase 0. We humans can look ahead what will happen next and know about crossing the s/f next. So you will realize the actual event of passing s/f although it will be slightly behind or ahead (in-accurate). LapTimer however runs though phases 1 to 5 before is knows about the result of passing s/f "precisely" and report it late. This is the reason the FAQ question "LapTimer triggers late, is this a problem?" is raised by users at all.
From the phase description above you may realize already it is actually no problem for the precision of lap timing. Although LapTimer is late with reporting, is will have phase 1 information finally and make its calculation based on this. Especially because GPS data is coming with a solid timestamp, it is possible to not only derive precise lap times, but store data for later analysis with the phase 1 timestamp matching reality best.
To get a feeling for typical latency, let us go through some samples. The phase 0/1 latency will be very low - sub-millisecond - for most sensors. GPS is different because phase 1 will include the complete time the signal sent by satellites travels to earth. In addition, deriving a position from the satellite almanac is a comparably expensive operation. For GPS, we get several tenth of a second latency in phase 1 already! Next, sensor update rates need to be added. For a 1 Hz device, this is an adder of up to a second. Transmission is sub-millisecond for wired sensors (like internal) and a few milliseconds for WiFi and Bluetooth connections used for external sensors. In addition, conflicts in wireless transmission may add any latency on top. This is the reason we encourage disabling all gadgets you have in your car when using external GPS or engine sensors. Phase 3 latency is defined by the slowest updating sensors. For most users, this is the GPS sensor. To finish fusion of all sensor measurements to a fix, all sensors need to deliver values ahead and behind of the GPS measurement to allow proper interpolation. Sample: GPS delivers a position every second (1 Hz), OBD delivers at 8 Hz and IMU delivers at 30 Hz. To "close" the fusion for the GPS fix, LapTimer needs to wait up to 1/8s for the engine measurement and 1/30s for the acceleration. So for this scenario, we get an 0.125s adder from engine sensors. In case the OBD is slow or even worse - drops out - this adds up on top.
Let us sum up some scenarios [phases in brackets and sub-milliseconds set to zero]:
#1 Internal GPS and internal acceleration: 0.5s [1 GPS] + 1.0s [2 GPS] + 0.03s [3 IMU] + 0.02s [4] + 0.01s [5] = 1.56s
#2 Internal GPS and OBD updating at 2 Hz: 0.5s [1 GPS] + 1.0s [2 GPS] + 0.5s [3 OBD] + 0.02s [4] + 0.01s [5] = 2.03s
#3 Internal GPS and OBD updating at 8 Hz: 0.5s [1 GPS] + 1.0s [2 GPS] + 0.12s [3 OBD] + 0.02s [4] + 0.01s [5] = 1.65s
#4 External GPS 10Hz and OBD updating at 8 Hz: 0.5s [1 GPS] + 0.1s + 0.01s [2 GPS plus BT] + 0.12s [3 OBD] + 0.02s [4] + 0.01s [5] = 0.76s
These examples need to be considered "best case". In reality, you may want to add half a second on top.
Just to make sure I want to repeat: this latency influences the perception of the users, but has no influence on timing / data accuracy.
OPTIMIZATION
One potential optimization is clearly to make a forecast on what will happen next based on information from the past plus an extrapolation to the future. So something similar we humans do when driving towards the s/f line. I consider this for triggering video recordings because precision is not an issues here as long as video recording starts ahead to the start and not once the final result is available approximately 2 seconds after passing s/f.
Another optimization is applied already. When displaying data like engine rpm or acceleration in real time, LapTimer accesses phase 2 information directly. This means you will see raw sensor data and not the fused data stored to the database later. Results will still not be as snappy as your in-car dashboard (which has a direct connection to the CAN bus and not go through the slow OBD gateway), but they will not be affected by phase 3.
TL;DR
Due to signal run times and processing times, any measurements processed by LapTimer are "old". This results in late notification of events. However, LapTimer can compensate the latency when deriving lap times. So data stored and times reported are precise despite they get available with some latency.
