## Continuity/Current-Sense Circuit Optimization

23 posts / 0 new
Author
Message

So I've got a model rocketry related project that I'm working on, and I'm looking to ( if possible ) simplify some of the circuitry that needs to go on the board.  Basically, I'm designing a flight computer that will have two or three igniter outputs as well as a high-speed telemetry output channel ( that will later be connected to a Raspberry Pi, collecting video and acting as a data-logger ).  Most of the design is coming together almost naturally, but the igniter channels are giving me some trouble.  The difficulty is that they really need to do several things, and the circuitry is getting more complicated than I really like.

Firstly, the igniter needs to be "fired."  This is accomplished by an N-Channel MOSFET to ground.  Secondly, the igniter needs to be checked for continuity ( resistance below, roughly, 100 ohms ).  This check needs to be able to be turned off such that no current flows through the igniter.  Finally, I want to be able to do an order-of-magnitude estimate of the current through the igniter while it is being fired so that the switch can be disabled in a short-circuit condition.  The circuit I'm considering at the moment is as follows:

Following the right-hand side, current flows from Vin through the igniter and down, through the bottom MOSFET to "fire" the system.  To check continuity, the "Continuity Mode" input is brought high ( switching the second MOSFET on and creating a voltage divider.  This voltage divider allows a small current ( around 1.5mA and maximum Vin ) to flow through the igniter.  This pulls the voltage divider up nearly to Vin and results in a voltage being buffered and passed through to the "sense" output.  These two work fairly simply.  Things are more interesting when "Continuity Mode" is brought high.  In this case, assuming that there is continuity through the igniter, the input to the buffer is pulled up to Vin.  Thus, the buffer attempts to pull "sense" up to Vin.  The "sense" output is wired to an ADC on a 3.3v microcontroller though -- hence the resistor and diode on the buffer output.  By putting the feedback after the resistor, the buffer will work to pull that point up to Vin but it will do so with a current limit ( again, less than 2mA ), and be clamped by the diode to ~0.4v above the microcontroller rail ( which should be safe ).  In this mode, no current flows through the igniter ( because the divider is disconnected and the op-amp is high impedance ).  But, when the fire MOSFET is closed, the on resistance of the MOSFET acts a current sense resistor.  The voltage across the MOSFET is buffered ( undivided, as the voltage divider is disconnected ) directly to the ADC.  With a 45mOhm MOSFET, this will give me plenty of voltage ( at 10A ) for my 12-bit ADC to read, without causing thermal troubles, after all, the switches will only be closed for a couple of seconds each flight.

Anyhow, there's the theory.  In the last couple of years, I've gotten much better at my analog design, but I know I still tend to design in a very piecemeal fashion -- adding components to solve problems as they arise.  I was just wondering if anyone saw any obvious changes that would allow for complete current shutoff through the igniter, continuity check, and rough current sensing ( without overvolting my ADC ), with fewer components, in less board space, cheaper ( all of the above! ) or just in a completely different way.  I'm hoping, at the moment, to place three of these circuits on my final board, so even a small improvement would be helpful.

Cheers,

Martin Jay McKee

As with most things in engineering, the answer is an unabashed, "It depends."

Martin,

I don't agree with your description of how this circuit works.

when "Continuity Mode" is brought high.  In this case, assuming that there is continuity through the igniter, the input to the buffer is pulled up to Vin.

No. the opamp +input gets pulled to Vin*(2K2)/(2k2+6k8+Rigniter). Ignoring the mosfet Rds.

In the idle mode (both mosfets OFF) the opamp's + input is pulled high to Vin via the igniter and the 6k8.

As a safety measure, both gates should be pulled to ground via individual resistors. Otherwise they are floating and liable to turn on the mosfet(s) via any induced voltage on your presumably long wires to the gates. Cell phones, etc.

Last year, or was it the year before, we had a similar request which after a couple of designs were presented (including one of mine), it was decided to delete them all on the grounds of safety and limited liability.

Cheers,

Ross

Ross McKenzie ValuSoft Melbourne Australia

Sorry, no solution to offer at the present, but a couple of thoughts.

Ross already mentioned that the NFets need 10K pull down resistors, to hold them off during power up of the circuitry, when the micro has not yet set the pins to the desired states.

If the igniter wires short out, then the Fire NFet is switching a direct short circuit from Vcc to ground.

That will likely exceed the NFet's Imax and fry the NFet.

I think it is often prudent to put a switch / relay in the igniter fire circuit that "arms" the system, once power has been applied.

It is an extra safeguard against power on startup transient conditions mis-firing the igniter.

Remember a cold nichrome wire has very little resistance until it heats up.

Select your NFets wisely.

JC

I'd re-arrange the circuit so that the mosfet can be tested as well. You'd need a resistor in the vcc leg that gets bypassed when everything checks ok. You could even get tricky and use a AC technique to measure the actual resistance.

First, Ross... Yes, you said exactly what I meant to say.  I must be tired.  The whole point of having that divider there, of course, is to scale the battery voltage down to the ADC range.  Given a maximum input of 13v ( 3s lipo ), the specified resistors would take it down to around 3.2v.  It's when the divider is not grounded, that it gets pulled all the way up to the battery voltage.

Actually, the "real" schematics ( on real paper... at the moment ), has the pull-downs on the gates of the fire MOSFETS.  The continuity channel doesn't really need the pull-down because the voltage divider doesn't allow enough current to do anything with the igniter, it just may start-up in the wrong mode for a split second.  No worries.  This isn't, actually, my first dance with driving igniters in this way.  I've done a number of ground based systems.  Some have used relays, some MOSFETS, one, both.  For this design, given that it's an onboard system, I'm just trying to strip the circuit down more.  I also am considering whether I want a real topside arm switch.  It's nice for safety ( though not typical for flight computers, like this one, which aren't powered on until they are on the pad ), and it's not that difficult.  It doesn't even have to be on for continuity testing if there's a resistor across it.  The resistor can be sized to limit current to a safe amount that is well below the triggering point of the igniter ( 10mA is safe ), but still larger than the needed test value ( 1mA is sufficient ).

