# Discharging a capacitor through a depletion MOSFET

I´m building a device to remotely operate a solenoid through a data link. That device, which is powered by a 9V battery, has a step-up circuit to raise the battery voltage to +- 160V which, in turn, charges a 330uF capacitor. As soon as a command is received from the base, the capacitor is discharged over the solenoid through a relay.

My concern here is about safety when the shoot is aborted after the capacitor is already charged. I'd like the capacitor to be discharged (not through the solenoid, of course) in a brief time span (let´s say 30s max), to minimize the risk of an accidental shoot in the case of a circuit failure.

An obvious choice would be a bleeding resistor in parallel with the capacitor. But to have it discharged in 30s, its value would be:

$$R = {t \over 5 \times C} \implies R = {30 \over 5 \times 0.00033} \implies R \cong 18,182 \Omega$$

Using a resistor with this value would permanently drain:

$$I = {V \over R} \implies I = {160 \over 18182} \implies I \cong 0.009 A$$

Due to the step-up configuration (which is raising input voltage about 20 times) the input current, in this case, would be $$\ 20 \times 0.009 = 180 mA\$$. That much energy would have to be drained only to "feed" the bleeding resistor. Considering all the other circuit needs, and the fact that the whole device is powered by a 9V battery, that seens a little too much.

My next, not so obvious choice, was to connect the bleeding resistor through the NC terminal of another relay, which should be kept open during the capacitor charge. Naturally, that would be power consuming too, but much less than the bleeding resistor being connected directly to the capacitor. Plus, got the bonus of having it being discharged even quicker because, in this case, I could use even smaller resistors.

In fact, I've assembled a prototype to test this concept and... it failed. Actually, the circuit worked as expected, but a single battery was not enough to power it and I've had to use two batteries in parallel, otherwise, when that additional relay was closed, the voltage supplied dropped so much that the Arduino Nano, which was managing all the fuzz, simply rebooted (forgot to mention his presence before).

Trying to reduce the power drain I disable all the LEDs and adjusted the radio module (a EBYTE LoRa E32-91520T) to the minimum transmission power possible, with no success.

My next choice is to use a solid-state device, instead of the relay. That could be a Form B (NC) SSR relay, but they are impossible to find where I live (can´t find them even on the Internet). Meanwhile I was doing that research I became aware of the Depletion mode MOSFETS, which at first glance should do what I want. Here comes the problem: I did tons of research over the Internet and couldn´t find a way to wire it up to behave like that, especially because it needs a gate voltage inferior to the Source's voltage to keep it closed. In a matter of fact, there is not so much information about those MOSFETs available, usually more theretical stuff than practical applications.

So, I've tried to simulate their use on the computer, in dozens of different configurations, even using a pair of then back to back (as I discovered they are used in SSR Form B relays), with no success. Sometimes they even worked closer to the way I expected but the current drain to keep the channel open was bigger than the original relay needed.

I do really feel that the answer to that dilemma is quite simple, just lurking around some corner, so I'm asking the experts for some clarification on that. If the use of a depletion MOSFET is not the best solution here, let me know as well.

EDIT:

This is the (almost) full schematic:

The blue squared area is a continuity test. When the user presses a button connecting TEST+ and TEST-, LED_TEST will turn on if there is continuity on the solenoid (which is plugged on OUT+ and OUT- binding posts). This part of the circuit is powered directly by the battery (the 9V_RAW power line).

The rest of the circuit is the step-up boost converter (to the left) and the output relays (to the right).

The boost converter is switched by Arduino PWM pin 3 (which is configured to 31372.55 Hz). The relays are triggered by Arduino's 5 and 7 digital pins.

R6FB and R6FB2 pair is a voltage divider to feedback the output voltage to Arduino´s analog pin 0. Obviously, they could also work as a bleeding resistor, but I had to choose that high value (1MOhm) due to the current constraints I've mentioned above.

The RELAY and RELAY2 subcircuits are like the following:

BTW, the relay contacts translate as NF = NC and NA = NO.

