9 replies to this topic

[fred_on_fire]

Hi,

I thought I would start a thread about my GCSE electronics project and how I went about creating a wireless electronic firing system. I am also open to questions if anyone wants advice or help on a project of their own.

I have had a passion for electronics for a few years now (I originally started with wanting to know why computers work and what is inside them) and I am now taking Electronics as one of my GCSEs.

When the time came for me to decide what I was going to do for my coursework project, I thought about doing something that would potentially have a practical use outside school and that I will enjoy making, so the idea of making a firing system came into mind. Just a firing system on its own would probably not make up much of a project so I threw wireless into the equation and a couple of months down the line that is what I have submitted as my coursework – a wireless firing system.

I will now go about explaining how the circuit works. Sorry if you do not understand it but some electronics knowledge is probably required for understanding the circuitry.

The project consists of two parts, the transmitter and receiver. First of all, the transmitter entails a wireless transmission unit (I did not make that but got it online), an oscillator (produces pulses at a set frequency) and a voltage regulator (for the power supply of the transmitter). The oscillator starts sending pulses to the transmitter when the button is held down. The pulses (at 38KHz) will be transmitted over a carrier signal of 433MHz. I have tested this to work over a range or nearly 400m!

The second half of the circuit includes a receiver unit, a PIC microcontroller (to check the pulses being received) and a MOSFET (an electronic switch to supply enough current for the nichrome wire to heat up and ignite the fuse). The PIC checks that the pulses are of the correct frequency and then turns on the MOSFET when all is verified. The power supply I am using to heat up the nichrome wire consists of just 4 AA batteries and that can supply enough current to make the nichrome wire glow yellow/white hot!

The circuit does have a few flaws though and I would not use this system as an actual firing system due to a few safety issues I could imagine, like an accidental firing, but the principle is there! I am currently designing a new system with the two sections communicating to one and other to make sure that that fire signal is validated and that only one transmitter can talk to a receiver unit (with a specific code needed to initiate firing); but GCSE revision is currently taking priority.

You can view photos and schematics of the circuits from the following link 'Pictures and Diagrams'

If anyone has any questions feel free to ask them!


Thanks,
Fred

[Arthur Brown]

Nice project, simply done. It would harden up to a good tool if you redesign it to sit on a PCB neatly with buttons where needed.

read this lot! Posts by JoeRatman are especially well crafted.
http://www.pyrounive...-Firing-Systems

[fred_on_fire]

Thanks, I will have a wade through all those threads! I'm sure there is some very useful stuff in there.

Due to limiataions with GCSE coursework I could not produce the project on a PCB, although I would have liked to. I make my own PCBs and the next incarnation of it I will certainly do on a PCB; they are a lot easier to design, more durable and in most cases smaller! Then I will put the two halves of the project in proper IP68 rated boxes (yes, possibly a bit overkill I know!)

Thanks for your comments,
Fred

[BrightStar]

Nice project. Interesting to hear that you're doing tone recognition in the PIC itself as it saves some quite complex circuitry. Are you familiar with DTMF signalling? It might be an interesting next step:

http://en.wikipedia....uency_signaling

[phildunford]

Good work!

If you intend to take it further to a practical design, do make sure you consider the consequences of all failure modes of all components.

I was feeling very pleased with a design of mine when I suddenly realised that loss of power to one decoder chip would result in 'all fire' on 128 channels! - Not good...

[fred_on_fire]

Thanks BrightStar

I have not seen DTMF signalling before, so thank you for bringing that to my attention. It might be an interesting next step to incorperate that into the project but I was going to go down another route for the comms between the units.

I am going to use two XBee units (proper 2.4GHz transceiver units) and then set up a network between the two. A special code will have to be confirmed to be the same at both ends and the two untis will have to 'handshake' before any action is permitted between the units. This will also stop any other units conneting into the network and firing cues when not wanted.

Also what I want to do when sending data packets between the units is to XOR the data and make sure that the data is sucessfully received and non-corrupted.

Thanks for you comments,
Fred

[fred_on_fire]

Thanks Phil

I will certainly design in failsafe devices for the unexpected events! I certainly do not want any mishaps! In one of my earlier designs, if the receiver was turned on before the transmitter then it would automatically put all the outputs high! Not really what you want!

Thanks for the warning, I do occasionally need reminding that if things like this go wrong then it could all quite literally blow up in your face! Certainly an outcome that I want to prevent at all costs!

Thanks,
Fred

[CCH Concepts]

You’re defiantly on the right track going digital rather than analogue. Although it could be less time consuming recognising the frequency using filters, using micro controllers to handshake is defiantly the way to go, for 100% reliability and safety. Do you have much programming experience? How will you be getting them to shake hands?

[fred_on_fire]

I do not have much programming experience myself but my friend is awesome so I think I might be able to get some help from him!

The XBee units are constantly scanning for other devices and when they discover each other then whey will send each other a code. They will 'handshake' and create a link between themsleves. The handshake itself just consists of the exchange of codes to tell them that the other unit is there and how to communicate to it.

The handshake is standard for XBee units to do themselves.
Here is the XBee manual if you want to have a look.

[CCH Concepts]

I do not have much programming experience myself but my friend is awesome so I think I might be able to get some help from him!

The XBee units are constantly scanning for other devices and when they discover each other then whey will send each other a code. They will 'handshake' and create a link between themsleves. The handshake itself just consists of the exchange of codes to tell them that the other unit is there and how to communicate to it.

The handshake is standard for XBee units to do themselves.
Here is the XBee manual if you want to have a look.

that makes more sence i thought you were saying you were going to design your own device, this would have been very difficult. i have a degree in electronics and i would find it a challenge to design that from ground up.