Bug Bounty - Win a Free Eggtimer Quantum!

[cerving]

There's been a lot of talk lately on the Forum about altimeters firing prematurely, and the need for having a physical switch on the pad, etc. etc. So, I thought I'd have a little fun with this...

I'll give a FREE Eggtimer Quantum kit to anyone who can show that there's a way to make a deployment channel on an Eggtimer Quantum fire WITHOUT it being armed remotely (or in test mode, obviously!). The ground rules:

o It has to be REPEATABLE... i.e. I have to be able to do "this, then this, then this" to make it happen.
o You have to use some kind of resistance load... LED's don't count. The continuity trickle current is about 500 uA, that's enough to dimly light some LED's (including the ones in the optoisolators that do continuity checking).
o The Quantum has to be 100% stock... no modifications that aren't in the Assembly Guide.
o You have to be the first one to come up with it. If there's an actual bug, it's going to get published immediately, with the software fix coming right on the heels. I take any issues with the deployment logic VERY seriously.
o If it involves dead-shorting the output and blowing the FET first, that's OK... that's why there are switches on both sides of the load. You'll have to replace the FET at some point, of course...

The contest runs through 6/30/2017. Good luck... you're gonna need it. I haven't found a way to make it blow yet...

Cris Erving
Eggtimer Rocketry

 

[ksaves2]

Ok, Cool, I quoted your post Cris and sent it to David Wilkins and Deb Koloms in followup to my question I sent to TRA for consideration.

Here is my original question from February 27th. It's not some confidential mumbo jumbo so I don't think anyone from TRA would be offended:
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Hi, Forward this to the party that can answer it or if the subject is going to be up for a ruling. If not, there should be an exploration within the BOD concerning the remote activation of rocket electronics. What is the standing with TRA on Magnetic switches https://shop.featherweightaltimeters.com/product.sc?productId=33&categoryId=2 and remote activation via EggTimer Rf switches, Wifi Switches, the Quantum wireless altimeter, EggFinder TRS and Altus Metrum products? Specifically, in many a smaller project a mechanical switch is simply not practical and the flier attaches the battery to the remotely activated device sans a mechanical switch and activates it from a handheld unit. The reason I ask is NAR requires mechanical switches for L3 certifications on the deployment altimeters. Doesn't matter if they are Rf, Wifi or magnetic. There has to be a mechanical switch. Sort of defeats the purpose of a wireless switch especially since once the battery is plugged into the device (ie. Quantum/TRS) the units start in the "**** state. The Featherweight Magnetic switch defaults to the "on" state but can be quickly turned off with the magnet before the altimeter can cycle. In reality I have have one L3 candidate rocket with switches and one that is designed clean and can use two Quantum Wifi activated altimeters. I was originally going to use magnetic switches but wireless is out now and attractive. I'd rather certify with the wireless rocket but could use the one with switches instead. I think this topic should be explored by the BOD. People are already flying small projects with remote activation without mechanical switches. I know because I've done it several times with the charges attached to the altimeters. Connect, secure the battery, button up the ebay and get the rocket checked by the RSO. Since the rocket is in the "**** state there is no beeping or suggestion it is "armed". Go to the pad, arm the device wirelessly and go fly. I propose an L3 flight could be carried out in the same fashion with two remotely activated devices without mechanical switches at all.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Kurt

 

[Steve Shannon]

Cris,
That's cool. Years ago A few products I worked on used a real time kernel, Vrtx, that promised a bug for a bug. If someone found a bug, a Vrtx would give them a Volkswagen.

Kurt,
The TRA Level 3 procedure doesn't specify. That means it is up to you and your TAP. I don't believe we want to remove it from that judgment.

Steve


Steve Shannon

 

[cerving]

I've had some conversations with a few TRA TAP's about electronic switches, it's pretty much up to the individual TAP. For NAR, it's pretty specific... power must be removed from all electronics. Period. Personally, I'm OK with that, although I think it adds an unnecessary complication, and of course another point of failure.

 

