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

[Jean-Baptiste Maneyrol <JManeyrol@invensense.com>]

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 ir=
q thread can take too much time and we loose interrupt). In this case manua=
l 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?

Thanks for your feedback.

Best regards,
JB


From: Martin Kelly <mkelly@xevo.com>
Sent: Monday, March 26, 2018 19:43
To: Jean-Baptiste Maneyrol; Jonathan Cameron
Cc: linux-iio@vger.kernel.org
Subject: Re: How to handle missing timestamps? (was Re: [PATCH] iio: imu: i=
nv_mpu6050: improve missing timestamp handling)
=A0=20

On 03/26/2018 07:20 AM, Jean-Baptiste Maneyrol wrote:
> Hello,
>=20
> 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 alwa=
ys a different story.
>=20

Agreed.

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

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

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

That sounds reasonable. Let me make sure I understand what you're=20
proposing. Let's say we have set the sample rate to 10 Hz. Every time we=20
get an interrupt, we already take a timestamp, which should be the=20
correct timestamp for the most recent sample. Imagine that after an=20
interrupt, we see there are 4 samples in the FIFO instead of just 1. In=20
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.
    =