So, maybe I'll try a three-stager

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Yes, I do too. The boost part was really nice. So far, I don't have a complete video of the flight, but I'm sure one will appear.

It was also nice that Steve Shannon was able to see the flight, after working so hard to try to fly the rocket twice last year. And it was great that Kip helped out this year.

Jim

It was beautiful! I was glad to see you nail all three stages.
 
Very cool. Congrats and thanks for sharing this journey with us. I’m living vicariously through this thread.
 
Phenomenal work Jim! I heard that you were one of if not the first to launch on Friday. Given you were flying a three stage that speaks volumes to your preparation and organisation. Congrats man, you deserve it!
 
Congrats Jim! So happy for you that it all came together on this one. So much work, previous iterations, trials went into this....well done sir!

Looking forward to seeing the flight data eventually. In the meantime, safe travels, relax and rest well!

:)
 
Well, we pulled out what we could. Seems like it was mainly the lower air frame with the motor (about a third of the motor was peeled back). However, I'm not certain that the upper air frame was there. Further, the 4x3 transition that was the "nose cone" for this stage came off and was recovered not far away from the lower section. I think the main just popped and the transition section came loose. However, I'm going to take a quick look around that area just on the chance that the upper air frame came free. Stranger things have happened.

Jim

Interesting, that would seem to indicate no drouge came out but maybe the main got out. Main would shred and upper airframe would go into a rapid spin, which could fling the transition off. I’ve seen a lower airframe recover stability after such a deployment so it’s quite possible that the lower airframe simply went on it’s way after a small diversion. I would assume the upper airframe would follow the wind to some extent. If perhaps the drouge survived it would descend fairly slowly so could have drifted some distance.
 
Interesting, that would seem to indicate no drouge came out but maybe the main got out. Main would shred and upper airframe would go into a rapid spin, which could fling the transition off. I’ve seen a lower airframe recover stability after such a deployment so it’s quite possible that the lower airframe simply went on it’s way after a small diversion. I would assume the upper airframe would follow the wind to some extent. If perhaps the drouge survived it would descend fairly slowly so could have drifted some distance.
I looked briefly for the upper air frame. No joy.

I got home on Tuesday evening and have spent a little time looking at the data. Before I do that, let me acknowledge the team members for the flight, who include Stu Barrett, Gordon Bain, Dan and Linda DeHart, Kip Daugirdas, and of course, my wife Gloria (without whom this stuff doesn't happen). We had so much fun!

Several interesting things happened during the flight. One thing that happened is that the rocket started to tumble at around 140K feet. Kip said that the same thing happened on his flight at about the same altitude. Interesting ...

Second, it turns out I ran into the COCOM limit. At around 160K feet, the gps quit recording and transmitting data. Recording and transmission resumed when the rocket went below 160K. I compared the simulation for the flight against the gps data before and after the COCOM gap. Prior to the time the rocket started to tumble (at 75 seconds), the altitude was almost exactly on the simulation. Roughly speaking, it looks like the rocket actually reached about 175K, and that the tumbling cost about 10K in altitude. I'll take 175K.

Third, the stabilization section inhibited roll and appears to have brought the rocket to a more vertical position. The flight was pretty straight, but it looks like the tilt decreased from about 5° to about 1.8° during the time that vertical stabilization was active. I"ll take that too. As a result of a more vertical position, and modest upper level winds, the third stage landed less than 3 miles away.

The attached pics illustrate the above data. The gps track shows the "missing" portion of the flight due to the COCOM limit. The RasAero II simulation result includes some of the actual gps data and my dotted extrapolation of the actual altitude pathway. The tilt data is from the EasyMega.

JimGPS clip.jpg Simulation 2.jpg Tilt Graph 2.jpg vlcsnap-2018-09-26-14h23m23s562.png
 
The attached pics illustrate the above data. The gps track shows the "missing" portion of the flight due to the COCOM limit.
The ITAR limits were revised in 2016 and the 15,000m limit was removed. The GPS data sheet does list an operational limit of 50,000m.
 
Second, it turns out I ran into the COCOM limit. At around 160K feet, the gps quit recording and transmitting data. Recording and transmission resumed when the rocket went below 160K. I compared the simulation for the flight against the gps data before and after the COCOM gap. Prior to the time the rocket started to tumble (at 75 seconds), the altitude was almost exactly on the simulation. Roughly speaking, it looks like the rocket actually reached about 175K, and that the tumbling cost about 10K in altitude. I'll take 175K.
Great work once again Jim! As to the COCOM limit, that makes sense. According to the documentation uBlox locks out above 50,000 meters / 164,000 feet ASL. So anything above that you wouldn't have had GPS lock from a uBlox chipset GPS tracker.

One thing that happened is that the rocket started to tumble at around 140K feet. Kip said that the same thing happened on his flight at about the same altitude. Interesting ...

Can you give more detail on that? When you say tumble how exactly did it tumble is what I'm curious about.
 
Great work once again Jim! As to the COCOM limit, that makes sense. According to the documentation uBlox locks out above 50,000 meters / 164,000 feet ASL. So anything above that you wouldn't have had GPS lock from a uBlox chipset GPS tracker.

Can you give more detail on that? When you say tumble how exactly did it tumble is what I'm curious about.

The rocket simply started to tumble at 140K feet. You'll see it in the video. It looked initially like the rocket had an apogee event. However, at the point where the apogee event should have been, you can hear the charges go off, and the nature of the "flight" changes. From all of the data, it is clear that the rocket was tumbling in one piece (in it's original configuration) and then separated later on.

