Thats a really wasteful design approach in my opinion .... what if your design is the next greatest "thing" and everyone must have one? If your design wastes 1A in the form of HEAT. that's 6 billion Amps across the world in wasted HEAT. We should all be more responsible with our designs.

 

Thanks to everyone for engaging. I'll have to order some logic-level MOSFETs for future. And the voltage-controlled switch in LTSpice got me able to simulate more edge situations.

I tried AlbertHall's suggestion (invert PWM with a pull-up on the transistor base). But it is now apparent that I must think about all three states - HIGH, LOW, HIGH-IMPEDANCE. So now instead the HIGH-IMPEDANCE state keeps the MOSFET gate low, but a LOW on the pin during reset drives the control signal high.

@BobTPH. its the first time I've really connected with the voltage doubler idea. For my low current requirements it looks good here. A single supply rail, perhaps Arduino 5V from USB (rather than having to always supply 9V) would also be nicer for me. My early morning smoke problem when the MCU was reset should also go away: when the PWM stops, the higher derived voltage will also stop. And I should have enough voltage headroom (no pun intended) to add MaxHeadRoom's suggestion of putting a drain resistor on the gate. I can dedicate one PWM GPIO to the voltage doubler (and leave it at 50% duty) while the other PWM GPIO retains its present function - essentially as an output DAC for the load control.

If it works, I can just run off a USB port or a 5V supply, I can still use my cheap MOSFETs that are not logic-level, I won't need a MOSFET driver. And I shouldn't see smoke.

Peter

 

I think I need it because the MOSFET needs more than 5V on its gate to deliver, say, 30A at 12V. http://www.irf.com/product-info/datasheets/data/irf3205.pdf

Some people like the smell of toasted transistors. Good luck.

 

It's been a while since I checked in on this thread, and it looks like the situation may have changed while I was tinkering with my ideas, but I'll share them anyway just in case there's something useful in here. I was working off of the original requirements, so not using logic-level MOSFET, and only protecting against the high-impedance GPIO scenario, not against forced high states during the boot sequence.

The interesting thing for me was trying to recreate the biasing scheme to set both min and max voltages for the MOSFET gate scaled to 0-100% PWM. I finally realized that using a three-resistor voltage divider, and then using a transistor to bypass the middle resistor does exactly what's needed. You can tinker with the values of the three resistors to fine tune the high and low values, but this is a reasonable starting point (at least for the MOSFET used in simulation.)

The 5 colored traces represent 0-99% duty cycle, and the big dip around 150ms is when the GPIO output goes high impedance, as if it were resetting.

 

It's been a while since I checked in on this thread, and it looks like the situation may have changed while I was tinkering with my ideas, but I'll share them anyway just in case there's something useful in here. I was working off of the original requirements, so not using logic-level MOSFET, and only protecting against the high-impedance GPIO scenario, not against forced high states during the boot sequence.

The interesting thing for me was trying to recreate the biasing scheme to set both min and max voltages for the MOSFET gate scaled to 0-100% PWM. I finally realized that using a three-resistor voltage divider, and then using a transistor to bypass the middle resistor does exactly what's needed. You can tinker with the values of the three resistors to fine tune the high and low values, but this is a reasonable starting point (at least for the MOSFET used in simulation.)

The 5 colored traces represent 0-99% duty cycle, and the big dip around 150ms is when the GPIO output goes high impedance, as if it were resetting.

View attachment 201167

Hi

I've just finished modeling an MCU GPIO pin in LTspice.

Model Provides:
weak pullup
I/O data
PWM at Arduino frequencies


Anyone want to test it for me?

eT

 

It's been a while since I checked in on this thread, and it looks like the situation may have changed while I was tinkering with my ideas, but I'll share them anyway just in case there's something useful in here. I was working off of the original requirements, so not using logic-level MOSFET, and only protecting against the high-impedance GPIO scenario, not against forced high states during the boot sequence.

The interesting thing for me was trying to recreate the biasing scheme to set both min and max voltages for the MOSFET gate scaled to 0-100% PWM. I finally realized that using a three-resistor voltage divider, and then using a transistor to bypass the middle resistor does exactly what's needed. You can tinker with the values of the three resistors to fine tune the high and low values, but this is a reasonable starting point (at least for the MOSFET used in simulation.)

The 5 colored traces represent 0-99% duty cycle, and the big dip around 150ms is when the GPIO output goes high impedance, as if it were resetting.

View attachment 201167