The two parallel courses I'm looking at for the switching FETS are massively oversided switches ( designed with a safety factor of ~8:1 peak, and thermally rated for 2x continuous  ), or to use Smart MOSFETS in the switching path.  Give their nice features like built-in current limiting and thermal fold-back, they make things lots safer without actually making it much more complicated.  They aren't cheap though.  The typical way that shorts are handled with commercial HPR ( high-powered rocketry ) flight computers, is to use a batter that has a high enough internal resistance that it can't kill the MOSFETS... I don't really like that idea.  I want it to be failsafe against anything that might reasonably go wrong.  I shouldn't have to cripple the power source, just to protect the switches.

I wish everything seemed as cut and dried as programming.  Somehow, I seem to go through more refactorings of hardware ( even before building something ) than I could ever dream of with the software I put in to run it.

Cheers,

Martin Jay McKee

As with most things in engineering, the answer is an unabashed, "It depends."

OK, so I sometimes get into trouble when I post an UNTESTED circuit, but give this one some thought:

It eliminates the op-amp.

It uses an ADC input on the micro.

I added a small series resistor to roughly match the igniter resistance in series with it.

I assume with a 13 V Vfire you will still insure the igniter works.

I assume your NFet can handle the short circuited igniter current, if not, pick a value that works to satisfy both conditions.

If the Arm/Safety switch is open, (Safe Mode), then the ADC voltage is 0 V, (tied low by the 10K resistor in the Voltage monitoring resistor divider).