Jim
 
One pellet. Plus some mag. Thanks Jim!!

Third stage should have been around 45K, but it will take some time to know for sure.

Jim
Well, even with one of CJ's magic pellets (0.9 grams BKNO3) and about 4 grams of magnalite, it still took 4.5 seconds for the 3rd stage to light. It would have actually come up to pressure right at 45K feet. I chose the magnalite quantity to be about twice what one might use with a burst disk (since I wasn't using a burst disk). Good thing I ran into CJ at Airfest.

Thanks for the calcs, John. Let's work on that burst disk approach of yours.

Jim
 
I have had some requests to post the RasAero II file for the rocket. Attached...

Note that it is not possible to show the stabilization canards, but the weight/length of the rocket includes that section.

Jim
 

Attachments

  • ThreeCarbYen-2018.CDX1
    6.7 KB · Views: 24
As others' have mentioned above, you pegged the GPS :cool:.

ecarson just pointed me recently at the relevant pages of the data sheet from ublox for their GPS receiver. See here for the discussion and to get the expurgated pdf:
https://www.rocketryforum.com/threads/enabling-galileo-gps-on-u-blox-m8n.148088/

Even if airborne mode is selected the lockout on position data is on altitude, so yep, 50km is the limit for position reporting.

That is a very useful table if considering high flights. I have it printed out for reference :).
 
As others' have mentioned above, you pegged the GPS :cool:.

ecarson just pointed me recently at the relevant pages of the data sheet from ublox for their GPS receiver. See here for the discussion and to get the expurgated pdf:
https://www.rocketryforum.com/threads/enabling-galileo-gps-on-u-blox-m8n.148088/

Even if airborne mode is selected the lockout on position data is on altitude, so yep, 50km is the limit for position reporting.

That is a very useful table if considering high flights. I have it printed out for reference :).

And here's that table without the watermarking posted on the ARF 5 weeks ago. ;)

file.php
 
And here's that table without the watermarking posted on the ARF 5 weeks ago.

One thing I have never understood in that u-blox GPS table is the “max vertical velocity”. It shows 100 m/s maximum for the 4G airborne mode. That is definitely not correct. I have flight data from a great many flights. It cuts out at 515 m/s. Not 100 m/s.
 
Vern, I assume you are still getting position as well? What attitude? Were you over 50km and 100m/s?

The way I read the data sheet is that the "sanity check" for that airborne 4G mode is only altitude (from the above table). This implies that V&H velocity are likely still reported. It will not report 2D fixes in that mode, so I think that implies that the 3D fix will be less accurate. I have read a lot of data sheets in my time but I have to say this part of this data sheet is a bit woolly o_O.

If I get desperate and can find the time I might have to create my own fully unlocked GPS in an FPGA. What a fun project that would be! Need some more spare time though :(
 
Vern, I assume you are still getting position as well? What attitude? Were you over 50km and 100m/s?

It reports a full 3D position fix and 3D velocity vector at all altitudes less than 50km and less than 515m/s. Over 50km it becomes very undependable. Usually, immediately reporting “no fix” with all the position and velocity data missing.
 
Back
Top