GrouchoDuke
Well-Known Member
- Joined
- Oct 18, 2016
- Messages
- 1,693
- Reaction score
- 1,537
...ignore this post. I hit submit on the wrong page & can't find the delete button.
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.
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?
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)
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.
How many HPR rockets and A/V bays have you built and flown?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.
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.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.
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.
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?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.
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.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?
Trying proving that code is correct. The authors certainly haven't tried to do that.Are you implying we should not trust them because we did not write the code or it might have bugs?
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.)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?
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?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.
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.
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.What about clubs/launches that are members of both organizations?
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.
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?
...
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.
...
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.
... and I’m saying for at least 150 years, the most basic safety rule for electronics has been to remove power.
Enter your email address to join: