MarsaNet Gadget Idea Feedback - Apogee break detector

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Hall effect sensor and a magnet sewn to the chute.
Magnet has to be large enough that the hall-effect can "see" it randomly packed in the bay.

Once deployed it's many yards away from the sensor.

You need to sense the presence of the chute....not just an open bay end....you need to confirm the chute is OUT.
 
Hall effect sensor and a magnet sewn to the chute.
Magnet has to be large enough that the hall-effect can "see" it randomly packed in the bay.

Once deployed it's many yards away from the sensor.

You need to sense the presence of the chute....not just an open bay end....you need to confirm the chute is OUT.

If the chute/packing is opaque and is between the phototransistor and the open end, then it will be dark until chute is out....?
 
Hall effect sensor and a magnet sewn to the chute.
Magnet has to be large enough that the hall-effect can "see" it randomly packed in the bay.

Once deployed it's many yards away from the sensor.

You need to sense the presence of the chute....not just an open bay end....you need to confirm the chute is OUT.

I dunno. I'd rather have my rocket come down in an unplanned drogueless configuration than blow the main at 5K.

Nate
 
Leo, my brain is not firing on all cylinders today. Can you please further explain this idea,? I am not getting it.....

I'm quiet sure your brain is running an all cylinders. It's my oversimplified wording that's the culprit.

What I am trying to say is why not measure the pressure to determine if an ejection charge had occurred. Add a small hole at the bottom of the e-bay so pressure can be measured inside the e-bay. If no ejection charge occurred then you won't see a pressure spike. In that case simply deploy the main. The routine should only take a couple of ms to analyse and execute.
 
I'm quiet sure your brain is running an all cylinders. It's my oversimplified wording that's the culprit.

What I am trying to say is why not measure the pressure to determine if an ejection charge had occurred. Add a small hole at the bottom of the e-bay so pressure can be measured inside the e-bay. If no ejection charge occurred then you won't see a pressure spike. In that case simply deploy the main. The routine should only take a couple of ms to analyse and execute.

Got it. Thanks!
 
If the phototransistor gets coated with BP residue then it will not be able to see the light from the open end.

Good one. How about the chute pulls a protective lens cover off on the way out?
 
Good one. How about the chute pulls a protective lens cover off on the way out?

Pulling a lens cover off the photo transistor would probably work but doing that would essentially be equivalent to pulling a magnet away from a hall sensor or using a pull-pin switch of some sort. Given they are all equivalent, the magnet and hall sensor scheme seems like the most robust to me. Although some care with the design would be needed in order to make sure the magnet does not shift too far away during a high G launch.
 
Pulling a lens cover off the photo transistor would probably work but doing that would essentially be equivalent to pulling a magnet away from a hall sensor or using a pull-pin switch of some sort. Given they are all equivalent, the magnet and hall sensor scheme seems like the most robust to me. Although some care with the design would be needed in order to make sure the magnet does not shift too far away during a high G launch.

Noted. I am not sure yet that an optical system could not be made robust against ejection residue.....I don't think the residue would be opaque.

The original request (that started all this) was for a airframe separation detection method. This would work with the optical sensor at the other end of the tube which probably would not have the bp residue hazard.

FredA was asking for a more robust detection of the apogee event emptying the compartment.
 
An optical system will require some care with regards to semitransparent airframes (e.g. unpainted fiberglass). My first thought would be to simply perform a differential measurement, if it becomes brighter than at lift-off, separations is detected. However, this might run into trouble when the rocket changes it's attitude, depending on the location and orientation of the sensor and maybe present partial obstructions (laundry).

Another idea, but not a panacea either: Measuring the load of the shock cord with something inspired by hook scales (or crane scales or luggage scales, whatever the official name of these things is). A typical scale is probably not suitable, unless the sensing element is protected against the expected severe overloads. A simple switch, that is sensitive enough for light rockets, but still robust enough for heavy rockets should be doable, but I don't see how such a thing could be made to match your expected price point in smallish quantities.

Reinhard
 
Yes that is an option for a different feature but that wasn't what the feature that was asked for....

The feature requested was specifically to pop the main if the apogee break did not happen to protect against a ballistic recovery, not a very fast floppy recovery:)

PS. It may be preferred to pop the main on schedule at even 100ft/s than popping the main at 10K feet. If you set your "trigger" velocity too high then its too late to deploy the main or already have impacted the ground.

