Electronics at 100,000+

The Rocketry Forum

Help Support The Rocketry Forum:

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

Thrustify

Well-Known Member
Joined
Oct 29, 2012
Messages
55
Reaction score
0
Anyone have some input on what options are available for recovery/data for flights well exceeding 100,000'. Barometric ceases to be reliable much over 100k, so accelerometer or other sensor input is needed for apogee detect. I've read that the r-das is used successfully in Up Aerospace's vehicles. Anything else out there that will work at 150k+? Will the raven3 work that high with the right setup? Timers are another option although, preferable as a backup, rather than primary. An IMU would be spiffy, but I don't have time to develop one. :D
 
Raven yes.


With proper configuration (ie, baro + timer). Accelerometer error on it adds up enough that it can't accurately predict apogee via accelerometer on super high flights. The baro sensor also runs into noise problems at IIRC 120k' or so, thus the baro + timer. There's quite a bit of discussion on the forum with more details on it, but I'm not going to go searching.
 
With proper configuration (ie, baro + timer). Accelerometer error on it adds up enough that it can't accurately predict apogee via accelerometer on super high flights. The baro sensor also runs into noise problems at IIRC 120k' or so, thus the baro + timer. There's quite a bit of discussion on the forum with more details on it, but I'm not going to go searching.

The Carmack prize winners used an rdas in accelerometer mode and a raven with barometric apogee plus 30 seconds.
 
Let me clarify, you might need to change how you eject the drogue.
 
You should read the UP Aerospace SpaceLoft Users Guide for flight profile and information.

SpaceLoft does not deploy anything at apogee. The system is designed to simulate microgravity for several minutes. A typical flight sequence is shown in the table below.


Event
Time
(seconds)

Altitude
(MSL, km)

[FONT=Times New Roman,Times New Roman][FONT=Times New Roman,Times New Roman]Booster Ignition [/FONT][/FONT]
[FONT=Times New Roman,Times New Roman][FONT=Times New Roman,Times New Roman]0 [/FONT][/FONT]
[FONT=Times New Roman,Times New Roman][FONT=Times New Roman,Times New Roman]1.4 [/FONT][/FONT]
[FONT=Times New Roman,Times New Roman][FONT=Times New Roman,Times New Roman]Booster Burnout [/FONT][/FONT]
[FONT=Times New Roman,Times New Roman][FONT=Times New Roman,Times New Roman]12.5 [/FONT][/FONT]
[FONT=Times New Roman,Times New Roman][FONT=Times New Roman,Times New Roman]17 [/FONT][/FONT]
[FONT=Times New Roman,Times New Roman][FONT=Times New Roman,Times New Roman]De-Spin System Initiated [/FONT][/FONT]
[FONT=Times New Roman,Times New Roman][FONT=Times New Roman,Times New Roman]55 [/FONT][/FONT]
[FONT=Times New Roman,Times New Roman][FONT=Times New Roman,Times New Roman]66.5 [/FONT][/FONT]
[FONT=Times New Roman,Times New Roman][FONT=Times New Roman,Times New Roman]Apogee [/FONT][/FONT]
[FONT=Times New Roman,Times New Roman][FONT=Times New Roman,Times New Roman]155 [/FONT][/FONT]
[FONT=Times New Roman,Times New Roman][FONT=Times New Roman,Times New Roman]115 [/FONT][/FONT]
[FONT=Times New Roman,Times New Roman][FONT=Times New Roman,Times New Roman]Payload Separation from Booster [/FONT][/FONT]
[FONT=Times New Roman,Times New Roman][FONT=Times New Roman,Times New Roman]240 [/FONT][/FONT]
[FONT=Times New Roman,Times New Roman][FONT=Times New Roman,Times New Roman]79.5 [/FONT][/FONT]
[FONT=Times New Roman,Times New Roman][FONT=Times New Roman,Times New Roman]Recovery Deployment [/FONT][/FONT]
[FONT=Times New Roman,Times New Roman][FONT=Times New Roman,Times New Roman]454 [/FONT][/FONT]
[FONT=Times New Roman,Times New Roman][FONT=Times New Roman,Times New Roman]3.3 [/FONT][/FONT]
[FONT=Times New Roman,Times New Roman][FONT=Times New Roman,Times New Roman]Vehicle Touchdown [/FONT][/FONT]
[FONT=Times New Roman,Times New Roman][FONT=Times New Roman,Times New Roman]799 [/FONT][/FONT]
[FONT=Times New Roman,Times New Roman][FONT=Times New Roman,Times New Roman]1.2 [/FONT][/FONT]

