Revision to Tripoli Rule Regarding Wireless Remote Switches

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Status
Not open for further replies.
There’s a lot of advanced technical conversation in this thread, which is great, but I can’t say I’m following 100% of it. But I do want to contribute to the conversation if I can, based on my own personal experience, and questions about my options going forward.

Until last year, I only used motor eject on my rockets. I had zero experience with building electronics, and I was not very comfortable with the terminology, tools, or techniques, and I was especially intimidated by the idea of wiring up charges to electronics. I liked simple motor eject flights, and I had also witnessed about 5 or 6 mishaps in the past 5 or 6 years with charges going off while people were prepping rockets in their prep areas, or while getting set up at the pads.

So I was not enthusiastic about electronic deployment based on what I perceived as the complexity of it and also my personal observations of people blowing up charges right in their own faces over the years. However, I also saw a few ballistic crashes of large high-power rockets over those years, and based on feedback from friends in the hobby, I was eventually convinced I should be using electronic deployment with motor backup with the size of rockets I was flying.

I selected the Eggtimer Quantum based of what seemed to me to be great safety features. I especially liked the fact that it could be armed from a distance, which I figured might help prevent me from being one of the guys who blows a charge off accidentally while standing right there with it. I also loved the wireless browser-based interface that seemed less error prone than flipping tiny switches or counting beeps. I had friends solder it up for me and help me set up the AV bays. My setup has no physical switches. I have the single-battery setup. I connect/disconnect the battery with a JST connector at my prep area and use the WiFi connection to arm the altimeter on the launch pad. Accessing the battery requires me to remove 6 screws from the nosecone bay on one rocket or 4 screws from the hatch bay on another.

So my questions have to do with the overall safety of this setup and the alternatives.

First, is the Eggtimer Quantum safe the way I am using it? I asked on the Tripoli Facebook group if there was ever a single known instance of the Quantum malfunctioning and setting off a charge accidentally. The answer was emphatically NO! And Tripoli did not in any way want to suggest there was even a hint of a problem with the product. It sounds like a 100% perfect safety record so far to me. It seems like the concern is not that there is a known way for the device to fail unsafely, but that there might be an unknown way for the redundant design to possibly fail unsafely someday. For now, the Quantum is what I have, so is it safe?

Next, what are my alternatives, and how do they compare with doing what I’m doing now?

The most obvious alternative is for me to stop using the Quantum at Tripoli events. I was flying for years without it, and motor eject is fully compliant with Tripoli safety rules for the rockets I am flying. But there’s a higher risk of deployment failure. Overall, would it be safer to fly motor eject with no backup or use the Quantum without a physical disconnect the way I have been with motor backup? Any opinions on the relative safety?

Another alternative is to leave the battery disconnected until after the check-in, connect the battery at the pad or special prep area (if any), screw the bay closed with the 4-6 screws, connect to the WiFi, connect to the Quantum, check the continuity on the closed up rocket and correct if necessary, then begin the normal process of loading the rocket on the pad, Installing the igniter, connecting igniter leads, and arming the Quantum. It seems kind of inconvenient. Would that kind of procedure have an impact on launch operations? Would you patiently wait for me to do all that? Are there safety concerns related to time pressure?

Another option would be to add a physical switch to disconnect the battery from the Quantum. I assume that’s the solution Tripoli would lean toward. I think I can probably install a screw switch on the bulk plate of the nosecone bay. I’m not sure about the second rocket. I would be able to leave the switch open, connect the battery, and screw on the nosecone bay in my prep area, then check in, move to the pads, remove the nosecone, turn on the switch, replace the cone, and then proceed normally. It’s more steps than I do now, but it’s fewer steps than connecting the battery at the pads. Anyone see an issues with this I’m not considering?

Another option is scrapping the Quantum and going to a different altimeter with only a physical switch, but I feel that’s probably what was being used with all those instances of guys popping off charges that I’ve seen in the past. I don’t know if that’s the case for sure. Are there mechanical failures or user errors with those kinds of systems that lead to accidental ignition of charges?

