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?
Thanks for your feedback.
Best regards,
JB
From: Martin Kelly <mkelly@xxxxxxxx>
Sent: Monday, March 26, 2018 19:43
To: Jean-Baptiste Maneyrol; Jonathan Cameron
Cc: linux-iio@xxxxxxxxxxxxxxx
Subject: Re: How to handle missing timestamps? (was Re: [PATCH] iio: imu: inv_mpu6050: improve missing timestamp handling)
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.
--
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
