How to slow the turn off time of an N Channel Mosfet

[onemanonelaptop]

Hi All,

With the prefaced caveat of i probably have no idea what im doing.. i have the following issue.

I have an N channel mosfet that is turning off TOO quickly and id like to slow it down.

Would the following work or is my thinking flawed


What i am assuming.

When turning on the gate, the diode will bypass the resistor and the gate will turn on at its normal speed.
When turning off, the resistor combined with the gate capacitance (630pF from the datasheet) will delay the turn off via the formula.

T = R x C_iss

so that 10k * 630pf = 6.4uS


Am i remotely close to something where i can play with the resistor value to tune the turn off time?

[Zero999]

Yes, your schematic shows the correct way to slow the turn-off time, but your formula is wrong. It doesn't take into account the Miller effect. You need to use the gate charge, not capacitance, in your calculation. Fortunately it's specified on the data sheet.

https://www.aosmd.com/sites/default/files/res/datasheets/AO3400.pdf

[magic]

With this circuit there will be a relatively linear voltage ramp on the drain. Drain voltage can only rise at a rate where the resulting gate-drain capacitance charging current doesn't exceed the current being sucked out of the gate by the resistor, which is approximately Vgs(th)/R1.

[tggzzz]

With the prefaced caveat of i probably have no idea what im doing.. i have the following issue.

I have an N channel mosfet that is turning off TOO quickly and id like to slow it down.

Recognising your own limitations is always a good starting point

So, you think slowing down the MOSFET is the solution. It is often beneficial to state the problem as well as one (suspected) solution.

Tell us your problem/goal, as well your solution. In most walks of life, technical or non-technical, if we know the reason for the question you will probably get a better answer. Either the answer will be more pertinent to your needs, or perhaps it can suggest a better alternative that you haven’t even considered. Don’t ask “Can you give me a lift into town?” Do ask “Can you give me a lift into town, so I can replace my broken frobnitz?”. The answer might be “There’s a spare frobnitz in the attic”, thus saving time, money, the environment – as well as making some space in the attic.

More directly, a Spice (e,g, LTSpice) time-domain simulation can be a good way of checking out basic circuit operation. With care and understanding such simulations can also yield valuable insights into the detailed operation.

so that 10k * 630pf = 6.4uS

Hint: capitalisation matters. There's no such thing a pf, even if it is easy to interpret as pF. m-vs-M is another traditional pitfall. However uS does matter, since that is a conductance, and *FETs do have a principal parameter measured in Siemens: g_m, their transconductance.

[onemanonelaptop]

Thankyou for the feedback.

Apologies for the slack capitalization

I am implementing a VREF signal that varies based on a control/status pin (TPS2121RUXR). The VREF signal i am generating is via a voltage divider, which is modified by the NMOS when the status pin goes high/low.

Currently, the lower voltage obtained by turning on the NMOS happens tooo quickly before the system is ready for it, so i want to delay it.

I have fired up lLTSpice (for the first time) and took a couple of hours figuring out how to plug everything in and come to the conclusion that the diode solution does not affect the delay in the order of magnitude i ultimately require.

So i have added a resistor on the gate and a capacitor from the gate to the source and this is looking like what i want to achieve.

It slows the turn on time a bit, but that doesn't effect what i am trying to do, and its seems to slow the turn off considerably which IS what i want.

Questions:

• Is this a recommended/acceptable way to achieve a delay in my VREF signal changing? (GREEN)
• Is there a better way to simulate an IC status pin other than my voltage source which goes from 0-5V and back to 0V in LTSpice.
  

note: absolutely zero thought has gone into the selection of R4 and C1 values apart from seeing if it changes the waveform.

GREEN = VREF (top of R3)
RED = STATUS PIN
BLUE = Voltage at GATE

Am i on the right track, or have i derailed completely. Re-adding the caveat that i know nothing, but know more that i did a few hours ago

[tggzzz]

I am implementing a VREF signal that varies based on a control/status pin (TPS2121RUXR). The VREF signal i am generating is via a voltage divider, which is modified by the NMOS when the status pin goes high/low.

Currently, the lower voltage obtained by turning on the NMOS happens tooo quickly before the system is ready for it, so i want to delay it.

There are two parameters in those statements: the rise/fall time when the MOSFET switches on/off, and the delay between the status pin changing and the MOSFET switching on/off.

It sounds like the rise/fall time is unimportant, but the delay between the status pin change changing and the MOSFET switching should be increased.

Consider something like the status pin driving an RC delay which drives the input to a comparator. The comparator output drives the MOSFET directly. The comparator could possibly simply be a logic gate with a schmitt trigger input.

[Zero999]

What sort of delay do you require?

As I said before, just using the gate capacitance is inadequate for calculating the switching delay.

Here's a simulation showing the gate charge/discharge curves for a MOSFET, with nothing connected to the drain vs a drain voltage of 24V and 100R load. The slowing switching with 24V on the drain is due to the miller effect. The MOSFET has a parasitic capacitor between the drain and gate which pulls the gate voltage down, as the drain voltage falls i.e. negative feedback.

I couldn't find a model for the AO3400, so I made one, using the spreadsheet posted in the thread linked below:
https://www.eevblog.com/forum/projects/mosfet-model-maker-excel/


EDIT:
The above schematic contained an error: M12's drain was short circuited to +24V. It has been corrected.