Recovery Electronics Survey

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

wetmelon

Well-Known Member
Joined
Jul 4, 2013
Messages
75
Reaction score
0
Hello, everyone!

I'm an engineering student in the US, and I've been working with a friend to design an altimeter for his HPR projects. As I've worked through the design I've realized that it could be commercially viable and I'd like to gauge community interest. To that end, I've developed a short survey that should give me a good idea of what aspects of the altimeters would be appreciated and which would not be used. If you could take 5 minutes to give me your input, it'd be greatly appreciated!

Here's the link to the survey (Google Forms): https://goo.gl/forms/x5DGiqh5Xm

If you have any questions, comments, or concerns, post them here :)
 
Last edited:
You need to survey the existing altimeters already on the market and decide if you can produce a product that has the same features and do it for less money or more features for the same price. There are some very capable products on the market with excellent price points.
 
You need to survey the existing altimeters already on the market and decide if you can produce a product that has the same features and do it for less money or more features for the same price. There are some very capable products on the market with excellent price points.

Oh for sure, that was step one. This survey is like... step 8 :)
 
Last edited:
I'd imagine your data will show several trends vs the one ideal product

3 products categories I can see:
1. Lowest cost alt
2. All the expensive bells and whistles
3. Something tiny to fit in 13mm tubes
 
