Altimeter MOSFET deployment switches turning on when power is applied

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

Adrian A

Well-Known Member
TRF Sponsor
TRF Supporter
Joined
Jan 21, 2009
Messages
3,185
Reaction score
2,912
Location
Lakewood, CO
I have been investigating a report from a user of two deployment ematches igniting instantly when a 3S lipo battery (12.6V) was connected to a Blue Raven altimeter via a screw switch. After looking into possible causes of this event, which did not happen when using the same hardware before or after, I was reminded of a potential failure mode for MOSFETs like those used on the Blue Raven.

The failure mode is called Miller turn-on, or parasitic turn on, or the Miller Effect.

The Blue Raven and other altimeters use a silicon-based solid state switch called an N-channel MOSFET.
1710350433629.png

Here is the data sheet for the one used by the Blue Raven and the previous Raven4 altimeters:
https://www.vishay.com/docs/63233/si5442du.pdf

You can think of the drain of the MOSFET, labeled "D" as the input, where positive voltage is applied. In a common configuration, the terminal "S" is connected to ground. When the gate, labeled "G" is grounded to the same voltage as the source, then the switch stays off and current can't flow from drain to source. But when the gate's voltage is raised high enough above S, then the switch turns on and current can flow from D to S through a small resistance. The gate-to-source voltage at which the current starts to flow is called the threshold voltage. The threshold voltage for the MOSFETs used in the Raven4 and the Blue Raven is 0.4V-0.9V, depending on temperature and part-to-part variation. This is low enough the the altimeter's microcontroller can fully turn on the FET with a 3.6V (Raven4) or 3.0V (Blue Raven) signal applied directly to the gate. One end of the ematch is connected to the battery + and the other end is connected to the Drain terminal of the MOSFET that's on the altimeter. When it's time to fire the charge, the microcontroller applies voltage to the gate, the MOSFET turns on, and one side of the ematch is connected to ground, allowing current to flow through the ematch, which heats up the pyrogen past the ignition temperature.

A more complicated version of the MOSFET schematic is shown below, along with an external resistor Rg that is connected to the MOSFET on the board:
1710352226373.png

Every physical transistor has some very small unintentional capacitors (parallel line symbols) that connect the three terminals. These capacitors are like tiny batteries that can supply absorb or supply current when a voltage is applied to them. They have the effect of preventing fast changes to the voltage across them.

When a battery is connected to the Drain (top) of the MOSFET, the drain terminal goes up to the battery voltage, but the capacitance between the gate and the drain is trying to keep those two terminals at the same voltage, so it also raises the gate voltage. Meanwhile, the capacitance between gate and source is trying to keep those two terminals at the same voltage, so it's pulling the gate down. If the drain voltage is raised instantaneously, then the gate voltage will get raised to a level in between the drain and the source, according to the ratio of the Cgd and Cgs capacitors. Meanwhile, the resistor Rg is pulling the gate voltage down to the source. In the steady-state case, Rg will keep the switch turned off. But for the case of instantaneous application of voltage to the drain, it takes a little bit of time before the charge stored in Cgs can get discharged through Rg. During this time, the gate of the transistor might pulled high enough to go over the MOSFET threshold voltage, and the MOSFET will turn on until the Rg has enough time to pull the gate back down again.

In the case of the MOSFETs used in the Raven4 and the Blue Raven, the Cgd is 115 pF, (Cgd + Cgs) is 1700 pF, and so the gate could get pulled up to about 115/1700, or 7%, of the drain-to-source voltage. When a 1S 4V lipo battery is used, the gate is only pulled up to 0.27V, below the threshold and the switch stays off. But if a 3S lipo battery is used, 7% of 12V is about 0.81V, which can be above the threshold voltage of the MOSFET.

To see if this could really happen on a Raven4 or Blue Raven, and if so how much, I have been doing testing of the MOSFETs on a Blue Raven.


IMG_2574.jpeg

The battery at the bottom is a 550 mAhr, 3S lipo battery, similar to the one that used during the accidental ematch firing. I have one end of an unfired ematch connected to the main terminal of the Blue Raven, and the other end is exposed and can be contacted to the battery wire to instantly apply the battery voltage through the ematch to the output terminal of the Blue Raven. I have test points attached to the main channel MOSFET gate, drain, and source. The Blue Raven has a 25 mOhm shunt between the source and ground, for monitoring the firing current. The test points are monitored at 50 million samples per second by a Saleae Logic 8 pro test equipment.

Here is the result from testing the configuration that most resembles the event that started this investigation:

1710355519303.png

When the battery is connected to the drain terminal (yellow trace), the gate voltage (red) goes up over 1V, and the source voltage (orange) also goes up, indicating that the output switch did briefly turn on. How briefly? Here's a zoom in of that event:

