O3400 Min Diameter L3

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Does anybody use the twist and tuck any more?
If they do, they definitely shouldn't. If you have to take it off the pad for whatever reason you've got live charges until you take the av bay apart.

Twin and tape, though, is great. Tape it to your switch band or just tape the wires together and let it go.

Braden
 
But I will explain below why dual identical altimeters are not a best practice for an amateur rocketry application.

A few months ago at FAR, I watched a 54mm minimum diameter M motor University project lawn dart. They used expensive and identical altimeters. Telemetry showed that neither altimeter commanded chute deployment at apogee. They will never know if it was due to a setup error or a software issue. I would suspect a setup error but can't eliminate a software issue. This anecdote is backed by sound reliability and safety practice however.

Identical altimeters protect against wiring problems (very likely) and hardware failures (very unlikely). They don't protect against user setup errors (very likely) or software issues (somewhat likely, particularly when pushing the flight envelope).
In fairness, I don't see the above as an altimeter issue, instead I see it as a lack of preparation/bench testing. As such I'm not sure I can support your statement that dual identical altimeters are not a best practice for any amateur rocketry application. Is it possible that a single altimeter can have an issue? Sure. Is it possible that two identical altimeters would fail identically in a single stage flight, MD M or otherwise? Much less likely. Combine that with your mention of telemetry I've got my suspicions, but most commercial flight computers with telemetry features are well proven in single stage applications, especially with later firmwares and batteries without voltage protection circuits.

I've seen people pitch up to the flight line running telemetry enabled FCs that they've never once turned on before arriving that day. I've seen them struggle to even instate a telemetry link with their FC, on the bench or in the rocket. I've seen people run up and down the flight line accusing anyone within earshot of having a powered up telemetry providing FC that their base station is connecting to instead of 'their' flight computer. Why? Because they both had never even powered up their FCs before and left them in their default configuration for telemetry and they were stomping on one another. How do you expect a base station to differentiate two identical telemetry feeds? In short, you don't.

Using two different brands of altimeters will not protect against user setup errors, in fact it makes the configuration problem twice as hard as you've got to understand two separate systems that operate completely differently from one another. As such the chances of errors goes up and the argument could then be made that using dual identical altimeters is the best practice for any amateur rocketry application if your best practice benchmark is deployment events occurring. But all of that is predicated on the flyer actually knowing their chosen altimeter's functions inside out.

TLDR; most altimeter issues are human related, not hardware related. Use what you're comfortable with and stick with it.
 
Just want to check my understanding. For Raven4 apogee detection it uses a combined baro and acceleration reading to detect apogee. This should work up to the max altitude of the pressure sensor which based on their manual is around 100k’. For main deployment the max altitude is 32700’ ish. This 32700’ limit does mot apply to the baro input to the apogee detection correct? Thanks.

-Tony
 
Just want to check my understanding. For Raven4 apogee detection it uses a combined baro and acceleration reading to detect apogee. This should work up to the max altitude of the pressure sensor which based on their manual is around 100k’. For main deployment the max altitude is 32700’ ish. This 32700’ limit does mot apply to the baro input to the apogee detection correct? Thanks.

-Tony
Correct. Unless you're exceeding 100k ft you best bet is to leave your Raven 4 configuration factory default. Baro will be more precise/accurate regarding apogee and main deployment events so it's best to rely on the default config that comes OOB.
 
I understand tone doesn't come through in text so I ask these questions not to be argumentative but to try to gain from other's perspectives....

I would certainly agree. I don't ask that to imply that what I am proposing isn't high performance but more so to ask the philosophical question. A large M in this design would be about a 30K' and Mach 2 flight. In the BlackHawk 75xl from Wildman a quick sim shows 35,000'+ and Mach 3 is achievable. I understand terms like "High performance" are inherently subjective and I want to understand what different people's experience have shown them. Given that most rocket flights are not in the Mach 3 regime and there are sadly still a lot of failed flights, my first L2 attempt among them :-( , it would seem that being more conservative isn't necessarily a path to success.