• As you've discovered, the common 9 volt batteries cannot deliver much current - you should probably use 6 AA cells instead. Dec 12 '20 at 21:41
• Why a depletion-mode MOSFET, you seem to need a plain (enhancement) MOSFET, unless I'm misinterpreting something. It would help with your exposition to draw a schematic of what your current idea is, so we can suggest on it. Dec 12 '20 at 21:45
• Why not use a single relay, DPDT configuration. Then you can put the resistor across the cap when not charging. This would pull 9mA extra during discharge though. Dec 12 '20 at 22:46
• An SCR might be a good choice, but we need to see a diagram of the entire system. Where is the MCU, at the remote end? Dec 12 '20 at 23:18
• @PeterBennett That was a solution, indeed. I didn´t like the idea of two 9v in parallel because that would render the device quite unreliable i.e. if one of the batteries went dead (or had a failed contact, etc) the circuit would still turn on as if nothing was wrong. The "cells in series" solution doesn't have that issue. What I didn´t know is that AA cells could provide more current than the 9V. Good to know! Dec 13 '20 at 14:22

OK, so there are two approaches to your question, and you are likely thinking of the first one, which is more general:

Question 1: which semiconductor switch can be conducting when there's absolutely no power, but non-conducting (open) when there is?

The answer to this would generally be something exotic like the depletion-mode NMOS or a normally-closed relay, which have problems of their own. You can add, for example, a TC7660 charge pump to generate -9V to keep the depletion NMOS pinched off.

Or you can take advantage of the fact that the 160 volts cannot be generated in the absence of any power, so you can design a circuit that assumes some power was available previously. To restate:

Question 2: which semiconductor switch can be conducting when power is removed, if power was available previously?

This can be simpler. You can store some small amount of power in a capacitor and use it to drive the gate of a normal (enhancement) NMOS, like this:

simulate this circuit – Schematic created using CircuitLab

Notes:

• I've simplified the schematic quite a bit. I'm not including the boost circuitry, instead I added a fictional 160V supply, which in reality comes from boosting the 9V rail.
• During normal operation (power applied), the C1 is charged to 8.5V, but Vgs of M1 (enhancement PMOS) is +0.5V, so it is closed. Thus the gate of M2 (enhancement NMOS) is ~0V, so it is closed, too.
• When the 9V power is disconnected, the boost circuit will keep pumping energy in the 160V cap for a very short while during the time the bypass caps on the 9V line are discharged (you've not shown them in your schematic, but I assume you have something, right?). This will quickly deplete the 9V rail to almost 0. There's no need for an actual R4 in your circuit - the boost circuit does that job of bringing the 9V rail to almost 0.
• When the 9V rail is zero, there would be still ~8.5V in C1 (D1 prevents backflow), and the Vgs of M1 will be close to -8.5V. Being a PMOS, it will conduct, bringing M2's gate to ~8.5V. M2 will conduct as well, quickly discharging the 330µF cap. With R2=1kOhm, it would require ~1 s to discharge it almost completely. Be sure to use a beefy R2, e.g. 0.6W, so that it can absorb the several joules of energy in the 330µF cap without overheating.
• C1 will slowly discharge to a volt or two, but that takes about 10 seconds.

See the simulation:

The "relay" opens at ~1.7s. As you can see it takes < 0.8s for the cap voltage to reach below 20V, making it non-dangerous.

• That´s great! I´ll surely have a try on this solution. Thanks for having your time. Now, I´m curious about the bypass capacitor. I've had it in previous versions of this project but remove it under the excuse that I wouldn't use that boost circuit to power another circuit or device, so I'd not need a steady power source. Based on your comment I guess I was wrong about that. Would you mind clarifying the benefits of a bypass capacitor in this configuration? Thanks again. Dec 14 '20 at 11:47
• My comment is mostly about best practices. As you understand a 9-volt battery has several ohms of internal resistance, so your boost switcher causes the "9V rail" to sag (maybe up to a volt?) thousands of times per second. Adding a capacitor would smooth that out. But then you ask, do you really need a clean supply? Best engineering practice says yes, because then you can worry less about the supply being a culprit to other problems should they happen to arise (you may want to add something to the schematic an year from now even if it's very simple right now). Dec 14 '20 at 15:04
• In the end it depends on your judgement and project requirements. A filtering cap is 5¢ and unless your BOM budget is thinned down to the point those cents are important, I'd just take the safe path and include it. Dec 14 '20 at 15:05
• Got it. I'll add that up again. Thanks. Dec 14 '20 at 15:33

It appears you are using "shoot" to mean activating the solenoid to do some work. Assuming your controller knows that the "shoot was aborted", then the only time that bleed resistor is needed is when the solenoid wasn't used. So, add a normally open relay that connects the bleeder, and don't activate it unless there was an aborted event.

• My concern is in the case of a circuit or power failure. I was looking for some solution that would quickly discharge the capacitor in a situation like that. But I'm just overthinking it... Dec 13 '20 at 14:51