An acceleration after apogee trigger would in my opinion be a better method to detect a ballistic case because you can predict what your velocity is going to be and then pop the chute before then. However that code is trickier and may be fraught with false positives until the algorithm is tuned.

Which is the reason for the requested direct detection of a case rather than an inferred detection.

If you have an available input channel for any kind of breakwire/sensor then it shouldn't be very difficult to do. If the drogue charge pops and the AV bay doesn't separate, or it doesn't come off enough (i.e. stuck chute...) then you can pop the main after a short delay (just to make sure... we've all seen chutes that "eventually" come out). I still think a velocity check would be in order, though, because if you wait too long after a drogue non-event you risk a high-speed main deployment and you're not much better off than if in was coming in ballistic.

The advantage of doing it all in software vs. doing it with a physical sensor is that there's one less thing to hook up, and potentially one less thing to go wrong. Of course, software can break too... :)
 
An optical system will require some care with regards to semitransparent airframes (e.g. unpainted fiberglass). My first thought would be to simply perform a differential measurement, if it becomes brighter than at lift-off, separations is detected. However, this might run into trouble when the rocket changes it's attitude, depending on the location and orientation of the sensor and maybe present partial obstructions (laundry).


Reinhard

Reinhard, Yes I thought of this. Since the original thought is that would not be a "mass market" gadget, requiring opaque painted airframes would not be an unreasonable request (users got to work with me here....).

For the FredA chute out detection request I am still strongly leaning to the optical MarsaNet gadget clipped to the chute. Dark when packed in the airframe, light when out, protected from BP residue because its packed in the chute. As long as the chute is within 60 feet of the av-bay then there will be communication back to the flight computer.
 
For the FredA chute out detection request I am still strongly leaning to the optical MarsaNet gadget clipped to the chute. Dark when packed in the airframe, light when out, protected from BP residue because its packed in the chute. As long as the chute is within 60 feet of the av-bay then there will be communication back to the flight computer

I like it!
 
For the FredA chute out detection request I am still strongly leaning to the optical MarsaNet gadget clipped to the chute. Dark when packed in the airframe, light when out, protected from BP residue because its packed in the chute. As long as the chute is within 60 feet of the av-bay then there will be communication back to the flight computer

I like it!

