Above 100K , What Altimeter has been used

The Rocketry Forum

Help Support The Rocketry Forum:

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

dlb

Sky Pyrate...
Joined
Jan 24, 2009
Messages
1,283
Reaction score
141
OK, dumb questions.......

What altimeters are people using for flights above 100K, I know it's not Baro based and must be accelerometer based????

I think R-Das maybe a option, most others I seen are only good to 100K, even the accelerometer based ones.

got a project that will hit 120K to 140K and no altimeters for that range, So time to start asking!!!
 
I'm pretty sure that the Featherweight Raven has been to 100k.
Ask Jim Jarvis for confirmation....

I think flight computers need GPS to be integrated into deployments systems for reliable deployment over 100k.
A system that uses the data to detect true apogee. Derek Deville might be your go to guy on this.
https://ddeville.com/derek/Qu8k.html
I know of none that are currently available to rocketry community that is affordable

JD
 
You'd need an accelerometer and a GPS filtered together with a Kalman filter. Sounds like a Telemega to me...
 
You have 3 options over 100 kft: GPS, INS and radar.

1.) A good commercial single frequency unlocked GPS is the most accurate apogee detector you can get for flights over 100 kft. It does not need ground support and it is inherently stable. An unlocked single frequency GPS receiver should be able to locate the rocket apogee to 16 meter or better much of the time with a 100 M (0.3% at 100 kft.) worst case, and using WAAS I think you should able to do substantially better with a worst case of ~8 M (0.03% at 100 kft.) with a typical vertical error of 1.5 m or 5' (0.005% at 100 kft). https://www.utdallas.edu/~aiken/GPSCLASS/ch5.pdf https://www.faa.gov/about/office_or...units/techops/navservices/gnss/waas/benefits/
https://en.wikipedia.org/wiki/Wide_Area_Augmentation_System

2.) A high qualtity INS would be acceptable but I'm not sure how well an affordable unit would work. All inertial systems drift and I think that one that is both affordable and can fit in a hobby rocket wound not be as good as a GPS.

3.) Radar works well, but it's going to be too expensive unless you have access to a test range and you don't have to pay for it.

Bob
 
gotta give a shout out to one of my club members, he designed and sells these

https://www.multitronix.com/

Not cheap, but damned impressive full-function altimeters tested to 118k. Don't think it has a max altitude limit.

Note that the 118k flight video has some light adult language from amazed spectators
 
Last edited:
I'm guessing he's asking for something which can fire an ejection charge at apogee so that rules out the Multronix stuff.
 
The report on the flight that won the Carmac 100K prize had good information on what they found out.
 
gotta give a shout out to one of my club members, he designed and sells these

https://www.multitronix.com/

Not cheap, but damned impressive full-function altimeters tested to 118k. Don't think it has a max altitude limit.

Note that the 118k flight video has some light adult language from amazed spectators
The GPS limits the apogee detection to 50 km according to the website. https://www.multitronix.com/specifications.html

  • U-blox-7 GPS engine, 56-channel, L1 C/A, SBAS: WAASOperating in high dynamics airborne mode at five position fixes per second
  • Operational limits 50,000 m and 500 m/s, (164,000 feet and 1,640 feet/sec)
  • GPS tracking sensitivity -162 dBm
  • Active patch antenna, 25 x 25 mm, SAW filter, 15dB LNA, +1.5dBic patch gain at zenith, RHCP
  • GPS almanac retained while device is powered off.

The retail cost is ~$2400 with is not bad for a turnkey solution because I don't think an well versed EE could put a similar system together for much less, and additionally the rocket that can really utilize the capabilities will cost several times this amount. You can see the flight data from a 118 kft flight at https://www.multitronix.com/uploads...pit_n5800_n1560_balls2014_140920_analysis.pdf

What I do not understand is how the GPS altitude data is obtained when the rocket is above 60 kft and 1000 knots which are the ITAR GPS restriction limits. The transmitter does employ an accelerometer (and possibly other sensors) and I'll guess that the GPS altitudes plotted versus time at velocities over 1000 knots (which are flat-line in the velocity plots) are actually calculated from the accelerometer data and fused via a Kalman filter to fit into the portion of the flight where the GPS data is blocked by firmware. The GPS should start reporting altitude and velocity within a second or 2 of the velocity dropping below 1000 knots so the apogee reported should be accurate. If I guessed right, this is a good way to avoid the issue of getting authorization to purchase an unblocked GPS.

