atmega328 -> optocoupler -> mosfet driver -> mosfet doesn't work well at low duty cycles

Go To Last Post
21 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have here:

 

- atmega328p running at 3.3V/8 MHz internal oscillator

- hardware pwm out at 16 bits / 122 Hz (no prescaler)

- optocoupler PS2501-1

- mosfet driver ir4427

- mosfet irfz44n

 

This is a construction I am fairly used to, except from the optocoupler. So normally I have the output of the pwm pin go directly into the mosfet driver (which runs at 12V, way enough to drive the mosfet's gate) and the output of the mosfet driver with a real small resistor to the gate of the mosfet. Works like a charm.

 

Now I wanted to add an optocoupler, as the device connected to the mosfet will be outside the house, and I'd like some protection from (indirect) lightning strike. I don't care if the mosfet, driver and the optocoupler get fried, I don't even care if the atmega gets fried, as long as the surge doesn't reach the enc28j60 which is connected to my home ethernet.

 

I add the optocoupler between de output of the pwm pin, with a 220 Ohms resistor in between, to drive the optocoupler at it's Vf of ~1.2 V (measured and is OK). The optocoupler's collector is connected to 12V, the emitter is connected to the input of the mosfet driver's input and I added a 33 kOhm resistor to ground to compensate for the driver's high input impedance.

 

The problem is the low duty cycle values (values < 16 (of 65536)). When I connect a led to the pwm directly (with suitable resistor of course), it lights exactly as expected. I have it run a sweep where the duty cycle gets multiplied by 1.1 every update, so it it glows up and down just nicely. When I connect the same led to the output of the optocoupler, I see non-smooth behaviour. The range 8-16 give all the same brightness, then below 8 the led stops completely.

 

I realise there are very small duty factors, but it can work nicely, when the optocoupler is removed from between the pwm output and the mosfet driver...

 

The optocoupler is supposed to have fast switching times, typical 3-5 microseconds (from the datasheet) and the input would have low capacitance: 0.5 pF at 1.0 MHz.

 

Anyone have an idea?

 

I have this theory, maybe some can comment? Although the complete pwm cycle is 280 Hz, if the pwm is switched off after only bit period, the "local" frequency is far higher than 280 Hz, something like:

280 Hz (complete pwm period) * 65536 (bit period, 16 bit timer), which yields 18 MHz (!), am I on the right track here? Possible solutions? (other than lowering the pwm cycle frequency or lowering the width of the pwm...)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

16 equates to a pulse width of 2us. Probably too narrow for the opto. A pc900 opto might be a better choice. Ethernet is normally isolated by the transformer, so it is isolated by design on both ends.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, I know of the ethernet transformer ;) I don't know if it's enough though.

 