Once you can't see the rocket at Apogee (around 10,000'-15,000' AGL and above all else being equal I would say) you are relying on the tracker to locate it and implicitly determine if the drogue has deployed (descent rate). Assuming you have the waiver and range space this would be just as true at 50,000'. With regard to the Mach the same analysis would be required for a design going Mach 2.5-3.0 and if there was a flaw in fin flutter mitigation, fin attachment, or drag separation analysis, just to name a few areas, the design could fail. I was fat dumb and happy with my initial design G10 funs until FinSim put me in my place, now I have the science to back the improved design. I say this to ask this question. IF, and it is a big IF, I can show a valid understanding of the engineering and concepts and that leads to a technically sound and safe design does the fact that it will go Mach 3.7 ish and possibly 80,000' make it a bad idea? The answer to that question could very well be yes, and there are people on this forum with more time under drogue than I have alive and I ask them and anyone else to make me smarter and tell me if that is the case. Unless and until that happens I intent to follow the science and the engineering to design, and hopefully build, something that will overcome these challenges.

I've learned so much already, thank you to everyone who has taken the time to contribute to this thread so far.

-Tony
 
In fairness, I don't see the above as an altimeter issue, instead I see it as a lack of preparation/bench testing. As such I'm not sure I can support your statement that dual identical altimeters are not a best practice for any amateur rocketry application. Is it possible that a single altimeter can have an issue? Sure. Is it possible that two identical altimeters would fail identically in a single stage flight, MD M or otherwise? Much less likely. Combine that with your mention of telemetry I've got my suspicions, but most commercial flight computers with telemetry features are well proven in single stage applications, especially with later firmwares and batteries without voltage protection circuits.

I've seen people pitch up to the flight line running telemetry enabled FCs that they've never once turned on before arriving that day. I've seen them struggle to even instate a telemetry link with their FC, on the bench or in the rocket. I've seen people run up and down the flight line accusing anyone within earshot of having a powered up telemetry providing FC that their base station is connecting to instead of 'their' flight computer. Why? Because they both had never even powered up their FCs before and left them in their default configuration for telemetry and they were stomping on one another. How do you expect a base station to differentiate two identical telemetry feeds? In short, you don't.

Using two different brands of altimeters will not protect against user setup errors, in fact it makes the configuration problem twice as hard as you've got to understand two separate systems that operate completely differently from one another. As such the chances of errors goes up and the argument could then be made that using dual identical altimeters is the best practice for any amateur rocketry application if your best practice benchmark is deployment events occurring. But all of that is predicated on the flyer actually knowing their chosen altimeter's functions inside out.

TLDR; most altimeter issues are human related, not hardware related. Use what you're comfortable with and stick with it.

FWIW, dissimilar redundancy saved my bacon on my L3. My trusted primary altimeter (Altimax G2 SD, not so common outside of Germany) treated sensor readings above 1000m AGL as an error during power up self test. That might make sense in Germany, but Black Rock is well above that. Other altimeter models from the same manufacturer signaled the error during ground check out, but I thought I was lucky that mine didn't act up too (I can't guarantee that I didn't miss warning sings, but I certainly don't remember them like on the other models).
Long story short, the altimeter never fired the charge or record the flight, but the backup EasyMega did 2 seconds later.
A firmware update is available for the Altimax that fixes this.

Another example of a SW bug that I observed: G-Wiz changed the protocol between PC software and altimeter. The unit of the main altitude got changed by a factor of 10. The owner performed an update on one side, I believe the PC, but not the other one. The result was a main altitude configured 10 times higher than he intended. This resulted in a main at apogee, which was only an annoyance compared to the other way round.

Dissimilar redundancy increases the chance that one altimeter fires prematurely but it decreases the possibility that neither fires at the right time. Personally, I'd rather walk than dig.

I understand that those are somewhat rare and exotic errors, but they do exist.

Reinhard
 
Last edited:
FWIW, dissimilar redundancy saved my bacon on my L3. My trusted primary altimeter (Altimax G2 SD, not so common outside of Germany) treated sensor readings above 1000m AGL as an error during power up self test. That might make sense in Germany, but Black Rock is well above that. Other altimeter models from the same manufacturer signaled the error during ground check out, but I thought I was lucky that mine didn't act up too (I can't guarantee that I didn't miss warning sings, but I certainly don't remember them like on the other models).
Long story short, the altimeter never fired the charge or record the flight, but the backup EasyMega did 2 seconds later.