The payload does not separate at apogee which is typically over 100 km. In the above example apogee is 113 km and the payload does not separate until 79.5 km and then reenters in a flat spin and recovery deployment does not initiate until 3.3 km. They could use a smart hobby rocket barometric altimeter to control the drogue/main non-apogee dual deployment, but it not a convention mode of deployment in hobby rocketry since the drogue is deployed by the barometer and the main deployed 10 seconds later.

Rocket flight to these altitudes do not use hobby rocketry components to determine apogee. I'm confident these guys use a 9-DOF (degree of freedom) IMU (Inertial Measurement Unit) which contains 3 accelerometers, 3 magnetometers, and 3 gyros coupled to a uP based INS (Inertial Navigation System) coupled to a GPS and barometer. The IMU measures the attitude and accelerations of the rocket and the rotational rates of the rocket. The data is sent to the INS to update the rocket's present position, attitude and trajectory, so the INS determines the apogee.

The IMU/INS is not perfect and has a small drift with time. First order drifts can be characterized and zeroed out, but higher order errors are more problematic. GPS data, when available, is used to correct any accumulated drift. Barometric data, when available is used to verify altitude. Larger payloads may also have radar so the AGL can be measured directly.

The size and cost of IMUs has decreased markedly over the past several years. Hobbyists can get reasonably priced units from Sparkfun.com, DIYdrones.com and FPVHobbby.com at reasonable prices. Many professionals make their own tailored to their needs, and we make a 10 g 9-DOF IMU with GPS and barometer for our uMAVs.

Another difference between hobby rocketry and professional rocketry is the design engineering. 99+% of hobby rockets are not engineered. Hobbyists tend to simply add endless amounts of FG and/or Carbon wraps so make their rockets "stronger". It may or may not do that, but it certainly makes them heavier. Professionals strive to make their rockets as light as possible and remove weight wherever possible to increase payload capacity and/or range and/or to reduce cost.

Also it should be noted that professional routinely use BP and other pyrotechnic charges for high altitude deployments. The difference between the hobbyist and the professional is that the pros use hermatically sealed charges to insure complete ignition and combustion of the charge. The same holds for high attitude SRM igniters. Igniters for high altitude SRM ignition are hermatically sealed to insure the pyrogen fully ignites. Read NASA SP-8051 for details.

Bob
 
Accelerometer error on apogee prediction on flights above 100K ft is really not a factor (unless you are using that for altitude prediction). There is no atmosphere up there to speak of so an early apogee deployment will not affect the trajectory of the rocket all that much. Same as a late deployment, there is hardly any atmosphere to cause damage if the event happens at high speeds. For a hobby flight you would rather have a system that's approximately right but not exactly wrong.

For altitude determination a u-blox GPS hooked to a data logger will suffice. Sparkfun is a place you can look for that.

I will be supplying DeMar a Marsa54 for such a 100K+ flight. It will work fine.
 
Last edited:
We at Mudd are planning on trying the new AIM Xtra, which uses gps for apogee detection, on our Bare Necessities flight. It doesn't have a full IMU, but it does Kalman filter the gps, axial accelerometer, and barometric sensor.
 
The earlier version of Ravens at one point did have trouble past 66k ft.
That is: once it was discovered that it failed when someone attempted to make it to 100k.



JD
 
The earlier version of Ravens at one point did have trouble past 66k ft.
That is: once it was discovered that it failed when someone attempted to make it to 100k.