I also don't see why the output of the unit can't be used to trigger altitude sensitive events such as drogue and main deployments if you have a small uC in the rocket that can receive the data stream, but there are also other systems that can be used to deploy recovery gear.

Overall it is a very nice system.

Bob
 
What I do not understand is how the GPS altitude data is obtained when the rocket is above 60 kft and 1000 knots which are the ITAR GPS restriction limits.

As far as I understand it, the ITAR limits are 50km and 500 m/s. u-blox programmed their IC with a restriction on 500 m/s and 50 km, not 1000 knots and 60,000 feet which are the old CoCom limits.
 
He's got a 6in minimum dia. baby "Q" motor project in the works.
Looking for those that have gone over 100k and wondering what was used.
 
Last edited:
As far as I understand it, the ITAR limits are 50km and 500 m/s. u-blox programmed their IC with a restriction on 500 m/s and 50 km, not 1000 knots and 60,000 feet which are the old CoCom limits.
As I understand it.
https://www.ecfr.gov/cgi-bin/retrie...HTML&h=L&r=SECTION&n=se22.1.121_116Electronic Code of

Federal Regulations Title 22: Foreign Relations
PART 121—THE UNITED STATES MUNITIONS LIST

[h=2]§121.16 Missile Technology Control Regime Annex.