Are there other alternatives I’ve overlooked?
 
No one in their right mind carries around a rocket with the altimeters energized. Why is it okay to walk around with a rocket with its wifi switch active which in the worst case could turn the altimeters on? This aint rocket science guys..... wait

No one walks around with an active altimeter because more of them are designed so a single FET/control line lights a pyro. No redundancy
The single failure mode of the WiFi switch would be to energize the altimeter. It would require both to fail between setup and pad to light a pyro. Single redundancy.
Specifically, the Eggtimer Proton would require a wifi/MPC failure, the FET failure, and the IO Expander to fail between car and pad. Double redundancy. But I would accept arguments that reduce it to single, or up it to triple because the software and hardware combinations are much more complex.

In the no redundancy case, you know of the failure when the pyro goes bang. Incident.
In the redundant cases, you know because you hear the altimeter wake up. And you stop and fix it. Near miss.

In the same sense, no one in their right mind uses a normal ladder out in the field. At least I could bring along an orchard ladder intended for uneven surfaces.

 
Another alternative is to leave the battery disconnected until after the check-in, connect the battery at the pad or special prep area (if any), screw the bay closed with the 4-6 screws, connect to the WiFi, connect to the Quantum, check the continuity on the closed up rocket and correct if necessary, then begin the normal process of loading the rocket on the pad, Installing the igniter, connecting igniter leads, and arming the Quantum. It seems kind of inconvenient.

I’m in the “unplug the battery” camp, for what it’s worth.

Inconvenience is the same reason used for virtually every bad safety practice I’ve ever seen — safety glasses, hearing protection, respirators, seat belts, fall harnesses, child seats, lock out/tag out, online passwords, washing your hands...

Convenience and safety are generally on the opposite end of the spectrum.

Would that kind of procedure have an impact on launch operations? Would you patiently wait for me to do all that? Are there safety concerns related to time pressure?

I foresee the solution being similar to the problem of not enough launch pads: add more stations. It takes space and equipment, but isn’t intractable.

It’ll probably take a while to figure out an optimal “electronics cell” to pad ratio, but it’s clear a well organized launch will require additional stations for flyers to connect and initialize their electronics. If there aren’t enough, the club can learn and set up more next time.
 
The whole fallacy to this rule is that a switch I add to my A/V bay will be safer than the devices we have been using, and that every rocket builder will do the same. I haven't seen any references to any kind of study or survey that shows this will be the case.

I also think many mechanical switches are far easier to activate accidentally than any of the electronic switches I have used. Screw switches can vibrate closed, pull switches can get snagged and pulled out inadvertently, even twisted wires could short against metal while exposed and untwisted.

Who wants to make the argument that the plethora of user created mechanical switches will all be safer than the small handful of electronic switches that we now use?


Tony

(edited for brevity)

I use twist and tape/tuck (depending on mood/flight profile). I never have exposed bare wire until I'm ready to twist. I strip the wires at the pad and then twist to arm , then tape. I always cut off the twisted pair to disarm the rocket.
 
The whole fallacy to this rule is that a switch I add to my A/V bay will be safer than the devices we have been using, and that every rocket builder will do the same. I haven't seen any references to any kind of study or survey that shows this will be the case.

The fallacy is in thinking a mechanical switch is specifically mandated. The requirement is “physically disconnected from power or must have their initiators mechanically disconnected from potential power sources while being transported or when presented for pre-flight inspection.”

The reliable/safe solution is “physically unplug your batteries.” Plugging in the battery is now not unlike requiring igniters to be installed on the pad, I think.

No modifications to rockets are necessary; a new prep procedure appears satisfy the requirement.
 
