On 03/27/2018 01:47 AM, Jean-Baptiste Maneyrol wrote:
Hello,
this raises a good question of which interrupts we are missing (the oldest ones or the newest ones).
My bet would be that we are loosing interrupts from the newest data (the irq thread can take too much time and we loose interrupt). In this case manual timestamping would rather be:
sample 0 (oldest timestamp): interrupt timestamp
sample 1: interrupt timestamp + 0.1 seconds
sample 2: interrupt timestamp + 0.2 seconds
sample 3 (newest timestamp): interrupt timestamp + 0.3 seconds
Can you check with your setup that this is really what is happening?
Yes, good point. I did a lot of testing and determined that the sequence
of events is something like this:
IRQ --> timestamp
new datum
new datum
new datum
IRQ --> timestamp
Specifically:
- At 50 Hz, interrupts are being generated at about 30 Hz.
- The timestamps in the FIFO correspond to the *newest* data, not the
oldest.
I tried interpolating using both assumptions: timestamps corresponding
to oldest and then to newest data. Using timestamps corresponding to
oldest data, we get timestamps that are not monotonically increasing and
thus time moving backwards as the data flows. Using timestamps
corresponding to oldest data, we get monotonically increasing time as it
should be, and the data looks pretty consistent.
What I settled on is to use the newer timestamps we see to backdate the
older data, the ones we remove first from the FIFO. It appears to be
working nicely.
I sent a v2 of the patch that does this interpolation.
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
