Bare Necessities: N5800 C-Star Flying Case

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
I think in this case it's more of "Calculated Risk" -- they recognize the ideal, but it fails in other parameters, and coupled with their analysis of the existing nosecone, they've determined the risk isn't sufficient to postpone the flight.

-Kevin

Fair enough.

I'm really looking forward to seeing the results of all these N5800 flights. As an east coast flier, I am insanely jealous of the altitudes you guys can achieve.
 
I'm really looking forward to seeing the results of all these N5800 flights. As an east coast flier, I am insanely jealous of the altitudes you guys can achieve.

I'm a midwesterner -- the best I've got nearby is 50K, down in Argonia (which is over 3 times the highest I've gone, successfully).

-Kevin
 
Im really looking forward to these: I was going to attempt but I have no way to get to a launch suitable. I live about half an hour away from the jersey shore so the best waiver I have within 6 hours of me is well... I don't have one right now but I will be at black rock next year. IF this challenge has not been met then I will attempt it and the CTI M challenge @ Black Rock next year.
 
We are not sure. Your mention of it in your thread was the first time I ever saw that there was a firmware revision to fix it. We had initially planned to use timers for apogee, but we might use barometric if it will not experience the bug.

Can the firmware be downloaded somewhere?

The firmware version needed to avoid premature baro-based deployments above 65,000 feet is version 2.4 or higher, and it's been out since around October of last year. Unfortunately, it's not user-upgradeable. If you have a version < 2.4, let's discuss via PM. With the new firmware, baro-based apogee detection has been tested in bell jar tests to 120,000+ feet equivalent pressure. When ramping up to about 120,000 feet equivalent, apogee detection is triggered on noise at about 118,000 feet equivalent pressure.

Experience has shown that due to non-linearity in the accelerometer sensor performance, accel-based apogee detection isn't accurate enough for flights that take longer than about 30 seconds to get to apogee.
 
Also, these:
N5800V14Alt.jpg
N5800V14Mach.jpg
N5800V14CP.jpg
CG on the pad is 59.1", CG at burnout is 51". Plenty Stable.
N5800V14Accel.jpg
And, in an amusing anecdote, I found it hilarious that for the first 2 seconds, Mach# is roughly equal to time. :)
N5800V14MachBurn.png

I can email people who are interested the .alx1 file; I can't figure out how to include it in the post, and I'm going to go work on the nosecone and do homework.
 
Last edited:
Hmmmm ...

I wonder if PBS/NOVA would like to cover this event: "The Race to Tame the N5800". Discovery Channel maybe?

Anyone have connections?

Greg
 
That doesn't look like more than Mach 3.7, I kept seeing 4.2 in other threads?
 
I can email people who are interested the .alx1 file; I can't figure out how to include it in the post, and I'm going to go work on the nosecone and do homework.

You're probably using the compact (single line toolbar) editor; click the "Go Advanced" button underneath it, and you'll get an editor with a multi-line toolbar. Top line, right side is a paperclip, which will allow you to attach your RASAero file.

-Kevin
 
You're probably using a liftoff mass that's too high then - here are my sim results for a 7.5 pound no-motor weight (which seems doable at the moment). I'll post the RASAero file over in my thread:

Altitude.PNG
Mach.PNG
Mach_detail.PNG
 
That doesn't look like more than Mach 3.7, I kept seeing 4.2 in other threads?

The 4.2 was from the worst-case aerodynamics model I ran back in June. We estimated the minimum mass we could possibly imagine for the rocket was 7.5lb + motor case and propellant. We're probably within 100 grams of the final weight now with the latest estimate, so Mach 3.7 it is. (We also changed the dimensions a little bit, adding some length).
 
You're probably using a liftoff mass that's too high then - here are my sim results for a 7.5 pound no-motor weight (which seems doable at the moment).

We figured that was the minimum weight we'd end up with. Our nosecone is heavier than I imagined, and I was way conservative on the aluminum anchor I made to attach it to the nosecone. I could probably shave a pound off of the anchor with careful modeling of stress concentrations and thinning out everything that's not load-bearing. The Nosecone is tough because we can't model it all that well...I don't have the experience or training in FEM on decidedly non-continuum materials. If we had time, we could probably do a few tests-both of the thermal protection system and of the underlying structure-and figure out what kind of structure we really need, since it's fairly straightforward to estimate the aerodynamic loading. But, lacking time and knowledge, we have to over-build. We could also probably make the front end smaller and lighter by single-deploy with a small chute, or drogueless, but AeroPac said we can't fly with any apogee device larger than 24", and 24" gave us a final descent rate that was uncomfortably high (though not as insane as USC's Traveler.). Classic problem, reduce the deployment system mass and the smaller deployment system might suddenly be adequate, but I didn't have time to explore that.
 
I always thought that was because it was over 100,000 feet.

It depends on the unit. Some GPSes work all the way to orbit although I couldn't say which ones. The balloon crowd regularly receives coordinates to 100k.

Now Im only guessing... but I suspect most of the problems are due to the position algorithms not tweaked for rockets. A GPS is NOT stateless. I also would not be surprised if there are issues with distortions of the crystal oscillators under high G loads.

If someone had infinite time, it might be interesting to down link raw satellite data and process the data on the ground.

->MCS


.
 
It depends on the unit. Some GPSes work all the way to orbit although I couldn't say which ones. The balloon crowd regularly receives coordinates to 100k.

Now Im only guessing... but I suspect most of the problems are due to the position algorithms not tweaked for rockets. A GPS is NOT stateless. I also would not be surprised if there are issues with distortions of the crystal oscillators under high G loads.

If someone had infinite time, it might be interesting to down link raw satellite data and process the data on the ground.

->MCS
.


as long as your inside all the satellites, i would think the "system" could be made to work. Filtering on the chips, is probably where the issue is, most GPS units wouldnt be expected to go over 50k.

I would think that it would be better served to send the signal from the rocket, to ground stations, and "reverse" gps the rockets transmittion. you would probably get MUCH MUCH better telemetry that way.

the frequency doesnt care about G forces....


But the fact there is GPS guided munitions, means that you can overcome this threashold of Forces, and velocity... and they arent illegal to obtain, just take a process to obtain.(from what i have heard)
 
I think the receivers make assumptions about their own movement, and shut down when those assumptions are violated, preventing you from suddenly appearing miles away when signals get interrupted or the like. But if you made a fully integrated IMU, with GPS and accels and gyros and maybe a magnetometer, you could use the faster-responding sensors to provide an assumption about the rocket's position to the GPS correlators, which would thus have easier computations to perform. Of course, if you did make it, you wouldn't be allowed to sell it to anyone but the military. And someone probably makes those for the military anyway.
 
I think the receivers make assumptions about their own movement, and shut down when those assumptions are violated, preventing you from suddenly appearing miles away when signals get interrupted or the like. But if you made a fully integrated IMU, with GPS and accels and gyros and maybe a magnetometer, you could use the faster-responding sensors to provide an assumption about the rocket's position to the GPS correlators, which would thus have easier computations to perform. Of course, if you did make it, you wouldn't be allowed to sell it to anyone but the military. And someone probably makes those for the military anyway.

you mean the 9dof IMU you can buy from sparkfun?
For the assumption it may be that the are also using their main resorces toward a specific purpouse.
From my understanding, (or interpreting what others have written) is that the filters that thake the UTC stamp take time to crunch numbers to lock a position, the math therefor is reserved for its most expected use.. Usualy x,y coordinates.... Z coordinates are not generaly used, as people generaly move about on the surface of the earth....

https://www.sparkfun.com/products/10736
 
you mean the 9dof IMU you can buy from sparkfun?
https://www.sparkfun.com/products/10736

I think he means something like that integrated on a sufficiently-capable microcontroller with a fast-response GPS receiver. The 9DOF IMU gives you a continual position update subject to drift and inherent inaccuracy (after a fairly non-trivial amount of processing and coordinate transforms). The GPS is then used to continuously re-calibrate the IMU, so that when GPS goes out for a few minutes, the IMU can still tell the vehicle where it is. This is (to my knowledge) how the ADS-B transponder in a private or commercial plane (well, a brand new one at least) works.

Also, the hardware sophistication required to get gyro/acceleration/magnetic field data accurate enough for measuring position in a non-trivial environment (aka a rolling/yawing/accelerating rocket covering large ranges of roll rate and acceleration) is very difficult. I've priced IMUs for a research project I might be doing this year, and acceptable quality ones even without GPS integration end up being many hundreds of dollars, usually $2-5k for the whole unit. Human-flight rated units cost many times that.
 
Sorry to interrupt this beautiful discussion, but does anyone know what GPS chip is used in the Garmin Astro?

We maintained lock through the entirety of a 3" minimum diameter flight to over 35,000ft Mach 2.2ish flight. Boost-coast-recovery.

We will have one on our flight with the mandatory beeline. Still figuring it out. The Beeline hasn't given me good data yet from tests. I must be doing something wrong.

We are launching Saturday. Sometime Saturday. Whenever we are ready. I think it is foolish to attempt to coordinate our launches. Of we happen to be out at the same time. Then sure hit two buttons together. But we aren't waiting for you and don't expect you to wait for us.
 
The biggest problem with IMU's which are out there for the hobby market is the accelerometer. 8G's is not enough for most rockets, so now you need two accelerometers - one for the fine details (fine res, low G) and one for the big G's (coarse res, high G). You also need a GPS which can handle the G forces - not physically but in software. With the speeds involved in a project like this, and the boost phase a hobby system running on an Atmega (eg: Arduino based software) simply wont cut it with the 50-200hz you can get out of it with highly optimised software - 8 bit systems also severely impede speed due to boxing and unboxing for larger values. This means you now need a mid to high speed ARM or ARM Cortex - a decent R4 or M3 will get you 120-180mhz which will get you 500-1500hz depending on the sensors you're using.

Obviously, hobbyists are more than capable of using these parts, however the "arduino generation" are going to struggle to create an optimised solution. This is where costs come in as you need developers who are extremely competent with optimisations at a low level, as well as having a firm understanding of the complex maths and weightings involved. Software for working on ARM which will give you the debugging and development capabilities starts at $1500 or so, and an optimised compiler (Keil) can easily set you back $10k. You also need an electronic designer who can optimally route and simulate the board so you're not getting noise introduced and who can manage the thermal profile of the board so drift is not artificially introduced. Software like this (Altium) starts at $5-6k. Whilst you could do this with a package like Eagle, and an open source tool chain for software you're not going to have an optimal solution - or if you do it takes months and months longer.

As far as GPS goes, i've worked extensively with SkyTraq who make the venus chips. They are very responsive and usually pretty happy to implement custom software. They already have a firmware version with less filtering which can handle rapid accelerations and less-linear trajectories. They also implement ITAR as an AND rather than an OR - meaning over 60,000ft AND over mach whatever - i dont remember the exact speed off the top of my head on a friday morning! They also do 20hz GPS data and 1.2m HDOP, not just 1 like, say, SIRF lol.

Sensor fusion like this is not easy, but its hardly the hardest thing i've ever worked on. The biggest issue here is time, and when time is money a good IMU will cost you thousands as others have said.
 
We are launching Saturday. Sometime Saturday. Whenever we are ready. I think it is foolish to attempt to coordinate our launches. Of we happen to be out at the same time. Then sure hit two buttons together. But we aren't waiting for you and don't expect you to wait for us.

That seems perfectly reasonable. I look forward to seeing it and honestly hope it goes well. Your fins are beast!
 
The biggest problem with IMU's which are out there for the hobby market is the accelerometer. 8G's is not enough for most rockets, so now you need two accelerometers - one for the fine details (fine res, low G) and one for the big G's (coarse res, high G). You also need a GPS which can handle the G forces - not physically but in software. With the speeds involved in a project like this, and the boost phase a hobby system running on an Atmega (eg: Arduino based software) simply wont cut it with the 50-200hz you can get out of it with highly optimised software - 8 bit systems also severely impede speed due to boxing and unboxing for larger values. This means you now need a mid to high speed ARM or ARM Cortex - a decent R4 or M3 will get you 120-180mhz which will get you 500-1500hz depending on the sensors you're using.

Obviously, hobbyists are more than capable of using these parts, however the "arduino generation" are going to struggle to create an optimised solution. This is where costs come in as you need developers who are extremely competent with optimisations at a low level, as well as having a firm understanding of the complex maths and weightings involved. Software for working on ARM which will give you the debugging and development capabilities starts at $1500 or so, and an optimised compiler (Keil) can easily set you back $10k. You also need an electronic designer who can optimally route and simulate the board so you're not getting noise introduced and who can manage the thermal profile of the board so drift is not artificially introduced. Software like this (Altium) starts at $5-6k. Whilst you could do this with a package like Eagle, and an open source tool chain for software you're not going to have an optimal solution - or if you do it takes months and months longer.

As far as GPS goes, i've worked extensively with SkyTraq who make the venus chips. They are very responsive and usually pretty happy to implement custom software. They already have a firmware version with less filtering which can handle rapid accelerations and less-linear trajectories. They also implement ITAR as an AND rather than an OR - meaning over 60,000ft AND over mach whatever - i dont remember the exact speed off the top of my head on a friday morning! They also do 20hz GPS data and 1.2m HDOP, not just 1 like, say, SIRF lol.

Sensor fusion like this is not easy, but its hardly the hardest thing i've ever worked on. The biggest issue here is time, and when time is money a good IMU will cost you thousands as others have said.

I am really happy with my venus equiped device that I fly... I don't have much comparitive experience with it. Although, the new firmware??? this sounds like an improvement that is upcomming? Nice.... from the treads that constantly pop up... :"What chip is best", the hobby here is looking for something that gets good "up" results. Some people seem to get good altitude tracking, while others don't..

My comment on the sparkfun IMU was facetical... even at far less than 8g's coupled with a gps, your good to be within 10' of your plotted path and waypoints (whith gps correction) things like "Kiting" are hard to automate.

Cheers!
Clay
 
Last edited:
Im really looking forward to these: I was going to attempt but I have no way to get to a launch suitable. I live about half an hour away from the jersey shore so the best waiver I have within 6 hours of me is well... I don't have one right now but I will be at black rock next year. IF this challenge has not been met then I will attempt it and the CTI M challenge @ Black Rock next year.

There is a CTI M challenge ???
 
There is a CTI M challenge ???

I don't think its an official challenge, but some people are looking at giving their 75 MD rockets one hell of a ride (and possibly an M record?) on an M2245. While not quite as intense as the N5800, its still nearly 10K N-s so I'd imagine its still going to be a challenging and exciting flight.
 
The biggest problem with IMU's which are out there for the hobby market is the accelerometer. 8G's is not enough for most rockets, so now you need two accelerometers - one for the fine details (fine res, low G) and one for the big G's (coarse res, high G). You also need a GPS which can handle the G forces - not physically but in software. With the speeds involved in a project like this, and the boost phase a hobby system running on an Atmega (eg: Arduino based software) simply wont cut it with the 50-200hz you can get out of it with highly optimised software - 8 bit systems also severely impede speed due to boxing and unboxing for larger values. This means you now need a mid to high speed ARM or ARM Cortex - a decent R4 or M3 will get you 120-180mhz which will get you 500-1500hz depending on the sensors you're using.

I think this may be a good opening for the Raspberry Pi, Adruino does not have the processing power, but the Raspberry Pi has 700 Mhz, and they currently have a "Gertboard" extension board under development which promises even more real-world interfaces and functionality. Since it is written in GNU Linux/ARM it can probably fulfill the processing requirements, plus it is only the size of a credit card, and I know I can fit my credit card into the CTI 54mm/3-grain so fitting it into a 98mm tube should be no problem. The best thing is that it is only $25, so destructive testing is not out of the question. The only thing that worries me is getting the unit to take the large amount of g's that it will be experiencing, and writing the software for it.
 
This challenge is supposed to end by the end of the year, though if nobody ends up succeeding (unlikely) then who knows, it may be renewed for 2013.
 
The biggest problem with IMU's which are out there for the hobby market is the accelerometer. 8G's is not enough for most rockets, so now you need two accelerometers - one for the fine details (fine res, low G) and one for the big G's (coarse res, high G). You also need a GPS which can handle the G forces - not physically but in software. With the speeds involved in a project like this, and the boost phase a hobby system running on an Atmega (eg: Arduino based software) simply wont cut it with the 50-200hz you can get out of it with highly optimised software - 8 bit systems also severely impede speed due to boxing and unboxing for larger values. This means you now need a mid to high speed ARM or ARM Cortex - a decent R4 or M3 will get you 120-180mhz which will get you 500-1500hz depending on the sensors you're using.

Obviously, hobbyists are more than capable of using these parts, however the "arduino generation" are going to struggle to create an optimised solution. This is where costs come in as you need developers who are extremely competent with optimisations at a low level, as well as having a firm understanding of the complex maths and weightings involved. Software for working on ARM which will give you the debugging and development capabilities starts at $1500 or so, and an optimised compiler (Keil) can easily set you back $10k. You also need an electronic designer who can optimally route and simulate the board so you're not getting noise introduced and who can manage the thermal profile of the board so drift is not artificially introduced. Software like this (Altium) starts at $5-6k. Whilst you could do this with a package like Eagle, and an open source tool chain for software you're not going to have an optimal solution - or if you do it takes months and months longer.

As far as GPS goes, i've worked extensively with SkyTraq who make the venus chips. They are very responsive and usually pretty happy to implement custom software. They already have a firmware version with less filtering which can handle rapid accelerations and less-linear trajectories. They also implement ITAR as an AND rather than an OR - meaning over 60,000ft AND over mach whatever - i dont remember the exact speed off the top of my head on a friday morning! They also do 20hz GPS data and 1.2m HDOP, not just 1 like, say, SIRF lol.

Sensor fusion like this is not easy, but its hardly the hardest thing i've ever worked on. The biggest issue here is time, and when time is money a good IMU will cost you thousands as others have said.

Issus is spot-on.

Again.. the problem with GPS is not COCOM but practical limits of a consumer device.

Novatel makes some interesting GPS devices in the $1k to $2k price range which might be a solution. For a few $$ more the COCOM limits can be removed.


-->MCS


.
 
Back
Top