Raven Altimeter

The Rocketry Forum

Help Support The Rocketry Forum:

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

Wiley

Well-Known Member
Joined
Oct 24, 2010
Messages
403
Reaction score
3
I downloaded the instruction sheet for the Featherweight Raven, but, not being electronically informed, most of it seemed like Chinese.

I intend to use the accelerometer function of this altimeter for apogee deploy on an 8" diameter upscale ACME Spitfire. The motor will be a 54-2500. Expected altitude ~2000 ft.

The first issue I need resolved is that the altimeter comes in two different versions: single axis 250G, or 2 axis 70G/35G. What do the "axis" designations mean, and which would be the best for my application?

Also, if its a simple explanation, do any of you know how to make this altimeter fire an apogee charge, and then back it up a few hundred feet later with a second charge, assuming that the rocket is similar to the one I described?
 
Yep.

The axis designations are fairly simple. An axis is simply a direction. The two axis 70g/35g can measure acceleration in two separate directions. It can measure accelerations up to 70g in the direction of the rocket's flight, and it can measure accelerations up to 35g which are perpendicular to the rocket's flight (side to side). The 250G single axis can only measure in the direction of the rocket's flight, but it has a higher acceleration limit. For most people, I'd recommend the dual axis, as it gives more data, it gives more accurate data, and very few rockets exceed 70g. If you forsee yourself flying small, minimum diameter screamers on White Thunder, Warp 9, Vmax, Blue Thunder, or similar fast propellants, then you might consider the 250g, but otherwise, the 70G is probably the way to go.

As for how to make the altimeter fire an apogee charge and backup? If you just use the default program, that should be achieved by attaching your main charge to channel 1 and the backup to channel 3 (if I remember right). You could also program it to, but I don't have the program on this computer, and I don't remember the exact interface on the top of my head.
 
Thanks! So the dual axis is definately the way to go. I'd figured that the axes they were referring to were the rocket's axes, but I didn't know which two they were indicating. It sure is good to have smarter people in this world!

A few more questions about the accelerometer function. I decided to use an accelerometer because it doesn't need to "breathe" like a baro, and with a crooked design like a Spitfire, (and everything else I build:blush:) I wanted something that doesn't have to sample the outside atmosphere.

However, if the rocket somehow flys in a perfect, parabolic curve, is it correct that an accelerometer will never fire the charges? What about normal, off axis flights (oddrocks)?
 
However, if the rocket somehow flys in a perfect, parabolic curve, is it correct that an accelerometer will never fire the charges? What about normal, off axis flights (oddrocks)?

Nope. That's not true. The accelerometer will fire the charges if the rocket flies straight or off axis. It will fire late if the rocket's flight is angled off, but it would have to be angled pretty far for this to matter very much.
 
Because of my never-ending quest for knowledge, I must inquire how late "it will fire late" is and how far off axis "pretty far" is:D.
 
Well, I don't feel like doing the math right now, but looking at some of my flight data, it appears that on two separate flights I had to 18k at roughly mach 1.5 with a boost that was perhaps 10 degrees off axis, it fired about 2 seconds late. On lower, slower flights that are the same angle off, it will be closer. The worst would be both far off axis and very fast.
 
Thanks, Chris. I agree with all the above.

The accel-based apogee detection works by calculating the upward speed as it goes along. Throughout the flight it adds measured acceleration from motor thrust and subtracts measured acceleration from drag, and it also subtracts whatever it measured for gravity at the pad. Once gravity + measured drag cancels out all the velocity from the motor, the rocket is at the top and it's time to deploy the apogee chute. It assumes that all the measured thrust and drag is vertical.

If the rocket is at an off-angle, most of the motor impulse goes toward vertical speed, and some goes to horizontal speed. The altimeter assumes that all the measured acceleration is vertical, so it over-estimates the vertical part of the velocity from the motor and then over-estimates the amount of time it takes for gravity to bleed off all the vertical speed.
 
Thanks, Chris. I agree with all the above.

The accel-based apogee detection works by calculating the upward speed as it goes along. Throughout the flight it adds measured acceleration from motor thrust and subtracts measured acceleration from drag, and it also subtracts whatever it measured for gravity at the pad. Once gravity + measured drag cancels out all the velocity from the motor, the rocket is at the top and it's time to deploy the apogee chute. It assumes that all the measured thrust and drag is vertical.

If the rocket is at an off-angle, most of the motor impulse goes toward vertical speed, and some goes to horizontal speed. The altimeter assumes that all the measured acceleration is vertical, so it over-estimates the vertical part of the velocity from the motor and then over-estimates the amount of time it takes for gravity to bleed off all the vertical speed.