[Steve Shannon]

I've had some conversations with a few TRA TAP's about electronic switches, it's pretty much up to the individual TAP. For NAR, it's pretty specific... power must be removed from all electronics. Period. Personally, I'm OK with that, although I think it adds an unnecessary complication, and of course another point of failure.

I think the NAR L3 procedure rule will change also. The existing rule was intended to be a clarification of the previous rule which was too easily misinterpreted to require switches for each output channel. The wording "physical break" was added because there had been altimeters which had soft switches. I believe that the intent is to avoid the possibility switching a transistor inadvertently, resulting in premature ignition or ejection. Out of curiosity I'd like to hear how that is prevented or mitigated in this design, but I wouldn't want the L3CC or TAP committees to have to certify altimeters. One of the concerns when we settled on the "physical break" wording was that L3CC members are not necessarily qualified to assess the safety of a solid state switch circuit, but all of us could recognize a "physical break".
If you have any suggestions for how we might develop more comfort with such things I'd enjoy hearing them.

I ought to also say that I'm speaking only for myself, not representing the Tripoli board of directors, TAP Committee or L3CC Committee.


Steve Shannon

 

[ksaves2]

Cris,
That's cool. Years ago A few products I worked on used a real time kernel, Vrtx, that promised a bug for a bug. If someone found a bug, a Vrtx would give them a Volkswagen.

Kurt,
The TRA Level 3 procedure doesn't specify. That means it is up to you and your TAP. I don't believe we want to remove it from that judgment.

Steve

Steve Shannon

The only problem is going there where a particular TAP has "never been" and they simply say "no" whereas someone else says yes.
Like the big deal certing with saucers. Ground rules were applied, basically 3 or 4 Fin with a nosecone and parachute period.
I'll drop it here to avoid creating a circular argument. NAR always seems to be a bit less progressive and for full disclosure I am a member of and support both
groups. Kurt

 

[Igotnothing]

I have not done my L3 yet (nor even finished building the rocket), but I chose the WIFI switches for my TRA project. I sent a bunch of information to my TAPs about how they functioned, and how they would enhance my safety by keeping my head away from an armed rocket on the pad trying to listen for beeps.

I then got to thinking about the many rockets that get found and fondled by others, etc. before the owner gets to it. We worry about unburnt ejection charges, but what factor of safety do we offer the public who might pick up our rocket while it is still active?

Maybe we all need a sticker:

 

[cerving]

The Quantum shuts down the power to the deployment channels after landing, whether they've fired or not. It's as safe as it would be on the pad unarmed.

 

[woferry]

The Quantum shuts down the power to the deployment channels after landing, whether they've fired or not. It's as safe as it would be on the pad unarmed.

