Hi,
On 12 Dec 2016, at 23:17, Kevin Townsend wrote:
Hi Sterling,
One other important question is what happens when we don't respect the
read request intervals between data samples?
In the accel sim (really nice to see sim examples, BTW ... that's
extremely useful to test sensor algorithms), you just check the number
of missing samples from the last interval and generate that many new
samples to fill the gaps:
https://github.com/apache/incubator-mynewt-core/compare/develop...sensors_branch#diff-1c17a623363565318dfefdb8891c0376R148
A lot of DSP algorithms are timing sensitive, though, such as sensor
fusion with accel/mag/gyro inputs, where you want to samples as close
as possible to a fixed rate like 50Hz or 100Hz, and the three
components read together as closely as possible (though timestamp at
least lest you know the difference between components).
Raising some sort of alert when a sample is missed might be a better
choice, or having the option to indicate which of the two behaviours
should be used by the timer when a sample interval is missed:
- 1. Read multiple values (default behaviour?)
- 2. Raise a missing sample alert
What is the failure condition when a sample is missed look like? My
assumption was that this would be, for example, a FIFO overrun on a
connected sensor that you are polling for data.
As a primer on how the polling works for those who haven’t looked at
the code, it essentially reads a sensor at a fixed rate of ms, and then
for each value read from the sensor, it calls the passed sensor read
callback. I had a few thoughts here:
- a “cookie” that represented a single poll sample set. So every
time you get a result, you will know its a part of a given poll set, and
can use that, for example, to assume that sensor readings were all taken
at a given time.
- a time associated with the sensor reading. however, it didn’t look
like most of the sensors I saw took this time into account, so I think
the cookie could be more relative.
- If the FIFO overruns, it would be nice to know for a given sensor set
that you are polling incomplete data. However, this did not seem to be
something that was portable, and it could lead to very nasty edge cases
where you expect it to, but the underlying interface doesn’t support
it.
I guess another failure condition is that you are late in processing an
interrupt (locally on the processor), or your task gets locked out for
too long and you miss a poll. However, I’m not sure if you want to be
putting strict requirements on this task — I think we’d just want to
log a delay / statistic every time we get locked out for more than
’n’ ms.
Sterling
