How To Build A Wireless Launch Controller

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
I can see several single point failure modes that would result in an energized output. With no warning unless you tap the clips together.

1) RLY1 contacts shorted. A not uncommon failure mode.
2) Q1 fails energizing RLY1
3) The Arduino fails turning on Q1.



At the bare minimum there should be an audible warning if the relay is closed. Better would be to include that and remove the single point failure modes.

The simplest being to have the relay switch the high side when the arm key switch on the controller is enabled. Then use a low Rds(on) FET to switch the low side. You might need a FET driver to fully enhance it. (The MIC5018 is my favorite.)

In addition a pad side safe/arm switch that disconnects the igniter outputs from the electronics is a very good idea. (DARS has had good results with 20A DPDT toggle switches.) Otherwise this system is totally dependent on the software operating correctly. Proving software correctness (not only what you write but in the Arduino libraries and in the XBee) is hard.

The keyswitch is wasted as it serves no useful purpose.

Then to the point of driving the high side...
I am attaching a modified schematic to try and capture your thoughts...

View attachment Launch Pad_Control Shield Alt.pdf
 
Proving software correctness (not only what you write but in the Arduino libraries and in the XBee) is hard.
That was one motivation for suggesting doing away with the Arduino and letting the XBee do everything (though it assumes that the people at Digi know what they're doing). That said, it's not very complex code, although it's amazing how simple code can have complicated and unexpected errors...

I'd be a little more concerned about the power-up behavior of the XBee and the Arduino. One hopes that the XBee would never ever drive an output during power-up, but extensive searches of the datasheet failed to find an explicit statement to that effect. Likewise for the AVR in the Arduino, although that datasheet is a lot longer.
 
I agree with David's assessment of what we can see of the circuit so far. I know Dave's background as an EE with decades of experience. My professional background is in my LinkedIn page (see my sig below). I don't know Dan Fox's background. But, I appreciate his willingness to share his design and get some feedback.

Here's my non-wireless simple launch circuit that incorporates much of the safety features David mentioned. I've shared this on the web many times. At least 10,000 launches have been done based on this design over the past 20+ years. Adding a simple/secure wireless link in between could be done without introducing too many additional failure modes. XBee + Arduinos + libraries + control software does not make a simple wireless link, but it's accessible to hobbyists without professional EE background.

Link: View attachment relayer.pdf

Some requirements that are met with this (non-wireless) design:
* Shorting a connector cannot activate the relay.
* There is a physical disconnect to safe the pad.
* There is a physical disconnect to safe the controller.
* Autoreset thermal breaker to protect wiring if there are shorted leads.
* If the relay is stuck closed for any reason, there is an alarm.
* No MOSFETs to fail, or be susceptible to RF flooding.
* Continuity at both sides (~5mA test current, could be less with an added opamp).
 
I spent 38 years designing test equipment and in product systems for several automotive and automotive electronics companies.
I am the designer of the Wilson F/x launch system for 17 years and hold an Amateur Extra license.
I don't claim to know everything but I try to stay active in helping people learn.
 
That was one motivation for suggesting doing away with the Arduino and letting the XBee do everything (though it assumes that the people at Digi know what they're doing). That said, it's not very complex code, although it's amazing how simple code can have complicated and unexpected errors...

I'd be a little more concerned about the power-up behavior of the XBee and the Arduino. One hopes that the XBee would never ever drive an output during power-up, but extensive searches of the datasheet failed to find an explicit statement to that effect. Likewise for the AVR in the Arduino, although that datasheet is a lot longer.

Arduino ATMEGA328P I/O pins are configured as inputs on boot, so they'll be at whatever state your pullup or pulldown resistors have them. The only exception that I've seen is the D13 pin... it glitches on startup, probably because it's used as part of the internal bootloader handshake.
 
I agree with David's assessment of what we can see of the circuit so far. I know Dave's background as an EE with decades of experience. My professional background is in my LinkedIn page (see my sig below). I don't know Dan Fox's background. But, I appreciate his willingness to share his design and get some feedback.

Here's my non-wireless simple launch circuit that incorporates much of the safety features David mentioned. I've shared this on the web many times. At least 10,000 launches have been done based on this design over the past 20+ years. Adding a simple/secure wireless link in between could be done without introducing too many additional failure modes. XBee + Arduinos + libraries + control software does not make a simple wireless link, but it's accessible to hobbyists without professional EE background.

Link: View attachment 324599

Some requirements that are met with this (non-wireless) design:
* Shorting a connector cannot activate the relay.
* There is a physical disconnect to safe the pad.
* There is a physical disconnect to safe the controller.
* Autoreset thermal breaker to protect wiring if there are shorted leads.
* If the relay is stuck closed for any reason, there is an alarm.
* No MOSFETs to fail, or be susceptible to RF flooding.
* Continuity at both sides (~5mA test current, could be less with an added opamp).

You might want to check the terminal designations on your relay it seems from the diagram they might be mis-labeled. NC should be NO and NO should be NC.
 
I spent 38 years designing test equipment and in product systems for several automotive and automotive electronics companies.
I am the designer of the Wilson F/x launch system for 17 years and hold an Amateur Extra license.
I don't claim to know everything but I try to stay active in helping people learn.

Thanks, Dan. Good to know. And it's much appreciated that you are here, open to review and suggestions.

I used to design telemetry systems for NASA, including critical squib-firing circuits for mission events. I've also design mixed-mode RF/analog/digital/software for life-critical medical products and military systems.

Now that we are mixing together help for individual hobbyists with a commercial venture, some of us may be more reluctant to help for free. ;)
 
Thanks, Dan. Good to know. And it's much appreciated that you are here, open to review and suggestions.

I used to design telemetry systems for NASA, including critical squib-firing circuits for mission events. I've also design mixed-mode RF/analog/digital/software for life-critical medical products and military systems.

Now that we are mixing together help for individual hobbyists with a commercial venture, some of us may be more reluctant to help for free. ;)