Does this mean the raven wont use baro-apogee detection? I.e. If the rocket goes horizontal off the rod, it wont break aprt before it cores....Or, most common on the downward reentry portions of apogee, where it is actually building speed again?
 
Does this mean the raven wont use baro-apogee detection? I.e. If the rocket goes horizontal off the rod, it wont break aprt before it cores....Or, most common on the downward reentry portions of apogee, where it is actually building speed again?

Baro-based apogee detection is an option on any of the 4 channels, and it's the default setting on the 3rd channel, to use as a backup.
 
Or, most common on the downward reentry portions of apogee, where it is actually building speed again?

That doesn't make a difference. Accel based will still work, even if it does make it to this portion of flight.

(From onboard the rocket, it still thinks it is decelerating)
 
I have used the Raven as backup or primary on about 80% of my flights. It is reliable and easy to use. I have has only 1 failure and it was user failure to properly read the instuctions.
 
That doesn't make a difference. Accel based will still work, even if it does make it to this portion of flight.

(From onboard the rocket, it still thinks it is decelerating)

If apogee detect is baro, then it doploys drouge at apogee, or as soon as it looses a few feet of altitude or whatever it takes for the buffer to register the new alittude being lower. This places drouge deployment at the lowest rocket velocity for all ballistic flight.

Wheras, accel based, will be before, or after, but rarely at exact apogee. Mostly a good bit after apogee.

I know junk about the raven, so i was curious to its operation in that aspect.

If i fly a BDR, and it weathercocks at 100', i want a charge to separate it. Likewise, if my 20k mach busting flight gets severe wind shear/rod whip and his very flat trajectory, i dont want to hunt down a dig out a separated booster....
 
If apogee detect is baro, then it doploys drouge at apogee, or as soon as it looses a few feet of altitude or whatever it takes for the buffer to register the new alittude being lower. This places drouge deployment at the lowest rocket velocity for all ballistic flight.

Wheras, accel based, will be before, or after, but rarely at exact apogee. Mostly a good bit after apogee.

I know junk about the raven, so i was curious to its operation in that aspect.

If i fly a BDR, and it weathercocks at 100', i want a charge to separate it. Likewise, if my 20k mach busting flight gets severe wind shear/rod whip and his very flat trajectory, i dont want to hunt down a dig out a separated booster....
I agree with all of this, except that accel is usually somewhere between apogee and 1-2 seconds late. I've never had it late enough to matter (although my standard altimeter combo is a raven set for baro deploy and an RDAS, so I have both a baro and an accel based), and I certainly wouldn't say that they usually deploy a "good bit after" apogee.
 
Does this mean the raven wont use baro-apogee detection? I.e. If the rocket goes horizontal off the rod, it wont break aprt before it cores....Or, most common on the downward reentry portions of apogee, where it is actually building speed again?

It'll do pretty much whatever you tell it to do. But even right out of the box, the third output is set up for barometric apogee. An extra ejection charge initiator and you're golden for a buck fifty or so.
 
I agree with all of this, except that accel is usually somewhere between apogee and 1-2 seconds late. I've never had it late enough to matter (although my standard altimeter combo is a raven set for baro deploy and an RDAS, so I have both a baro and an accel based), and I certainly wouldn't say that they usually deploy a "good bit after" apogee.

ohh, i agree, most flights are that way, but if you read some of CJL's posts earlier on, he indicates the flatter the trajectory, the later it will be.

I am not dogging the altimeter - most dual based altimeters including the ones i use now, are accelorometer based for droge... BUT some will deploy from altitude readings first, if the math for decelloration hasnt already deployed it.(being a check for mach delay in programming)
to me, i want both systems to work together.
I have had baro falure, and i have had early accell deploys. soooo, i like to see both working...
 
To reiterate, there are 4 channels that can be configured for all kinds of different scenarios. In the default (i.e. right out of the box) configuration, channel 1 is accelerometer-apogee and channel 3 is baro-apogee. To change to different criteria (i.e. to use for staging, air starts, different back-ups etc) all you do is connect it to a computer with the FIP software and select the new settings.

To me, the Raven is somewhat similar to a Swiss army knife. Of the altimeters I have used, it has the most different 'features.'

Sandy.
 
ohh, i agree, most flights are that way, but if you read some of CJL's posts earlier on, he indicates the flatter the trajectory, the later it will be.
Which is true.