First of all I appreciate any efforts that lead to a safer hobby, as that is better for us all in the long run. Assessing risk is a tricky task. I do R&D in an industry where reliability is extremely important, and I think that there are some useful corollaries between safety and reliability (although they're not the same thing).

As a simplistic generalization, a mechanical system with more moving parts will tend to be less reliable than one with fewer moving parts. However, I gather that the concern is that reliance on software introduces a vulnerability to bugs or "unexpected behavior". If software is simple enough to be described as a deterministic state machine (AI and learning algorithms excluded), then it is repeatable and the same inputs (in the same sequence) will give the same outputs. It is testable. The problem is that very complex software and systems don't allow for testing every conceivable input sequence (probably true for most software). It is true that no software is perfect and free from bugs. We occasionally find "unexpected behavior" in code that is 10 years old, but those are usually revealed in extreme edge cases where a customer is doing something that no one ever expected anyone to attempt (or it was not designed for). I can't say for certain, but I don't think that our altimeters are sufficiently complex, or our use cases so varied that we're likely to frequently encounter situations that haven't already been extensively tested.

If the reliance on software introduces a vulnerability, I think it is worth weighing that against the benefits of simpler mechanical construction. On this forum are exquisite examples of fine craftsmanship and carefully constructed A/V bays, but I also see a few samples that make me wonder if the wiring will survive the trip out the pad. A mechanical disconnect that fails either open or closed can result in an unsafe event.

Any opportunity to eliminate a wire that can fray, connection that can corrode, or moving part that can fail, almost always results in better reliability. A progression from mechanical switches to solid state switches is analogous to the advance from relays to transistors.

I don't inherently trust or distrust software, but I do trust things that I can test and are repeatable and consistent, and I distrust things that are unreliable.

Thanks for the interesting discussion.
 
The fallacy is in thinking a mechanical switch is specifically mandated. The requirement is “physically disconnected from power or must have their initiators mechanically disconnected from potential power sources while being transported or when presented for pre-flight inspection.”

The reliable/safe solution is “physically unplug your batteries.” Plugging in the battery is now not unlike requiring igniters to be installed on the pad, I think.

No modifications to rockets are necessary; a new prep procedure appears satisfy the requirement.
How many HPR rockets and A/V bays have you built and flown?

In my experience and with the types of rockets I fly, it is impossible to physically unplug the batteries without completely disassembling the entire A/V bay. You are essentially saying I should take my rocket to the RSO table either unassembled so they can verify the batteries are not installed, and then reassemble it out by the pad, or assemble it without the batteries, get it RSO'd, and then disassemble, install batteries, and reassemble at the pad. Neither is a realistic or practical solution, not only for me, but for the majority of fliers that I routinely associate with.

But more importantly, you exactly prove my point. This rule change only forces us to us a much wider, non-standardized way of arming our electronics than a handful of purpose built electronic devices. Nearly everyone at lunch today used either mag switches, wifi, or both. Now all of us, each in our own way, have to devise an alternate solution. How is that safer or better? If it isn't then what is the purpose of this rule?


Tony
 
Last edited:
I can't say for certain, but I don't think that our altimeters are sufficiently complex, or our use cases so varied that we're likely to frequently encounter situations that haven't already been extensively tested.
Things built using the ESP8266 (WiFi switches) are built on a large pile of RF and TCP/IP code. Written and maintained by someone else. Networking code is subject to bugs (buffer over flow being a fairly common bug) that can reveal very unexpected behaviour.

Don't forget the development environment. A change in that can alter what code is produced and what library code is called. If that environment changes, you have to either stick with the old version or retest and certify the resulting firmware.
 
As a skydiver, I used a device called an AAD (Automatic Activation Device) that would detect ground level, detect an airplane ride up, detect freefall, and monitor altitude on the way down. The idea was that if the AAD's on board computer detected that I was still in freefall at 1000 feet, it would activate a pyro-based cable cutter that would deploy my reserve so that I did not freefall into the ground.

Pretty much every dropzone has signs everywhere reminding people NOT to turn on their AAD and let it calibrate anywhere except the landing area, because if the device were calibrated elsewhere, it might either a. deploy a reserve canopy in the trunk of a car, b. fail to fire when its owner lost altitude awareness in freefall, allowing its owner to crash into the planet at triple digit speeds, or c. deploy a reserve parachute that would entangle with the main parachute, resulting in its owner crashing into the planet at triple digit speeds.

I say all this only to point out that barometric devices can be tricked, and I applaud the INTENT of the rule. I am not sufficiently familiar with HPR procedures and equipment to know whether the rule has unintended consequences, so I have no opinion on whether it is a good rule.

Very good points.
Unfortunately almost every rule or rule change has unintended consequences; this one is no different. The people I work with on the board are ethical enough that they would revise the rule as their understanding changes. Our understanding always changes with technology.
 
Things built using the ESP8266 (WiFi switches) are built on a large pile of RF and TCP/IP code. Written and maintained by someone else. Networking code is subject to bugs (buffer over flow being a fairly common bug) that can reveal very unexpected behaviour.

Don't forget the development environment. A change in that can alter what code is produced and what library code is called. If that environment changes, you have to either stick with the old version or retest and certify the resulting firmware.
Are you implying we should not trust them because we did not write the code or it might have bugs? How much of the code did you write in the car you drive?

The current products are testable and relatively standardized. They are literally tested by the community every time one is used. Unlike the results of this rule, which will result in essentially every flier having a different solution to the rule. The rule assumes each builder is smarter and more capable than those who have developed the electronics we were formally allowed to use. That we won't choose components that are unsuitable or design circuits that don't work as intended. That a mechanical solution is better than an electronic one.

I'm still waiting for someone to make the argument that 1,000 different solutions is better than a handful.


Tony
 
Last edited:
Very good points.
Unfortunately almost every rule or rule change has unintended consequences; this one is no different. The people I work with on the board are ethical enough that they would revise the rule as their understanding changes. Our understanding always changes with technology.
In this case though there are intended consequences that are hard to understand. The board or authors of this rule have decided that those of us who have a large investment in time, money, and experience with a very small set of products are now wrong and must largely abandon that entire investment. It will also very adversely affect several vendors who have made large and very positive contributions to our hobby. Their financial loss is likely to be substantial. That is a very clear outcome of this rule.

I have seen or heard of no justification, no studies or analysis, no precipitating event, nothing that justifies this change in rules. None of the Tripoli members I spoke with today thought it would make flying safer, in fact, they all had the contrary opinion. If there isn't any specific reason that can be given for this rule, then why does it exist?


Tony
 
In this case though there are intended consequences that are hard to understand. The board or authors of this rule have decided that those of us who have a large investment in time, money, and experience with a very small set of products are now wrong and must largely abandon that entire investment. It will also very adversely affect several vendors who have made large and very positive contributions to our hobby. Their financial loss is likely to be substantial. That is a very clear outcome of this rule.

I have seen or heard of no justification, no studies or analysis, no precipitating event, nothing that justifies this change in rules. None of the Tripoli members I spoke with today thought it would make flying safer, in fact, they all had the contrary opinion. If there isn't any specific reason that can be given for this rule, then why does it exist?

This ^

The Quantum/Proton/WiFi switches were previously allowed to be used without a separate mechanical switch. What is the reason for the change? Were there any actual incidents involving one of these products?

Adding mechanical switches to my ebay adds another point of failure. Disassembling my av-bay to connect the batteries out in the grass at the pad is a whole other set of problems.

.mark.
 
Tripoli board reviewed the Wi-Fi altimeters years ago and determined they were safe.

No reported incident or additional documents were provided to the board? And now they are unsafe?
 
Are you implying we should not trust them because we did not write the code or it might have bugs?
Trying proving that code is correct. The authors certainly haven't tried to do that.

I am sticking with the AltAcc2. Simple (runs on a 8 bit PIC) and includes an arming switch which disconnects the outputs from the battery.
 
Tripoli board reviewed the Wi-Fi altimeters years ago and determined they were safe.

No reported incident or additional documents were provided to the board? And now they are unsafe?
And I remember (only three years ago) when mechanical switches were THE WORST thing since sliced bread! The more things change, the more they stay the same... https://www.rocketryforum.com/threads/rotary-switch-failures.138371/ (i.e., never had a Schurter switch fail.)
 
Last edited:
Trying proving that code is correct. The authors certainly haven't tried to do that.

I am sticking with the AltAcc2. Simple (runs on a 8 bit PIC) and includes an arming switch which disconnects the outputs from the battery.
Can you please post a link to where we can purchase one? And post the code as well so we can test it and verify there aren’t any bugs. Or have you done that already?

Yes, I realize I’m being snarky but your solution only works for you. What about those who don’t already own an AltAcc2?

And yet another fallacy, that simpler is always better.


Tony
 
Last edited:
Can I propose a thought experiment?

Let’s say you’ve got a house with all the nice high tech “smart home” switches and motion sensors.

Now I have a problem with the overhead light not working, so I hire an electrician.

Does anybody think for a moment the electrician will touch anything without physically cutting all power to the circuit?

Is the fact the “smart switch” is turned “off” and requires a specific set of instructions over WiFi to turn on going to sway the electrician’s mind?

Yet somehow, Volunteer RSO’s are supposed to just smile and pick up your rocket and it’s wired up black powder charges that work on the same principles as the smart home switch?

It’s pretty clear the industry standard of physically cutting all power has something going for it. Maybe it’s because they’re written in blood.
 
Last edited:
Let’s do an actual experiment. Allow vendors and flyers get used to developing, selling, buying, and using a handful of devices that seem to have an excellent safety record over the course of years. And then with no explanation or reason, tell them they are no longer allowed and now everyone has to invent their own way of making something ‘safe’. And RSO’s are now faced with every flyer having a different way of trying to do the same thing.

As you clearly state, there is a good reason for what electricians do. Where is the reason for the change in our rules? How was it determined that each of us inventing our solution is safer than what we had?


Tony
 
Who wants to bet on whether the next rule change is that ALL devices that are connected to energetics must have BOTH a mechanical disconnect AND a remote arming system in ALL cases? No mechanical switches on their own, no remote switches on their own, always both in series.

That way, you aren’t walking around with a powered up wireless remote switch. When you do close the mechanical disconnect, the wireless remote switch will prevent the device from arming immediately. And you will be able to get the rocket positioned and then move to a safe distance before arming with the remote arming system.
 
Allow vendors and flyers get used to developing, selling, buying, and using a handful of devices that seem to have an excellent safety record over the course of years.

... and I’m saying for at least 150 years, the most basic safety rule for electronics has been to remove power.

In all that time, nobody has found a way to replace disconnecting power; when you do that nobody has to trust the circuit.
 
Last edited:
It is bad enough today out at the pads with guys fiddling with altimeters, GPS, cameras, installing igniters, and taking pictures with the wife and kids. Now we have to wait for them to strip wires, assemble av-bays, drop screws in the grass, etc, etc, etc. :mad:

Nobody mentioned this. I assume NAR does not have the same rule. A simple solution (for me, anyway) is to avoid Tripoli. What about clubs/launches that are members of both organizations?
 
What about clubs/launches that are members of both organizations?
Depends on which rules they fly under. My club has both NAR section & TRA prefecture but we fly NAR rules. But I have been wondering if NAR is going to adopt this new requirement too.
 
It is bad enough today out at the pads with guys fiddling with altimeters, GPS, cameras, installing igniters, and taking pictures with the wife and kids. Now we have to wait for them to strip wires, assemble av-bays, drop screws in the grass, etc, etc, etc. :mad:

Nobody mentioned this. I assume NAR does not have the same rule. A simple solution (for me, anyway) is to avoid Tripoli. What about clubs/launches that are members of both organizations?

If they’re taking pictures with the spouse and kids at the pad they’re already violating the Tripoli Safety Codes unless the spouse and kids are insured flyers. Common to both organizations is that no unnecessary people should be at the pad when arming energetics.
 
Last edited:
...
The current list of Tripoli approved wireless remote switches includes:
• The Eggfinder WiFi Switch,
• The Eggfinder Proton,
• The Eggfinder Quantum, and

• Multitronix Kate 2.0.
...

I will ask a glaringly naive question. How can Tripoli approve wireless remote switches that are user assembled? And before you say: "motors are certified predicated on proper assembly by the end user following provided manufacturers instructions", I would argue that soldering a board with many components is far more complicated than assembling a motor.

How can Tripoli test such a device? How many are tested? What is a representative sample size? Do you choose a certified assembler (if there is such a credential)? What solder is used? What soldering device? Device temperature? Tip size or shape? Flux? Verification and inspection of solder connections?

I own several Eggtimer products and have built them successfully and not so successfully. I built two Quarks, and had a strange experience that I brought to Cris' attention. An excerpt from our email correspondence:

"I received the kits and assembled 2 of the 3. Both appear to be working fine. They power up, correctly report continuity, and fire the deployment channels. As a matter of fact, using Christmas bulbs in place of e-matches, I tested both of the units together in a vacuum bottle and one reported apogee at 12,840' and the other at 12,846'. However, I did notice that one of the units emitted a constant tone after launch detection, while the other one was silent."

Our conversation continued without concluding if there was an issue or not. Short of sending them to Cris for a test, I honestly don't know if there is a component defect or assembly error. I know the Quark is not WiFi enabled, but the point of trusted user assembly is representative of the kits.
 
I have never heard that NAR ever allowed Wi-Fi switches. They were presented to Tripoli for review years ago. But was there ever an NAR approval of them?
 
However, I did notice that one of the units emitted a constant tone after launch detection, while the other one was silent.

I have seen this same thing. It seems to happen when a vacuum is pulled to fast. The altimeter still performs as expected. But it seems like it alarms because it doesn't believe the flight parameters.
 
I see the prep at pads or special prep area solution as the least viable. The workflow will never work. You can’t get a pad assignment and then have a half hour or more of work to do afterward. No one would stand for that.

The two clubs I fly with are big and already have a large number of pads. One has 2 banks of either 6 or 8 pads each (can’t remember for certain), so 12 or 16 at every launch. And the other sets up 1 or 2 banks of 8 depending on turnout, so 8 or 16.

When you get a pad assignment, you need to get out there, set up, and clear out efficiently. You do not want to be the one holding up the entire bank of 6-8 fliers. And it’s not just that people are being impatient — for some fliers, once their rocket is ready, it’s burning the batteries and needs to fly before they are gone.

And how many tools and materials are you going to have to lug out to the pads with you?

It seems like a totally impractical idea.
 
I have seen this same thing. It seems to happen when a vacuum is pulled to fast. The altimeter still performs as expected. But it seems like it alarms because it doesn't believe the flight parameters.

I guess I will have to find something that doesn't suck as fast.
 
... and I’m saying for at least 150 years, the most basic safety rule for electronics has been to remove power.

'Because that's the way we've always done it' is not a strong argument. It's not allowed at all in the process safety environment I work in. I understand that it may be short-hand to reference other analyses - but on it's own, it's just not valid.

As I said above, if no combination of design, analysis, and testing can be used to create a policy that allows electronic solutions, then the solution isn't debatable, it's political. And this discussion was only useful in expanding the discussion to all electronic power control, not just the listed devices. (Actually, I also got some good thinking about testing out of it, and always appreciate Jim's thinking about dis-arming.)

I'll go one step further, if the magnitude of the risk is irrelevant to the discussion, and the policy must be applied equally to D-D flights of paper rockets with 0.5g charges and N-N flights with 50g charges, then I question your (the BoD) approach to risk management.

Seeing a policy change not based on new data, nor reported incidents - because you've said you have neither - then I question your approach to change management.

I believe you're incorrectly assessing single failure modes. While I'll comply to fly with my Tripoli friends, I doubt you'll convince me that a single mechanical switch controlling power to an altimeter that is one transistor away from firing, and boots to the detecting launch state is safer than a design with both (+) and (-) leg control and boots into an idle state.
 
Status
Not open for further replies.
Back
Top