I am not getting paid for this project, it is just something I feel can help folks who are new to electronics and are interested in launch systems get a start.
I am putting together a "systems mech" to show how one could use the proposed Arduino and Shield to make a safe system. Hopefully sometime today I will get time to put it together and post it here.
 
I agree with David's assessment of what we can see of the circuit so far. I know Dave's background as an EE with decades of experience. My professional background is in my LinkedIn page (see my sig below). I don't know Dan Fox's background. But, I appreciate his willingness to share his design and get some feedback.

Here's my non-wireless simple launch circuit that incorporates much of the safety features David mentioned. I've shared this on the web many times. At least 10,000 launches have been done based on this design over the past 20+ years. Adding a simple/secure wireless link in between could be done without introducing too many additional failure modes. XBee + Arduinos + libraries + control software does not make a simple wireless link, but it's accessible to hobbyists without professional EE background.

Link: View attachment 324599

Some requirements that are met with this (non-wireless) design:
* Shorting a connector cannot activate the relay.
* There is a physical disconnect to safe the pad.
* There is a physical disconnect to safe the controller.
* Autoreset thermal breaker to protect wiring if there are shorted leads.
* If the relay is stuck closed for any reason, there is an alarm.
* No MOSFETs to fail, or be susceptible to RF flooding.
* Continuity at both sides (~5mA test current, could be less with an added opamp).



Based on your drawing, here is the same basic mech for the pad using the shield....

View attachment DIY PAD SYS MECH.pdf
 
I don't understand it at all.

That was not the expected response.....
if we look at the shield schematic as a system block, ( the item on the left labeled "DIY Shield") the other components are attached to it to make a PAD box. The Shield was intended to be part of a pad box, not the whole pad box. It will need to be connected to the outside world (buzzers, LEDs, push buttons), however if you wanted to connect it with the disconnect switch and the "shorted relay" warning, the diagram shows how to do that.
Does that help?
 
That was not the expected response.....
if we look at the shield schematic as a system block, ( the item on the left labeled "DIY Shield") the other components are attached to it to make a PAD box. The Shield was intended to be part of a pad box, not the whole pad box. It will need to be connected to the outside world (buzzers, LEDs, push buttons), however if you wanted to connect it with the disconnect switch and the "shorted relay" warning, the diagram shows how to do that.
Does that help?

