Pulsed continuity test using least IO pins

[mike_au]

I'm working on a firing box, and I'm after some input on how best to do continuity testing.

 

I want to use pulses rather than continuous current. When there is no pulse being send, I want both sides of the ematch to be pulled to the same potential (either high or low, don't care which). I want it to be entirely solid state and, of course, I want to use the least number of IO pins possible and keep the cost down.

 

Added points if the testing can use the uC's voltage supply rather than the firing voltage.

 

I have come up with a couple of ideas, but so far they all require multiple solid state relays (expensive) and/or 3+ IO pins/cue.

 

Any suggestions would be much appreciated.

[Bonny]

Pretty much most of what you said is beyond me. From what I've seen in firimg systems, the test circuit is either resisted or whatever to only allow enough juice to light a light and say the circuit is OK.

On my own box, I test each ematch ahead of time and hope for the best at show time... not a great plan, but I have some confidence in my work...that will undoubtably let me down one day.

[Arthur]

Pro ematches pop at 500ma and take about 20milli seconds so your pulses will have to be a LOT shorter than that.

 

It's more normal for test current to be limited to LED type currents 2 - 20 ma using either a resistor or a constant current device. Consider using a stepping process to step through the cues while there is a sensing resistor in the power line to the firing ccts.

[mike_au]

Oh I still intend to have something in place to limit the current, I want it pulsed as well.

 

My concerns are that over time even a small current might build up enough heat to cause an early ignition, and that if I just have (for example) constant power connected to my ematch with a transistor/relay preventing it from reaching ground (and a resistor connected before the transistor for testing) I am constantly one failed transistor away from ignition.

 

If I pulse it, and keep both sides of the match at the same potential when not being tested, the firing circuit could fail closed and (hopefully) it still wouldn't fire.

 

I can generate pulses of about 2-3microseconds, depending on the capacitance of the wire I might need to make them a little longer to ensure reliable detection, certainly no more than about 20microseconds though.

[GalFisk]

How many ematches need to be tested? If you have say, 16 ematches, you can connect them to the µC in a 4x4 matrix, with µC outputs horizontally and inputs vertically. Send a pulse to one of four outputs and see if you detect it on all the inputs. A missing pulse means no connection. Use diodes on the outputs to protect the µC from the firing voltage.

If you need to use even less µC I/O pins, there are multiplexing/demultiplexing ICs you can use.

I can draw up a block diagram if you want.

[mike_au]

GalFisk: Thats not a bad idea actually, I'm doing pretty much the same thing to scan the keypad.

 

I didn't think of using it for the testing because I was thinking of continuity testing and firing as being parts of the same thing. Maybe I would be better of making them completely separate.

 

I'll have a play around with that, thank.

[GalFisk]

Why not do the firing in a matrix fashion as well? You'll save on transistors, and the cues will be insulated until both the x and y transistor are conducting. Also, a single transistor shorting out would then at worst result in a cue firing out of order. You can also use some of the same µC output pins for both testing and firing.

Edit: actually, if your µC can switch pins between input and output during runtime, you can get away with using only x+y I/O pins and the same number of transistors fo the testing and firing (plus a couple to switch between test and fire mode).

 

This is my idea: A NPN transistor is connected between V+ and each x line, and controlled by an output pin on the µC. A PNP transistor is connected between each y column and ground, and the base of each goes to an I/O pin on the µC. The emitter is connected to the column.

 

For testing, the y pins are set to input and the firing voltage is disconnected. When an x output is set to 1, this voltage (minus the base-emitter voltage drop of the x and y transistor, ~1.4v total) can be detected on the base of each y transistor. Since a pin in input mode has high resistance, the testing current will be very small and none of the transistors will conduct much (this means testing could actually be done with firing voltage present, but then a failed y transistor would cause the circuit to fire).

 

For firing, the y pins are set high and changed to outputs, and firing voltage applied. Firing any cue consists of setting an x pin high and an y pin low.

 

Use bits or whole of this idea as you please

[mike_au]

Why not do the firing in a matrix fashion as well?

 

That is a really cool idea. That will save on IO pins and reduce the component count. I like the testing using leakage trick too, that is quite neat.

 

I'm just waiting on some double sided board so I can etch the controller and free up my big breadboard for the receiver.

 

Thanks a lot

[Richtee]

That is a really cool idea. That will save on IO pins and reduce the component count. I like the testing using leakage trick too, that is quite neat.

 

I'm just waiting on some double sided board so I can etch the controller and free up my big breadboard for the receiver.

 

Thanks a lot

I'm curious why a pulsed system has you so enamoured? Are there advantages I don't realize? I mean I know NOTHING about firing systems, but a bit of electronics. Seems yer computerizing the flush toilet here.

 

Or I'm just missing something. Would not be the first time.

[mike_au]

It doesn't have massive benefits, I certainly wouldn't be telling everyone that they should be implementing it on their existing systems, but I am designing a wireless system from scratch and it is just one more thing to make it that little bit safer. The chances of a continuous 1mA triggering an ematch is tiny, but the chances of a 10usec pulse at 1mA triggering it is even less.

 

Being wireless, it is already computerized and using GalFisk's design no additional hardware is required (in actual fact, less hardware is required compared to continuous continuity testing I would need separate current limiting resistors and separate inputs on the controller).

[Richtee]

Being wireless, it is already computerized and using GalFisk's design no additional hardware is required

 

Hmm what are the pertainant posts here? Interesting. Soo.. you are depending on a wireless system to link data to a program showing continuity and allowing firing from a laptop? I just have an inherent mistrust of wireless in any life safety application. Altho, I do use wireless med alert pendants for some customers. Not as dangerous as a pyro system in case of a false however. I'm more worried that I don't GET a valid signal, of course.

Edited July 29, 2008 by Richtee

[mike_au]

Not wireless as in 802.11 and no computers (well no big ones). Both ends are going to be PIC microcontrollers communicating over a 915Mhz FSK radio.

 

I am also a little wary of wireless, but being in Oz where fireworks aren't technically legal the ability to pack up quickly is fairly important. The other options are to either abandon large amounts of wire, or be standing around rolling it up if/when anyone comes to investigate.

 

I'm taking some precautions but if you can think of anything I'm missing I would appreciate your input.

 

So far I have:

 

The drone (which is what I'm calling the bit near the mortar) listens for a 1 byte preamble, at which point it starts a timer just long enough for 4 bytes to arrive. If it doesn't get the full 4 bytes by the time the timer runs out, it throws away everything it has received and goes back to waiting for another preamble.

 

The fourth byte is a checksum, so if all four do arrive before the timer, they are first verified against the checksum (and again disposed of if they don't match).

 

Once they have been verified the first byte is checked against a list of valid commands (report status, arm, fire, disarm, abort) any command that isn't recognised is considered to be abort (that way, in the unlikely event that noise results in a valid preamble, followed by a valid packet with a valid checksum, it would still have a 253 in 256 chance of either disarming or aborting the drone).

 

The middle two bytes are data, in the case of the fire command they specify which cue to fire (only one cue can be specified at a time, any more and the command is interpreted as "disarm"), the other commands don't have any data so the data bytes are filled with a constant value that is (at the moment) ignored.

 

For the first 35 seconds after power up, only the report status command is accepted any others are ignored (this is so that even with someone deliberately faking a fire command, everyone will be at a reasonable distance before anything will go off). After the power up delay, the drone defaults to "disarmed" where only the report status, arm and abort commands are accepted. After it receives the arm command, it will then accept all other commands. Obviously the disarm command puts it back to ignoring the fire command and abort puts it into disarm mode and then shuts down (ignoring all other commands until it is reset).

 

The remote (i.e. the hand held part) sends out status requests every 2 seconds when idle. If the drone doesn't hear from the remote for more than 6 seconds, it goes into disarm mode. A further 30 seconds and it goes into abort mode. The remote also has a key lock that when removed will send a "disarm" command and then prevent it from sending anything other than "request status" commands.

 

Both remote and drone have coloured LEDs to indicate their current state at a distance. The drone has a watchdog timer that will reset it in the event that it crashes.

 

Obviously there are possible improvements, I would like to use encryption instead of just plaintext and checksums but the processors just aren't up to it, frequency hopping is also a good idea, but I'm not quite up to implementing it yet (also my radios are relatively slow to change frequency), those two data bytes should be verified and any sign of corruption in them should trigger a disarm/abort, the remote could also be set to automatically send an abort command if excess data corruption is detected (at the moment it just displays a notification on the screen) and I could have dual redundant processors at each end (but I have no idea how to do that).

 

All in all, I think I have erred on the side of caution where possible. Suggestions for improvement are always welcome.

[Richtee]

Not wireless as in 802.11 and no computers (well no big ones). Both ends are going to be PIC microcontrollers communicating over a 915Mhz FSK radio.

All in all, I think I have erred on the side of caution where possible. Suggestions for improvement are always welcome.

 

Well, Hmm. 20 years ago I'd have dug into this... LOL! Well, assuming the tech was there. Now... I just don't have the time nor inclination to educate myself to give any worthwhile input. Sounds like you have covered alot of bases for sure. And yeah..frequency rolling Tx-Rx is cool, but as you say, there's alot more to falsifying a fire command than just grabbing the freq.

 

I'll be watching... carry on, soldier! :{)

[GalFisk]

Glad you like my idea. Your communicaiton scheme looks well thought out. Let me know how everything turns out, and if you have any questions just ask.

You could probably use the vacant data bytes for some sort of simple encryption/obfuscation, such as sending a value with the "arm" command to be xor'd with any subsequent firing data (not very secure, ideally the pic shouldn't accept identical looking "arm" or "fire" commands twice). Probably unneccessary but maybe interesting to implement.

[Arthur]

I've seen Pyromate P-45 units sitting there with the continuity LEDs lit for 15 - 40 minutes with no problem. in fact from http://www.pyromate.com/Basics-of-Electrical-Firing.htm and down the page they quote two igniter types as 200mA no fire current. Most LED based ccts use 10 - 20 ma!

 

However there is perhaps something to be gained from having a single continuity switch cycling through all the cues AND sending the results back to the control station. The UK Firebywire system already does this in the full computer controlled mode. The computer steps through all available cues and records the ones with igniters on and lists them on the screen AND compares the list with the list of cues to fire. If any differences show up then they are flagged another colour on the PC screen! - TAkes time if you have gor close to the 256 x 64 basic system limit though!

[Boomer]

You can make the system as secure as you want, with triple checking each command and double-redundancy CRC test .... but all this would not make me feel much safer when working around the mortar stand with the PIC powered up.

 

I've seen some very strange things happen in 20 years of EE work (explosive..... no shit, I mean electrical engineering ), and you already mentioned both areas of trouble already: 1) EMC issues and 2) system bugs (usually software based). Let me just point out some things:

 

1) EMC (Electro-Magnetic Compatibility)

 

EMC can mean random noise that gets coupled into the antenna (or tracks, cables...) from things like car-ignition, other radio equipment (garage door openers, CB, cell phones...), EMP from lightning, menstruating girlfriends, explosively pumped flux compression generators, and nuclear blasts.

 

This danger can be reduced to almost nil with CRC checksums, redundant transmission etc. Just a figure, compared to malfunction of redundant transmission of only six bytes plus 8-bit CRCs, winning the million dollar lottery twice in consecutive weeks is a million times more likely. A few more lines of code and it's a million trillions times safer than driving only ten feet in a car. I would surely trust my life to such a software.

 

And that's the problem, the security is in the *code*. And we speak of random noise (or random code on a close frequency etc). Of all the processor systems I have seen go crazy in the EMC test chamber (with up to 4000V surge/burst, 8-16kV ESD and 30V/M AM), it was one of these:

 

- Processor worked but display showed nonsense/Cyrillic

- Processor worked but analog inputs read nonsense

- Processor executed random code, skipped lines, mixed up variables, jumped to reset in mid-procedure ....

 

The latter is what we want to avoid but this CANNOT be done in software. The very failure mode is random jumps of program counter, stack and/or data pointer. If I had lost a digit for every time my or a colleague's PIC did nonsense under stress, I would have gone through my fingers *and* toes twice each year.

 

The ONLY thing that helps here is hardware. There's dedicated encryption codecs cast in silicon: For entry systems, smart cards, cash machines, and at least one is in every nuclear warhead since 1970.

Or think about one RF front end with two PICs decoding in parallel, shifting their data into shift registers, with the outputs going to two lines of two series-connected mosfets, plus XORing the registers to an abort FET (diode-hard-wired to the gates).

 

Considering a mosfet's gate oxide thickness is measured in microns, you might think about a second safety that's old-fashioned mechanical - a relay switching the supply to the FETs. And a 5.1V Z-diode at each gate won't hurt and costs two cent. It's bad enough we men often bet our financial independence on 50µm of latex rubber!

 

You might even have a very *simple*, but completely *separate* system for this purpose. What about a garage door opener, or a remote door bell, that gets activated *only* during a fire command, with it's receiver switching said relay?

 

 

2. System bugs (usually software based)

 

These become more likely the more complex the code gets. A comma for a semicolon brought down one of the Apollo flights IIRC. I've seen boards that randomly switched a load every few hours, caused by a subroutine's execution time being input-dependent. Once in a while it took a microsecond too long and a timer interrupt got missed....

 

Or the electronic thermostat that worked perfectly, controlling a big compressor for cooling (whatever). Perfect that is, only if it started below 25.5 degree C. If it came down from above, at 25.6/25.5 degree it missed a carry flag, which inverted the hysteresis, which in turn made the contactor go 'click-clack-click-clack...' at 4 Hz. The machine literally jumped around the factory floor....

 

One more thing, remember 'brown-out'. While PICs are quite robust EMC-wise, as a fully static design they do random shit if the voltage dips below min working voltage, then recovers. This could be a shorted e-match forcing the supply down. If the PIC has no internal BOD/R (brown-out detect/reset), use an external reset IC or at least a transistor + divider. Plus, do use the watchdog timer, ideally resetting it via the frequent status requests (e.g. the 16F946 has a *software* configurable WDT with up to 4.75 minutes, and lots of pins (ports A-G) for 2$). Guess I don't have to tell you to do that only once, and only in the main loop....

[mike_au]

I realise nothing is perfect and the idea is to always reduce the risks (I got a big lecture about therac25 and the like on my first day at uni). In this project alone there have been a few cases where everything looks fine until some combination of things line up (thank god for simulators, I really need to get an ICD box).

 

I don't intend to be anywhere near the mortars while the PIC is running. The receiver will be powered up as the last step just before leaving the rack and shut down as the first step when approaching it, I'm going to have some sort of connector (DB25?) that can be pulled so the receiver can be removed if any testing/maintenance/etc is required.

 

The watchdog timer is disabled at the moment (for testing) but will be put back in before the gear gets used. My PICs do have brownout detection, I haven't looked at it too much, but I'll certainly add it. I had considered redundant transmissions (Something like "Fire 1", "Did you say Fire 1", "Yes, Fire 1") but I haven't tried to do it yet. That might not make it into the first model, but it will certainly be in v2.

 

Reading on pyrouniverse about some of the issues they have had with relays, I would prefer to stick with solid state where possible. Your suggestion of two PICs decoding in parallel sounds good, my problem is that it is a two way link, so sending data back might get a bit complicated. Having said that, having a second PIC that doesn't talk back, but listens and controls an "arm" switch and maybe has the ability to reset/switch off the primary PIC shouldn't be too hard to rig up.

 

Thanks for your suggestions, I'm copying all of this into my notes for when my boards (finally) arrive and I have room to really get to work on the receiver. Hopefully by the time it is all up and running it will be at least as safe as commercial systems, if not more so.

[Boomer]

The relay idea comes from a safety critical project. Gas heaters with electronic control must be "intrinsically safe". The agencies don't allow solid state with no extra protection, and software is considered to ALWAYS malfunction. Good luck designing something they let pass, and that the customer is still willing to pay for.

 

Back when I did 'fireworks' with electric ignition, I always had a long cable with a 9V battery, and the battery went back into my coat pocket before approaching the test stand again. I would not have trusted any electronics, considering the 'stars' coming from my shells were usually steel, traveling at 10000 feet per second.

[mike_au]

I have seen quite a few write ups about relays malfunctioning from the shock of the launches, some people have suggested mounting them sideways so that the shock is perpendicular to the movement of the arm but that seems like a bit of a dodgy fix, others have said it's not an issue if you use expensive relays. If I were to go with a relay in it, is there anything I can do (other than buying a really good one) to reduce the chances of the shock messing it up?

 

I guess since it is there to disarm the device rather than fire the cues, a failure in the relay wouldn't be that big a deal compared to the boxes that rely on the relays to do the actual firing, but I'm more of a software person and I'm biased against all those ugly bits of the computer that actually exist, especially the bits that move.

[Boomer]

I'd use a big relay with plenty of contact distance, and wire it so that once it closes it locks itself in that position magnetically. One with 3 sets of contacts, two for disabling the firing on both polarities, one to keep itself magnetised. This is meant if it's a safety that normally does nothing.

 

It's a good idea not to fix the receiver box to the mortar stand but have it on a short cable on the ground. Putting something over it (old jacket etc) or wrapping it somehow can protect it in case something goes wrong (flowerpot, shell upside down...). I've had my VoD-meter one step from the column of HE that was tested, and it did not mind as long as it had cover (cable around tree or through window).

 

The separate door bell that activates for every firing command would use solid state, i.e. a mosfet in series to the ones doing the actual firing. Using photovoltaic optocouplers saves you lots of separate supply voltages.

[mike_au]

Galfisk: I have run into a slight issue (or more of a concern really) trying to implement your matrix firing idea.

 

I put a high on the base of the NPN and as long as there is continuity a voltage appears on the base of the PNP, so far so good. The problem arises when there is no continuity, the base of the PNP has no bias and the uC pin is left floating. Obviously a pull down resistor is the solution, and obviously pulling the base of the PNP low turns it permanently on. To solve this I have put another resistor between the base of the PNP and the emitter of the "Master arm" NPN (which is of course turned off during testing). This way when the master arm NPN is on, the two resistors act as a voltage divider and ~2V appears at the base of the PNPs, thus pulling them safely high. If the master arm is off, the top resistor isn't connected to anything and the bottom one acts as a pull down.

 

My concern is that using this setup during testing I am (sort of) only one component away from firing. The NPN is turned on by the testing signal, the PNP is turned on by the pulldown resistor, only the master arm transistor prevents firing current from reaching the ignitor. Obviously if the master arm were to fail closed then the PNP would instantly be pulled high, so it still wouldn't fire, I'm just wondering if I'm missing a better solution.

 

Any suggestions?

[mike_au]

OK, I've decided the above issue isn't that big a deal, I can measure the state of the PNPs while none of the NPNs are turned on, that would quickly show up a master arm failure and I can abort the testing.

 

However, I think this one is a deal breaker when it comes to using a single IO pin to control the PNP transistors and do continuity testing :/

 

When I have the 12v firing voltage reaching the emitter on the PNP transistors, I need to pull the base up to 12v to inhibit firing. My PIC is running at 3.2v, so it can't supply that itself, it can't even tolerate more than 3.5v on it's IO pins. I'm at a loss as to how to work around this.

 

I have a feeling I'm going to have to switch to a bigger uC and use seperate pins for controlling the PNP transistor (via another transistor) and measuring the voltage present on the base (via a voltage divider).

[GalFisk]

If the resistance of the pulldown resistor is high enough, the transistor won't conduct to any meaningful degree.

How about instead of pulling the base up on the PNP to prevent firing, you keep the I/O pins as input and therefore high resistance. To fire, you change the relevant pin to output and send a 0 to the pin.

Edited August 29, 2008 by GalFisk

[mike_au]

I did have a play around with setting the pin to an input, and I did get it working better than when I was trying to set it high, but the data sheet says not to exceed VDD+0.3V on any IO pin. While it didn't seem to cause any problems in my brief testing, this thing is going to be controlling explosives, so I think I should play it by the book.

 

It's not that big a deal now anyway, I've borrowed an ICD2 programmer off a mate making it easier to work with the larger devices and I'm considering using the analogue inputs to get a rough idea of the ignitor's resistance (hopefully I will be able to tell the difference between an ignitor and a short circuit).

[GalFisk]

Ah yes, you're right, feeding the µC voltages above VDD can lead to funny issues such as latchup.

Nice to hear you're making progress, using analog inputs to check for shorts is an interesting idea.