Project Blacksky 200K two stage - Class 3 submitted!

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Damit, I ran out of popcorn, time to pop some more.:facepalm:
Glad I'm trying to working on a small gyro system for straight flight on my small "Q" 125K trek.:clap:
hey popcorns done, and a refill on the drink, I'm ready, is intermission over? :pop:
 
I have reason to believe the commercial u-blox GPS that is used in the Multitronix TelemetryPro System will provide position fixes at 200K feet.

U-blox is a Swiss company. I have seen u-blox firmware release notes that specifically say the firmware was designed to meet the Swiss government’s implementation of the Wassenaar Arrangement. (Not to be confused with the Wassenaar Agreement.) The Wassenaar Arrangement is the successor to the Cold War-era Coordinating Committee for Multilateral Export Controls (COCOM), and was established on 12 July 1996, in Wassenaar, the Netherlands.

The Waasenaar Arrangement specifies a velocity restriction but it does NOT specify an altitude restriction. It specifies a maximum velocity of 600 m/s. I have data from many different flights that show the u-blox GPS actually stops reporting position fixes above 1000 knots which is 515 m/s. (A little below the maximum 600 m/s that is allowed.) This happens regardless of altitude. These flights also show that as soon as the velocity drops below 1000 knots, the position fixes immediately resume.

The u-blox data sheet does specify a maximum altitude of 50,000m which is 164K feet. However, I have also been told that the 50,000m limit is just the point where the GPS is guaranteed to meets all it's performance spec's. It is not a limit above which the GPS will refuse to report position fixes. U-blox wrote to me: "...if the position fix seems to be repeatable and trustworthy (i.e. several calculations appear consistent with plenty of satellites, good DOP geometry, and no significant residual deficiencies, then an exception is made and the GPS will still report positions."

Therefore, provided the velocity is low enough and provided the quality of the fix is high enough, I expect the TelemetryPro u-blox GPS to report fixes at 200K feet. (An apogee in the 200K range will by definition make the velocity low there.)

None of my customers have actually flown that high so I do not yet have flight data to prove it works. Perhaps someday. :)


Interesting, that dropout and immediate reacquire of the position with only the velocity limit was interesting to see. If that is indeed the case and they didn't implement a altitude limit there is no reason why the GPS would stop working.
So much of our lives would be less stressful if they would just post the source code for their firmware so we could actually see how they implemented the limits.

I'll also have to amend my previous statement about the LEA-5/6. I've been reading the operations manual more, and it looks like the Airborne <4g mode is just a dynamic model to increase accuracy. Not operating limits of the GPS unit. Operating manual got me by saying MAX vertical velocity.
 
U-blox is a Swiss company. I have seen u-blox firmware release notes that specifically say the firmware was designed to meet the Swiss government&#8217;s implementation of the Wassenaar Arrangement. (Not to be confused with the Wassenaar Agreement.) The Wassenaar Arrangement is the successor to the Cold War-era Coordinating Committee for Multilateral Export Controls (COCOM), and was established on 12 July 1996, in Wassenaar, the Netherlands.

The Waasenaar Arrangement specifies a velocity restriction but it does NOT specify an altitude restriction. It specifies a maximum velocity of 600 m/s. I have data from many different flights that show the u-blox GPS actually stops reporting position fixes above 1000 knots which is 515 m/s. (A little below the maximum 600 m/s that is allowed.) This happens regardless of altitude. These flights also show that as soon as the velocity drops below 1000 knots, the position fixes immediately resume.

The u-blox data sheet does specify a maximum altitude of 50,000m which is 164K feet. However, I have also been told that the 50,000m limit is just the point where the GPS is guaranteed to meets all it's performance spec's. It is not a limit above which the GPS will refuse to report position fixes. U-blox wrote to me: "...if the position fix seems to be repeatable and trustworthy (i.e. several calculations appear consistent with plenty of satellites, good DOP geometry, and no significant residual deficiencies, then an exception is made and the GPS will still report positions."

Therefore, provided the velocity is low enough and provided the quality of the fix is high enough, I expect the TelemetryPro u-blox GPS to report fixes at 200K feet. (An apogee in the 200K range will by definition make the velocity low there.)

WOW sweet you just basically smoothed out all of my thoughts I wasnt sure about.
So I WONT loose lock, and I should see some reliable and some unreliable packets on the way up and down for the areas below 1000kts. Thats good. I will even be able to tell if the rocket is coming in hot based on the packets not resuming the second time after 110 seconds or so (will refer to my timecharts based on GPS reporting near apogee. Could go lower or higher which will change that 110 value a lot)

Thank you for clarifying that for me!!!


Interesting, that dropout and immediate reacquire of the position with only the velocity limit was interesting to see. If that is indeed the case and they didn't implement a altitude limit there is no reason why the GPS would stop working.
So much of our lives would be less stressful if they would just post the source code for their firmware so we could actually see how they implemented the limits.

I'll also have to amend my previous statement about the LEA-5/6. I've been reading the operations manual more, and it looks like the Airborne <4g mode is just a dynamic model to increase accuracy. Not operating limits of the GPS unit. Operating manual got me by saying MAX vertical velocity.

Yeah Ive seen the GPS-1 used on many high G flights before without issues. Id imagine during boost the numbers might get a little wack but post burnout the accuracy would go back to normal, provided you werent going too fast still haha.
 
