Ideas for a new firing system

[chuckufarley]

Hi everybody,

I've been thinking about making a new firing system for a while now. I have a good idea what I want it to do, in general. I was hoping some of you more experienced guys could chime in on what features, or abilities, you like in the systems that you use.

This is what have decided is the minimum of features. :

 

2.4ghz transceivers for communication (xbee style) rated at 1000m range

 

Digital readout of system state, selected cue,selected channel..... On the control unit

 

Continuity indicators on the control unit and the firing unit.

 

Secure, physical, keyed cut off switches on all units

 

Point to mulitpoint communication. (Ability to assign a channel to, and communicate to multiple firing units)

 

Im open to all ideas of things that would be handy to have as features.

Im not planning on having this system sync up to music or anything, but I had thought about adding some simple programming(fire cue #1, wait 6.5 seconds, fire cue #2) or a 'fire all' with a set delay between cues.

 

Small, multiple firing units, or one larger central unit?

 

Thank you,

Edited May 1, 2017 by chuckufarley

[limak]

I have recently found opensource project of professional firing system - http://www.pyrobox.com.pl/index.php/opensource. Everything is written concisely and to the point.

It's a project of computer controlled system with 256 channels, which is multiground type. Each section with 16 channels.

Never tried making this but i think it may be good choice if you're good in electronics. Unfortunately site is not in English but google translator will be your right hand

My choice for simple device which will filfill my needs was cheap 12 cues receiver and transmitter from China (only 12$ with shipping).

I think about making sequencer with arduino soon

Edited May 1, 2017 by limak

[chuckufarley]

Thanks limak. Ill check that out

[Arthur]

Never underestimate the functionality of a bundle of wires. Some people invest a lot of money in a system that they use infrequently.

[Mumbles]

Please keep us updated on what you decide and maybe the build. I for one am very interested in seeing what goes into something like this.

[chuckufarley]

It may be a while before I actually start building anything. Right now I just trying to get ideas of everything I want to do so I can design I board to handle what I need. Then ill get onto the programming part of things.

So far Im going to use (at least to start since I have some on hand) nrf24l01 transceivers, one in the control unit, and one for each firing unit. Im hoping I can just assign a unique Id to each firing unit (say; unit #1= cues 0-15) then broadcast a signal from the control unit with the unit Id and instructions. All the firing units will receive this info packet, but if the Id number doesn't match, that unit will just ignore the packet.

Features Id like at this point (beyond safety lockouts, and secure transmissions) are;

1) multiple firing units with between 8-16 cues on each unit.

2) power capabilities to fire all cues on each unit simultaneously.

3) continuity indicators on the firing, and control units.

4) backlit display on control unit (4 line LCD display for now) showing selected cue, continuity, firing mode...

5) effective range of at least 300 meters (transceivers I have are rated for 1000 meters) in real world conditions.

 

Im open to any and all ideas folks may have on features they like on systems, or features not to waste my time on. Right now Im not building this to sync with music, so Im not worried about split second timing, or storing large amounts of data for a pure-programmed show.

[lloyd]

Chuck,

What about bi-di communications, so the remotes can confirm proper-receipt of a CRC'd firing info packet?

 

It does little good to simply 'broadcast' instructions unless you have some feedback indicating they've been received correctly.

 

(Yeah... I know... you don't have to say it! <grin>)

 

Lloyd

[chuckufarley]

Lloyd. I should have clarified that point, thank you. The units Im using do have that type of bi-directional communication as a default. When a unit receives a packet it sends a confirmation request to the sender, if the info matches, it then implements the commands.