If I'm not mistaken, Adrian has a fix for this -- you need to send him the altimeter, and he can update its firmware.

-Kevin
 
The UAV equipment is quite reasonable indeed!. Thanks for the links.
 
I have a few but don't intend on flying above 65k ft.
The affected Raven 2 that I have, has had no issues thus far.
Just like upgrading the bios on your computer: if it works leave it along.
It's been to 12k and 14k without any problems (knock on wood).


JD



If I'm not mistaken, Adrian has a fix for this -- you need to send him the altimeter, and he can update its firmware.

-Kevin
 
Anyone have some input on what options are available for recovery/data for flights well exceeding 100,000'. Will the raven3 work that high with the right setup?

It depends what you mean by "well over" 100 kft. The Raven's baro-based apogee detection has been used successfully by Ken Biba's team to win the Carmack prize at about 105,000 feet, and would have worked even better for them if an excessive deployment delay were not used. Based on bell jar tests I have done, I think the limit for the Raven's baro-based apogee detection is about 115,000 or 120,000 feet if you use a deployment delay of a few seconds.

I recommend using a lot of caution if you plan to use the Raven's accel-based apogee deployment over about 30,000 feet, because maybe 1/3 to 1/2 of the Ravens have non-linearity errors in the accel sensor and/or A/D converter that can result in time-to-apogee errors on the order of 10%. That's not a big deal with a 20 or 30 second time to apogee, but it can lead to a lot of vertical velocity at deployment on an 80,000 foot fight. Most Ravens are a lot more accurate than that, but there isn't an easy way to test for the non-linearity other than flying it.
 
Last edited:
Can the Raven be filtered to prevent it from reporting the peak accel reading as the apogee deployment charge?
On a few flights it reports 52 G's as max. I'd like the report be from actual flight acceleration.


JD


It depends what you mean by "well over" 100 kft. The Raven's baro-based apogee detection has been used successfully by Ken Biba's team to win the Carmack prize at about 105,000 feet, and would have worked even better for them if an excessive deployment delay were not used. Based on bell jar tests I have done, I think the limit for the Raven's baro-based apogee detection is about 115,000 or 120,000 feet if you use a deployment delay of a few seconds.

I recommend using a lot of caution if you plan to use the Raven's accel-based apogee deployment over about 30,000 feet, because maybe 1/3 to 1/2 of the Ravens have non-linearity errors in the accel sensor and/or A/D converter that can result in time-to-apogee errors on the order of 10%. That's not a big deal with a 20 or 30 second time to apogee, but it can lead to a lot of vertical velocity at deployment on an 80,000 foot fight. Most Ravens are a lot more accurate than that, but there isn't an easy way to test for the non-linearity other than flying it.
 
Can the Raven be filtered to prevent it from reporting the peak accel reading as the apogee deployment charge?
On a few flights it reports 52 G's as max. I'd like the report be from actual flight acceleration.


JD

There isn't a reliable way that I can think of to automatically distinguish the different causes of measured accelerations for the min/max summary page. It's all "actual" acceleration measurements. A human looking at the graph can figure it out, though. You can zoom in and hover the mouse over the time you're interested in to read the precise measured value.
 
I recommend using a lot of caution if you plan to use the Raven's accel-based apogee deployment over about 30,000 feet, because maybe 1/3 to 1/2 of the Ravens have non-linearity errors in the accel sensor and/or A/D converter that can result in time-to-apogee errors on the order of 10%. That's not a big deal with a 20 or 30 second time to apogee, but it can lead to a lot of vertical velocity at deployment on an 80,000 foot fight. Most Ravens are a lot more accurate than that, but there isn't an easy way to test for the non-linearity other than flying it.

For data junkies, that 10% can be a lot, especially when it is affecting half of your product (or at least both of my ravens). I wouldn't imagine it would be that difficult to build a small centrifuge to test the ravens in before shipping, or depending on the assembly process, before adding the accelerometer and adc. Not sure what the accelerometer and adc market is like, but maybe look into chips that have tighter tolerances? I'd certainly be willing to pay more for an accelerometer that was accurate.
 