I don't see the original functionality, just a bunch of components going off to a block of complexity. The idea is to make things reliable by reducing components and complexity to meet the basic requirements. Once you add more components, it takes time to understand the failure modes and unexpected interactions of each. This goes against the main basic requirement which is Safety.

If you look at my original 1-pad wired launch system, there are 3 wires between the controller and the pad box. Those 3 wires supply two functions: an analog continuity signal (from pad) and a digital launch signal (to pad). To make that a wireless system, all that is needed is a simple wireless link that implements those two functions. If you don't need continuity at the controller, it is one function and a transmit-only link.

The requirements of the basic wireless link could be specified further, for security and other modes of interference, range, licensing restrictions, etc. There are other limitations, such as availability&cost of components, and knowledge of how to design such a link.

A Rube-Goldberg pile of parts is overkill with unnecessary complexity and cost. I guess that was a little snarky, but I *am* trying to help.:smile:
 
Not sure how to respond to this, if you look at your drawing and then look at the systems mech. This will provide your "warning " system for a shorted relay condition that seemed to be a big deal. The shield never was going to have a buzzer or board mounted LEDs, since most if not all units would be built into a box which will require having buttons, buzzers, etc mounted and hooked up to the board.
The simplest version would be not to have the disconnect switch and shorted lead warning. It is optional.
I don't understand why you seem to think everything was going to be put on a 2.5sq in board and hooked up under a rocket...
Be as snarky as you want I just wanted to show how it could be added with little effort.
 
Not sure how to respond to this, if you look at your drawing and then look at the systems mech. This will provide your "warning " system for a shorted relay condition that seemed to be a big deal. The shield never was going to have a buzzer or board mounted LEDs, since most if not all units would be built into a box which will require having buttons, buzzers, etc mounted and hooked up to the board.
The simplest version would be not to have the disconnect switch and shorted lead warning. It is optional.
I don't understand why you seem to think everything was going to be put on a 2.5sq in board and hooked up under a rocket...
Be as snarky as you want I just wanted to show how it could be added with little effort.

There are very good reasons for each safety feature I've recommended. This is based on experience flying HPR since 1991, and building many launch controllers (as well as military and aerospace systems). It is based on specific incidents where people have had large motor go off while hooking up igniters or arming pad boxes.

1) You have to have a disconnect at the pad box. Disconnecting the battery is one option. A switch is more likely to be used as part of the arming process.

2) Relays fail. Especially those that someone randomly purchases for a hobby project, beyond the control of a commercial product. An audible warning is simple and cheap and does not require any electronics or software.

3) Too many connectors and control paths allow for misconnections. There must be no combination that causes the pad to apply unexpected current through the igniter.

4) Power sequencing of electronics, especially microcontrollers, is always susceptible to unknown states on outputs before software is in full control. The electronics must survive the transient of battery removal (or low battery, or a reset) without firing the pad.

5) Software, especially magic free libraries with hobby-level boards, is difficult to qualify.

That's enough. I'm repeating myself and nobody is listening. :eek:
 
There are very good reasons for each safety feature I've recommended. This is based on experience flying HPR since 1991, and building many launch controllers (as well as military and aerospace systems). It is based on specific incidents where people have had large motor go off while hooking up igniters or arming pad boxes.

1) You have to have a disconnect at the pad box. Disconnecting the battery is one option. A switch is more likely to be used as part of the arming process.

2) Relays fail. Especially those that someone randomly purchases for a hobby project, beyond the control of a commercial product. An audible warning is simple and cheap and does not require any electronics or software.

3) Too many connectors and control paths allow for misconnections. There must be no combination that causes the pad to apply unexpected current through the igniter.

4) Power sequencing of electronics, especially microcontrollers, is always susceptible to unknown states on outputs before software is in full control. The electronics must survive the transient of battery removal (or low battery, or a reset) without firing the pad.

5) Software, especially magic free libraries with hobby-level boards, is difficult to qualify.

That's enough. I'm repeating myself and nobody is listening. :eek:

1. The drawing I gave you has a disconnect at the pad box. The disconnect disconnects power to the relay and as such the pad.