1710355653853.png

The source voltage is measuring the voltage across the current-measuring resistor. The resistor plus the rest of the path adds up to about 35 mOhm, so the peak current was about 6.7 Amps. But it only lasted for a fraction of a microsecond. Ematches typically take hundreds of microseconds to fire, so this one turn-on event probably only heated up the bridge wire around 1% of what's necessary to cause it to fire. In fact, in my test setup where I connected the battery multiple times in multiple ways, I was not able to cause the ematch to fire, despite attempting to make the contact bounce or have multiple contacts. This should not be too surprising, as there are thousands of Raven4 and Blue Raven altimeters in service, and this report was the first time I could recall hearing that an ematch had fired on power-up. The original poster also had used his same hardware setup multiple times for ground tests and flight before he had his accidental firing, and the he did not experience an accidental firing again when he re-tested later. My best guess as to what happened in his case is that the screw switch he was using had a particulary noisy closing, and made dozens or hundreds of contacts during the fraction of a second in which the switch was being closed, enough of them to heat up the bridgewires in both charges to the ignition temperature. The OP is kind enough to ship most of his av-bay configuration back to me, and I'll re-test with his screw switch and wiring when I receive it, to see if I can reproduce a flurry of turn-on events that would be required to ignite the ematch.

Next up: How risky are other configurations?
 
Last edited:
Transient behaviour can be very surprising. I have been testing one of our spectrometers for mains transient behaviour. The transient voltage across the MOV (metal oxide varistor) actually doubled the applied 2kV transient voltage to nearly 4kV, before the MOV turned on and snubbed the surge. Basically it was transmission-line behaviour that doubled the voltage. A pulse sent down a transmission line will double when it hits an open circuit. Interestingly this was all AFTER a large mains inlet filter :shocked: . It is amazing what you find when you look.
 
In some emails with Brandon who had the charges blow, he wrote this: (copied with permission) :

You mentioned a noisy turn-on and it made me remember something. I had a difficult time switching the rotary switch on because of the angle and alignment of the arming hole (blame the structures team....). You'll see when you get our hardware but the switches we use are these ones https://www.apogeerockets.com/index.php?main_page=product_info&products_id=71. (We just use them as SPST's)

They sort of "latch" into place but you have to rotate them for it to "latch". Because I was having trouble with the angle I couldn't get the switch to fully "latch" so it would have been in a "floating?" state for a few seconds where I had it rotated but it wasn't fully latched in either state (on/off). I remember this happened a number of times before I managed to get the angle and give it enough force to make it fully latch into the on position which is when the charges blew.
Having the switch stuck in an intermittent contact situation is exactly the sort of scenario that could cause enough Miller effect transients to add up to enough energy to blow the ematches.

With this additional information, I'm pretty confident that we found the root cause of the incident.
 
Last edited:
I quit using that type switch, I have had few rockets with bad ones in the switch band and just added another as a quick fix. Mine always failed on the ground failing to turn on thankfully.
 
I did some more testing to check out other common configurations.

To review, here is the OP's configuration, with the 12.6V battery powering the electronics and the output together:

1710425330663.png
The ringing you see in is caused by the LC circuit of the wires leading to the input capacitors for the Blue Raven's regulator.

This one is when a 3S battery is connected to the output FET without being connected to the input of the altimeter. This would be the situation if you have a 3S lipo battery powering only the deployment charges, and the altimeter electronics are powered from a separate battery. Without the extra oscillations it does a little better:

1710425578588.png

The next plot is from if the altimeter is powered from a separate battery but it's already on when the battery is applied to the deployment output. The difference here is that the microcontroller is doing its best to pull the gate down to 0V, working in parallel with Rg. I was hoping this would eliminate the Miller transient, but it just reduces it. I think there might be a little too much parasitic inductance on the microcontroller's gate drive line for it to be very effective in holding the gate down on such a fast transient. It does help, though:

1710425732991.png

Finally, if the 12.6V battery is turned on via a solid state magnetic switch, rather than a mechanical contact like a rotary or screw switch (or twist-and-tuck), the Miller transient is further reduced:

1710427079474.png

The next time I redesign the magnetic switch I'll add a gate resistor to slow down the turn-on rate, which should eliminate this entirely.
 

Attachments

  • 1710424671340.png
    1710424671340.png
    302.8 KB · Views: 0
  • 1710425004257.png
    1710425004257.png
    275.8 KB · Views: 0
Great circuit work and writeup here Adrian. An option comes to mind: is adding a discrete 2nF (or so) cap between the FET gate and ground be feasible here? That would give more resilience to any rising drain transients (whatever their source), but drawback is it could slow the FET turn on slightly.
 
Yes, great work tracking this down.

