I’ve updated the graph that logs the raw data from the sensor to show the errors as vertical red bars and the time error as a green line:
Now I can see what was in the logs in real time.
angle.py has the concept of a “duplicate” reading. This is the most common error and really the only one we could do anything about. The sensor tells you (in some way) that its not ready to give a new reading yet. I call this a sample_not_ready error. Because the clock in the sensor and the MCU are never going to be perfectly aligned this always happens on some timescale.
This really bugs me. I really think we should re-try the sensor to get that reading. Especially for a probing application, a re-try would improve accuracy at the critical moment.
A re-try would have to happen at a frequency higher than the sample frequency to be of any use. This has the downside of increased MCU load when a sample_not_ready error occurs. If I keep the existing monotonic sequence of wakeup times this load would be repeated for every wakeup as the clock drifts.
The alternative is to go to sleep for the full rest_ticks after a successful reading so the next reading is aligned with the sensors clock. But then the sequence of readings isn’t tied to the monotonic sequence and the clocks need syncing.
These events are rare. I could send back a synchronization frame when they happen with the 32 bits of clock. Just reserve tcode == 0xFE as the code for a synchronization frame and put the time in the payload. The next data point reported in the sequence was read at that exact clock time. The payload is already 32 bits so the payload size stays constant. I know I can use clock32_to_clock64() to convert that to chip clocks.
Seem like a sane idea?