(Or the igniter is open circuited, (not connected, burned out, etc).

If the Arm/Safety switch is closed, then:

ADC = 3 V means you have igniter conductivity is good. (Igniter is present, connected, good)

ADC = 0 V means that the igniter is open circuited, missing, not connected, burned out

During "Fire", (your spec!):

ADC = about 1.5 V or lower as the igniter heats up, igniter is good

ADC = 3 V, igniter is short circuited

ADC = 0 igniter has finished, is now burned out

The "extra" 100 ohm resistor in series with the igniter lets you determine if the igniter is good or shorted out during the fire state, as the junction is either at Vfire or at Vfire / 2.

This voltage changes as the igniter heats up.

The 33k & 10K simply scale the Vfire to the ADC's range, and limit the igniter current to 0.3 mA once the Arm/Safety switch is armed.

Don't forget to check the power rating on the 100 ohm resistor.

Be sure to check the igniter capability with the "extra" 100 ohm resistor in series with it.

Be sure to check the NFet's Imax, and built in current protection capability.

Good luck with your project!

Photos expected!

JC

Edit:  Forgot to label the NFet Gate pull down resistor as 10K.

Last Edited: Tue. Mar 1, 2016 - 06:04 PM

JC

I like your idea, but a couple of things I see, the nichrome wire ignitor(sp?)  will only be at most a few ohms (1-2 ohms) at most cold and your 100 ohm series resister will prevent it from heating.

Perhaps lower the series resistor to 0.1 ohm, gives you ~ 1 peak volt out during ignition.

Jim

Edit: after looking up current sense resistors (digikey), you may have to go to 0.05 ohm flameproof with a lower peak output voltage

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get \$5 free gold/silver https://www.onegold.com/join/713...

Last Edited: Tue. Mar 1, 2016 - 06:57 PM

Hi Jim,

Yup, consider it conceptual, the details remain to be worked out.

I used Martin's 100 ohm igniter value from the original post, but I agree, it could be much lower.

When one uses the ADC to monitor that status, one has a lot of leeway in the value.

If one goes very low with the resistor, then one probably needs to use a smart NFet, with built-in current monitoring, so as not to fry the device.

A spec sheet for the igniters would make the design easier!

JC

So I've done some more research ( I've got to learn not to depend upon my memory... my ECC doesn't always work... ).  Anyhow, a typical Estes igniter is typically around 0.8 ohms, some larger HPR igniters are down approaching 0.5ohms.  Going the other way, Quest igniters are somewhat less than 2 ohms and some ultra-low current jobs are around 5 ohms.  Taking into account wiring, 10 ohms is a very safe estimate ( so... only an order of magnitude off... geez.... ).  I will say that the original circuit was not intended to measure the igniter during fire -- it would measure the voltage drop across the MOSFET, to estimate current through the igniter.  I love the minimalistic design of the circuit though.

I've spent the day designing myself into a corner ( simplicity wise ).  I'll not go through much explanation at the moment ( as it's HIGHLY likely to change entirely ), but my current "B" design is this:

It is divided into two blocks, a common section and a per-channel section.  The common section contains an arm switch, and the continuity mode switch.  It also provides a buffered reference level ( constrained to the 3.3v ) rail.  The per-channel section includes a Smart FET ( likely an ST VN70x0 series device ), a non-inverting amplifier that is offset by the common section reference, and a couple of resistors.  The Vx output gives a voltage proportional to Vref and a gained up version of the voltage drop across the paralleled 10k and igniter.  Vref, Vx, and Vin ( a scaled down version, of course ) are run to ADCs and together are used to calculate the resistance of the igniter ( possible because all of the impedances in the circuit are known except for the igniter resistance.

The advantage of this circuit is that it will allow calculation of resistances down to 0.5 ohms and below ( though not with very good resolution ).  That means that it could warn about shorts or over resistance.  Also, both the upper and lower switch ( Fire and Arm ) are safely testable in circuit, with or without an igniter connected ( though, of course, testing one of the switches puts the system in a position that only a single switch is needed to fire it.

Obviously, this is not a simple design, but, I realized that I do have something else I can add to my specification.  It should never be necessary to check ( or activate ) more than one channel at a time.  As such, the amplifier on the left of the schematic can be driven by signals routed through a multiplexer.  Only the high-side switch and two resistors ( 10k and 27k ) would need to be duplicated for every channel.  I'm not sure I like the added complexity, but it's actually growing on me; and, I love the fact that this is a safer implementation than my first.  It would be nicely protected against short-circuits ( by the upper switch ), and would require a two-step process to trigger ignition.  Currently, the values are just approximations.  I haven't yet looked at biasing currents, output voltage range, or other possible gotchas, but, I may.

Thanks all for the ideas thus far.  I'm starting to feel that my next big push needs to be toward refining the required specs just a bit more.

Martin Jay McKee

As with most things in engineering, the answer is an unabashed, "It depends."

This is a killer article:

https://engineering.purdue.edu/e...

If you put a charge pump on the ARM fet, this means the cpu needs to keep toggling the port pin in order for the system to be in a state to fire. I haven't analysed the circuit carefully, but I'd think you'd be able to determine if the ignitor is open,short or good and whether the fets are operational. So you should be able to tolerate one defect but be able to detect all. Nothing like having good diagnostics.

I need to take another look at the circuit myself, but yes, I think I should be able to detect defects all the various components I may have.  Additionally, I was already thinking about what is needed from a safety/reliability standpoint further up the control chain.  I like the idea of a charge pump on the ARM switch.  There certainly needs to be a way to do a hard disable while the system is on the pad, but that's relatively easy.  It's even more important to think about what a sorts of issues the code might run into.  It wouldn't be too difficult for errant code to simply flip two pins high -- sustaining a toggle, or synchronizing multiple on/off cycles ( separated by conditionals ) is much more likely to be failsafe.

The more work I do, the more I love diagnostics.  Although the purpose of this system is -- first and foremost -- to provide a vehicle for collecting inertial data, I think I'll go back to an older plan I had for a similar system and record the diagnostic state in the data logs right from the start.  Anything to make later troubleshooting easier.  Luckily, the first dozen or more flights will be only data collection ( no ignition firing required ).  Still, it can be programmed for that, and I can watch what it "wants" to do as an adjunct to the data collection from those flights.  Then, I'll be in a much better position to trust the ignition system at a later date.

@Kartman

Yes, that's an excellent article ( series ).  I've read it before, but thanks for the reminder.  This is just the sort of project that deserves another read!

DocJC requested pictures.  This project's going to take me longer than the first flush estimate ( since that didn't include adding failsafe igniter outputs! ).  But I'll certainly oblige with notes on the development and pictures as I make progress.

Cheers,

Martin Jay McKee

As with most things in engineering, the answer is an unabashed, "It depends."

mckeemj wrote:

...detect defects all the various components I may have.

Don't overlook the fact that as you add more components, so as to help you detect more defects, the chance of defects goes up and you'll need more components to detect those defects in components which are there to detect defects in the original components. And then....

mckeemj wrote:

It wouldn't be too difficult for errant code to simply flip two pins high -- sustaining a toggle, or synchronizing multiple on/off cycles...

I think you'd be surprised at how difficult that scenario is. Your code is running from flash and not ram. Code randomly rewriting itself just doesn't happen.

A significant part of my work comes from designing firing systems for proximate pyro; I've posted a picture of a system in action somewhere here before now. I can't help feeling that you're over-thinking this. Safety often comes from simplicity.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

Code randomly rewriting itself just doesn't happen.

No, but errors in reading flash, errors in decoding instructions, bit errors in SRAM and GP registers, and internal logic sequencing errors are all not-unlikely outcomes of an environmental upset.  Such an upset could simply be the result of an electrostatic charge delivered to the device, or a strong EM field such as from a high-power commercial wireless handset.  Such handsets are often used on construction sites, film and television locations, and other location-based events (like rocketry conventions!).  You don't want your rocket to fire prematurely just because somebody pressed 'talk' on a nearby walkie.  A film production company I've worked with complained that their home-brew LED 'bounce', a mylar blanket covered in LED tape, driven by a simple commercial 555-based 24V dimmer module, would 'freak out' whenever the AD stood nearby while radioing 'quiet on set!'

Mind you, proper hardware design is the first and best line of defence against these kinds of environmental upsets, and EMC testing should come before any live-fire testing.  But software support of safety systems is also important, even if only in a diagnostic role during development and testing, and later during deployment.

A significant part of my work comes from designing firing systems for proximate pyro

I bow to your expertise.  Really.  That stuff scares me whenever I have to deal with it, which is infrequently, thank goodness.

I've posted a picture of a system in action somewhere here before now.

If you dig it up, I'd be interested!

 "Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience.  Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast.  Cheap.  Good.  Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl]

joeymorin wrote:

If you dig it up, I'd be interested!

Here you go. AVRs at work here...

https://www.avrfreaks.net/comment...

I do seem to get to work on some half-decent shows. No AVRs on this one, PICs all the way...

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

Gott'em. So... Guy Fawkes did use a delay timer!

Ross McKenzie ValuSoft Melbourne Australia

Had to look it up.  Three Queens.  Impressive!

 "Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience.  Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast.  Cheap.  Good.  Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl]

I appreciate the input from people with ( much ) more experience in this than I.  It's a learning curve to be sure.

Also, I seem to design by the maxim that, "too much is never enough."  Finding the simplest -- most direct -- design seems to be a challenge for me.

As to Brian's comment about errant code flipping two pins being unlikely... I wasn't referring to code that happened to go wonky just randomly.  I was referring to uncaught logical errors.  To be perfectly honest, I'd be much less worried about safety on the "trigger end" if this wasn't all getting attached to a fairly complicated AHRS ( Attitude-Heading Reference System ) / Data-Logging / Flight Control front end.  If I add a second MOSFET "for safety" and then have code that looks like,

```if( its_safe ) {
arm();
fire();
}```

there's only one check.  Adding the second MOSFET -- from the standpoint of the software -- didn't add anything in the way of safety.  There are lots of ways around that sort of thing.  If you are willing to trust a microcontroller to never do anything stupid ( that the code doesn't tell it to do ), then you just make the code perfect.  Well..., as perfect as you can.  What I'm more interested in doing, however, is adding enough external logic that it will monitor the system to the point that it is able to see when the system is doing something "wrong."  For instance, if the correct order is enable/arm/fire, and the hardware sees ( either because that's what the controller did, or because there were errors elsewhere, enable/fire/arm, the system should lock-out the action and raise a flag for the error.  As things stand, I'm expecting to do the bench testing and design then do, perhaps, a dozen test flights.  It is entirely my expectation that I wouldn't see any errors in any of these flights.  It would be over-designed for the use.

Then again, as it ends up with larger engines to deal with, and the possibility of on-board radio telemetry, and other experiments that it will be in charge of controlling.... I'm comfortable with the need to handle the complexity.  And besides, I saw a quote somewhere that said that, "the creation of a new product is an evolutionary process."  I expect quite a bit more give-and-take of complexity increase and reduction before I reach a destination.  But it's been an interesting journey so far! ( of course, I really should be getting PCBs ordered in the next week.... )

Martin Jay McKee

As with most things in engineering, the answer is an unabashed, "It depends."

I think anyone working on a "mission critical system" and its software should always take a minute to recall the Therac-25 incident.

JC

Therac-25 and some other prominent software "oops's" feature prominently in my mind very often.  But, I must say.  What I'm working on isn't that critical.  Everything would have to line up badly for someone to die as a result, and even then there would likely be several "failures" outside the system that I'm working on.  If I can make a demonstrable improvement in safety over the status quo, I'll be happy with that.

Martin Jay McKee

As with most things in engineering, the answer is an unabashed, "It depends."

If you think about current polarity in the two wire cable that goes to the rocket + igniter, you can measure a possible cable short circuit without involving the igniter.

Using a diode in series with the igniter, and a resistor in parallel with the diode.   By this way you can safely measure current on the cable without compromising the igniter.

I designed the following launching circuit, you need to follow the steps 1 to 8.

There are just one LM339 chip, it is 14 pins, 4 circuits inside, see the datasheet.

This LM339 comparator will give you the perfect maximum current on FET, based on R2, R9 and R5 values.  R2 you may keep 0.1 as usual, change the value of R9 or R2 to allow different maximum currents, if you are afraid of a short circuit in the cable to fry the mosfet. Increase the value of R5 to achieve higher currents.

The other 3 LM339 circuits, are used to compare voltage.  The first (u5) compare voltage of the battery and light the green led if the battery is higher than 11V.  You can adjust R15 (560 ohms) for lower value in order for the led lit with higher values of the battery.  You can use a 1k ohms trimpot to adjust the green led to lit with 12V or more... making sure the battery is fully charged for launching.

LM339 U6 and U7 compare voltages returning from measuring the cable and the igniter.  Observe that when the DPDT switch is as in the circuit, 12V is blocked by the diode close to the igniter, this reversed current is forced to go via the 1k resistor.  There are two 1k resistor in this circuit, and a third to ground on the return path.  So, measuring the voltage on the cable, it will be 8V on the forward current, 4V on the return path.  In real this voltage is a little bit lower due other resistors on board.  Those voltages are compared with the voltage divider made by R17, R18 and R19, the relative voltage is on the circuit.  The LM339 will lit the green leds if the voltages are correct, it means, no short on cable, igniter in order.  If there is a shorting cable, Led 7 will not lit.  If the cable is open, Led 6 will not lit.  Simple as that.

Pins "Integrity 1", and "Integrity 2", means exactly that with 1.9V, that you can read with your microcontroller.

Pin "100mV/A" means current reading, exactly the current that goes via Mosfet to igniter.  This is the dropoff over the 0.1 ohms resistor, that also control the maximum current.

Your microcontroller can read this voltage and know exactly what is the current over the igniter.

Last is the launch sequence 7 and 8.

3V3HoldLaunching means that while the microcontroller holds 3V3 on this pin (high), launch will not happens.

So, sequence 7 needs the microcontroller to drop this voltage to zero, and go for sequence 8, lift 3V3 on the pin 3V3LAUNCH.

12 miliseconds later, the capacitor C1 charges with 350mV and the LM339 opens the open collector output, allowing resistor R7 to charge the Mosfet gate, and current will flow through igniter.

But this only will happen if there is correct voltage over the cable, this is possible if you flip the DPDT switch 5 and turn on switch 6 first.

So, the sequency is exactly that, 1, 2, 3, 4, 5, 6, 7, 8, where 2, 3, 4, are leds to observe.

I tested this circuit on LTSPICE simulator.

Wagner Lipnharski
Orlando Florida USA

I don't think that is a very safe circuit.

Kartman wrote:
I don't think that is a very safe circuit.

Can you explain why?

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get \$5 free gold/silver https://www.onegold.com/join/713...