Altus Metrum EasyTimer; exceeding max acceleration, result?

[StreuB1]

Does anyone know for a fact, what happens when you exceed the maximum acceleration of 16 G's on the EasyTimer?

As expected, there is extremely poor documentation on their products and after going through their entire "consolidated" documentation PDF, I have yet to see anything that says what happens if/when you exceed the max acceleration on their products from a software/operational POV. I might have missed it and if that is the case, if someone can point it out to me, that would be great.

I have not attempted to contact the MFG as based on other threads, they are a 2-man show thats down to 1-man trying to do everything. Given that, I don't expect a response and figured it might be best to reach out to a wider audience.

Thanks in advance!

 

[mikec]

I don't feel like going through the AltOS source to see if I can tell for sure, but from software I've written for similar accels it will simply underestimate the velocity by some amount (since the true acceleration will be higher than indicated.) For the EasyTimer that should be benign, though I agree with everyone who says the documentation is far from clear for this product. Burnout detection and timing from launch and burnout should be unaffected.

 

[Grog6]

If you exceed the chip limits by too much, it will damage the accelerometer chip. If you look it up on digikey, you can get the chips datasheet; it will tell you what happens in odd situations.

 

[mikec]

If you exceed the chip limits by too much, it will damage the accelerometer chip.

The BMX160 9-axis chip is rated for mechanical shock of 10,000g for 200 microsec and 2000g for 1 millisecond so for typical rocket accelerations I think it would probably not be damaged, but I'm not sure I'd take it beyond 50g or so. https://www.mouser.com/datasheet/2/783/BST_BMX160_DS000-1509610.pdf

 

[Grog6]

Some chips give odd outputs when you exceed the operating range, I used an adc years ago that the outputs all inverted. that was fun, lol.

 

[Grog6]

That's a neat chip; I need to get one to play with.

 

[StreuB1]

The unfortunate part is that 16G's for HPR is not that high. I find it odd that they would set it rather low and then not tell you why or what happens when you exceed it. More so the latter as I guarantee that many people that have used them, exceeded that maximum.

I need it for staging so the reality is, I just need the accelerometer to accurately measure ignition and burnout and then tilt. If altitude calc's get wonky, then knowing how they get wonky would be helpful so I can at least open up the window for altitude as a loose 3rd qualifying parameter.

 

[mikec]

The unfortunate part is that 16G's for HPR is not that high. I find it odd that they would set it rather low and then not tell you why or what happens when you exceed it.

They didn't set it this way, it's a fundamental limitation of the IMU they picked. AFAIK all such chips all have similar limitations; you would need a separate high-g accel chip to not have this limit.

Agreed that AM has never valued documentation quality very much. In the case of the EasyTimer I'm not sure what conditions are supported and if you can even have an altitude gate.

 

[JimJarvis50]

I asked Keith the question about using an "altitude check" as a permissive with the EasyTimer. Here is what he said:

"The biggest issue is that the accelerometer in EasyTimer has only +/- 16g range, so if the flight expects to accelerate harder than that, the integrated speed/altitude will be inaccurate. Otherwise, the double integration of acceleration to compute height is pretty good as the measurement of the accelerometer is much finer than our +/- 200g units. You'll want to make sure to re-calibrate the accelerometer before flight using AltosUI to get the zero-points as close as possible."

Although he wasn't specific about the nature of "inaccurate", what I have seen with other IMU's is that the acceleration value pegs at the maximum value. So, the calculated altitude and velocity would be low if that's what happens.

Jim

 

[jbr]

interesting to see others with documentation issues, guess I was not the only one, but maybe I was too vocal

 

[mikec]

Although he wasn't specific about the nature of "inaccurate", what I have seen with other IMU's is that the acceleration value pegs at the maximum value.

My recollection from having done the analysis for a similar homebrew system I built was that having the accel pegged for a little while during boost didn't affect the time of apogee estimate very much, but did affect the absolute estimate of apogee altitude. It's fairly easy to take some sim data out of OpenRocket and model what would happen with the double integration if the accel value was clipped.

I'm skeptical that using an accel-only altitude gate is really providing much extra safety. The flight path can be very squirrely but the axial acceleration fairly normal, and so the derived altitude could easily be very wrong. If the tilt value is managed properly then you shouldn't really need an altitude gate?

FWIW, I'm waiting for the Featherweight product with tilt sensing, having lost confidence with AM from experiences with previous products and the poor state of their documentation. YMMV.

 

[JimJarvis50]

My recollection from having done the analysis for a similar homebrew system I built was that having the accel pegged for a little while during boost didn't affect the time of apogee estimate very much, but did affect the absolute estimate of apogee altitude. It's fairly easy to take some sim data out of OpenRocket and model what would happen with the double integration if the accel value was clipped.

I'm skeptical that using an accel-only altitude gate is really providing much extra safety. The flight path can be very squirrely but the axial acceleration fairly normal, and so the derived altitude could easily be very wrong. If the tilt value is managed properly then you shouldn't really need an altitude gate?

FWIW, I'm waiting for the Featherweight product with tilt sensing, having lost confidence with AM from experiences with previous products and the poor state of their documentation. YMMV.

I think an altitude check should be used. The tilt has to be within limits, but it is possible for a flight to be coasting to a stop and still be within the tilt limits. You wouldn't want to light a sustainer in that case, and the altitude check is the way to avoid that. The altitude check has to be a significant fraction of the expected altitude (e.g., 75+%) to get much benefit, but even a lower altitude check ensures that the rocket is at least a lot further away if things go bad.

Jim

 

[jbr]

Featherweight making a tilt timer?

 

[mikec]

I think an altitude check should be used.

Agreed as a rule certainly. I'm just not sure that something without a barometric sensor can really implement an altitude estimate that's robust in the face of all failures. To really do that you have to reliably integrate 3D position from 3D orientation and acceleration.

My main concern about all of these tilt-sensing systems is how all of the failure modes are managed ("Anyone can build something that works when it works. But it's how it works when it doesn't work that counts.") AM's source code is freely available and auditable, but I've looked at it pretty extensively and not come away with warm fuzzies about it.

FWIW, I'm getting good vibes from Adrian's discussion of his upcoming Blue Raven system over on that thread.

 

[Adrian A]

Featherweight making a tilt timer?

The first production run of the Featherweight Blue Raven is getting assembled now. I have been doing flight-testing of all but the Bluetooth interface, since April. Hopefully by the end of December enough of the Bluetooth interface and phone app will be done to start shipping them. See lots of posts on this sub-forum for results and data so far.