Another example of a SW bug that I observed: G-Wiz changed the protocol between PC software and altimeter. The unit of the main altitude got changed by a factor of 10. The owner performed an update on one side, I believe the PC, but not the other one. The result was a main altitude configured 10 times higher than he intended. This resulted in a main at apogee, which was only an annoyance compared to the other way round.

Dissimilar redundancy increases the chance that one altimeter fires prematurely but it decreases the possibility that neither fires at the right time. Personally, I'd rather walk than dig.

Reinhard

Very good point that it is easy to miss firmware and software changes. For my setup it isn't just the altimeter and the PC but also my phone and GPS tracker that all need to be updated, sometimes at different times. All that said I would respectively disagree that your example is an argue for dissimilar altimeters. Would that not be a setup error in that the system wasn't configured for flight/tested correctly. If it was known that readings about 1000m (I assume you meant MSL) would be treated as an error then it would not be a good fit for a Blackrock launch.

There is always the chance that some software error could cause either no deployment or a deployment at a significantly different time than planned. Like you said walking is much better than digging but if you have dissimilar altimeters, and therefore twice the software/firmware to update and 2 wiring setups to implement, and miss an update and the apogee charge fires at a high speed then you could be walking to dig the thing up.

My thinking is that if both altimeters have the features and performance specs that I need then even if one of them totally fails the flight will still have a good chance to be successful. I can be more familiar with all parts of their wiring, programming and updating and so reduce the chance of an error from that side of things. The one exception I can think of right now is using something like a TeleMega v4.0 to get an integrated downlink/tracker and then having a dissimilar second altimeter to save cost and not duplicate capabilities that you may not be able to use simultaneously. That said, getting the second altimeter from the same manufacturer would probably help minimize the setup and update differences.

Just my thoughts and BS flags are welcome.

-Tony
 
Featherweight Ravens straight out of the box have been proven reliable for this particular flight profile.

I'm not saying others won't work, but I think firmware are setup issues would be a non-issue with dual Ravens.
 
If they do, they definitely shouldn't. If you have to take it off the pad for whatever reason you've got live charges until you take the av bay apart.

Twin and tape, though, is great. Tape it to your switch band or just tape the wires together and let it go.

Braden


Twist and Tape is the ONLY way I fly!!
 
I'm not stupid enough to attempt a Mach 2.5 flight but others have, with total success. What don't you understand and why are you questioning this method. This is all we had to use when the first altimeters hit the market. Nobody thought about using a switch, which in my opinion is more prone to failure than a simple twist.
 
You make some excellent points. Funny enough I am virtual TDY to Air Force safety training right now and we are talking about these same processes in class.

While I certainly agree with you that having two different altimeter types can be beneficial, I have a Raven4 and RRC3 in my 54mm MD redundant dual deploy, my thinking on using dual Raven4s for this project was based on the predicted apogee altitude. Looking at previous similar builds I saw many people using Ravens for two reasons. The first was the small size which I would argue is the least important with my internal volume, and my decision to use the expansion terminals. The second is the accelerometer feature of the Raven. This is important to me first for "Mach Proofing" the altimeter during the ascent but also for ensuring a reliable apogee detection. I know that other manufactures offer these features so they are not exclusive to the Raven. Subjectively I also have confidence in the Raven having flown it to Mach 2 and yesterday to about Mach 1.2. By the time of the L3 I hope to have at least a few more supersonic flights on it. Yes, these are anecdotes.

My thinking is that the likelihood of a simultaneous component/software failure of 2 Ravens is extremely low and certainly lower than the likelihood of a setup error on my part. With the Raven expansion terminals that I plan to use the wiring is as simple as I've seen on flight computers. I don't mean to dismiss your 54mm core sample story by any means and I would really like to know what others that have flown to these altitudes think about altimeter choice. The TeleMEGA v4.0 system looks awesome, especially with the integrated tracker although IDK if that is putting too many eggs in one basket. If I didn't already have the Featherweight tracker I would be very inclined to go with that product and buy their ground station.

It's good to hear another positive review of the Fingertech switches!

-Tony

I agree, certainly the chance of simultaneous component failure of 2 Ravens is nearly impossible.