2. I agree relays can fail. I included in the drawing a buzzer that will sound if the contact is made and the relay is active, when the disconnect is open.

3. the connections between the battery through the breaker, then to the switch to the relay (in my case a FASTON connector is the same as yours.

4. The disconnect does not power down the controller, it disables the relay from providing power to the pad connections.

5. I am not trying to force you to use magic free libraries with hobby-level boards. My entire effort (apparently to my detriment) was to answer the question posed by the first person on the list:
"Does anyone have plans/suggestions for building/buying a one pad wireless launch controller with a minimum range of 1000 feet? I do fairly well at soldering and electronics, as long as it's not SMT "

Yes it uses an Arduino, but I guess that was mentioned along the way by others. The board seems to be quite simple and I think the libraries I am using are not out of the line for a project of this type.

I have not dis-agreed with your ideas, I was simply trying show how you can implement them in this instance.

I am going to post the control software in a little while, then if anyone is interested in pursuing this project they are welcome to send me a private email requesting further information on getting the boards, or the artwork.

For me I will never post to this site again.

Sorry for not having a Dr as my surname




 
1. The drawing I gave you has a disconnect at the pad box. The disconnect disconnects power to the relay and as such the pad.

2. I agree relays can fail. I included in the drawing a buzzer that will sound if the contact is made and the relay is active, when the disconnect is open.

3. the connections between the battery through the breaker, then to the switch to the relay (in my case a FASTON connector is the same as yours.

4. The disconnect does not power down the controller, it disables the relay from providing power to the pad connections.

5. I am not trying to force you to use magic free libraries with hobby-level boards. My entire effort (apparently to my detriment) was to answer the question posed by the first person on the list:
"Does anyone have plans/suggestions for building/buying a one pad wireless launch controller with a minimum range of 1000 feet? I do fairly well at soldering and electronics, as long as it's not SMT "

Yes it uses an Arduino, but I guess that was mentioned along the way by others. The board seems to be quite simple and I think the libraries I am using are not out of the line for a project of this type.

I have not dis-agreed with your ideas, I was simply trying show how you can implement them in this instance.

I am going to post the control software in a little while, then if anyone is interested in pursuing this project they are welcome to send me a private email requesting further information on getting the boards, or the artwork.

For me I will never post to this site again.

Sorry for not having a Dr as my surname

Thanks for your reply. I will look at your latest schematic in more detail to try to find the simple connections you mentioned.

I don't have "Dr." in my name either. Why does that matter anyhow?

Consider that your company turned a hobbyist's thread into a commercial venture to offer a kit. If you didn't want your work to be reviewed and suggestions made, you shouldn't have offered it up in a public forum. On the other hand, I think you *could* make a better product by being here.
 
Thanks for your reply. I will look at your latest schematic in more detail to try to find the simple connections you mentioned.

I don't have "Dr." in my name either. Why does that matter anyhow?

Consider that your company turned a hobbyist's thread into a commercial venture to offer a kit. If you didn't want your work to be reviewed and suggestions made, you shouldn't have offered it up in a public forum. On the other hand, I think you *could* make a better product by being here.


I have been trying to get the "shorted relay warning" integrated into the board. The board itself is quite small especially using thru hole parts and the XBee thrown in. But I think I am getting closer.

Sorry, it was getting a bit frustrated. As to the commercial venture part, this is not intended to make money, just something I was doing to try and answer a question. The kit idea was just something to get more people interested in this part of the hobby.

Yes, I understand about this being a hobby, and in this case for me it really is.

Back to the project...
 
.... The keyswitch is wasted as it serves no useful purpose[/I].

Hello UhClem,

You were doing fine till you got to this last line. I keep seeing guys saying that they don't need a key-switch. Technically you may be correct that you don't need an actual key-switch, but both TRA and NAR REQUIRE (not suggest, not hope to see something like it, but they REQUIRE) a removable interlock on EVERY LAUNCH Control System used in this hobby. A key switch is a very easy and efficient means of meeting that REQUIREMENT.

So fine, that may not mean that you need a fancy KEY-Switch like we use at Wilson F/X. But you sure as shootin' better have something in your launch controller that can be easily removed completely eliminating any possibility of the firing switch from firing an igniter.... excuse me, a motor starter..... ( Lord have mercy I hate trying to be PC. )

Safety First. Without a removable safety interlock no launch control system can be SAFE.

So what do you propose to use instead?

Brad
 
So what do you propose to use instead?

Context is everything and the context here was the pad shield.

I had only commented on the pad shield but looking at the control shield it appears to fail the "removable safety interlock in series with the launch switch" requirement.

The control shield schematic shows the keyswitch being a power switch. While in some abstract sense that is in series with the launch switch, I doubt if the writers of the NFPA model codes were interested in the abstract.
 
The key switch is in series with the launch switch since it provides the power to the switch as well, power to the wireless unit which is completely disabled with the key switch in the off position.
 
Context is everything and the context here was the pad shield.

I had only commented on the pad shield but looking at the control shield it appears to fail the "removable safety interlock in series with the launch switch" requirement.

The control shield schematic shows the keyswitch being a power switch. While in some abstract sense that is in series with the launch switch, I doubt if the writers of the NFPA model codes were interested in the abstract.

Hello David,

In some ways I would agree with you that context really does matter, but the definition of the words that we are using also matters a great deal if not more.

According to the actual definition of an in series circuit, it is one in which the electrical current follows one path as it runs through every component in the circuit.* *These are sometimes called current-coupled or daisy chain-coupled. *Because the current in a series circuit goes through every component in the circuit, there is only one path thru which the current can flow.* A series circuit's main disadvantage or advantage, depending on its intended role in a product's overall design, is that because there is only one path in which its current can flow, opening or breaking a series circuit at any point causes the entire circuit to "open" or stop operating.

Just because one is using a circuit board and digital programming circuits to control analogue functions does not negate the fact that it can be an in-series circuit.* And the design that Dan has created does fit this definition exactly.

So when the NFPA says that we are required to use a removable interlock in series with the firing switch in order to disable the firing switch, the key-switch in Dan’s design does exactly what the NFPA is requiring.* There is nothing abstract about the way that Dan’s design fulfills the NFPA requirements. His design fulfills the requirements as they are actually defined.

Brad
 
Last edited:
Hello David,

In some ways I would agree with you that context really does matter, but the definition of the words that we are using also matters a great deal if not more.

According to the actual definition of an in series circuit, it is one in which the electrical current follows one path as it runs through every component in the circuit.* *These are sometimes called current-coupled or daisy chain-coupled. *Because the current in a series circuit goes through every component in the circuit, there is only one path thru which the current can flow.* A series circuit's main disadvantage or advantage, depending on its intended role in a product's overall design, is that because there is only one path in which its current can flow, opening or breaking a series circuit at any point causes the entire circuit to "open" or stop operating.

Just because one is using a circuit board and digital programming circuits to control analogue functions does not negate the fact that it can be an in-series circuit.* And the design that Dan has created does fit this definition exactly.

So when the NFPA says that we are required to use a removable interlock in series with the firing switch in order to disable the firing switch, the key-switch in Dan’s design does exactly what the NFPA is requiring.* There is nothing abstract about the way that Dan’s design fulfills the NFPA requirements. His design fulfills the requirements as they are actually defined.

Brad

Brad, you could have just said "sorry, David, I was wrong to take your quote out of context". ;-)

If you *really* want to continue with your interpretation of NFPA 1122/1127, and your (seemingly pretentious) novice explanation of a series circuit, one could conclude that all wireless launch controllers are disallowed. Turning off the key switch does not necessarily remove power at the pad. It is no longer a simple circuit, it is a system. Without removing power at the pad with a switch, you are not guaranteeing that there is only one path in which the current can flow.

It is then up to the system design, and not simply the circuit design, to implement the purpose of the "interlock switch". Safety is the overriding intent. All design options should be analyzed to make sure the system is safe. From my professional experience, the component interactions and human factors are not obvious to someone outside the field of systems engineering.

Or, just say a prayer and hope for the best? :duck:
 
I'm not sure why this discussion has become so contentious. Yes, safety is important; nobody wants a motor going off in their face. I appreciate Brad and kc9qzf's efforts to give us more visibility into their commercial products. It's important to distinguish issues of taste ("that's not how I'd do it") from legitimate safety concerns that we can all learn from, and I think we should focus on the latter.
 
Brad, you could have just said "sorry, David, I was wrong to take your quote out of context". ;-)