I am not dogging the altimeter - most dual based altimeters including the ones i use now, are accelorometer based for droge... BUT some will deploy from altitude readings first, if the math for decelloration hasnt already deployed it.(being a check for mach delay in programming)
to me, i want both systems to work together.
I have had baro falure, and i have had early accell deploys. soooo, i like to see both working...
Most won't do that actually. The reason is that if they allowed the baro to override the accel, then they would no longer be mach immune. They (accel-based altimeters) pretty much all look for the same thing for the apogee event, which is a velocity of zero. Some (like the Raven) can be programmed to use either accel or baro.

Oh, and if you've ever had an early accel deploy (and I don't mean half a second or a second, I mean genuinely early), something was wrong. Accel-based should never deploy significantly early.
 
Most won't do that actually. The reason is that if they allowed the baro to override the accel, then they would no longer be mach immune.

You can use both a baro and accel for an apogee determination.

One method is to use a velocity check to inhibit baro events so that it is mach immune and trigger on the first detected apogee. This is OR'ing the accel and baro apogee detect.

The other method is to incorporate the accelerometer and barometer in a Kalman filter to estimate altitude and velocity and base apogee detection on that.
 
Which is true.


Most won't do that actually. The reason is that if they allowed the baro to override the accel, then they would no longer be mach immune. They (accel-based altimeters) pretty much all look for the same thing for the apogee event, which is a velocity of zero. Some (like the Raven) can be programmed to use either accel or baro.

Oh, and if you've ever had an early accel deploy (and I don't mean half a second or a second, I mean genuinely early), something was wrong. Accel-based should never deploy significantly early.

I know of several that have a built in programming to allow the baro to become active for deployment after the chance of mach deploy is gone. Being that meco is detected, and velocity - from the accelerometer is below so many FPS... this is more common than you think, escpecially among the hombrewers...(i want both to be considered...)