However software failures in identical hardware are by nature common cause, so I wouldn't eliminate this. In aircraft systems we compensate for this by a rigorous software requirements definition, testing and documentation process, and the level of rigor or Design Assurance Level (DAL) required is based on the severity of the consequences of failure. Consumer electronics like altimeters have little to none of this rigor in software development.

Ravens do have a proven track record in high altitude applications so I believe the software risk is minimal, although not insignificant.

I think we agree that setup errors are the the biggest risk by far. These are reduced by your experience with this altimeter and simplicity of the Raven setup. I hope you have already developed your checklist and use it for ground testing. This minimized the probability of missing a step during flight testing.

Accelerometers excel (ha) at velocity measurement, and I think many of us have seen pressure based velocity go to crap during mach transition. There are several out there with this accelerometers and my next project will include the Eggtimer Proton.
 
I'm not stupid enough to attempt a Mach 2.5 flight but others have, with total success. What don't you understand and why are you questioning this method. This is all we had to use when the first altimeters hit the market. Nobody thought about using a switch, which in my opinion is more prone to failure than a simple twist.

I was stupid enough to successfully go Mach 3.6, then.

If you're "not stupid enough" to go Mach 2.5, why do you think your opinions would be tolerated here?

tfish was able to give excellent, real world examples of why twist and tape won't work for this flight profile-
some where around mach 2.2 and above.. twist and tape stops being a good choice
1st mishap...tape came off and wires 'untwisted'.
2nd mishap..one set of wires severed at the hole.

I fly mostly dual electronics..

I now use screw switches.

Tony

I am enjoying the hearing from those with relevant experience! It's been a great thread so far.
 
I agree, certainly the chance of simultaneous component failure of 2 Ravens is nearly impossible.

However software failures in identical hardware are by nature common cause, so I wouldn't eliminate this. In aircraft systems we compensate for this by a rigorous software requirements definition, testing and documentation process, and the level of rigor or Design Assurance Level (DAL) required is based on the severity of the consequences of failure. Consumer electronics like altimeters have little to none of this rigor in software development.
The Ariane V disaster comes to mind. Redundancy of a proven system, but the same software failure destroyed the effectiveness of the redundancy.
 
In fairness, I don't see the above as an altimeter issue, instead I see it as a lack of preparation/bench testing. As such I'm not sure I can support your statement that dual identical altimeters are not a best practice for any amateur rocketry application. Is it possible that a single altimeter can have an issue? Sure. Is it possible that two identical altimeters would fail identically in a single stage flight, MD M or otherwise? Much less likely. Combine that with your mention of telemetry I've got my suspicions, but most commercial flight computers with telemetry features are well proven in single stage applications, especially with later firmwares and batteries without voltage protection circuits.

I've seen people pitch up to the flight line running telemetry enabled FCs that they've never once turned on before arriving that day. I've seen them struggle to even instate a telemetry link with their FC, on the bench or in the rocket. I've seen people run up and down the flight line accusing anyone within earshot of having a powered up telemetry providing FC that their base station is connecting to instead of 'their' flight computer. Why? Because they both had never even powered up their FCs before and left them in their default configuration for telemetry and they were stomping on one another. How do you expect a base station to differentiate two identical telemetry feeds? In short, you don't.

Using two different brands of altimeters will not protect against user setup errors, in fact it makes the configuration problem twice as hard as you've got to understand two separate systems that operate completely differently from one another. As such the chances of errors goes up and the argument could then be made that using dual identical altimeters is the best practice for any amateur rocketry application if your best practice benchmark is deployment events occurring. But all of that is predicated on the flyer actually knowing their chosen altimeter's functions inside out.

TLDR; most altimeter issues are human related, not hardware related. Use what you're comfortable with and stick with it.

I think my point is being missed.
Yes, setup error was probably but not definitely the cause of the lawn dart. Yes, the chance of twin hardware failures on identical hardware is insignificant for our purposes. Yes, dissimilar makes setup twice as hard. But it makes the probability of a failure to deploy go down by a factor of something like 1000.

A single error in the setup checklist will happen on both altimeters at the same time and you will have a lawn dart.
A single software failure will happen on both altimeters at the same time and you will have a lawn dart.
Dissimilar altimeters eliminate these two causes.

