Electronics > Projects, Designs, and Technical Stuff
16bit inclinometer accuracy problem
(1/4) > >>
webgiorgio:
https://www.st.com/en/mems-and-sensors/lsm303agr.html
LSM303AGR is described as a high accuracy 3 axis accelerometer that I use to measure the gravity acceleration and to calculate the inclination (I use it for a solar tracker). I find that the output is very unstable. The oscillations are huge, like 2 degrees. That's far from "high accuracy" in my opinion.
I think I configured the chip correctly (Normal power mode, high accuracy, 50Hz sampling), via i2c. I read at 20 Hz.
Here is a plot of the results, with the inclinometer standing still.
Am I doing something wrong or it is normal for a high accuracy digital inclinometer to be that bad?

The i2c code where I configure the chip:

--- Code: ---void configure_inclinometer(){
  Wire.beginTransmission(0x19); // Set accel
  Wire.write(0x20);             // CTRL_REG1_A register
  Wire.write(0x47);             // 50 Hz, normal power, all 3 axis enabled. 0x47 0b0100 0111
  Wire.endTransmission();

  Wire.beginTransmission(0x19); // Set accel
  Wire.write(0x23);             // CTRL_REG4_A register
  Wire.write(0x08);             // continuous update, littleendian, 2g, high resolution, 4-wire spi //0x08 0b0000 1000
  Wire.endTransmission();
 
}

--- End code ---
Alti:
If that is just plain white noise then you can filter out as much noise as you want, till thermal, slow changing drifts, take over. 12-bit resolution refers to the resolution of ADC converter inside. The "high accuracy" is high relative to "something". Find that "something".
Siwastaja:
Some thoughts in general (didn't look at the datasheet),

What does "normal power" mean? Some IMU products require a higher-power mode for lower noise.

Average the shit out of the readings. If you need very quick response (i.e., quickly moving objects), fuse a slowly averaged gravitation vector from an accelerometer, with gyroscope integral. But I guess this isn't a problem. So just average it.

Then, increase sampling rate: rms noise is approximately the same, but now you can average more samples and still get your desired output responsitivity.

Because the sampling time itself is probably very short, if you sample at lowish sample rates, classical signal processing things apply: you are aliasing high-frequency noise (such as any vibration; even electrical noise) on your band of interest. Oversampling (using higher sampling rate than you need), then filtering and decimating, solves the problem. You can go on and design a nice gazillion-tap FIR filter if you want to for a nice brickwall response, but a simple average, say, sum the readings until you have some 128 samples summed, then divide by 128 and output a value - is nearly as good.

And, of course, average the x, y, z values separately. Calculate the angle with averaged values. I would avoid calculating the angles with noisy data, then average the angles, especially if there is any possibility you encounter a wrap-around of angles.

And wait until you have to work with magnetometers, you'll love the amount of noise and drift you see with accelerometers.

Compensating for the angular error is trivial, calibrate it once on a level surface. Thermal and aging drifts, OTOH, are your worst enemies.

There is a reason a proper module costs $200 while the chip inside costs $2. When you DIY barebones, you need to do the necessary math yourself.
IDEngineer:
Agree 100% with what Siwastaja said, and I'll add the following.

I designed in an ST MEMS chip a few years ago. Fought like crazy to get it to work, but finally got it settled down. Fast forward and it's time to update that design, and that particular chip was considered "not for new design" (MEMS devices seem to have very short production lifespans for some reason). So I found another suitable ST part... and could NOT get it to work. Bug after bug, problem after problem. The worst one was it could get itself into a lockup mode where its SPI/I2C interface became inoperative and there was no way to recover it (since you couldn't issue a soft reset) except power cycle the chip. Since that experience I've always incorporated the hardware to firmware-control the supply rail(s) on MEMS devices. You have been warned.

Eventually I gave up on ST MEMS devices. They abandoned customer support to their online forums. So in addition to troublesome devices, you couldn't count on applications support to get them working. Life's too short.

I revised the design again, this time using a Bosch-Sensortec part. MUCH better. The spec sheet is one of the most disorganized messes I've encountered since the STM32 MCU, but if you're patient and cross-reference all over the place the data is usually in there somewhere. That design is still in production. I did keep the hardware to power-cycle the MEMS device, though. I won't go without it again.

A few more hints:

Do not use the on-chip filters no matter how much they brag about them. I've never found a device where the on-chip filters work properly. If they work at all, they often seem to exceed the part's onboard processing capacity (this was one of the lockup conditions in the ST part mentioned above). Just do your own filtering off-chip in firmware, you'll save tons of time and frustration.

Unless you're in a cellphone or tablet, always run the part at "full power". It's usually microamps anyway and the parts operate far more reliably. The power-saving modes are too much hassle for the theoretical savings.

Definitely run the ODR as high as you can, then filter/decimate in firmware as recommended above. Usually the ODR is inversely related to the max resolution, but seriously consider just how much resolution you actually need. Just eight bits in 360 degrees is 1.41 degrees/LSB... does a solar tracker really need more accuracy than that? Let's say horizon to horizon is 180 degrees, that's ~128 increments. Hard to imagine that you can even measure the impact of "solar misalignment" of less than two degrees. In which case, you can average your raw data in its full 16 bits, and then apply filtering to that, ultimately emitting eight useful bits. You can get very reasonable performance from numbers like those.

Try to do your math in integer format. Unless you're correcting for angular misalignment in real time (in which case you'll have to do dot-product trig and you'll probably want to use floating point), you can get plenty of resolution from integer math while saving gobs of clock cycles.

My biggest tip: Don't get too frustrated. MEMS devices are like a world all their own. They're finicky and difficult, but once you get the feel for them they can work really well.

EDIT: One more thing... many MEMS devices are affected by package stress. For example, if the package is soldered to the board with some twist, that twist can cause what appears to be a DC bias (fixed nonzero output value) on one or more axes. You can experiment with this by twisting the PCB of an otherwise unmoving assembly and watching the "acceleration" values move around (!!!). One solution is to calibrate that out in each assembly. Or, another approach is to route slots in the PCB around three sides of the footprint, so the package is mounted on a sort of "tab" supported on only one side. Obviously all traces have to pass through that tab. This makes it difficult for stress from the outside world to be coupled through the PCB to the package. I ran into this on a product a while back; units would factory calibrate great but their mounting surfaces were not machined flat and imparted some torsion to the enclosure when installed. My solution in this case, rather than revise the PCB, was to deepen the amount of potting compound and change to a compound with greater Shore hardness. We had enough capacity in the enclosure that we could get the more-solid potting compound deep enough to resist stress from external mounting.

Report back!
jmelson:

--- Quote from: webgiorgio on May 21, 2020, 11:55:55 am ---https://www.st.com/en/mems-and-sensors/lsm303agr.html
LSM303AGR is described as a high accuracy 3 axis accelerometer that I use to measure the gravity acceleration and to calculate the inclination

--- End quote ---
An inclinometer can't tell the difference between changes in inclination and horizontal movement.  They are basically a pendulum.  So, unless you have the thing bolted to a granite surface plate sitting on inflated inner tubes, you can't be sure it isn't picking up vibrations through the floor, etc.

Jon
Navigation
Message Index
Next page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod