Re: How to handle missing timestamps? (was Re: [PATCH] iio: imu: inv_mpu6050: improve missing timestamp handling)

[Martin Kelly <mkelly@xevo.com>]

On 03/26/2018 07:20 AM, Jean-Baptiste Maneyrol wrote:
> Hello,
> 
> we should have 1 interrupt every time a sensor data has been acquired. So in theory this is not something that should happen. But real world is always a different story.
> 

Agreed.

> Do you have a case where you saw that happen?
> 

Yes, I'm seeing this on a board I'm working with. I'm also seeing I2C 
bus lockups at high frequencies, so my best guess (though speculation) 
is that the interrupts are being generated by the bus is dropping some 
of the messages. I'm seeing that, when the data ready interrupt fires, 
there are multiple messages in the FIFO, so all but the first get filled 
in with 0 timestamps. I plan to investigate why I'm getting bus lockups, 
but since this is exposed a bug, I wanted to first work on improving the 
resilience to such conditions.

> The best way if this happens would be to create the timestamp based on the sampling rate since we know it (last timestamp + sampling interval). That would be very similar to the real value since the only difference is  the clock drift between the chip and the system.
> 

That sounds reasonable. Let me make sure I understand what you're 
proposing. Let's say we have set the sample rate to 10 Hz. Every time we 
get an interrupt, we already take a timestamp, which should be the 
correct timestamp for the most recent sample. Imagine that after an 
interrupt, we see there are 4 samples in the FIFO instead of just 1. In 
that case, we mark the samples with timestamps:

sample 0 (oldest timestamp): interrupt timestamp - 0.3 seconds
sample 1: interrupt timestamp - 0.2 seconds
sample 2: interrupt timestamp - 0.1 seconds
sample 3 (newest timestamp): interrupt timestamp

Does that sound right to you? If so, I will revise my patch to do it.