So my plastics man and I made some prototype sled and avbay parts for initial testing and playing with. And we did quite a review of the parts and minor things do need to be changed before they could be regarded as flightworthy, but nothing major. Going to be doing some talking with my GPS guy at Dairy Aire about some mounting and insulating logistics... I thought I'd share this minor progress with everyone and also pose a pre-build question.

Photo Apr 13, 8 58 31 AM.jpg

Per some lengthy conversations with Curt Von Delius regarding high altitude environments and batteries, I am beginning to change some ideas about my avbay, slightly.

After looking at some timescale line graphs of temperature recordings from various high altitude balloon projects I think I may be able to safely build an avionics bay that is not air-tight for my 200K flight.

The key point we brought to light is the overall short amount of time my rocket will spend in these drastic environments. While the temperature drops in the graphs from balloon data is indeed extreme, it is not quick. Take a look at this graph i pulled from https://www.societyofrobots.com/space_balloon_temperature.shtml

space_temp_sb2.png

It describes some sensor plots from a few iterative balloon proects, doccumenting both exterior and interior avbay temperatures over time and altitude. Very useful for my project, even without having much detail on their avbay insulation work. Based on this graph and others like it, I think it is safe to say that my rocket wont be up there long enough to freeze batteries or overheat chipsets.

The lack of atmosphere to serve as a thermal reservoir shouldnt be as much of a problem for my batteries as will be the ice-cold air re-entering the avionics bay as the rocket descends..

To counter this, I plan to wrap the batteries themselves in an insulating wool, of sorts, and pack the rest of the empty space of the avbay full of simple foam. This should help retain some of the original thermal energy and protect against that cold air.

Major major benefits to doing it this way. I now may use barometric detection for pyro events as well. THIS MEANS THAT I DRASTICALLY IMPROVE THE OVERALL SAFETY OF THE PROJECT by allowing for a deployment based on a failed staging.

I was pretty sure I could do this via accelerometer/timer setting with both the Raven and the Telemega, but I hadnt had a chance yet to contact Adrian or Altus to confirm this. But I am almost positive that I can do it with baro.
Example
In the event that Time < 100 seconds, yet baro altitude decreasing, fire pyro lines. ( which would be a surgical charge)
THIS WILL PREVENT MY SUSTAINER FROM COMING IN HOT in the event of a failed light for whatever reason.
But... Am I understanding the criteria correctly?

I will try to get a chance to send some emails out tomorrow, as well as update the writeup to reflect these avionics bay changes... But I'd like to hear feedback from here and TRA (emailed) first...

As for the funding and advertising, Im looking at maybe setting that up next week.
 
I have collected temperature data via the Raven's on multiple high altitude flights. Haven't seen much of a drop in temperature at all; thus, I haven't taken any special measures to protect the altimeters or batteries from the cold.

I use barometric deployment in the case of no staging. My normal approach is to use baro if pressure is increasing and if the altitude is less than 90K. Both the Raven and Telemega can be programmed for this, although maintaining a "mach lockout" capability based on velocity can be challenging, particularly for the Raven.

I suggest you not use surgical tubing charges.

Jim
 
I have collected temperature data via the Raven's on multiple high altitude flights. Haven't seen much of a drop in temperature at all; thus, I haven't taken any special measures to protect the altimeters or batteries from the cold.

I use barometric deployment in the case of no staging. My normal approach is to use baro if pressure is increasing and if the altitude is less than 90K. Both the Raven and Telemega can be programmed for this, although maintaining a "mach lockout" capability based on velocity can be challenging, particularly for the Raven.

I suggest you not use surgical tubing charges.

Jim

The other thing operating in that environment is heat transfer isn't as quick in the vacuum that exists at altitude. The up and down with a rocket is relatively short that it's not likely to be a problem. I've read where the balloon guys have flown some of those small liquor bottles at altitude and have noted that they're still pretty cold if they recover quickly enough. In that case, they sit up there for hours and it gets mighty cold over time. Kurt
 
Air is not a thermal storage medium. It is a heat transfer medium. The airframe gets cold, the residual air within the e-bay will remove heat from the electronics and batteries and transfer it to the colder airframe.

The reason for this is that air density at sea level is about 1/1000 that of a solid, and at 100 kft decreases to 1/100000 that of the solid and heat capacity is proportional to mass. What air does is to transfer heat via convection from one part of the e-bay to the other. In most cases, the issue is not over-cooling but rather over-heating. If you simply line the e-bay airframe which will get cool with ~1/8" pink anti-static foam sheet, you should have much better thermal control.

https://www.mcmaster.com/#standard-closed-cell-foam-sheets/=11ytwti is a pink anti-static polyethylene foam that will provide an effective barrier when attached to the inside of the airframe and is electronics friendly.

https://www.mcmaster.com/#static-control-foam/=11yu1mg is a pink anti-static polyurethane foam that will provide an effective barrier when attached to the inside of the airframe and is electronics friendly.

You can also wrap the batteries with a layer as well. Don't fill the entire insides with loose foam. Not necessary and can potentially go in places where you don't want it.

references:

https://www.electronics-cooling.com/1998/09/cooling-electronics-at-high-altitudes-made-easy/

https://www.electronics-cooling.com/1999/09/adjusting-temperatures-for-high-altitude/

https://www.iaeng.org/publication/WCE2010/WCE2010_pp1444-1447.pdf

https://www.engineersedge.com/heat_transfer/convection.htm

https://dspace.mit.edu/bitstream/handle/1721.1/39011/20404614-MIT.pdf?sequence=2

Bob
 
Ok Ill send you pictures once i get the motor and some of the other parts.
 
Back
Top