Data Logging Launch System

I've built a number of launch controllers... more than I've had opportunity to use, actually. But, even so, I've got another design in the works. It's looking to be the most ambitious and complicated launch controller I've ever designed. It will also, potentially, be the most useful. I'm giving myself time. I hope to get it finished sometime around March ( around when our club launches here will start again ).

Basically, it will be a wireless-enabled, Raspberry Pi based data-logging launch system. The system will track igniter resistance ( for continuity checking and igniter characterization ) and at launch will do a high-speed recording of battery voltage and igniter current. The launch controller would be my laptop, the safety-key a flashdrive with a key ID file on it, and the Raspberry Pi could run a web server and provide a website that smart phones and tablets can access that shows the pad status. After fifty launches or so ( hey, it could be used for several consecutive club launches ), I'll have a nice data set to analyze.

Yes, I have quite a bit of work to make sure that launch via wifi is safe. The big question is, however, quite mundane. What I'm wondering at the moment, is what a good design current for the continuity tester is. I'm actually going to be measuring the resistance of the igniter rather than simply checking for a non-infinite resistance, so higher currents would be better... one doesn't want the continuity check to trigger a launch however! I haven't worked with any igniters that would be in any danger with a current of 5mA ( even the Quest Q2G2s are okay there ), so I'm thinking that would be a good place to start. The question is, does anyone see any problem with a current around 5mA continuous for continuity check? ( although... I'm really more likely to used pulsed sampling with a low duty-cycle in any case )

Martin Jay McKee

Most launchers use a LED for indicating continuity and most LED and Piezo buzzers work at about 20mA. I see no problem with 5 mA.

Number one, the flash drive safety key scares me even if you can convince yourself that it meets NFPA requirements.

Why? Software Kills: Therac-25.


I am using a test current of 1mA which is plenty as the gain on the IA is only 11.

Thanks for the thoughts on currents, both of you. I guess I'll just be comfortable with 5mA being safe and figure it out later. That is really the very upper end of the range that I was looking at, and I should be able to get a resistance resolution of 1mohm with even less, so I'm not worried. I just wanted so other thoughts on where the line is.

I can appreciate that any wireless system or even just any software-in-the-loop system has a number of failure modes. I do not see it as an insurmountable problem, however, but rather one that needs to be approached great care and consideration. A flash-drive safety key falls into the same category. First, I feel it's important to describe what the system is "not" trying to be. It is not supposed to even pretend to be security. Any copy of the same thumb drive would work just as well. What the key "is", is a way to signal the control computer that it is in an unsafe state. Honestly, a specialized dongle would be preferable. It would even be possible ( all it would require is a USB enabled microcontroller and a connector ). I'd rather not go to that length, however. And I don't believe that it's necessary.

The software, in any safety critical system, needs to be designed for safety at multiple levels and it needs to be designed to be both pessimistic and in such a way that it will fail safely. Removing the thumb drive, or in any way changing the "key" file, would cause the system to go to a "safe" state. Actually getting a key "insert" message ( and thus allowing the system to go unsafe ) would be much more difficult. The system would have to check the key file for internal continuity and for a match to the launch controller.

The key, however, would not be the only level of safety. A defined launch control order would be enforced at the software level and the control machine being out of communication with the pad for any length of time would immediately safe the pad ( there would be constant "heartbeat" messages ). At the pad, any deviation from the defined launch pattern would also cause the system to go into a safe state. At this level, all of the system is software based. There would be another layer, however, of hardware safety systems that would enforce a fixed pattern. The hardware would possess two separately controlled switches that, moreover, would have to be actuated in a defined sequence otherwise the hardware would go into a locked, safe mode ( resettable by a proper "reset" process of course ).

One thing that I cannot argue is that the design, as it stands, is incompatible with a strict reading of NFPA1127 on point 4.13.2 as it does not, strictly, have a removable interlock that is physically in series with the launch switch. At the bottom level of hardware, however, there IS an interlock switch in series with the launch switch that would be directly dependent on a removable interlock. Is that playing games with words? Probably. But, that doesn't mean that the system would be any less safe -- even if I can only use it in my backyard ( about 1000 acres worth... ).

In the end, I can take the computer entirely out of the loop if I want, but I simply don't see that as necessary. Software is one the most complicated thing that humanity has ever created. It is easy to do it wrong -- with disastrous consequences. Still, I've seen LPRs launch unexpectedly because of low-current ignitors. I've also seen standard two switch launch controllers fail with one or both switches closed when all looks just fine. These were cheap Estes controllers, yes, but lack of software does not a bulletproof system make. Every system has the potential for being unsafe. The question is how you deal with that possibility. For myself ( and maybe that's because I'm a computer scientist by trade ) I am willing to accept that software is able to be made reliable enough to be entrusted with my life ( if I didn't, I wouldn't fly ). And, in such a limited scope, and given no time limit, I am perfectly comfortable with being able to design and test a system to the point where it can be shown to meet the same strict requirements myself. Of course, you mileage may vary.

Cheers,
Martin Jay McKee

martinjaymckee said:

And, in such a limited scope, and given no time limit, I am perfectly comfortable with being able to design and test a system to the point where it can be shown to meet the same strict requirements myself. Of course, you mileage may vary.

Click to expand...

Besides proving that your code is correct, you also have to show that the operating system code is correct. On two different systems. That present a moving target.

Good luck with that.

Any updates to this? Very cool idea.

I've been working on a flight computer recently. It's more immediately useful to me and it's an easier goal, at the moment. I have been rather concerned with some of the questions asked above -- regarding how to ensure its safety. I have been thinking recently, that I will simply start by building a freestanding launch-pad data acquisition system, play with that for a while, and work from there.

I do particularly love the idea of a wireless launch system. I'm acutely aware of safety concerns with that though.

I'm still working on it, just slowly.

Martin Jay McKee