400g triple axis i2c accelerometer

[Chad]

I know for most rocketry purposes the standard accelerometer breakout boards you find online won't work because of the high acceleration during boost. I was browsing adafruit and ran across a 400g accel breakout board interfaced to an i2c bus using Qwicc/stemma qt ( jst ph 2mm ) connectors. It's pretty expensive but looks like it would work for a DIY rocket IMU ( as far as acceleration measurement is concerned )

just an FYI

https://www.adafruit.com/product/4627

 

[cerving]

The ST H3LIS family of accelerometers only has a 256-bit resolution, so although they can register high G's you'd probably only go with the 100G setting, with about a .5G resolution. For launch detect or apogee detection, I'd really want about .1G or better.

 

[UhClem]

The ST H3LIS family of accelerometers only has a 256-bit resolution, so although they can register high G's you'd probably only go with the 100G setting, with about a .5G resolution. For launch detect or apogee detection, I'd really want about .1G or better.

I think you meant 8 bit resolution. The datasheet for the H3LIS331DL lists resolutions of 49mg, 98mg, and 195mg/digit with a 12 bit representation. Keeping in mind that the AltAcc2A used an 8 bit ADC and managed to do OK. (Sometimes noise helps.)

I am not impressed by its low pass filters. A cutoff frequency (I seem to have missed the filter order/type) greater than Nyquist just doesn't work for me.

 

[cerving]

I think you meant 8 bit resolution...

Yeah, that... 256 values full-scale. The AIS1120 120G accelerometer in the Proton is 14 bits full-scale, although it's only available in one and two axis versions. Roughly .015G per LSB, and the built-in filter works really well (although we do run the data through the same filter as the baro, so when we do the baro-accel altitude comparison we're doing apples-to-apples).

 

[SparkyVT]

I use this sensor in my flight computers and I'm really happy with it. I use two accelerometers onboard, switching to the H3LIS331DL when the G-load exceeds the limits of the IMU. When set to the 100G setting, the resolution is 0.049Gs per LSB, which is about 20 steps per G. I can't speak to low pass filtering, because I don't use it. I use a moving average of about 15 points and the signal is about as good as less G-capable sensors. Below is a comparison of the averaged H3LIS331DL output to the raw LSM9DS1 output.

 

[AllDigital]

You have to be doing some insane things to exceed 100g's with our rockets, so 400 g's is overkill. We use two accelerometers on our board, a 200G ADXL375 and a 32G LSM6DSO32. The chips aren't cheap and are getting harder to find, but they are available on break-out boards for DIY. The 32G is higher resolution and the 200G data stream is used when going over 32G's. We've run dozens of 15K flights with both of them and it is fascinating to see the data side by side. Since we correct for bias on the pad, they both integrate velocity accurately to apogee within milliseconds apart. Also, we routinely exceed 32G's, but the LSM6DS still nails apogee within milliseconds, since the "pegged time" is equally up and down. That said, it is very helpful to have the higher gee data. On a two stage flight last Saturday, our separation charge was oversized and it popped at 66 gees of force on the sustainer. It worked just fine and there was no damage, but we could see in the data that the charge was way oversized -- and it put the electronics and other components at risk. We also don't use any filtering, as it messes with the velocity integration.