If you *really* want to continue with your interpretation of NFPA 1122/1127, and your (seemingly pretentious) novice explanation of a series circuit, one could conclude that all wireless launch controllers are disallowed. Turning off the key switch does not necessarily remove power at the pad. It is no longer a simple circuit, it is a system. Without removing power at the pad with a switch, you are not guaranteeing that there is only one path in which the current can flow.

It is then up to the system design, and not simply the circuit design, to implement the purpose of the "interlock switch". Safety is the overriding intent. All design options should be analyzed to make sure the system is safe. From my professional experience, the component interactions and human factors are not obvious to someone outside the field of systems engineering.

Or, just say a prayer and hope for the best? :duck:


I happen to be an engineer with more than 38 years of professional engineering experience which included component interactions, human factors and systems engineering.

I firmly believe this design meets all 4 of the major requirements mentioned in the Tripoli Rocketry Association Safe Launch Practices – April 2017,I. Ignition Systems:
 
And the design that Dan has created does fit this definition exactly.

If there were a hint of a coherent argument here, I might be able to rebut it. But you go from single current path to claiming you meet that definition without any justification. The current doesn't split after the keyswitch? Using your reasoning I could argue that removing the battery meets the requirement.

A system that powers up armed is not safe and it is trivially easy to change the design so that the arm switch is in series with the launch switch. Then you can add arm and disarm commands to the serial data protocol. Since it is so easy, why not do it?

