Altimeter with Accel based Variometer

[thomas]

Hi,
does anybody know an Altimeter with a variometer which is based on acceleration data, which can be used as a high speed falling detector after apogee?

I would like to have something like this:
If Apogee was deceted by acceleration based speed and after that speed gets lager than x or lower than -x -> fire ecjection charge.

The Raven2 has such a feature but it can not be used as a high speed falling detector after apogee.
Mainly due to the fact, that there is no "apogee has been detected before" setting.

You can trick it with using the baro based descending option, but i do not want to relay on baro data, especially if it has no kalman filtering.

SALT-3R has also some build in variometer, but it is based on unfiltered baro data.

I could reprogram a telemtrum, but that's not so easy.

 

[Larry Curcio]

As far as I know, there is no such thing as a high speed falling detector based on an accelerometer.

 

[fyrwrxz]

Tall to Adrian at Featherweight -see if he mite build you something. This mite be more software based than hardware.

 

[troj]

Explain the problem you're trying to solve, and folks might be able to better suggest a solution.

-Kevin

 

[jderimig]

Impossible with current single or 2-axis accelerometer based devices.

You can approximate vertical descent speed up to moderate speeds by simply setting a delay after an accelerometer based apogee assuming a normal gravity.

 

[bobkrech]

https://en.wikipedia.org/wiki/Variometer Mt variometers are barometric devices.

The SALT-3R is a barometric device as well. https://www.gau.de/SALT3/SALT3R_50.pdf

Bob

 

[Adrian A]

Hi,
does anybody know an Altimeter with a variometer which is based on acceleration data, which can be used as a high speed falling detector after apogee?

I would like to have something like this:
If Apogee was deceted by acceleration based speed and after that speed gets lager than x or lower than -x -> fire ecjection charge.

The Raven2 has such a feature but it can not be used as a high speed falling detector after apogee.
Mainly due to the fact, that there is no "apogee has been detected before" setting.

You can trick it with using the baro based descending option, but i do not want to relay on baro data, especially if it has no kalman filtering.

The Raven's accel-based velocity check is only applicable while the rocket is pointed upward. After apogee it should be disregarded.

The Raven's "pressure increasing" and "pressure decreasing" are heavily filtered so that they can be relied upon to be accurate for the subsonic portions of flight. Having a flight trigger for a user-settable descent rate could be done, but generally if you're trying to minimize deployment stress, it's best to do it at the minimum velocity time (apogee). Backup charges can be done with a variety of altitude or apogee-detection options. If you need a deployment to happen at some point on the way down, basing it on a particular descent rate could be tricky because depending on drogue configuration, etc, the rocket may not achieve that descent rate on the way down. It's not a good idea to land with unfired charges (personnel and fire hazard) so I would not recommend using setting up a backup charge that may or may not fire according to descent rate. What application this would be for?

 

[Reinhard]

A little background to the SALT3. It's variometer function activates the main chute. The idea behind it, is to prevent a high speed deployment in case something goes wrong at apogee. The default settings are somewhat low, so a couple of fliers experienced unplanned main at apogee flights. If I remember correctly, I set mine at 27m/s and never had any issues. I like the feature, but had never "used" it so far.

A pure accelerometer based variometer (in its strictest sense) can't work. In theory inertial navigation might do this. I've talked to guy earlier this year, who is part of a team that works on inertial navigation in rockets. He mentioned that they are still not capable to mention lock after the ejection of the parachute. This is hardly surprising, given how the rocket is usually jerked around at this moment and the range of the sensors involved.

One trick that might be able to replicate the fall back feature of the SALT with an accelerometer is to sense the absence of free fall after apogee and use this to trigger the main after a certain threshold. But this can't be called a variometer anymore. Accelerometer based designs usually have barometers too, so I don't think anybody will see the need to try this.

Reinhard

 

[bobkrech]

The Raven's accel-based velocity check is only applicable while the rocket is pointed upward. After apogee it should be disregarded.

The Raven's "pressure increasing" and "pressure decreasing" are heavily filtered so that they can be relied upon to be accurate for the subsonic portions of flight. Having a flight trigger for a user-settable descent rate could be done, but generally if you're trying to minimize deployment stress, it's best to do it at the minimum velocity time (apogee). Backup charges can be done with a variety of altitude or apogee-detection options. If you need a deployment to happen at some point on the way down, basing it on a particular descent rate could be tricky because depending on drogue configuration, etc, the rocket may not achieve that descent rate on the way down. It's not a good idea to land with unfired charges (personnel and fire hazard) so I would not recommend using setting up a backup charge that may or may not fire according to descent rate. What application this would be for?