So I am probably on the right track, too high frequency. Shame :(

 

Thx.

Last Edited: Sat. Oct 18, 2014 - 11:01 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The ethernet transformer is probably rated similar or better than your opto. I would expect at least 1500V isolation, probably 3000V from the ethernet transformer.

If you get a direct lightning hit, all bets are off.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've looked up the specs for the transformer, it says 1500 V, which is not bad, indeed. The optocoupler does 5000 V though. So this means I'll have to decide between better protection or better pwm resolution, hmm...

 

Thanks!
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So this means I'll have to decide between better protection or better pwm resolution, hmm...

 

Hmm indeed.  I haven't followed the intent of all this, but apparently you have a concern with accurate rendition... at duty cycles of <0.04% ?

And what does that have to do with "resolution"?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The problems are present at duty factor = 0-8 from 65536 (16 bits timer). Up from 8 until and higher there is no problem. I can make the timer emulate a 15/14/13/12 bits timer by setting the wraparound value. That would probably solve the problem but it would also reduce the resolution, and it's exactly the very small duty factors that I need working. Yes, I need a duty cycle of 1/65535 which sounds rediculous, I know!

 

Anyway it works without the optocoupler so I am considering dropping that.

Last Edited: Sat. Oct 18, 2014 - 06:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman has already pointed out that your optocoupler is too slow.  The PS2501 has a typical rise time of 3 μs and a typical fall time of 5 μs.  He suggested something from the PC900 series which have typical rise/fall times of 100/50 ns.  Others are faster.  Check out high-speed optocouplers on mouser and filter by speed:

http://ca.mouser.com/Optoelectro...

 

Parts can be had with typical rise/fall times as low as 8 ns.  That's probably overkill.

 

"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]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes that is something I will have to consider.

 

Thanks for the advice.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As above. Just to add that a digital isolator IC would be better suited for this task and its also low power.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have ordered some high speed optocouplers. Let's see what it brings...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The trick to lighning protection is providing a more favorable path for the energy than through your equipment. Optos will do very little apart from galvanic isolation.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have received and applied a couple of HCPL2630's to resolve this issue. They are "very high speed" (10 Mbits/s), I couldn't find anything faster for a comparable price.

 

First challenge: This device has active logic, so it needs to run on 5V, exactly 5V. I don't have 5V on the board (19V, 12V and 3.3V). So I had to add an 78L05.

Next challenge: The device doesn't have an active output like the ps10, it has an open collector output. So I made a pull-up of 33k against the 5V.

 

So the atmega's output is connected with 220 Ohms to the input of the HCPL2630, this should get the right amount of current through the detector from 3.3V. The outputs of the HCPL are pulled up using 33 kOhms and fed into the IRF4426 (I replaced the IRF4427 by an IRF4426 because the IRF4426 has inverted inputs which match the inverted open collector outputs of the HCPL2630).

 

This all more or less work, but I still have a problem. When the port is "off" the mosfet still leaves some current through, a tiny bit, but enough to light a led just visibly. That's a problem, off should be off.

 

The output of the atmega is 0.06 mV  when off, I think that's fair enough (might just be noise picked up from the environment). The inputs of the HCPL have 0.05 mV on them, so that should not be enough to light up the internal led by far (Vf = 1.5 V, measured). Next piece in the chain is the output of the HCPL which gives 4.70 V while it gets 4.98 V as supply voltage. This is tad on the low side, but it shouldn't matter, because the IRF4426 accepts anything above 2.7 V as "high" and anything below 0.8 V as "low" (says the datasheet...). So the IRF4426 should really be shutting of the mosfet completely from this input. But it doesn't. There is still 0.03 mV on the gate. Which is actually hardly significant, but apparently it's enough the drive this mosfet IRFZ44n the tiniest bit. I can hardly believe it myself....

 

The alternative I can think of, is that "somewhere" some AC is picked up and that the low DC I am measuring is actually full-scale AC. I have a very basic oscilloscope I will try on it, but I don't think it'll bring the solution.

 

The interesting part is that while I was using the PC10 optocoupler I didn't have this problem (well, yeah, others, but not this one...)

 

Any hints, experiences?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

According to my (very basic) 'scope just a little bit of ripple in the whole chain, but nothing above a few mV's, capable of opening up the mosfet. I am puzzled.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, we would need a schematic to be of any assistance, although I don't understand your issue, so lets go by steps:

The secondary is what needs to have a supply voltage. Assuming you need isolation, If you have a 12V supply just step it down to 5V top feed the optocoupler and place a 1K pull up to 12V not to 5! 

 

The IRFZ44 starts to conduct with a VGE between 2 to 4V, but just in case you haven't noticed, the datasheet refers to an Id of 250uA. The actual VGS that you should be using is 10V for the rated Rds of 17.5mOhm @ 25A. Again, attaching the pull up to 12V would solve this. ​Lastly you need a gate turn off signal, which can be a 10K resistor from the gate to GND. Going to basics I assume you know that the optocoupler inverts the output and that 33K is a very high pull up. As I suggested, use a 1K. With the combination 1K(up) and 10K(down) you should have about 1V when the signal from the uP is high and 9V when is low. 

 

But I have to ask again, have you seen my previous suggestion regarding the use of a digital isolator IC rather than an optocoupler?

 

The Si826x series are specifically used to drive Mosfets, with both sync and source capabilities and can be supplied directly from 12v to supply the correct gate driving signals without inverting the output.

http://uk.farnell.com/silicon-labs/si8261aac-c-ip/digital-isolator-40ns-dip-8/dp/2423175

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

cts_casemod wrote:

But I have to ask again, have you seen my previous suggestion regarding the use of a digital isolator IC rather than an optocoupler?

The Si826x series are specifically used to drive Mosfets, with both sync and source capabilities and can be supplied directly from 12v to supply the correct gate driving signals without inverting the output.

http://uk.farnell.com/silicon-labs/si8261aac-c-ip/digital-isolator-40ns-dip-8/dp/2423175

This appears to be a very interesting part, and indeed it could replace both the optocoupler and the mosfet driver in one go. There are just two issues: it can't run on 3.3V (although that can be overcome with an extra voltage regulator, just like I do now) and I can't buy it... Farnell / RS Components do not supply to "normal customers" (yeah, from 50 Euro's and up, right...), Digikey will probably have the part as well, but experience has tought me that including shipment and customs, the part will cost about the same, about 50 euro's... Also ebay (China...) doesn't have it, it seems.

 

cts_casemod wrote:

Well, we would need a schematic to be of any assistance, although I don't understand your issue, so lets go by steps:

I don't have a schematic, it's all hand made (and that proves to be right, because I had to change a few things to get it working). The principle is really simple though. Atmega 328p with timer1 PWM running at 16 bits/8 Mhz, pins oc1a and oc1b drive optocoupler, optocoupler drives mosfet driver, mosfet driver drives mosfet. Optocoupler was ps10 but appeared to be too slow and got replaced by a hcpl3126. Mosfet driver was ir4427 but was replaced by a ir4426 because the input is inverted now. The mosfet is an irf44z. The problem/issue is that the mosfet never completely shuts, there is always running a tiny amount of current through drain->source which makes the attached load never go completely off. Even when the PWM is halted and the oc pins are completely off. The mosfet is supposed to completely shut and with the former setup (using ps10) I had that working, also in my other board without optocouplers, so I guess it's not an issue with mosfet driver -> mosfet.

 

cts_casemod wrote:

The secondary is what needs to have a supply voltage. Assuming you need isolation, If you have a 12V supply just step it down to 5V top feed the optocoupler and place a 1K pull up to 12V not to 5! 

No can't do that. The hcpl cannot tolerate voltages over 5 volts on it's open collector output. Which makes is a bit less useful indeed. Besides that, the mosfet driver should be able to deal with 5V based input equally well (switching points at 0.8 V and 2.2 V)

 

cts_casemod wrote:

The IRFZ44 starts to conduct with a VGE between 2 to 4V, but just in case you haven't noticed, the datasheet refers to an Id of 250uA. The actual VGS that you should be using is 10V for the rated Rds of 17.5mOhm @ 25A. Again, attaching the pull up to 12V would solve this.

Apparently you misunderstood the issue, indeed. The mosfet goes "on" very well, that's really not the problem. I know my way around mosfets and I know that it's simply safest to drive them using a mosfet driver, which makes all of this very simple. The hcpl is not driving the mosfet, the mosfet driver is... And the mosfet has a Schmitt trigger on it's inputs.

 

Quote:

​Lastly you need a gate turn off signal, which can be a 10K resistor from the gate to GND. Going to basics I assume you know that the optocoupler inverts the output and that 33K is a very high pull up. As I suggested, use a 1K. With the combination 1K(up) and 10K(down) you should have about 1V when the signal from the uP is high and 9V when is low. 

I completely agree, if the mosfet driver would need 12V based signalling. But according to the datasheet that's not the case. The signalling is TTL-levels based, so 5V based input should really suffice. Indeed the 33k may be well to large, I forgot to mention that I also tried values down to 1k, with no effect. No effect on the output and no effect on the voltage delivered to the mosfet driver (low = 4.71 V, high = 0.001 V), so I guess the input impedance of the mosfet driver is really largge, which I indeed expected, but I didn't find the actual value in the datasheet.

 

The only thing I can think of yet, is that I made a very stupid mistake in the source code and the PWM doesn't actually shut off all the way. I don't think that's very likely though, because I have been using the code for years, but well, you never know how you can screw up things without noticing....

Last Edited: Sat. Nov 1, 2014 - 03:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
This appears to be a very interesting part, and indeed it could replace both the optocoupler and the mosfet driver in one go. There are just two issues: it can't run on 3.3V (although that can be overcome with an extra voltage regulator, just like I do now) and I can't buy it... Farnell / RS Components do not supply to "normal customers" (yeah, from 50 Euro's and up, right...), Digikey will probably have the part as well, but experience has tought me that including shipment and customs, the part will cost about the same, about 50 euro's... Also ebay (China...) doesn't have it, it seems.

 

The part I pointed was just an example, as I happen to have used it before with good results. I am sure Texas, Linear or even Maxim have something similar as they seem to be always fighting for the best portfolio. There are also a large number of optocouplers specifically rated to drive small IGBT's which can also drive mosfets that would form a better choice.

 

I don't have a schematic, it's all hand made (and that proves to be right, because I had to change a few things to get it working). The principle is really simple though. Atmega 328p with timer1 PWM running at 16 bits/8 Mhz, pins oc1a and oc1b drive optocoupler, optocoupler drives mosfet driver, mosfet driver drives mosfet. Optocoupler was ps10 but appeared to be too slow and got replaced by a hcpl3126. Mosfet driver was ir4427 but was replaced by a ir4426 because the input is inverted now. The mosfet is an irf44z. The problem/issue is that the mosfet never completely shuts, there is always running a tiny amount of current through drain->source which makes the attached load never go completely off. Even when the PWM is halted and the oc pins are completely off. The mosfet is supposed to completely shut and with the former setup (using ps10) I had that working, also in my other board without optocouplers, so I guess it's not an issue with mosfet driver -> mosfet.

Ok, so you are saying that you have a Mosfet driver, which changes the game all together. Its unclear why the Mosfet is conducting then without having an oscilloscope view. I would start by taking the opto from the circuit and placing a 10K pull down on the driver input to see if that would make a difference. Does the mosfet conduct any current if the driver is removed and with a 10K gate pull down resistor?

Apparently you misunderstood the issue, indeed. The mosfet goes "on" very well, that's really not the problem. I know my way around mosfets and I know that it's simply safest to drive them using a mosfet driver, which makes all of this very simple. The hcpl is not driving the mosfet, the mosfet driver is... And the mosfet has a Schmitt trigger on it's inputs.

I haven't. I just mentioned that at those voltages the Rds is uncharacterized. There is a graphic on the datasheet that shows how much current the device can carry with a given VGS voltage.

 

I completely agree, if the mosfet driver would need 12V based signalling. But according to the datasheet that's not the case. The signalling is TTL-levels based, so 5V based input should really suffice. Indeed the 33k may be well to large, I forgot to mention that I also tried values down to 1k, with no effect. No effect on the output and no effect on the voltage delivered to the mosfet driver (low = 4.71 V, high = 0.001 V), so I guess the input impedance of the mosfet driver is really largge, which I indeed expected, but I didn't find the actual value in the datasheet.

 

I was not mentioning the driver, but rather the Mosfet itself. But since now we know that you have a driver you could reduce from 1K to 47Ohm and keep the 10K to make sure the device goes off should the driver go into high impedance mode for whatever reason. 

 

Last Edited: Sat. Nov 1, 2014 - 03:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Please bear with me for the moment, I might have found something in the code. The ocr register is set to 0, but apparently the code, that I normally use to ensure pwm off = really off has been lost somewhere in the process (it appears that setting the OCR register to 0 is not always sufficient to make sure the OC pin is always off, I usually disconnect the OC pin and write it LOW explicitly using the PORT register in that case). So I am going to reintroduce that piece of code first and then see what happens. That would be very shameful :-/

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah. This would be the time to bite the dust (or insert more appropriate proverb here). I have been foolish. On very small OCR values, the OC output will have been enabled and will only be disabled after a minimum number of timer cycles, especially on high frequencies, which is the case here (8 Mhz unscaled). So you can never completely shut off a port just by setting OCR to 0. Which is clearly stated in the datasheet and which I've been know for years, but simply didn't think of in this version of the code.

 

I apologize for all effort spent in vain by the helpful forum members :-(

 

Well not completely in vain, I now know of the digital signal isolators, which I am definitely going to look into for future projects. Thanks!
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Use a phase correct mode, or a phase and frequency correct mode.  Both support full-off and full-on PWM.

 

Or, use and inverted compare output mode on your chosen OCxn pin, and invert the OCRxn register value.  This will give you full-off with PWM at the expense of full-on (255/256 duty is the highest you can get in this mode).

"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]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Good tip, but won't apply in this case, I need the full range (16 bits) and full timer cycle (only 120 Hz left), with phase-correct mode, the full timer cycle would drop to 60 Hz. Can't go any higher on the cpu clock though, because it needs to run on 3.3 V. I now simply disconnect the OC-pin when OCR is 0 and set the OC pin to 0 explicitly, which isn't too much hassle. Which I always did, but forgot on this one, shame on me...

 

The root of the problem, btw, is that strings of LED's tend to be well visibile even on low PWM cycles. I need them to be almost off, barely visible. With an 8 bits timer, and even 12 bits, the minimum duty cycle won't be small enough. Even with the 16 bits timer of the 328 I can't make the LED's invisible just by reducing the duty cycle. I know it works, because difference can be seen between the lowest duty cycles values. I guess I'll have to accept it like this, the lowest duty cycle is indeed very faint already.