Thanks, I'll explore this. For the record, I found the LTSpice model of the IRFZ44N doesn't match my experience or the datasheet. The IOR datasheet puts the Gate threshold at Min 2V Max 4V. And the typical transfer curves show 4V on the gate delivering somewhere between 3A and 10A, depending on temp. As others have pointed out, if I do push 20A through here its going to be pretty damn hot, and impossible to turn off completely, even at PWM=0. Just playing with a couple of IRFZ44Ns on the bench confirmed this for me. So I'm targeting my gate voltage below 2V when PWM=0. I've also used a different MOSFET - an IRF3205 - in my build, and only last night learned how to use imported models in LTSpice.

 

As others have pointed out, if I do push 20A through here its going to be pretty damn hot, and impossible to turn off completely, even at PWM=0.

I definitely understand that you can't dissipate too much power for too long without damaging the MOSFET, but this is the first I've heard of not being able to turn it off. How would that work? Is there some latching behavior I'm unaware of at high temperatures? Or are you just referring to what happens when the device fails completely, at which point it's likely to fail shorted and never turn off again?

Also, it occurs to me that giant, high wattage resistors are simpler and cheaper than MOSFETs. I know you want to be able to control the current, so I'm not suggesting you replace the MOSFET, but maybe you should put one or more larger resistors in series with it to provide a portion of the voltage drop and greatly reduce dissipation in the MOSFET itself.

 

I definitely understand that you can't dissipate too much power for too long without damaging the MOSFET, but this is the first I've heard of not being able to turn it off. How would that work? Is there some latching behavior I'm unaware of at high temperatures? Or are you just referring to what happens when the device fails completely, at which point it's likely to fail shorted and never turn off again?

Also, it occurs to me that giant, high wattage resistors are simpler and cheaper than MOSFETs. I know you want to be able to control the current, so I'm not suggesting you replace the MOSFET, but maybe you should put one or more larger resistors in series with it to provide a portion of the voltage drop and greatly reduce dissipation in the MOSFET itself.

Sorry - I expressed that badly! Looking at your VGate graphs I see when PWM=0 that VGate is about 3.8V. So the MOSFET can turn off and there is no weird behaviour - we just need to get VGate down to below what the datasheet says is the minimum threshold voltage. And those transfer curves are dependent on temperature, so 3.8V on the gate of a hot MOSFET is going to be allowing a lot of current to flow. And yes, it is a nice idea to shunt some power elsewhere, even a fan, to protect the MOSFET.

 

Hello,

I noticed you show a frequency of 15.6Khz. How did you get that high a frequency?
I thought Arduino PWM could only go as high as 1000 Hz(?)

eT

 

It's been a while since I checked in on this thread, and it looks like the situation may have changed while I was tinkering with my ideas, but I'll share them anyway just in case there's something useful in here. I was working off of the original requirements, so not using logic-level MOSFET, and only protecting against the high-impedance GPIO scenario, not against forced high states during the boot sequence.

The interesting thing for me was trying to recreate the biasing scheme to set both min and max voltages for the MOSFET gate scaled to 0-100% PWM. I finally realized that using a three-resistor voltage divider, and then using a transistor to bypass the middle resistor does exactly what's needed. You can tinker with the values of the three resistors to fine tune the high and low values, but this is a reasonable starting point (at least for the MOSFET used in simulation.)

The 5 colored traces represent 0-99% duty cycle, and the big dip around 150ms is when the GPIO output goes high impedance, as if it were resetting.

View attachment 201167

Hi

I tried your schematic with my model.
The result is slightly different but there are variables that haven't been shared by the TS.

eT

 

Hi

I tried your schematic with my model.
The result is slightly different but there are variables that haven't been shared by the TS.

eT


View attachment 201184

Are the differences just because you included the "startup" command and I didn't? I wouldn't expect subtle differences in GPIO behavior to effect this circuit that much.

P.S. That GPIO module you created looks pretty cool. I am interested in playing with it, just didn't have time right away.

 

Hi

I tried your schematic with my model.
The result is slightly different but there are variables that haven't been shared by the TS.

eT


View attachment 201184

Yeah, I was embarrassed when I recognized that my model didn't get the gate voltage below 2V either. Which is probably why I paid keener attention to your work than my own!

 

Hello,

I noticed you show a frequency of 15.6Khz. How did you get that high a frequency?
I thought Arduino PWM could only go as high as 1000 Hz(?)

eT

Arduino PWM can go as high as 4MHz. It has a fast PWM mode during setup.

 

Hello,

I noticed you show a frequency of 15.6Khz. How did you get that high a frequency?
I thought Arduino PWM could only go as high as 1000 Hz(?)

eT

My current understanding, not guaranteed ....

There are three hardware clocks on the MCU. One is "reserved" to ping at 1000 Hz to update the millis() counter; You can add an additional register match comparator to create your own interrupts at 1Khz. (somewhere in the middle of the millis counter cycle). https://learn.adafruit.com/multi-tasking-the-arduino-part-2/timers