It depends what you mean by "well over" 100 kft. The Raven's baro-based apogee detection has been used successfully by Ken Biba's team to win the Carmack prize at about 105,000 feet, and would have worked even better for them if an excessive deployment delay were not used. Based on bell jar tests I have done, I think the limit for the Raven's baro-based apogee detection is about 115,000 or 120,000 feet if you use a deployment delay of a few seconds.

I recommend using a lot of caution if you plan to use the Raven's accel-based apogee deployment over about 30,000 feet, because maybe 1/3 to 1/2 of the Ravens have non-linearity errors in the accel sensor and/or A/D converter that can result in time-to-apogee errors on the order of 10%. That's not a big deal with a 20 or 30 second time to apogee, but it can lead to a lot of vertical velocity at deployment on an 80,000 foot fight. Most Ravens are a lot more accurate than that, but there isn't an easy way to test for the non-linearity other than flying it.

In case you have an error, can you set a different vertical velocity threshold? If the Raven decides that you're not below 400 ft/s and your rocket is already arcing over, what would happen?
 
Is the 250G accel version more linear than the 70G version? Since 250 is close to a power-of-two multiple, thinking it might be.

Also, I would think that it would be easy to ignore a few accel samples for peak reading purposes after you fire the deployment charges, since the software has control of that event. Of course, I suspect that your flash is probably just about maxed out... I know that I'm always looking for something to do with the last few bytes. :)
 
