Continuing to push/expand my limits: Dealing with overflow

[gpsmith]

I have a curious situation with a sensor that I'm hoping you guys can help me with...

I have a 16-bit binary value coming out of a chip.  I can read this well enough, but from time to time the signal exhibits an overflow behavior (going from near values near 65535 to values near 0 in one read and back again). This comes from the chip and not any read problems in LV, and I don't see any settings to be able to adjust it on the chip side....

I'm wondering if there are any strategies for dealing with this on how I interpret the data.  Ideally, I'd like to simply shift the low values up, but I'm having trouble figuring out how to reliably to apply that.  I was thinking that if the signal dropped by 2^15, that'd be a big enough flag; I just don't have any feel if that's "legit".

Thanks for any thoughts!

[ToeCutter]

Yes there are strategies and yes your idea is potentially reasonable. Whether it is applicable depends entirely on what these 'magic numbers' coming from your chip represent, and you have told us absolutely nothing about that.

What does the value represent?

Is there any relationship between one value and the next? e.g. if it's the output of a counter/accumulator

Are there any further limitations on the output? e.g: count should only increase

[johnsold]

One more question: What is the largest change which can occur between readings (not including the rollover)?

Lynn

[gpsmith]

My apologies, it's more from a "uncertain what's important" oversight than anything else...

This is an 6-axis IMU, whose output I see after an internal ADC.  The chip sets itself to range limits on the accelerometer (+/-2g) and gyro (+/- 250 degrees/s).  There's some noise in that signal, and while a lot of it seems reasonable, I occasionally catch the outside limits with casual testing.  I can reset to larger limits, but that loses sensitivity.

So, to answer your reasonable questions:

1) Value represents acceleration (before scaling against the limits)

2) There is no relationship between one and the next (solely dependent upon the IMU motion)

3) Largest change could conceivably change across the entire range in one reading (if we aggressively shake the IMU), but it's too early to say if that would be normal.  At the moment, all tests are in a static case, suggesting we shouldn't hit that realm.

Thanks!

[johnsold]

Your answer to 3) makes it entirely a judgement call on your part. If the value changed from half of full scale to half of full scale - 1LSB on successive readings, you would be unable to judge whether this was the smallest resolvable reduction in acceleration or someone just launched it with a golf club giving it a full range increase with overflow.

Realistically, if your final application can have changes of acceration that large and fast, then you do not have a fast enough sensor to make unambiguous measurements.

Could your "spikes" be the result of impacts on the device being measured or "slips" (think miniature earthquakes) where two parts of the device suddenly move to relieve accumulated tension? If so, they might be real accelerations which occur sporadically and have short durations.

Lynn

[gpsmith]

From what I'm seeing, I doubt it (attached is a screenshot of representative data).  The problem seems to be cropping up when I'm "resting" near an extreme, but the noise/transient/whatever appearing sporadically crosses past the edge and overflows. If I didn't know better, I'd interpret it a sporadically losing the signal.  Trouble is, I don't go to zero, I go to a value within the measured noise of the signal.

I'm collecting at about a 1kHz rate, and the IMU is stationary (though admittedly hanging in the air on stiff wires, haven't bolted it down yet 🙂 )

[ToeCutter]

So that graph shows 700 samples, right- so 0.7 seconds? From what you're saying, this is position (double integrated acceleration) rather than direct accelerometer output. So yes, it's a glitch- the arm can't possibly travel full range in such a tiny fraction of a second and back and two axes go from long term fixed value to around 0 at the same reinforces that conclusion.

It's not an overflow- it's a glitch of some sort. Filter it out or reject it, e.g-

IF abs(difference between current sample and last sample) > (max velocity*sample interval) THEN ignore sample and replace it with average of surrounding samples.

[gpsmith]

It is acceleration, before integrating for position. I wonder if it might be some sort of timing issue in the chip and I just happen to catch a value as it's resetting, or some sort of voltage variance.

I will also think about filtering 🙂

[ToeCutter · Accepted solution]

If it's acceleration, how can your 'resting' arm be showing constant, high accelerations and x, y and z axes? How can your acceleration only ever be positive and never negative?

It doesn't explain what your example graph shows, but if as you said earlier you see numbers going from 65535 to around zero, it could be that you are reading an I16 and somehow casting it or misinterpreting it as a U16.

Then, for a noisy signal around zero,

I16 of -1 cast to U16 gives 65535

I16 of 0 cast to U16 gives 0

[gpsmith]

That's a _very_ interesting possibility...

The data is being read through NI-845x I2C Write Read.vi, which has an unsigned U8 output.  Two of those get combined to form the 16bit data (high and low byte).  I hadn't thought about signed vs unsigned.