There is nothing in the NFPA model codes that supports your position. You rely on twisting the definition of "series" to fit a circuit with series and parallel paths. If the NFPA had wanted to require a switch in series with the power source, they would have said so. Instead the requirement is that the safety interlock be in series with the launch switch. That seems very clear to me.
 
Here is everything for the Pad Shield part, I will send the controller part later.

View attachment DIY Pad.zip

This is a .zip file which contains a copy of the Arduino software, the parts list and copies of the schematic and the connecting parts. Also included are images of the shield board itself.
If I am missing anything, I am sure you will let me know.
 
If there were a hint of a coherent argument here, I might be able to rebut it. But you go from single current path to claiming you meet that definition without any justification. The current doesn't split after the keyswitch? Using your reasoning I could argue that removing the battery meets the requirement.

A system that powers up armed is not safe and it is trivially easy to change the design so that the arm switch is in series with the launch switch. Then you can add arm and disarm commands to the serial data protocol. Since it is so easy, why not do it?

There is nothing in the NFPA model codes that supports your position. You rely on twisting the definition of "series" to fit a circuit with series and parallel paths. If the NFPA had wanted to require a switch in series with the power source, they would have said so. Instead the requirement is that the safety interlock be in series with the launch switch. That seems very clear to me.


Not into arguments.....sorry

The attached schematic adds the Interlock directly in series with the launch switch. The Launch switch cannot be taken low (active) when closed unless the interlock is active. Otherwise the Launch Switch will remain high regardless of its state. In the software, when the unit is locked (interlock removed) the controller will remain in an idle state. When the Interlock is active, The controller will begin sending out Continuity commands to the Pad. The pad only becomes armed once it starts receiving continuity requests. When the Launch command is sent when the launch switch is pressed (and the interlock is in place),
the relay can be closed. As long as launch commands are being sent the relay will remain closed. When the launch switch is released a reset command is sent and the relay opens, if communications is lost or power to the controller is lost or the receiver fails at the pad, the hardware timer in the pad processor will timeout and open the relay.


Here is a schematic with the Interlock in series with the launch switch. Does that fit your criteria?

View attachment DIY Launch Shield with Interlock to Launch Switch.pdf
 
Last edited:
Does that fit your criteria?
It is not a question of meeting my criteria but meeting the plain meaning of the NFPA requirements.

But that would work although the alarm output looks weird. As near as I can tell it has battery + connected to both sides. PAD+ and GND would do the job.

Or is this a side effect of trying to fit two schematics on a single page?
 
Back
Top