Do have a question:
You recommend either a 1S LiPo (~4V max) or a 9V transistor battery.
Would a 2S LiPo (~8V max) be ok????
This is less than the 9V battery.
I have found that a 2S LiPo can easily fire an igniter.
 
An option comes to mind: is adding a discrete 2nF (or so) cap between the FET gate and ground be feasible here? That would give more resilience to any rising drain transients (whatever their source), but drawback is it could slow the FET turn on slightly.
That is what I was thinking.
 
Great circuit work and writeup here Adrian. An option comes to mind: is adding a discrete 2nF (or so) cap between the FET gate and ground be feasible here? That would give more resilience to any rising drain transients (whatever their source), but drawback is it could slow the FET turn on slightly.
That would help this issue, but it would probably not be compatible with being able to limit the output current by pulse width modulation (PWM) as I'm doing now. Slowing down the FET would directly increase the heat dissipation when it is limiting the current.
 
The CGS/CGD ratio for the MOSFET you're using is about 14 according to your info above. To prevent parasitic turn on, the CGS/CGD ratio should be at least 20, preferably 50. So, 2nf seems like a good value, as @tfischer suggested.

CGD is dependent on VDS so it's understandable that the misfire is dependent on the battery voltage.

Your PWM driver frequency would have to take this into account, of course.
 
Yes, great work tracking this down.

Do have a question:
You recommend either a 1S LiPo (~4V max) or a 9V transistor battery.
Would a 2S LiPo (~8V max) be ok????
This is less than the 9V battery.
I have found that a 2S LiPo can easily fire an igniter.

I have more test results that I will share later, including a 9V battery. I should test the 2S configuration also. And I have some FirstFire igniters on the way so I can do sensitivity testing also.

Am I assuming correctly that the phenomenon can be avoided by using magnetic switches?

Yes. There is is still a single sub-microsecond pulse when the switch turns on, but a magnetic switch won't have the intermittent contact that can cause dozens or hundreds of pulses that I believe caused the OP's ematches to fire.
 
My FirstFire igniters arrived, so I decided to test with a standard small Featherweight 1S cell, in a Power Perch configuration. I used a battery that was at 3.8V, which would represent sitting on the pad for about 3 hours before launching.

Here's the screenshot of the data recorded during the ground test firing, zoomed into the 1 second that the output FET was on:

IMG_2613.png

You can see that the igniter was receiving about 3.5 Amps for the first 0.8 seconds before it opened.

Here's what it looked like during the ground test (video clip trimmed to fit file size limits) :
View attachment RPReplay_Final1710703905.mov

I did the test again with a more fully-charged battery, and the results were similar, though a bit faster, since the initial current was about 3.75 Amps:

IMG_2619.png
 
Looking at the igniter instructions, it calls for 12V but also a minimum of 3 amps. But because the igniter's resistance is a little less than 1 Ohm, a tiny 150 mAhr lipo battery with 3.8V open circuit and 3.1V during the firing can supply 3.4 Amps of current, enough to burn this igniter.

A 12V battery is not required, but a 9V alkaline battery has a lot of internal resistance and may have a hard time firing this igniter reliably, which I suspect is why the instructions call for a 12V car battery, which is way overkill.
 
Am I assuming correctly that the phenomenon can be avoided by using magnetic switches?
It can be reduced.
But if you use Adrians magnetic switch, it turns the whole system ON at the connection of the battery and has to be turned OFF to make it safe. This introduces a secondary problem/ undocumented feature.
 
It can be reduced.
But if you use Adrians magnetic switch, it turns the whole system ON at the connection of the battery and has to be turned OFF to make it safe. This introduces a secondary problem/ undocumented feature.
The ones I use turn on the altimeter only when the magnetic switch is activated, this is with the battery already connected.
 