Back to the case of the 54mm lawn dart I witnessed (but was not directly involved in). The identical telemetry was operating on two different frequencies. Both altimeters were correctly reporting their altitude via telemetry during coast and rapid descent. This eliminates the gross setup errors you describe above.
Both altimeters correctly reported that they did not fire the drogue. We may never know why they both chose not to fire. It could have been a wrong setting, made twice, or it could have been a software issue.

I will say that these engineering students did perform ground testing before the flight, and did use detailed checklists. And their carbon composite rocket design and construction was sound. It looked great and held together at over Mach 2.5 and 40,000 feet, reporting back on both channels until colliding with the playa.
 
Due to the extreme performance of this rocket, if your tracker fails, you will almost certainly lose this rocket (and thus fail your L3).
So I'd recommend an integrated tracker and altimeter for backup. I used the Eggtimer TRS with an external rubber antenna.
TeleMega v4.0 looks like a good choice as well.
 
I understand tone doesn't come through in text so I ask these questions not to be argumentative but to try to gain from other's perspectives....

I would certainly agree. I don't ask that to imply that what I am proposing isn't high performance but more so to ask the philosophical question. A large M in this design would be about a 30K' and Mach 2 flight. In the BlackHawk 75xl from Wildman a quick sim shows 35,000'+ and Mach 3 is achievable. I understand terms like "High performance" are inherently subjective and I want to understand what different people's experience have shown them. Given that most rocket flights are not in the Mach 3 regime and there are sadly still a lot of failed flights, my first L2 attempt among them :-( , it would seem that being more conservative isn't necessarily a path to success.

Once you can't see the rocket at Apogee (around 10,000'-15,000' AGL and above all else being equal I would say) you are relying on the tracker to locate it and implicitly determine if the drogue has deployed (descent rate). Assuming you have the waiver and range space this would be just as true at 50,000'. With regard to the Mach the same analysis would be required for a design going Mach 2.5-3.0 and if there was a flaw in fin flutter mitigation, fin attachment, or drag separation analysis, just to name a few areas, the design could fail. I was fat dumb and happy with my initial design G10 funs until FinSim put me in my place, now I have the science to back the improved design. I say this to ask this question. IF, and it is a big IF, I can show a valid understanding of the engineering and concepts and that leads to a technically sound and safe design does the fact that it will go Mach 3.7 ish and possibly 80,000' make it a bad idea? The answer to that question could very well be yes, and there are people on this forum with more time under drogue than I have alive and I ask them and anyone else to make me smarter and tell me if that is the case. Unless and until that happens I intent to follow the science and the engineering to design, and hopefully build, something that will overcome these challenges.

I've learned so much already, thank you to everyone who has taken the time to contribute to this thread so far.

-Tony

YES, ABSOLUTELY
 
Would that not be a setup error in that the system wasn't configured for flight/tested correctly. If it was known that readings about 1000m (I assume you meant MSL) would be treated as an error then it would not be a good fit for a Blackrock launch.
Just to clarify: To my knowledge, neither of the errors mentioned by me were documented. At least I didn't find anything in the user manual after a double checked. They were only understood when the manufacturers were contacted afterwards.

Reinhard
 
Just to clarify: To my knowledge, neither of the errors mentioned by me were documented. At least I didn't find anything in the user manual after a double checked. They were only understood when the manufacturers were contacted afterwards.

Reinhard
That is extremely frustrating that they did not publish something so critical...

-Tony
 
Due to the extreme performance of this rocket, if your tracker fails, you will almost certainly lose this rocket (and thus fail your L3).
So I'd recommend an integrated tracker and altimeter for backup. I used the Eggtimer TRS with an external rubber antenna.
TeleMega v4.0 looks like a good choice as well.
The TeleMega v4.0 looks like a great setup and would be really nice to have for future smaller diameter builds where I don't want to have the weight or volume for a separate tracker.
 
If you're tight on space, and aren't doing airstarts, then the Telemetrum might be a better option. It still has the GPS tracking, accelerometer, and barometric sensors of the Telemega. It only really gives up the gyro and the large number of pyro outputs on the Telemega.
 
Looking at Featherweight's website one ground station can track 2 trackers on different channels. I know this will start the one software bug kills everything discussion again but the system is proven and it is a simpler integration than a whole different ground station, wiring and power supply...

-Tony
 
Back
Top