One question would involve what the Quantum considers "landing". I could be mis-remembering, but I believe I had a TRS land on a hill at Snow Ranch once (not hard, it's a hilly area that launches in a low-spot), and the altitude never got low enough for it to consider itself "landed". Given that the deployment channels shouldn't be needed after the main event firing (or whatever event fires later since I think airstarts confuses this a bit), shouldn't it power things down then (even if it never "lands")? Or can it try to fire a channel multiple times?

 

[Bat-mite]

I think the NAR L3 procedure rule will change also. The existing rule was intended to be a clarification of the previous rule which was too easily misinterpreted to require switches for each output channel. The wording "physical break" was added because there had been altimeters which had soft switches. I believe that the intent is to avoid the possibility switching a transistor inadvertently, resulting in premature ignition or ejection. Out of curiosity I'd like to hear how that is prevented or mitigated in this design, but I wouldn't want the L3CC or TAP committees to have to certify altimeters. One of the concerns when we settled on the "physical break" wording was that L3CC members are not necessarily qualified to assess the safety of a solid state switch circuit, but all of us could recognize a "physical break".
If you have any suggestions for how we might develop more comfort with such things I'd enjoy hearing them.

I ought to also say that I'm speaking only for myself, not representing the Tripoli board of directors, TAP Committee or L3CC Committee.


Steve Shannon

My L3CC was of the opinion that a typical $5 110/220 rotary switch created a sufficient break. That's how I got my L3.

 

[cerving]

One question would involve what the Quantum considers "landing". I could be mis-remembering, but I believe I had a TRS land on a hill at Snow Ranch once (not hard, it's a hilly area that launches in a low-spot), and the altitude never got low enough for it to consider itself "landed". Given that the deployment channels shouldn't be needed after the main event firing (or whatever event fires later since I think airstarts confuses this a bit), shouldn't it power things down then (even if it never "lands")? Or can it try to fire a channel multiple times?

It powers down after it fires the last channel, but it also explicitly shuts it off at landing (< 30' AGL for >5 secs.). It's theoretically possible that your rocket could drift under drogue and land on a high spot at an AGL above the main chute threshold, then when you pick it up and take it back it would pop as you're driving downhill. I've never heard of that happening (it would have to be a pretty big hill), but it IS possible. I don't think this is unique to the Quantum, however... I think most altimeters would do the same.

To prevent that, plus the annoyance of having hundreds of identical low-altitude readings if you land in a tree/hill above 30' AGL, I'm going to add some logic that just looks at your current AGL after nose-over, and if it essentially has not changed for at least 15 seconds we'll assume you're down. You could be under main and be caught in a thermal too, so you have to give it a pretty decent time threshold... 15 seconds should be way more than enough.

 

[woferry]

It powers down after it fires the last channel, but it also explicitly shuts it off at landing (< 30' AGL for >5 secs.). It's theoretically possible that your rocket could drift under drogue and land on a high spot at an AGL above the main chute threshold, then when you pick it up and take it back it would pop as you're driving downhill. I've never heard of that happening (it would have to be a pretty big hill), but it IS possible.

I read something here at one point about this being an issue at Black Rock Desert, not the altimeter going off later, but the rocket hitting the ground (might have even been on Black Rock proper) which was at an altitude above what the rocket's main parachute was programmed to deploy at (I think it was set to 700' and landed at more like 1000'). So it was more a story about damage to the rocket and needing to set the main altitude higher at BRD if you were in danger of blowing towards the hills (i.e. higher-altitude flights). But yeah, if by the time you got to the rocket the altimeter was still alive and it decided to fire on the way down that could be bad, and probably not unique to the Quantum's design. That said, I've landed on Snow Ranch's hills with other altimeters and haven't had them not consider the flight complete, so it seems like the ones I've flown have a similar "I don't seem to have moved significantly in XX seconds, so I must be landed" approach, or at least consider the minimum landed altitude to be something above 30' AGL. I was still below the main deployment altitude so I can't say what would have happened if it still had unfired charges. Not too keen to find out either, both because of it being a drogue-only landing and a lot higher than I'd like to go to recover a rocket.

 

[Steve Shannon]

My L3CC was of the opinion that a typical $5 110/220 rotary switch created a sufficient break. That's how I got my L3.

I would absolutely agree. A switch is the most common form of physical break. It's up to the flyer and their L3CC if the flyer wishes to use something else like twist and tape.

 

[UhClem]

I'll give a FREE Eggtimer Quantum kit to anyone who can show that there's a way to make a deployment channel on an Eggtimer Quantum fire WITHOUT it being armed remotely (or in test mode, obviously!). The ground rules:

This would only be possible if schematics and source code were available. Otherwise, we are just stumbling around in the dark.

 

[dixontj93060]

Had a couple of on pad ejection charges this week at LDRS--were they Egg-somthings???!

 

[cerving]

This would only be possible if schematics and source code were available. Otherwise, we are just stumbling around in the dark.

Well, yes and no. If you have schematics, it would be really easy to intentionally jumper something and make it blow as soon as you apply power. Of course, if you have a decent knowledge of electronics and you know the part numbers of the transistors/FETs (hey, they're public!), it shouldn't be too tough to figure that out. I don't have the schematics for a Raven, RRC3, or Stratologger but I didn't have much trouble figuring out how to connect the remote continuity feature of the WiFi Switch to them.

But that's not a bug, that's intentionally breaking it. You can do that pretty easily with just about any altimeter.

In terms of software, I try to break things, but I'm not going to pretend that ANY piece of software is 100% unbreakable. That's what this is all about... the more troubleshooters you have, the better. Does this imply that I think the Quantum is full of bugs? Absolutely not! If I find any issues, I make them public, and patch them immediately. Quality is important... that's why it took so long for the Quantum airstart software to come out.

 

[UhClem]

But that's not a bug, that's intentionally breaking it. You can do that pretty easily with just about any altimeter.

Completely missing the point. It is very hard to find problems in edge cases when you can't look at the schematics or code. You can fiddle around and try to find conditions that cause a failure but you have nothing to guide you. I don't need this information so I can find ways to intentionally break it by changing something but to find bugs in the design/code that could result in trouble.

Is there some reason why you think that this information must remain a closely guarded secret?

 

[cerving]

Dave, you're a smarter guy than I am but you're sounding a little trollish here. The OP wasn't a request for a peer review... it was to "have a little fun" at the user level. Users manage to find ways to break software all the time without having the code. I'm sure Microsoft has a large team of software QA engineers that pore over every line of Windows, and there's always something they miss. The difference is that developers are looking at the way that software is SUPPOSED to work, and users are looking at the way that they THINK it works. The challenge is making those one and the same.

 

[rharshberger]

Dave, you're a smarter guy than I am but you're sounding a little trollish here. The OP wasn't a request for a peer review... it was to "have a little fun" at the user level. Users manage to find ways to break software all the time without having the code. I'm sure Microsoft has a large team of software QA engineers that pore over every line of Windows, and there's always something they miss. The difference is that developers are looking at the way that software is SUPPOSED to work, and users are looking at the way that they THINK it works. The challenge is making those one and the same.

That's the same reason the Army has its new/experimental equipment tested by Privates, if it can be broken or a unexpected use found its the lower ranked enlisted that are most likely to do it.

 

[BDB]

This morning I test-fired two e-matches with my quantum, and much to my amazement, it worked. Later in the day I wanted to show off for my wife, so I loaded another e-match and connected my iPhone to the quantum via wifi. I didn't have the instructions with me to get the URL for the testing page, so I loaded it from the browser's history....

The e-match popped instantly while I was holding the quantum in my hand! No harm was done, but we were definitely surprised.

Bonehead move on my part. I had accidentally loaded the page with the firing sequence. I'm not sure that is a bug, but I just wanted to tell everyone to be careful. I've since bookmarked the test page, so I don't make the same mistake again.

 

[Kallahan11]

This morning I test-fired two e-matches with my quantum, and much to my amazement, it worked. Later in the day I wanted to show off for my wife, so I loaded another e-match and connected my iPhone to the quantum via wifi. I didn't have the instructions with me to get the URL for the testing page, so I loaded it from the browser's history....

The e-match popped instantly while I was holding the quantum in my hand! No harm was done, but we were definitely surprised.

Bonehead move on my part. I had accidentally loaded the page with the firing sequence. I'm not sure that is a bug, but I just wanted to tell everyone to be careful. I've since bookmarked the test page, so I don't make the same mistake again.

That is absolutely a bug. A dangerous one at that.

 

[les]

The difference is that developers are looking at the way that software is SUPPOSED to work, and users are looking at the way that they THINK it works. The challenge is making those one and the same.

I have learned you can't make things foolproof. The fools are "smarter" than us. :wink:
They will find a way to try to do something that the developers would not think of...

 

[cerving]

This morning I test-fired two e-matches with my quantum, and much to my amazement, it worked. Later in the day I wanted to show off for my wife, so I loaded another e-match and connected my iPhone to the quantum via wifi. I didn't have the instructions with me to get the URL for the testing page, so I loaded it from the browser's history....

The e-match popped instantly while I was holding the quantum in my hand! No harm was done, but we were definitely surprised.

Bonehead move on my part. I had accidentally loaded the page with the firing sequence. I'm not sure that is a bug, but I just wanted to tell everyone to be careful. I've since bookmarked the test page, so I don't make the same mistake again.

What version of the software do you have? In the first released version (1.02) you could reused the arming code by hitting the "back" arrow. In later versions (1.03a and above), the arming code is recalculated after firing, so a "back" arrow won't fire because it loads an invalid arming code. It will immediately recalculate a new one without doing anything.

Here's all the release notes notes directly from the source code, since 1.02.

//------------------------------------------------------------------------
// 03-30-2016 1.02 1.01j RENAMED TO 1.02 (PRODUCTION)
//-----------------------------------------------------------------------
// 03-30-2016 1.02 - Fixed continuous on-time in igniter mode (didn't work)
// - Fixed bug that showed Drogue as "**** in post-flight display if Drogue Delay was non-zero
// 04-05-2016 1.02a - RELEASE Added "sec" to Drogue Delay and post-flight display, changed display to n.n format
// - Cleaned up a few errors in the Drogue Delay pick list
// 04-06-2016 1.02b - Added Main deploy at N-O option
// 05-02-2016 1.03a - RELEASE Added Validation Code change after deployment test, prevents
// back button on browser from starting deployment test again
// 05-07-2016 1.04a - RELEASE Added yield()'s to help WiFi stability
// 10-11-2016 1.05 - RELEASE Fixed bugs in baro routine that caused bad readings below about 60F
// 10-29-2016 1.06 - Added airstart code (not compilable)
// 10-30-2016 1.06a - Made Drogue & Main channels independent in Airstart Mode (inc.)
// 11-06-2016 1.06b - Added Airstart dependent continuity/checking code... (inc.)
// 11-06-2016 1.06c - First test airstart code...
// 11-08-2016 1.06d - Fixed some web code issues
// 11-10-2016 1.06e - Added breakwire status in Status code
// 11-13-2016 - Added breakwire arming check
// 11-14-2016 - Shut off FET for airstart only if both channels are off
// 11-20-2016 1.06f - Fixed airstart timing bugs
// - Added drogue (nose-over) option to "B" channel
// 11-25-2016 1.06g - Fixed airstart issues
// 12-03-2016 1.06h - Removed link to "Change" from Mode Display (must be explicitly entered)
// 12-03-2016 1.06i - Changed Mode screen to go to Status, not Settings
// 12-09-2016 1.06j - Fixed bug in Drogue/Airstart@N-O
// 12-18-2016 1.06k - Added velocity check for airstart
// 01-15-2017 1.06k1 - fixed bug in deploy mode display (showed failsafe instead of main)
// 01-15-2017 1.06L - Added option for airstart V/Alt check for one-time check or any-time
// 02-07-2017 1.06M - Changed LowV filter to Last 5 raw velocity weighted average
// 02-19-2017 1.06N - RELEASE Changed breakwire input to INPUT_PULLDOWN_16, changed BW_OPEN & BW_CLOSED values appropriately
// - Cleaned up Settings screen

 

[cerving]

I have learned you can't make things foolproof. The fools are "smarter" than us. :wink:
They will find a way to try to do something that the developers would not think of...

True, however this bug was fixed a year ago as far as we know. I just tried it with 1.06N (the current production version)... you can't do it.

 

[BDB]

True, however this bug was fixed a year ago as far as we know. I just tried it with 1.06N (the current production version)... you can't do it.

I haven't done the flash update yet. I was probably just too eager to test it. That will surely fix the issue. Thanks.