The ones I use turn on the altimeter only when the magnetic switch is activated, this is with the battery already connected.
At CONNECTION of the BATTERY, the old magnetic switch goes ON. You then have to turn it OFF.
Once the battery is connected and the magnetic switch has been turned OFF, you can turn it ON and OFF normally with a magnet.
The NEW switch does not do this. It stays off at the connection of the battery. From May 2023, ( https://www.rocketryforum.com/threads/new-and-improved-featherweight-magnetic-switch.180159/) But all the original ones do. Of which I have 2.
 
Last edited:
The next time I redesign the magnetic switch I'll add a gate resistor to slow down the turn-on rate, which should eliminate this entirely.
You mean to say you don't already have a gate pull down resistor installed?
That's a standard engineering practice when using mosfets.
 
You mean to say you don't already have a gate pull down resistor installed?
That's a standard engineering practice when using mosfets.
There is already a gate pull-down resistor. (parallel to the gate). I was talking about a gate series resistor to slow down the turn-on time.
 
It can be reduced.
But if you use Adrians magnetic switch, it turns the whole system ON at the connection of the battery and has to be turned OFF to make it safe. This introduces a secondary problem/ undocumented feature.
The magnetic switches being sold currently start out in the off state when connected to the battery.

There have been several implementations over the years, as different parts have become available and others have become obsolete. For the versions that start out on when connected to the battery, safe operation is still simple. Connect the battery and turn the switch off first. This can be done days or weeks ahead of time. Then connect the charges while the altimeter is off.
 
There is already a gate pull-down resistor. (parallel to the gate). I was talking about a gate series resistor to slow down the turn-on time.
Got it.
Also wondering if the output state of the micro could be the culprit if the turn on supply voltage is erratic.
 
Got it.
Also wondering if the output state of the micro could be the culprit if the turn on supply voltage is erratic.
I've seen it and experienced it with my own much more amateurish electronics. Would a lowpass RC filter not be more suitable with filtering out unstable transients to the gate? ie. instead of utilising the FET's capacitance, use a separate cap?

TP
 
The magnetic switches being sold currently start out in the off state when connected to the battery.

There have been several implementations over the years, as different parts have become available and others have become obsolete. For the versions that start out on when connected to the battery, safe operation is still simple. Connect the battery and turn the switch off first. This can be done days or weeks ahead of time. Then connect the charges while the altimeter is off.
It's great you've updated. But how would anyone who has an old switch or has bought a secondhand one know what the old ones do? There is no reference to the development of the switch or previous versions on your website. Or the operation of the old switches.

And I really do not want to connect charges with the battery connected regardless of how safe someone says it is.

I've designed multiple firing systems for special effects over the years. Making sure you know the state of all outputs at power up of all equipment is critical.

When I design stuff for myself I can have a lower level of failsafe. I know what stupid things I'm capable of doing. If you design stuff that other people will use, you've really got to cover a lot more stupidity. Last year some chaps did a firmware upgrade in a hotel room with igniters in. Should the manufacturer have had a subroutine to check no charges were connected before allowing a software update? Maybe. Should all flight computer manufacturers have now implemented that? Yes. (but of course, a new subroutine can create additional havoc) We all know about it, we didn't then. At a minimum, it should be in the documentation. (it is for the manufacturer involved)
It's important to acknowledge issues, and you have here, but the Featherweight website also needs to have that history. Then no-one will be able to say they didn't know. Or that their switch behaves differently to the way it's described on the website.
 
I've seen it and experienced it with my own much more amateurish electronics. Would a lowpass RC filter not be more suitable with filtering out unstable transients to the gate? ie. instead of utilising the FET's capacitance, use a separate cap?

TP
Put 2 FETs in series. Control 1 with your PWM source, single pull down resistor 1M ohm. Control the second with 10n cap in parallel with 100k as a pull down. We then get minimum parasitic capacitance to allow your PWM to go as fast as it can and a safer turn on for the firing FET. But you'd need to make sure you had enough voltage for gate drive voltage.

You can also actually current limit by limiting the gate drive voltage rather than limiting the power by using PWM directly to the gate.
So you could use PWM into a RC circuit to create an average voltage to drive the FET as current limited, rather than full PWM to drive the FET.
These are just a couple of ideas. You'd need to test it in your application and make sure the FET will reliably survive. And you'd probably want to refine this if you were unhappy with the OFF time.
YMMV
Norm
 
You can also actually current limit by limiting the gate drive voltage rather than limiting the power by using PWM directly to the gate.
Yup, I went down that road with a solenoid saver design once ie. using the D>A functionality of the micro to modulate/regulate the current to drive the coil. Didn't work too well for that application (heats the FET up too much with the increased voltage drop across it), but can't see why it wouldn't work for the quick pulse in this application.

TP
 
Yup, I went down that road with a solenoid saver design once ie. using the D>A functionality of the micro to modulate/regulate the current to drive the coil. Didn't work too well for that application (heats the FET up too much with the increased voltage drop across it), but can't see why it wouldn't work for the quick pulse in this application.

TP
If you limit the current at the FET through gate voltage control, the FET will have to dissipate the power. This would be ok for a 1 sec fire command (probably)
For your solenoid driver application, you'd have been better fully driving the FET in PWM mode(not limiting the gate voltage) and having a capacitor across the solenoid to do a basic D-A conversion at the coil and reduce the voltage. ( don't forget a good diode across the coil for back emf) PWM at 100Hz should work well-ish. That will reduce your FET losses. My go-to FET is the IRFZ44N.
50 Volts 50Amps TO220 package. There is also a Logic driven version of it that's happy to be driven by 5v logic. IRFZ44NPBF I can send you down a couple if you want to have a go.
 
Last edited:
Back
Top