But you can also grab one of the other 16-bit hardware slave timers, fed from the master clock. The Arduino Uno master clock is 16Mhz. You can configure to pre-scale the master clock by dividing it by 1, 2, 4, ... etc The slave timer counts up from 0 to whatever value you set in the TOP register for the clock - then you get the reset-to-0 cycle. So the pre-scaler and TOP determine the PWM carrier frequency. (I use the fastest available. i.e. divide-by-1 pre-scaler so my slave clock ticks up at 16Mhz) Then another hardware comparator register which can be set somewhere between 0 and TOP determines the duty cycle, and toggles the GPIO line low. The mode I use wraps around to 0 at TOP, and sets the GPIO line high.

So the tradeoff is this: if I want only 1 bit of PWM resolution, I can set TOP to 2. PWM carrier becomes 8MHz. If I want 2-bits of pwm resolution (4 settable values), I must set TOP to 4, and PWM carrier becomes 4Mhz. 3-bits of resolution (8 values), 2Mhz carrier possible. Notice that the number of settable values times the PWM carrier gets back to 16Mhz master clock.

So at 10 bits of resolution, I get a 16Mhz / 1024 carrier - my 15.6 Khz carrier, variable over 1024 PWM values.

The magic is in the hardware. The programming incantations to invoke the magic are explained at
https://arduino.stackexchange.com/questions/12718/increase-pwm-bit-resolution/12719

 

My current understanding, not guaranteed ....

There are three hardware clocks on the MCU. One is "reserved" to ping at 1000 Hz to update the millis() counter; You can add an additional register match comparator to create your own interrupts at 1Khz. (somewhere in the middle of the millis counter cycle). https://learn.adafruit.com/multi-tasking-the-arduino-part-2/timers

But you can also grab one of the other 16-bit hardware slave timers, fed from the master clock. The Arduino Uno master clock is 16Mhz. You can configure to pre-scale the master clock by dividing it by 1, 2, 4, ... etc The slave timer counts up from 0 to whatever value you set in the TOP register for the clock - then you get the reset-to-0 cycle. So the pre-scaler and TOP determine the PWM carrier frequency. (I use the fastest available. i.e. divide-by-1 pre-scaler so my slave clock ticks up at 16Mhz) Then another hardware comparator register which can be set somewhere between 0 and TOP determines the duty cycle, and toggles the GPIO line low. The mode I use wraps around to 0 at TOP, and sets the GPIO line high.

So the tradeoff is this: if I want only 1 bit of PWM resolution, I can set TOP to 2. PWM carrier becomes 8MHz. If I want 2-bits of pwm resolution (4 settable values), I must set TOP to 4, and PWM carrier becomes 4Mhz. 3-bits of resolution (8 values), 2Mhz carrier possible. Notice that the number of settable values times the PWM carrier gets back to 16Mhz master clock.

So at 10 bits of resolution, I get a 16Mhz / 1024 carrier - my 15.6 Khz carrier, variable over 1024 PWM values.

The magic is in the hardware. The programming incantations to invoke the magic are explained at
https://arduino.stackexchange.com/questions/12718/increase-pwm-bit-resolution/12719

Thank you for that explanation. It cleared things up.
I'm familiar with MCU's (mainly PIC), just not Arduino. I've ordered an MEGA 2560 R3 today to play with and should receive it tomorrow.


eT

 

Are the differences just because you included the "startup" command and I didn't? I wouldn't expect subtle differences in GPIO behavior to effect this circuit that much.

Yes. Its important to either, use "startup" so that the power supplies ramp up from 0 (25us), or set initial voltages/currents on devices (or nodes). That way devices like capacitors can be "charged" or "pre-charged" appropriately for the simulation.
My comment about "unknowns" regards things like "weak pull-up" resistors. Are they used? what value? Are they reset after a reboot?, etc. I suspect not being used, but it will effect the behavior of your circuit.

P.S. That GPIO module you created looks pretty cool. I am interested in playing with it, just didn't have time right away.

Thanks. The work I've done so far is from studying Arduino datasheets and schematics but I've ordered one today (receive tomorrow) to play with so I can produce an accurate model.

The model currently has 7 parameters:

WPU - pullup enable/disable (0,1)
RPU- pullup value (range 20k-150k)
PWM - (range 0-6) disable (0), enable(1-5 preset, 6 user))
UF - user specified PWM frequency (hz) (if PWM=6)
DC- PWM Duty cycle (percent)
BT - Boot time, (0, time) when to reboot (seconds)
BU - Boot duration, (0, time) how long reboot lasts before ready (seconds)

and supports bidirectional I/O

If your still interested, I will ping you when ready.

eT