Yes, my early's were all 1's seconds or less early... the big one i noticed it on, was probably becaused it knocked the sensor around and probably had some gain issues. it actually showed decellorating at over 1g nearing apogee...(the rest of the flight other than that, was verry near the same reading on my back up... one had 29fps decel, and the other had close to 33.. both were 32 on the pad...
 
This is OR'ing the accel and baro apogee detect.

.

This is my preffered method of an altimeter..Baro is the most accurate detection of apogee, but the accel is there to make sure a piece of tape or loose wire blocking a port doesnt ruin your day...
or in my case it was a fried baro sensor, and the acelerometer put out the droge to save the day."1/2 second late". problem was without baro sensor, it immediately put out the main.... UGHH...made for a long walk but im not digging anything out...
 
You can use both a baro and accel for an apogee determination.

One method is to use a velocity check to inhibit baro events so that it is mach immune and trigger on the first detected apogee. This is OR'ing the accel and baro apogee detect.

The other method is to incorporate the accelerometer and barometer in a Kalman filter to estimate altitude and velocity and base apogee detection on that.

Oh, absolutely. That's how the Raven's default baro is set up (the velocity deployment inhibit). I usually run my raven in this mode. It's not how most accel-based altimeters work though, at least out of all of the ones I've looked at or used.
 
Why can't the 2-axis Raven figure out based on the lateral accelerometer how off-axis the flight is, and then use that plus the linear accelerometer's data to figure out exactly when to fire the drogue?
 
Why can't the 2-axis Raven figure out based on the lateral accelerometer how off-axis the flight is, and then use that plus the linear accelerometer's data to figure out exactly when to fire the drogue?

lateral acceloration is not uniform,
1st. the sensor is never "centered" in the rocket.
2nd Roll, - not being centered, creates lateral acceleration not proportunate to the tilt of the rocket.

I have never understood the need for 2 axis, typically, sensors are never placed in accurate reading locations anyway.

although, i have seen multi-axis (3)axis, show gravity at low roll rates and at very low velocity. Being 1 g differnce from once side to the other...(its confusing, but if you saw the data... it would make sense) But, this data looks the exact same when the rocket is spining under thrust. (just without 1 g difference...)

Accelorometers have different threasholds for postive and negative force. so when they spin, , the data looks more like a series of spikes....

gyros, are the only accurate way of measuring axis change while moving...
 
Last edited:
Of course there would be controversy:D! That's what forums are for. I'm seeing about half of the posts like the accel atimeter, and about half don't.

For my application, (8" upscale ACME Spitfire, about 20lb., 54-2550 motor, roughly 2K altitude, and laundry out at apogee) which would be the best: the dual axis Raven, or a regular baro altimeter, like a Perfectflite HiAlt45K?
 
Of course there would be controversy:D! That's what forums are for. I'm seeing about half of the posts like the accel atimeter, and about half don't.

For my application, (8" upscale ACME Spitfire, about 20lb., 54-2550 motor, roughly 2K altitude, and laundry out at apogee) which would be the best: the dual axis Raven, or a regular baro altimeter, like a Perfectflite HiAlt45K?

well, certainly didnt mean to spark contraversy, I did pose questions, Because ravens are fairly new. THUS, I have never heard 1 thing bad ....
i am a firm believer, if it sounds to good,,, it probably is..????
so i posed some questions to try to understand how it works. at the end of the day, these are all calls that your rocket depends on. So biast or not, your the one with the liability,

I havent ruled out the raven.. But, i am not confident in it either. I simply am not firm in how it operates. Even old guys stuck in thier ways tout this altimeter...So there must be something good about it.

For soemthing that has a low slow mentality, i would go with BARO it is usually 1 or 2 feet resoution, so you be at apogee with separation not after(bad- for low and slow rockets)...
weather its raven or not.... i dont have the experience to comment on.

Ill add something here in edit... I highly recomend a DUAL BASED system, where, both baro and accelerometer working for apogee detect. Not one or the other...
I dont like to pick, i want both....

i really dont understand the benefit of 2 axis..??? But, accelerometer and baro apogee used for apogee is a must for me.
 
Last edited:
lateral acceloration is not uniform,
1st. the sensor is never "centered" in the rocket.
2nd Roll, - not being centered, creates lateral acceleration not proportunate to the tilt of the rocket.

I have never understood the need for 2 axis, typically, sensors are never placed in accurate reading locations anyway.

although, i have seen multi-axis (3)axis, show gravity at low roll rates and at very low velocity. Being 1 g differnce from once side to the other...(its confusing, but if you saw the data... it would make sense) But, this data looks the exact same when the rocket is spining under thrust. (just without 1 g difference...)

Accelorometers have different threasholds for postive and negative force. so when they spin, , the data looks more like a series of spikes....

gyros, are the only accurate way of measuring axis change while moving...

Thanks, I hadn't considered those factors. Well, assuming the accelerometer is mounted on the rocket centerline, could you deduce roll-rate with 2 axis? I would think you'd need 3 just thinking about it...
 
I intend to use the accelerometer function of this altimeter for apogee deploy on an 8" diameter upscale ACME Spitfire. The motor will be a 54-2500. Expected altitude ~2000 ft.

It is kind of off topic, but could we see some pics if you have any? Thanks!
 
Thanks, I hadn't considered those factors. Well, assuming the accelerometer is mounted on the rocket centerline, could you deduce roll-rate with 2 axis? I would think you'd need 3 just thinking about it...

well, its going to measure the g force created by roll, not the rpm. 3 axis is different than 2 in that the Z vertical, X and Y lateral .. will be different at different angles for the same roll rate due to gravity... (assuming it is centered) wich can be used to measure roll rate...
(it would be mighty difficult.....)

i re-read and realized i dodged your question...
If you have a single axis lateral measurement, the positive and negative threashold are different. SO, if it is centered 0'G from roll, as it rolls you will see positive and negative acceloration from gravity, as the axis changes in line with the force of gravity.
so, 2 axis is theoreticly possible... but, practicly impossible IMO...


I have seen lots of raven data, that suggests you can determine roll rate...
 
Last edited:
I'd definately choose a baro altimeter first (mainly because they're so much cheaper ;)), but have you considered the nasty turbulent zones that surround an ACME Spitifire? I've asked this question before, in a different thread, but it seems that no one has ever really tried using a baro altimeter in a Spitfire.

Would it need baffles over the static ports? What type of baffle really works? I was thinking of a baffle shaped somewhat like a tiny bat house (the bird house like devices with their bottoms missing, designed to allow a place for bats to roost), but with the top as well as the bottom open. Another, slightly larger one would be placed over the first one, with its two openings placed opposite those of the first, and a third, still larger one over this, with its openings opposing the second one's openings. Bat house baffles (BHB's) :D.

Has anyone ever tried this?
 
Why can't the 2-axis Raven figure out based on the lateral accelerometer how off-axis the flight is, and then use that plus the linear accelerometer's data to figure out exactly when to fire the drogue?

Because no matter how far off-axis it is, if the flight follows a gravity turn trajectory (which most do), there is no way to determine the flight angle purely from an onboard accelerometer. Most of the point of a lateral accel is to see things like lateral vibrations.
 
Back
Top