Last edited:
One thing I'm trying to sort out in my mind is what's the use of an accelerometer now? In bygone days in units with an accelerometer/barochip, the accelerometer would be used for the apogee deployment of the drogue and the baro used for more accurate main deployment. The algorithm for the baro side was not that developed and one had to
set a Mach delay in order to avoid apogee deployment on ascent. How many have done that or witnessed that?:wink::facepalm: (I've seen it and not "done it".)

As it is, with the new algorithms for the baro units, one doesn't even need to be concerned about it anymore. Nothing to set even on a $20.00 deployment device the Quark outside of deployment delay of the apogee charge and the main chute deployment altitude.

Adrian from Featherweight even recommends that one no longer use the accelerometer for apogee and depend on the baro unit as it's more accurate for the apogee deployment with the Raven III.

So what's the scoop besides knowing how many G's the rocket pulled? What's the use for the
accelerometer now? Not meaning to sound like a troll or baiting but it was easier to get my head around this when it was felt that the baro side under acceleration couldn't be "trusted" in the past.:shock: Kurt Savegnago
 
Last edited:
If you elect not to use the accelerometer for deployment it can still be used in several ways, particularly when paired with a fully array of sensors to create a 9DOF IMU:

  • Know your Yaw, Pitch, and Roll
  • Interpolate Position and Velocity between GPS hits
  • Prevent staging beyond a certain angle ("tilt sensor")
  • Motor characterization
  • Estimate velocity at end of launch rail
  • Prevent deployment under heavy acceleration

I'm sure there's more things I can't think of at the moment.
 
If you elect not to use the accelerometer for deployment it can still be used in several ways, particularly when paired with a fully array of sensors to create a 9DOF IMU:

  • Know your Yaw, Pitch, and Roll
  • Interpolate Position and Velocity between GPS hits
  • Prevent staging beyond a certain angle ("tilt sensor")
  • Motor characterization
  • Estimate velocity at end of launch rail
  • Prevent deployment under heavy acceleration

I'm sure there's more things I can't think of at the moment.

I thought the gyro took care of Yaw, pitch and roll? Indeed I am thinking of the
simpler devices with the arrow "pointing up" in the olden days.

To interpolate position and velocity between GPS hits would take some sort of
inertial gymnastics, I'd think you'd have to have a device to keep track of
all three axis. Plus if GPS hits are few and far in between because the speed limit
has been broken and the G's are too high for the GPS module, the position could be
a tough nut to crack accurately. What use would that be for a hobbyist? Sure it
might be needed for someone trying for a spaceshot but for most fliers what would
be the utility?

I thought the gyros were what was used for tilt sensing or is there input from a 3 axis
accelerometer too?

Characterization? For the accelerometer to be accurate for that, doesn't the rocket have to be going as straight up as possible? Any deviation off vertical messes
with the numbers?

Prevent deployment I thought is very valid but the Baro only wonks seem to think the baro algorithms are good enough now.

Not trying to dissuade or be difficult, but if you develop something to do all this stuff and there are very few who need it or it's priced pretty high, you might be stuck with a lot of
stock on your hands. Plus there are some units out there already Altus-Metrum, Raven, Marsa4, and even the ol' ARTS 2 can do some of that stuff in one degree or the other with the Tele-Mega able to do the most.

Kurt Savegnago
 
I thought the gyro took care of Yaw, pitch and roll? Indeed I am thinking of the
simpler devices with the arrow "pointing up" in the olden days.

I thought the gyros were what was used for tilt sensing or is there input from a 3 axis
accelerometer too?

MEMS gyros have inherent drift that needs to be calculated out by some other method. The typical way to do this in Pitch and Roll is with the gravity as a reference. In Yaw, you need another reference so they use magnetometers (compasses). Take 3 axis accel, 3 axis gyro, and 3 axis magnetometer and you have a 9DOF IMU that can fully calculate your pitch, roll, and yaw in real time.

To interpolate position and velocity between GPS hits would take some sort of
inertial gymnastics, I'd think you'd have to have a device to keep track of
all three axis. Plus if GPS hits are few and far in between because the speed limit
has been broken and the G's are too high for the GPS module, the position could be
a tough nut to crack accurately.

The position interpolation is much more useful for active stabilization and for graphing your path AFTER the flight than anything else. But it comes with the territory of having a 9DOF IMU. It's just a thing that can be done (relatively easily, actually).

Characterization? For the accelerometer to be accurate for that, doesn't the rocket have to be going as straight up as possible? Any deviation off vertical messes
with the numbers?

It shouldn't, if you have a 3 axis accel.


As for getting stuck with stock - I'm not planning on doing any high volume orders any time soon ;) This is a niche market, and it will definitely take some time to figure out where the board fits. Keep in mind, I'm designing a board with all the functionality that my friend wants for his L3 FIRST. If, based on my survey and talking with members of the community, the board ends up being at a good price point that could sell, that's great! But it's actually not the primary reason I'm designing it.
 
"survey" was missing some things - you probably should have added a comments box at the end.

I assume things like Mach inhibiting, Kalman filtering, and other "basics" are features you know you need to include, which is why they are not options :> Not a lot of specificity around telemetry (900Mhz vs. amateur band, etc...), events beyond dual deploy. Up to 9 outputs would be nice, and make them all high current :> if you include 9 DOF IMU capability, it could be used as a variable for other events (could make airstart dependent upon angle of attack, etc...). Frankly what would really, really be interesting is a flight computer that had a rudimentary boolean language to program it in. when you start to add a significant amount of functionality, dip switches, even a software interface start to limit flexibility. We already have the telemega which has 80% of everything you've listed. They have a few other boards (telescience) that, if they ever made them would just about complete this. Provide a mechanism to turn on the electronics remotely (like eggtimer) would also be nice.
 
"survey" was missing some things - you probably should have added a comments box at the end.

Erm, yeah. I should have. I thought about like 20 minutes ago - 10 hours after I posted the survey lol.

Not a lot of specificity around telemetry (900Mhz vs. amateur band, etc...)

I'm not very familiar with it is the reason :(

Are you the one who put
9 DOF orientation logging - both raw, and kalman filtered data from accelerometers & barometer, secondary power input for lipo, airstart current capabilities
in the survey? Because you'll be happy to know all of that stuff is already planned ;)
 
MEMS gyros have inherent drift that needs to be calculated out by some other method. The typical way to do this in Pitch and Roll is with the gravity as a reference. In Yaw, you need another reference so they use magnetometers (compasses). Take 3 axis accel, 3 axis gyro, and 3 axis magnetometer and you have a 9DOF IMU that can fully calculate your pitch, roll, and yaw in real time.

There is no gravity reference once the rocket is launched so using the 3D accel to cancel gyro drift is not possible. If you figure out a way to use a 3D magnetic field reference to cancel gyro drift from current noisy MEMS magnetometers that would be quite an achievement.

Fortunately current MEMs gyro's have negligible drift for the time that a typical HPR rocket is under boost so drift compensation is not really needed to determine rocket attitude within a few degrees.
 
One thing I'm trying to sort out in my mind is what's the use of an accelerometer now?

Hi Kurt,

Accelerometers on flight computers are still useful for:
1. Precise timing of events during rocket boost such as airstarts and staging. Accelerometers will nail launch detect within milliseconds, baro not so much.
2. Detection and timing of motor burnout for staging for above
3. Accurate (relative) determination of maximum velocity.
4. Determination of rocket Cd from #3 and 2.
5. Motor characterization. The net force on the rocket in the flight axis is directly determinable from the raw accelerometer reading. Orientation (verticality) affects the body force on the rocket axis rocket but not the accelerometer reading thereof (because the onboard accelerometer cannot sense the body force (weight) ).
6. Not all rocket designs or av-bay configurations allow for acceptable atmospheric static pressure measurements. And some rocketeer don't know that. Fusion of a baro and accelerometer reading makes the system more reliable for those cases you do not know if your pressure sampling is adequate.
 
Last edited:
There is no gravity reference once the rocket is launched so using the 3D accel to cancel gyro drift is not possible. If you figure out a way to use a 3D magnetic field reference to cancel gyro drift from current noisy MEMS magnetometers that would be quite an achievement.

Fortunately current MEMs gyro's have negligible drift for the time that a typical HPR rocket is under boost so drift compensation is not really needed to determine rocket attitude within a few degrees.

That's a really good point. How do commercial rockets typically do this then? Integrate data from laser ring gyros?
 
Hi Kurt,

Accelerometers on flight computers are still useful for:
1. Precise timing of events during rocket boost such as airstarts and staging. Accelerometers will nail launch detect within milliseconds, baro not so much.
2. Detection and timing of motor burnout for staging for above
3. Accurate (relative) determination of maximum velocity.
4. Determination of rocket Cd from #3 and 2.
5. Motor characterization. The net force on the rocket in the flight axis is directly determinable from the raw accelerometer reading. Orientation (verticality) affects the net force on the rocket but not the accelerometer reading thereof.
6. Not all rocket designs or av-bay configurations allow for acceptable atmospheric static pressure measurements. And some rocketeer don't know that. Fusion of a baro and accelerometer reading makes the system more reliable for those cases you do not know if your pressure sampling is adequate.

Could you elaborate on point 6 a bit? I know a bit about this, but do not claim to be an expert. Sorry for the hijack.
 
Thanks for the understanding and the reply. I see it has opened up some other interesting discussion.

Kurt (trying not to be a troll) Savegnago

MEMS gyros have inherent drift that needs to be calculated out by some other method. The typical way to do this in Pitch and Roll is with the gravity as a reference. In Yaw, you need another reference so they use magnetometers (compasses). Take 3 axis accel, 3 axis gyro, and 3 axis magnetometer and you have a 9DOF IMU that can fully calculate your pitch, roll, and yaw in real time.



The position interpolation is much more useful for active stabilization and for graphing your path AFTER the flight than anything else. But it comes with the territory of having a 9DOF IMU. It's just a thing that can be done (relatively easily, actually).



It shouldn't, if you have a 3 axis accel.


As for getting stuck with stock - I'm not planning on doing any high volume orders any time soon ;) This is a niche market, and it will definitely take some time to figure out where the board fits. Keep in mind, I'm designing a board with all the functionality that my friend wants for his L3 FIRST. If, based on my survey and talking with members of the community, the board ends up being at a good price point that could sell, that's great! But it's actually not the primary reason I'm designing it.
 
Could you elaborate on point 6 a bit? I know a bit about this, but do not claim to be an expert. Sorry for the hijack.

Hi Mark,

I assume you already know about the possible problems that can happen with av-bay venting. Examples, turbulence, inproperly sized vent holes, subtle av-bay leaks, etc. Some of these effects can be really subtle. One example is a customer had a 5.5" Nike smoke (the one with the nosecone lip). Most flights gave ordinary baro altitude curves, occasionally he would suffer an apogee deployment during boost where the baro curve was jagged. We concluded that this occured when the rocket had high angles of attack and the nose cone lip may have been generating trailing vortices that spoofed the altimeter.

By fusing the baro and accel sensors in a Kalman filter or similar you can allocate "trust" to the sensor that is probably giving a truer picture of the dynamics of the rocket.
 
It's not only about the electronics, features, etc. One of the most important things is vendor reliability. When making investments in avionics, I want to work with a firm that will be there in the long run, providing customer service, firmware updates, product enhancements, and so forth. I won't pursue full-featured systems without reliable, long term technical support & customer service.

There's a long list of electronics available. Consider how many of these are no longer supported.
https://data.rocketsetc.com/altimeter_data.html
 
Hi Mark,

I assume you already know about the possible problems that can happen with av-bay venting. Examples, turbulence, inproperly sized vent holes, subtle av-bay leaks, etc. Some of these effects can be really subtle. One example is a customer had a 5.5" Nike smoke (the one with the nosecone lip). Most flights gave ordinary baro altitude curves, occasionally he would suffer an apogee deployment during boost where the baro curve was jagged. We concluded that this occured when the rocket had high angles of attack and the nose cone lip may have been generating trailing vortices that spoofed the altimeter.

By fusing the baro and accel sensors in a Kalman filter or similar you can allocate "trust" to the sensor that is probably giving a truer picture of the dynamics of the rocket.

I do know about those things. I was hoping that someone such as yourself might be able to expound on this for those who may not know.
 
That's a really good point. How do commercial rockets typically do this then? Integrate data from laser ring gyros?

I do not know but just speculating they have REALLY GOOD IMU's, and ground radar and perhaps other ground or celestial references.
 
I do not know but just speculating they have REALLY GOOD IMU's, and ground radar and perhaps other ground or celestial references.
I had the experience in college (74-78) of seeing and watching a class geek firing up a Minuteman I D-17B guidance computer with a heavy duty
28V physics power supply. https://en.wikipedia.org/wiki/D-17B. Got it to do some tricks but I was blown away by all they crammed in there and there was another
one still in its crate with the last inspection stamp of 1965. After the government upgraded, they eventually released them to colleges and universities. There was a loose leaf manual they released with them and by golly there's a scan of it online. I remember paging through it. I was amazed by the small hard drive
on the thing as we had a removable hard drive for the HP minicomputer we had access to and it was the size of a small closet.
There was a big empty space in the middle of the D17B that I presumed at the time to be room for the mechanical gyros. I still smack myself to this day as my deceased uncle Cecil was a retired missile technician from the Air Force and was stationed at Warren Air Force base in Cheyenne, Wy. He might have been able to share some stories . It never occurred to me to ask. Other regret is my paternal grandfather was an expert welder retiring from the gas company after 48 years. I was scared watching him use a torch when I was a kid because he cautioned about the high temperature. When I got older, stupidhead should of asked, "Show me how grandpa."
I know he would have. Kurt
 
Back
Top