Item 11—Category II
[/h][h=2]Avionics equipment, “technology” and components as follows; designed or modified for use in the systems in Item 1, and specially designed software therefor:
(a) Radar and laser radar systems, including altimeters (see §121.1, Category XI(a)(3));
(b) Passive sensors for determining bearings to specific electromagnetic sources (direction finding equipment) or terrain characteristics (see §121.1, Category XI(b) and (d));
(c) Global Positioning System (GPS) or similar satellite receivers;
(1) Capable of providing navigation information under the following operational conditions:
(i) At speeds in excess of 515 m/sec (1,000 nautical miles/hours); and
(ii) At altitudes in excess of 18 km (60,000 feet), (see §121.1, Category XV(d)(2); or
(2) Designed or modified for use with unmanned air vehicles covered by Item 1 (see §121.1, Category XV(d)(4)).
(d) Electronic assemblies and components specifically designed for military use and operation at temperatures in excess of 125 degrees C, (see §121.1, Category XI(a)(7)).
(e) Design technology for protection of avionics and electrical subsystems against electromagnetic pulse (EMP) and electromagnetic interference (EMI) hazards from external sources, as follows, (see §121.1, Category XI (b)).
(1) Design technology for shielding systems;
(2) Design technology for the configuration of hardened electrical circuits and subsystems;
(3) Determination of hardening criteria for the above.
[/h][h=1]Notes to Item 11 [/h][h=2](1) Item 11 equipment may be exported as part of a manned aircraft or satellite or in quantities appropriate for replacement parts for manned aircraft.
(2) Examples of equipment included in this Item:
(i) Terrain contour mapping equipment;
(ii) Scene mapping and correlation (both digital and analog) equipment;
(iii) Doppler navigation radar equipment;
(iv) Passive interferometer equipment;
(v) Imaging sensor equipment (both active and passive);
(3) In subitem (a), laser radar systems embody specialized transmission, scanning, receiving and signal processing techniques for utilization of lasers for echo ranging, direction finding and discrimination of targets by location, radial speed and body reflection characteristics.

Maybe you have another more current reference but this is as of yesterday.

Bob

[/h]
 
I have a feeling that something like the entacore with gps apogee deployment will be a good way to go. I don't know if anyone has actually used it for deployment on a high altitude flight.

The Raven will actually report barometric altitude well above 100K. The problem, though, is that the data get too noisy and the unit detects "apogee" too early. Adrian proposed setting a channel to fire at 90K feet with a certain delay period. I never used this approach.

Using accelerometers would be better, but you have to be very careful to get a unit that has an accurate accelerometer. I'm not going to name names, but I know of some altimeters where this would work fine and others where it would not.

The way I have done it is with a timer. When you're above 100K feet, you don't have to hit apogee all that accurately. With a reasonable simulation, a timer can work. On my 118K flight, I hit apogee almost exactly. I also use a Raven as a backup, which I program for barometric apogee deployment if the altitude is below 90K feet. So, if something goes wrong and you don't make the expected altitude, you don't have to rely on the timer. This approach also works if you go above 90K and then come back down to 90K. In that case, if you get to 90K before the timer time, it will still deploy barometrically on the way down. This approach covers quite a few scenarios.

Jim
 
The GPS limits the apogee detection to 50 km according to the website. https://www.multitronix.com/specifications.html

What I do not understand is how the GPS altitude data is obtained when the rocket is above 60 kft and 1000 knots which are the ITAR GPS restriction limits. The transmitter does employ an accelerometer (and possibly other sensors) and I'll guess that the GPS altitudes plotted versus time at velocities over 1000 knots (which are flat-line in the velocity plots) are actually calculated from the accelerometer data and fused via a Kalman filter to fit into the portion of the flight where the GPS data is blocked by firmware. The GPS should start reporting altitude and velocity within a second or 2 of the velocity dropping below 1000 knots so the apogee reported should be accurate. If I guessed right, this is a good way to avoid the issue of getting authorization to purchase an unblocked GPS.

Bob

My experience has been that the u-blox GPS reports "no fix" as soon the velocity exceeds 1000 knots regardless of altitude. This means there are no velocity, altitude or lat/lon readings available above 1000 knots. As soon as the velocity drops below 1000 knots the GPS immediately resumes reporting good data even above 60,000 feet. The Multitronix unit has not yet been flown above the 50km spec but when I asked u-blox technical support if it would report a valid fix above 50km the answer was "maybe". They said it depends on several different factors and basically comes down to how much confidence the GPS has in the fix. Not very detailed but that's all they would give me. They said it would quite possibly work as long as the velocity was low.

As far as the GPS altitude plot goes, I should improve that. The plotting script is very simple. It just connects every GPS altitude to the next one with a straight line. Consequently, the plot shows a straight line from the last valid reading before exceeding 1000 knots to the first valid reading below 1000 knots. Since the altitude trajectory is very steep in that part of the curve the straight line is not very noticeable other than the fact it does not exactly overlay the accelerometer data. I should probably make that more clear by omitting the straight line between altitudes with no valid data in between them.
 
Question for the OP. What is the need: Is it to determine peak altitude OR is it needed to control an apogee event near 120K feet?

If its the latter (to control an apogee event at > 100kft), what is the consequence if the apogee event is +/- 20kft from true apogee? The atmosphere is so thin at those altitudes I am not sure the rocket will feel any significant force differences if the event happened +/- a large error in apogee.
 
I'm pretty sure that the Featherweight Raven has been to 100k.
Ask Jim Jarvis for confirmation....

I think flight computers need GPS to be integrated into deployments systems for reliable deployment over 100k.
A system that uses the data to detect true apogee. Derek Deville might be your go to guy on this.
https://ddeville.com/derek/Qu8k.html
I know of none that are currently available to rocketry community that is affordable

JD

Use the Raven III (the latest one) unless one sends their older Raven back to Adrian. The v2 had a quirk with deployment above 66k'. If one is never going to go there, the v2 is fine. I have one and am not going to deal with the "problem". Kurt
 
Question for the OP. What is the need: Is it to determine peak altitude OR is it needed to control an apogee event near 120K feet?

If its the latter (to control an apogee event at > 100kft), what is the consequence if the apogee event is +/- 20kft from true apogee? The atmosphere is so thin at those altitudes I am not sure the rocket will feel any significant force differences if the event happened +/- a large error in apogee.

Yeah ditto that, I've seen a few high altitude balloons come in on an APRS tracking program and if the balloon bursts "way up there", even if there is a large chute, ain't no air of reasonable amount to have an effect on it. Falls really fast anyways until the atmosphere is denser. A rocket coming in from 100k' at least initially probably doesn't matter much if it's in one piece or two pieces on a shockcord. Kurt
 
Actually, Kurt, this isn't the case. The Raven 2's work fine with upgraded firmware.

Jim
 
Actually, Kurt, this isn't the case. The Raven 2's work fine with upgraded firmware.

Jim

Right I understand Jim but if a person doesn't know there is a problem in the first place, they wouldn't know that they could send it back for Adrian to flash. As I recall, the Raven II with the original firmware works fine if one isn't going above 60k'.
I did mention the fact about upgrading in an obtuse fashion: "Use the Raven III (the latest one) unless one sends their older Raven back to Adrian." I found this thread very interesting even though I know I'll never be going to those flight levels. Kurt
 
Right I understand Jim but if a person doesn't know there is a problem in the first place, they wouldn't know that they could send it back for Adrian to flash. As I recall, the Raven II with the original firmware works fine if one isn't going above 60k'.
I did mention the fact about upgrading in an obtuse fashion: "Use the Raven III (the latest one) unless one sends their older Raven back to Adrian." I found this thread very interesting even though I know I'll never be going to those flight levels. Kurt

Sorry. Didn't read your post closely enough. Year, trying to figure out how to do high altitude deployment when you're at the limits of the sensors and the products aren't perfect is a challenge.

Jim
 
OK, dumb questions.......

What altimeters are people using for flights above 100K, I know it's not Baro based and must be accelerometer based????

I think R-Das maybe a option, most others I seen are only good to 100K, even the accelerometer based ones.

got a project that will hit 120K to 140K and no altimeters for that range, So time to start asking!!!

EasyMega flew to 118k' https://keithp.com/blogs/easymega-118k/. Because the altitude is above the range of the barometric sensor, the flight computer is effectively running solely on the accelerometer to determine apogee.

I've been collecting GPS data from flights with GPS receivers and have not been satisfied that it can reliably detect apogee. Most of the time it works fantastically, but there are still the occasional flights where the GPS receiver fails to provide accurate position information until well after apogee.

One thing I haven't yet tried, but which would be fairly easy, is to take advantage of our gyroscope in EasyMega and TeleMega and compute vertical acceleration and speed instead of Z axis acceleration and speed. That might allow us to more accurately determine apogee, even for off-vertical flights. Right now, off-vertical flight under-estimates apogee, which can cause early drogue deployment.
 
Wow, Thanks for all the answers.

I guess I needed to explain my self more, I was looking for what people have already used, trying not to re-invent the wheel.
Still looks to be 99% of manufactures are dealing with below 100K electronics, I was under the perception that once you hit 90K or better an Accelerometer was used. I knew about GPS , but noticed GPS had problems over mach, unless it had a faster sample( unlocked GPS) rate as Bob noted.

Multitronix was nice , but no control of Charges, nice voice, but I can get a sexy voice lady to read off the data for a lot cheaper. hahahaha

So the quest continues, with a lot of reading.....

Loved Black Magic UFC-3 , did not want the take out a second mortgage on my house.
 
My experience has been that the u-blox GPS reports "no fix" as soon the velocity exceeds 1000 knots regardless of altitude. This means there are no velocity, altitude or lat/lon readings available above 1000 knots. As soon as the velocity drops below 1000 knots the GPS immediately resumes reporting good data even above 60,000 feet. The Multitronix unit has not yet been flown above the 50km spec but when I asked u-blox technical support if it would report a valid fix above 50km the answer was "maybe". They said it depends on several different factors and basically comes down to how much confidence the GPS has in the fix. Not very detailed but that's all they would give me. They said it would quite possibly work as long as the velocity was low.

As far as the GPS altitude plot goes, I should improve that. The plotting script is very simple. It just connects every GPS altitude to the next one with a straight line. Consequently, the plot shows a straight line from the last valid reading before exceeding 1000 knots to the first valid reading below 1000 knots. Since the altitude trajectory is very steep in that part of the curve the straight line is not very noticeable other than the fact it does not exactly overlay the accelerometer data. I should probably make that more clear by omitting the straight line between altitudes with no valid data in between them.

Thanks Vern. It's a great unit. I didn't know you were multitronix.

I know what the ITAR limits are, but I also know that not all manufacturers implement the restrictions the same way. Some simply disable the fix until the unit has a power down reset, others have an extremely long calculation times and could miss apogee, and some do it right and once one of the two conditions are below the ITAR limit they start reporting data in a second or 2. I went to the u-blox website but it appeared that unless you have a signed NDA, they aren't going to tell you how their chips work so you could know ahead of time what response you would observe. Hence my comment/question on how the plot was obtained....

Unless u-blox did something out of the ordinary with their chip, I see no reason why it would not work above 50 km, but until you get a ride on something that exceeds that altitude you won't know for sure if they wouldn't tell you.

Bob
 
Back
Top