Adrian

The SALT-3R analyzes the barometric data (it doesn't have an accelerometer) in real time to determine the real time rate of descent. The software programming permits a backup deployment of the main in the event of an apogee deployment failure if the descent rate exceeds a preselected value between 10 to 50 meters per second (in steps of 2 meters per second). An input value of 0 meters per second disables this function.

This option is easy to implement in any barometric altimeter that has a reasonably fast processor.

Bob

 

[Adrian A]

Adrian

The SALT-3R analyzes the barometric data (it doesn't have an accelerometer) in real time to determine the real time rate of descent. The software programming permits a backup deployment of the main in the event of an apogee deployment failure if the descent rate exceeds a preselected value between 10 to 50 meters per second (in steps of 2 meters per second). An input value of 0 meters per second disables this function.

This option is easy to implement in any barometric altimeter that has a reasonably fast processor.

Bob

I agree that it's do-able (and not surprised someone has done it) but I think having a backup that normally will result in live, armed charges after landing is a bad idea. Moving the rocket around or taking it apart could cause baro sensor changes that could be mistaken for a fast descent rate if the device is still running. I can't think of an advantage to waiting for a fast descent rate before firing a backup charge, when there are plenty of ways to make the charge fire harmlessly up in the air, shortly after the primary charge is supposed to fire. Well, maybe one advantage; you would save the cost of an ematch and some BP. But that's not a trade that I would make or that I would recommend anyone else make, either.

 

[bobkrech]

I agree that it's do-able (and not surprised someone has done it) but I think having a backup that normally will result in live, armed charges after landing is a bad idea. Moving the rocket around or taking it apart could cause baro sensor changes that could be mistaken for a fast descent rate if the device is still running. I can't think of an advantage to waiting for a fast descent rate before firing a backup charge, when there are plenty of ways to make the charge fire harmlessly up in the air, shortly after the primary charge is supposed to fire. Well, maybe one advantage; you would save the cost of an ematch and some BP. But that's not a trade that I would make or that I would recommend anyone else make, either.

I obviously did not explain how it works clearly.

With any dual deployment system, you have an apogee event and a main deployment event. Each event has a pyro charge activated by an e-match.

In the nominal flight, the apogee event is triggered either when the barometric pressure altitude decreases after apogee and/or when the accelerometer derived altitude decreases after apogee and/or by a backup timer.

The main event is typically triggered barometrically and/or by a backup timer. If for any reason the apogee event fails to deploy a drogue or break up the rockets aerodynamics, the velocity at the main event will likely strip the main and cause the rocket to impact the ground at high velocity or severely damage the rocket with a zipper.

The SALT-3R uses an electronic barometer based varometer to add an additional condition to fire the main charge. Should the apogee deployment not occur due to a bad e-match or insufficient BP to separate and/or deploy the apogee recovery hardware, the rocket will ballisticallyy accelerate downed to terminal velocity unless electronic variometer kicks in and triggers the main at a higher altitude but at a velocity that is higher than the normally expected drogue descent rate, but at a velocity where the main will not be stripped, saving the rocket and preventing a ballistic impact.

A well designed altimeter deactivates the pyro circuits after landing This can be done with a timer, a barometric monitoring circuit and/or an accelerometer monitoring circuit. A properly configured barometric variometer adds a redundant path to the main deployment circuit to enhance recovery safety, not detract from it.

Bob

 

[thomas]

Thanks for all the reply.

The idea behind this was to have a backup parachute which will only fire when the drouge was not deployed properly and system is coming down ballistic.
But i agree that it is not a good idea to land with live charges.

In principle you could use the main chute for this, when the rocket goes down ballistic, the main will deploy earlier and if it is not ballistic it will come out at intended height. But using the same chute means no real redundancy.

I found they are thinking about embedding it to telemetrum, there is a comment in the code.

'Would like to use the accelerometer for this test, but the orientation of the flight computer is unknown after drogue deploy, so we ignore it. Could also detect high descent rate using the pressure sensor to recognize drogue deploy failure and eject the main at that point.'


Thanks for your comments, that it is not possible to simply use the vertical acceleration data after drogue deployment, as i intended to do.