Deployment above 100K is a real pain for me. My current approach for flights in the 100 to 125K range is to use a timer. However, I also use a Raven with standard barometric deployment and an altitude flag, which will do the apogee event if apogee is below 90K (where I'm pretty sure the Raven will work).

Jim
 
I'd certainly be willing to pay more for an accelerometer that was accurate.

I don't think you want to pay that much. I have great (painful) experience with negotiating special lot testing on electrical devices. Special lot tests (call them group A) run well in excess of $2k typically, if not more, per lot. Then you have to scrap some of the lot (ostensibly 10%). Say Adrian plans to make 100 "high test" ravens, so he lot tests 112 accelerometers at 50 cents a pop, scraps 10, and is charged $2000 for the procedure. Amortize over the 100 devices. Now you made your 50 cent part 21 bucks. Plus, it is not just the accelerometer, it is the ADC (as Adrian indicated). I bet that one is more than $2k to screen out ADC variation.

Adrian would then have to carry than inventory, so cost of money calculation...

I would not pay $1000 for a "Super" Raven. Someone might, but not me.

It might be easier and cheaper to screen out the 10% that vary. Tell you what, buy three on your own, install all three in a rocket, test, and sell the nonconforming items to me :D

(kidding)
 
I don't think you want to pay that much. I have great (painful) experience with negotiating special lot testing on electrical devices. Special lot tests (call them group A) run well in excess of $2k typically, if not more, per lot. Then you have to scrap some of the lot (ostensibly 10%). Say Adrian plans to make 100 "high test" ravens, so he lot tests 112 accelerometers at 50 cents a pop, scraps 10, and is charged $2000 for the procedure. Amortize over the 100 devices. Now you made your 50 cent part 21 bucks. Plus, it is not just the accelerometer, it is the ADC (as Adrian indicated). I bet that one is more than $2k to screen out ADC variation.

Lot testing will not fix problems that are the result of design decisions.

The eZ8 ADC is the worst micro-controller ADC I have ever looked at. The specifications indicate that there are missing codes and it isn't monotonic. Fixing that is as simple as switching to a micro-controller with a better ADC. I suspect anything will be better than the eZ8.

But that doesn't address the problem of running a 5V +/-5% accelerometer at 3.6V. A simple fix here is to switch from the ADXL78 to the ADXL001. Same package and an almost compatible pinout but it is single axis and costs more.

In any case the RDAS Tiny also uses the ADXL78 but runs it at 5V and uses a better micro-controller and ADC with much better results.
 
Lot testing will not fix problems that are the result of design decisions.

The specifications indicate that there are missing codes and it isn't monotonic.

I have never heard these assertions made against the microcontroller I'm using for the Raven, and I can't find anything like that in the spec or the errata for the part (https://www.zilog.com/index.php?opt...ne=1&parent_id=2&familyId=6&productId=Z8F0880) Moreover, those assertions are not supported by any recorded flight data I have ever seen. So either David has gotten confused (hey everyone has a bad day) or he's talking about a different microcontroller. Now that said, the nonlinearity error of +-5 LSB isn't a great spec, considering how it's only practical to calibrate at +-1 G and we're talking about a 70G or 250G range. I've looked into changing microcontroller families, and the trade just hasn't come out in favor of making the switch away from Zilog so far. Apparently Zilog stopped developing new ones some time ago, so at some point I'll need to switch, (probably to a 32-bit ARM) but not any time very soon.

But that doesn't address the problem of running a 5V +/-5% accelerometer at 3.6V. A simple fix here is to switch from the ADXL78 to the ADXL001. Same package and an almost compatible pinout but it is single axis and costs more.

First of all, the accelerometer operating range isn't 5V +/- 5%, it's specified to operate from 3.5V to 6V. https://www.analog.com/static/imported-files/data_sheets/ADXL278.pdf See page 5. I know from experience it really operates down to about 3.3V. Operating the Raven at 3.6V puts allows the Raven to run from a single Lipo cell, which is key for packaging it into a tiny av-bay. That's one of the main reasons why it was chosen by Tripoli for all of its barometric-based records, and why I couldn't fly any other altimeter in most of my rocket designs even if I wanted to. I can install 2 complete av-bays for about the same mass as a single 9V battery.

I would also contend that an altimeter with a dual-axis accel and 2%-10% accelerometer error has more useful and informative information than one with a single-axis accel and 1%-2% error. It's especially useful when diagnosing a problem flight, when data is needed most. After a shred, did the rocket go aerodynamically unstable as it hit Mach 1.8, or did it throw a fin? How high up was the rocket when it stopped fishtailing? What was the sideways force on an eyebolt that got bent? You've got a good chance of figuring that out with a dual-axis accelerometer, and almost no chance if you don't. Cost aside, I would rather fly a a dual-axis accel that gives me data that's probably good to a few percent, maybe 10% error if I'm unlucky, rather than a single-axis accel with better linearity. Not everyone will think the same way, but anyone is welcome to design their own Raven-beater and see how that fares in the marketplace.

For every decision that went into the Raven's design, I have done my best to make choices that balance the needs and desires of the largest number of users, while maximizing the Raven's compatibility with record-setting rocket performance. Up to about 110,000 feet, the Raven is pretty hard to beat by those criteria. It did successful deployment duty and recorded excellent-accuracy barometric data on the Carmack prize-winning flight to 105,000 feet. It has been used to break altitude records for H, I, J, and L impulse motors. Its potential in multi-stage flight has only begun to be tapped. Is it the best choice for a 130,000 foot shot where you would like to have a really accurate accelerometer-based apogee detection, preferably with a Kalman Filter? Probably not. For just about any other flight, there's no altimeter I would rather fly (even if I didn't own the company).

May your rocket flights be safe, fun, and informative.
 
I have never heard these assertions made against the microcontroller I'm using for the Raven, and I can't find anything like that in the spec or the errata for the part (https://www.zilog.com/index.php?opt...ne=1&parent_id=2&familyId=6&productId=Z8F0880) Moreover, those assertions are not supported by any recorded flight data I have ever seen. So either David has gotten confused (hey everyone has a bad day) or he's talking about a different microcontroller. Now that said, the nonlinearity error of +-5 LSB isn't a great spec, considering how it's only practical to calibrate at +-1 G and we're talking about a 70G or 250G range.

The differential nonlinearity is minimum -1 count which implies missing codes and maximum +4 counts which implies non-monotonic operation.

Add that to the integral non-linearity of +/- 5 counts and this is awful. More typical specifications are +/-1 count or less.


First of all, the accelerometer operating range isn't 5V +/- 5%, it's specified to operate from 3.5V to 6V.

All of the specifications listed are for operation at 5V +/- 5%. It does claim that it is functional down to 3.5V but says absolutely nothing about how well it works over that range. Do you have any data showing it meets specifications at 3.6V?

In addition, the voltage regulator is a +/-4% part. That range extends below the 3.5V functional range of the ADXL78 and above the 3.6V absolute maximum or it might cause damage rating of the eZ8. Not the best choice.

I would also contend that an altimeter with a dual-axis accel and 2%-10% accelerometer error has more useful and informative information than one with a single-axis accel and 1%-2% error.

The report from the Carmack prize winners shows that the errors are much worse. They reported that on a flight test the two Ravens on board reported apogee 15 and 25 seconds before the actual apogee. For a 50 second flight to ~33,000 feet this is appallingly bad.
 
Any reason why you couldn't use GPS for apogee detection? I know that some of them are limited to 60,000', but apparently this also depends on velocity, so if waited to turn it on until you were well into the subsonic coast phase you might be able to get past this...
 
Any reason why you couldn't use GPS for apogee detection? I know that some of them are limited to 60,000', but apparently this also depends on velocity, so if waited to turn it on until you were well into the subsonic coast phase you might be able to get past this...

There is no reason why you can't, other than slow sampling frequencies. The AIM XTRA supposedly can.
 
Near apogee your velocity should be low, so 3-5 samples/sec should be adequate. I would think that it would be more accurate than either accel integration or baro, especially since air pressure pretty much goes away at 100K.

There is no reason why you can't, other than slow sampling frequencies. The AIM XTRA supposedly can.
 
What if altimeters recognized that at 50kft+ their noise-signal ratio gets poor. So to counter act that they slowed their sample rate. So that the difference in altitude per sample is higher and maybe that would decrease the failure rate.

We are talking about a <1% flight profile, but one I hope to accomplish in the next 18months. I have an RDAS that I will begin getting comfortable with and am confident these types of conversations will improve the information that gets spread and we can all learn about what it might take to judge apogee detection in these kinds of flights.

I love the idea of GPS as a apogee detection device. I have seen data go that high, but at this point in time I wouldn't trust it entirely.

I am not a electronics engineer so most of this conversation goes over my head.

But that you for this conversation.
 
This is a good idea, though the implementation would be a little different. The Raven uses a digital filter that prevents noise from triggering the baro apogee detection early. I could make the filter coefficient altitude-dependent to cancel out the increasing noise at high altitudes.
 
This is a good idea, though the implementation would be a little different. The Raven uses a digital filter that prevents noise from triggering the baro apogee detection early. I could make the filter coefficient altitude-dependent to cancel out the increasing noise at high altitudes.

If you filter the pressure data before converting to altitude it should do it automatically, assuming noise is constant no matter the pressure level.
 
The differential nonlinearity is minimum -1 count which implies missing codes and maximum +4 counts which implies non-monotonic operation.

Actually, it doesn't imply that at all. A positive and negative range simply means that the error can be in a positive or negative direction relative to a perfect linear slope. The differential nonlinearity is a measure of the nonlinearity errors sampling 2 different channels; i.e. do the errors in 2 channels tend to move in the same direction to cancel out. The data sheet shows that for the most part, they do.
The report from the Carmack prize winners shows that the errors are much worse. They reported that on a flight test the two Ravens on board reported apogee 15 and 25 seconds before the actual apogee. For a 50 second flight to ~33,000 feet this is appallingly bad.

The initial description of the Raven's performance at apogee on the prize-winning flight was not consistent with the actual data, which the team was nice enough to provide to me. If I get the data from the flight you're talking about, I'll comment on it.
 
Back
Top