Not only that, but you will be able to get a status signal sent down by telemetry on the deployment status (because you fly where you can't see whats going on at apogee....).
 
I think that you should sample the descent rate, not presence of darkness ... things that don't separate are rapidly accelerating
I'd also make it "fire an auxiliary circuit" not just the main.
I think east coasters would try to get separation, probably with an over-sized charge as blowing the main is akin to loosing the rocket (and also violating the code requiring the flight plan land within the recovery area, but this is debatable).

This is interesting problem. When I think of why it might happen, i think about too small charge or failure of ematch (or not enough power to drive it). I wonder how many of those things could be rectified by another charge - and the only one I list is a ematch failure. Would i be likely to get one? Probably not as it's also an additional complexity. If I'm that worried, I use 2 channels with different altimeters. Those who know me sometimes laugh at my battery farms as I tend to use 2 rechargables for each channel. (eliminates the power issue).

Some may mention too tight of a coupler as a reason to have it, but that's just a build issue that you can check for in advance. Of course charge sizing can be checked by ground testing, but that appears to be an inexact science. I once got into a debate about how much BP should be used in a ultimate wildman....even though i use the same amount as Tim and Crazy Jim and fly mine a lot........
 
I think that you should sample the descent rate, not presence of darkness ... things that don't separate are rapidly accelerating
I'd also make it "fire an auxiliary circuit" not just the main.
I think east coasters would try to get separation, probably with an over-sized charge as blowing the main is akin to loosing the rocket (and also violating the code requiring the flight plan land within the recovery area, but this is debatable).

This is interesting problem. When I think of why it might happen, i think about too small charge or failure of ematch (or not enough power to drive it). I wonder how many of those things could be rectified by another charge - and the only one I list is a ematch failure. Would i be likely to get one? Probably not as it's also an additional complexity. If I'm that worried, I use 2 channels with different altimeters. Those who know me sometimes laugh at my battery farms as I tend to use 2 rechargables for each channel. (eliminates the power issue).

Some may mention too tight of a coupler as a reason to have it, but that's just a build issue that you can check for in advance. Of course charge sizing can be checked by ground testing, but that appears to be an inexact science. I once got into a debate about how much BP should be used in a ultimate wildman....even though i use the same amount as Tim and Crazy Jim and fly mine a lot........

I agree with you that there are other ways. I use a 4 channel altimeter with staggered charges on the apogee event. Normal for the primary and an Armageddon sized charge for the backup. But that assumes my backup fires.

The person that requested this feature had other concerns. They (its a group project) wanted a separation detector. My guess from my correspondence with them is they wouldn't need it because they seem pretty sharp. I suspect they did a DFMEA and needed an action for one of the possible failure modes. This is a school project, if you are doing a project for credit you need to follow all engineering best practices I am guessing.
 
John, do you have a planned roadmap for your gadgets? On the website I only see extra channels which is of only mild interest. The separation detect has much more value to me with some complex projects coming up. What other things might we see in the future?

BTW, if that is "top secret" then I understand. Or you could PM me--I'd never tell (promise).
 
John, do you have a planned roadmap for your gadgets? On the website I only see extra channels which is of only mild interest. The separation detect has much more value to me with some complex projects coming up. What other things might we see in the future?

BTW, if that is "top secret" then I understand. Or you could PM me--I'd never tell (promise).

Gadgets that are very close to release:
GPS module
Telemetry Xmtter (and receiver)
 
Gadgets that are very close to release:
GPS module
Telemetry Xmtter (and receiver)

By any chance is there a one-to-many association between the GPS receiver and transmitters so multiple separate assemblies can be tracked during one flight?
 
By any chance is there a one-to-many association between the GPS receiver and transmitters so multiple separate assemblies can be tracked during one flight?

Yes, you can configure multiple transmitters on the same network PANID and track them with a single receiver. I haven't developed the code for that yet for the initial release but I will code it on the first request from a customer.
 
Has anyone said "just do a simple circuit to determine whether or not the rocket has separated"?

Two JST connectors. One side is affixed to the part to be separated, the other is affixed to where the altimeter is. The part to be separated (female) has the leads twisted together, therefore completing the circuit when the two parts are together and broken when the rocket separates. Put a 3 or 5 foot wire on the male side going to the altimeter so that you know the parts separated sufficiently far apart. The key is to make sure that neither side can pull free without breaking the circuit.

All you need is a connection to the necessary port on your altimeter. It really don't get any simpler than that
 
Wires?!?! :eyeroll: So 20th century tech......

Understanding your sarcasm...it's the most fail safe method presented. Fewer "well what if..." scenarios.

It's why I will always prefer screw switches to magnetic switches...and why Jack White records in analog!
 
Understanding your sarcasm...it's the most fail safe method presented. Fewer "well what if..." scenarios.

It's why I will always prefer screw switches to magnetic switches...and why Jack White records in analog!

And why Tarantino films on film.... But I think its more of an artistic choice than a reliability choice....

I am glad you got my sarcasm. But the wire break is only the sensor part of the system. Comparing the wire break (sensor) to the photocell, the photocell is simpler and more fail safe that a wire break sensor.

Now if you do a FMEA of entire system it is not clear to me which one will be more inherently reliable. I do not know yet because I haven't done the FMEA yet.

But in general the system that requires less human elements to be done correctly is more reliable. A mechanical system (like wire break or pull pins) has more steps in the process that requires human skill than an optical sensor with a wireless interface. I will offer that there are more opportunities for error in a mechanical break wire system than some of the systems that are being brainstormed here. We will see.


PS. Do you know what the biggest cause of system failures in the world today is? (From Reliability science)
 
Last edited:
Incorrect assumptions with regard to system requirements>

And why Tarantino films on film.... But I think its more of an artistic choice than a reliability choice....

I am glad you got my sarcasm. But the wire break is only the sensor part of the system. Comparing the wire break (sensor) to the photocell, the photocell is simpler and more fail safe that a wire break sensor.

Now if you do a FMEA of entire system it is not clear to me which one will be more inherently reliable. I do not know yet because I haven't done the FMEA yet.

But in general the system that requires less human elements to be done correctly is more reliable. A mechanical system (like wire break or pull pins) has more steps in the process that requires human skill than an optical sensor with a wireless interface. I will offer that there are more opportunities for error in a mechanical break wire system than some of the systems that are being brainstormed here. We will see.


PS. Do you know what the biggest cause of system failures in the world today is? (From Reliability science)
 

Latest posts

Back
Top