[Craig Turner] wrote in to tell us about the wireless fireworks controller he just finished building. It has eight total channels and offers the kind of safety features we like to see when working with explosives.
The image above details the launcher side of the project. The project box houses an Arduino which is powered by a 9V battery. To enable this base station the key lying on top of the project box must be inserted and turned to the on position. To the left is the 12V battery which is used to supply the igniters via a set of eight relays. In the demo video after the break [Craig] is using nichrome wire to demonstrate, but we’ve even see projects that actually burn up resistors to light the fireworks.
The system uses RF12 wireless modules to communicate with the control panel. That also has an Arduino, along with a number pad. After switching on the power the operator must enter a PIN code before the system will allow any of the fireworks to be launched.
Nice. A good addition would be a way to remotely connect the main igniter power – what happens if the software goes awry and fires all the igniters as soon as the 9v battery is connected? The relay outputs seem to be directly controlled by the arduino pins – seems easy to glitch (especially if the 9v battery is low!). Wouldn’t need to be complex – a time delay relay (http://www.allaboutcircuits.com/vol_4/chpt_5/3.html) could be inserted in series between the 12v battery and the rest of the system. So it would be:
1) Connect 9v battery.
2) Connect 12v battery system (with time delay relay integrated).
3) Arm the system with key.
4) Press a toggle button to energize the time delay relay (starting the countdown).
5) Run :)
6) Proceed with the remote panel as usual.
This way even if your software has bugs you’d be far away by the time things start launching.
Why used a special more expensive relay? Why not have a power switch (DPST) that switches both the 9v and 12v at the same time, and the key switch just the 12v? Still the same requirement of having to switch one first, but a bit cheaper / easier.
The thing the relay buys you is that you’re far away when the 12v igniter power supply gets enabled, to avoid a worst-case scenario. A DPST switch would connect the 12v while you were still at the base station, which I’m trying to avoid here. Another option would be to hack up a simple R-C constant time delay circuit, but sometimes where failure can result in injury it’s best to use a known reliable system. A commercial time delay relay fits this, AFAIK.
i made one of these i few years back. i always ran into the problem on having to use two power sources. but i found that the best way to do it was to use a flash cap and a relay.
Actually I really like the flashcap approach. Main power source can’t set things off, and the charging of the cap provides a built-in time-constant, assuming the caps have resistors to bleed off charge relatively quickly.
You don’t necessarily need a relay to trigger this circuit. A reasonably rated SCR or IGBT (look at the pulse ratings) can easily trigger the pulse discharge through the bridgewire. You can also use a pair of gas discharge tubes to effect a trigger for this fire set, although this configuration is patented.
There really needs to be some kind of safety feature in case of code error. This thing uses a separate relay to turn on power, but it’s done through the SAME PROCESS.
There should be some kind of secondary circuitry to control the safety relay, maybe a couple of analog comparators, resistor, capacitor and PWM output from the µC to limit the risk of a general code fault triggering the safety.
Also this build is missing a continuity tester which is important for the opposite reason, to make sure you don’t screw up that expensive fireworks display.
Nice, I’m gonna steal the idea of needing the micro to d/a a specific voltage for it to work. Personally I’ve used a set of spare IOs and a series of ANDs and inverters to set up a “magic key” that must be generated by the micro, but that project had many spare IOs to waste.
Nice work, but can you make of these ? http://epicfireworks.com/blog/2011/07/the-epic-fireworks-rocket-launcher-taking-rocket-launching-racks-to-the-nth-degree/
That is awesome and very practical. I might make a mini-version!
Best of luck Craig. Let us all know how you get on :)
Nice but have you considered using bluetooth communication and a smartphone as the remote ?
Class 1 bluetooth devices have range of 100m. While most smartphones are class 2 devices (10m range) you still get some extra range. Quoted from wikipedia -> “In most cases the effective range of Class 2 devices is extended if they connect to a Class 1 transceiver, compared to a pure Class 2 network. This is accomplished by the higher sensitivity and transmission power of Class 1 devices.” …. and tested empirically by me
I built something similar, although not nearly as elegant and polished.. Mine has 24 channels, and is controlled via WiFi with an XBEE form factor WiFi module and has a built-in web-page to trigger the channels.. My biggest problem is that with the “high voltage” (which is really just a 9v in my case) connected to the output side of the relays, somehow it is inducing noise into the 74595 shift registers I have controlling the outputs, and the relays just start firing randomly… not a good feature for such a device!!! Luckily I haven’t tested it with anything more than Estes model rocket igniters yet, so no harm done. SO.. In this one, do you control the output relays directly with the arduino digital output pins, or are you going out through some kind of shift register or other intermediary to increase port count??
Very well done..
Hi Guys,
thanks for all the constructive feedback. Note duely taken of extra safety features required. Cheers, Craig
Thanks Craig for sharing with us!
Use of relays for this application is generally a no-no: The problem is that being a mechanical device, the relay can be triggered by a mechanical force. There are reported instances of relay-based firing systems setting off all cues at once when the controller was dropped, or when the ‘blast’ from the first cue firing created an impulse which caused every other relay to bounce closed. Solid state is better.
You may want to consider beefing up your safety architecture. I may be wrong, but it sounds as if all of your safety is coming from the micro right now. That’s not very safe, mainly because it’s susceptible to single point failures and an ignition device is safety critical. A good reference for safety critical design in energetics initiation would be MIL-STD-1316E, which is distro A (public release) and available here: http://www.assistdocs.com/search/document_details.cfm?ident_number=36251&StartRow=1&PaginatorPageNumber=1&doc_number=1316&status_all=ON&search_method=BASIC
Basically put, all military initiation systems have a two-interrupt architecture. You either have to have two mechanical locks (like on the old mechanical fuzes) or two electrical energy interrupters. There is also typically a third input, to set off the device. This is dirt simple to implement on your system, with a PMOS and NMOS interrupting the arming energy. You can then fire the individual igniters based on a number of appropriately sized NMOS switches discharging a cap through them. Pretty standard stuff at that point, really.
On top of this, I would suggest making the control of these switches based on discrete logic and timers. You can enforce your power-up sequence here, making one switch active when you plug in the first battery and the second active when you plug in the second battery. Voltage supervisors can give you a little bit of a timeout window, but I would seriously suggest delaying for a period of time (20 seconds, maybe) based on a LTC-6994 timerblock before you arm the igniters. This will give you time to get out of harms way before you arm the device.
Keep in mind that you want to avoid single-point failures arming the device. It’s not fun to lose fingers or get injured in some other way.
I feel as if I need to amplify my previous comment.
I’ve been looking at your safety architecture, and I’ve come to the conclusion that you have NO safety built into the device as presented on your blog. This makes the system much more dangerous, as you think that you have safety built in whereas in reality you do not have any safety features whatsoever.
I will cone out and say this: initiation is post safety. It doesn’t matter if you have a lockout on your trigger, if the initiator is always live, then it is unsafe! You need to build your safety into your arming mechanism.
Now, the US military, along with most other militaries, requires at least TWO actions be qualified prior to arming any explosives. This is why hand grenades have both jungle clips and cotter pins… you need to have two separate actions done before the device can arm! Now, a grenade is armed mechanically (striker held down by the spoon), but you still need this for electronic systems.
I can’t stress how important building safety into your system is… you don’t want to injure yourself. This is actually why I am commenting on this (I rarely comment on HaD), I feel pretty strongly that there is a good chance that this could end up killing someone. There’s a reason why the military has such stringent safety regulations, and those regulations are written in the blood of less careful or less lucky men. (look up the fire on the USS Forrestal, one example of a horrible tragedy leading to an increase in the safety of ordnance)
Your safety architecture doesn’t have to be all that complex. It’s not as if you’re trying to get this past military safety boards, right? That having bewen said, I see some definite improvements, and I will list them as follows:
1 You’re plugging in your arming energy battery. This is a great place to put one of your safety devices. I would suggest a window timer to qualify the battery voltage. A LT-6700 would do (fairly simple too) to implement a window comparator. I would put this into a microprocessor reset device to give a time of, or say a hundred milliseconds or so. This will screen out spurious noise on the comparator. When the signal gets through the reset, I would latch that in as the upper static signal (little logic D-FF would be great here), and switch on a static PMOS switch on the high side of your firesets.
You’re using an arming key currently, I would use that as my second environment check. Again, I would put it through a reset circuit to debounce the switch, then I would check the sequence. Mainly, I would check to see that the switch was NOT closed when the arming power was applied. This is fairly easy to do in logic. Then I would feed it into the LTC6994 timerblock, configured for a delay of around 30 seconds or so. When the timer expired, I would switch on a static NMOS switch on the lower side of your firesets. I would also include, in this lower static logic, a way of remotely disarming the device. Say, an AND gate that is inline with the lower static switch that you could strobe the clock input of a D-FF to remotely disarm the device. I would especially rig it so that you could not re-arm the device until you remove arming power from the device.
Keep in mind that this is really rough, basically me sitting at my keyboard and pouring out my thoughts on the subject. This is not the word of god, but it is based on my (limited, I will grant you) experience in designing safety critical arming and firing systems used with explosives.
In addition, I like your fireset design, but it can be improved. Relays are always an option for triggering your device, and have several benefits. They are large and have problems with switch bounce (unless you get mercury wetted relays, but those are expensive). I would suggest swapping your relays with a single high current rated NMOS switch. They’re cheap, and much smaller than the relay. I personally have used devices rated for several tens of amps in a package the size of an SOIC-8, which would be more than enough to trigger your bridgewire igniters. Coupled with some logic, you can greatly expand your capabilities for launching fireworks with a device similar in concept to this one.