Lets say I have a single LED connected to a digital pin that is commanded to blink at a 3% duty cycle. How can I determine the current through the LED? Using digitalWrite to pulse the LED is confusing what I assume is a very simple calculation. MY meter can't seem to make sense of it.
Passenger12:
Lets say I have a single LED connected to a digital pin that is commanded to blink at a 3% duty cycle. How can I determine the current through the LED? Using digitalWrite to pulse the LED is confusing what I assume is a very simple calculation. MY meter can't seem to make sense of it.
-LED forward current = 50mA
Duty cycle has nothing to do with current through a LED.
Current through a LED is set by:
Vf (working voltage) of the LED.
supply voltage.
value of the current limiting resistor in series with the LED.
Duty cycle is just changing the time that the LED is on/off.
Your brain and your DMM are too slow to see PWM on/off events.
The DMM will give random values, depending on when/where during the duty cycle it did the sampling,
and your (slow) vision sees it as dimming.
I hope you didn't draw that 50mA from an Arduino pin.
Leo..
What is important is the peak current, not the avrage current when talking about these situations. There is a common misunderstanding that a PWM signal will somehow protect an LED from over current. It will not.
With a 3% duty cycle the avrage current is reduced to 3% of the peak current, but that is no mitigation of the damage that will cause if the peak current is over the rated current for either the device or what is driving it.
Some LEDs have a peak current rating and a continuous current rating. This mainly applies to IR LEDs and a specific rated duty cycle. It does not apply to most visual LEDs which can have their life shortened considerable by pulsed currents above the continuously rated value.
Grumpy_Mike:
What is important is the peak current, not the avrage current when talking about these situations. There is a common misunderstanding that a PWM signal will somehow protect an LED from over current. It will not.
That is true GM. If the PWM frequency is relatively low ...... the 'on' time could take forever, and the peak voltage might as well be just plain DC.
Grumpy_Mike:
It is also true for very fast PWM signals as well. The only mitigation you might get is thermal and that is not the only damage mechanism.
Passenger12:
Lets say I have a single LED connected to a digital pin that is commanded to blink at a 3% duty cycle. How can I determine the current through the LED? Using digitalWrite to pulse the LED is confusing what I assume is a very simple calculation. MY meter can't seem to make sense of it.
-LED forward current = 50mA
You've just said that the current is 50mA.
So it's 50mA for 3% of the time. And zero mA for 97% of the time. At least that's what a 3% duty cycle normally means.
If you are looking for the AVERAGE current then a meter is not going to be able to measure that though calculating it is pretty simple.
Grumpy_Mike:
What is important is the peak current, not the avrage current when talking about these situations. There is a common misunderstanding that a PWM signal will somehow protect an LED from over current. It will not.
With a 3% duty cycle the avrage current is reduced to 3% of the peak current, but that is no mitigation of the damage that will cause if the peak current is over the rated current for either the device or what is driving it.
Some LEDs have a peak current rating and a continuous current rating. This mainly applies to IR LEDs and a specific rated duty cycle. It does not apply to most visual LEDs which can have their life shortened considerable by pulsed currents above the continuously rated value.
Good info, thanks. I should clarify that the 50mA forward current is the MAX rating of the LED. The typical value is not called out in the datasheet and I may need to contact the manufacturer to get a number. So, considering that the MAX current output from an Arduino Uno digital pin is ~40mA, and I've been running it at a 3% Duty Cycle with no issue, the LED is either not drawing above 40mA or the PWM signal is in fact mitigating damage-which I gather from the comments is unlikely.
So the bottom line is that PWM signals do not interfere with output current-that is determined by the load?
So the bottom line is that PWM signals do not interfere with output current-that is determined by the load?
Yes.
Duty Cycle with no issue, the LED is either not drawing above 40mA or the PWM signal is in fact mitigating damage-which I gather from the comments is unlikely.
Just because you haven't seen a failure yet don't mean there is no issue. What if you LED life or Arduino's life is shorted to a year. Then you would not see that yet.
It is even more complex than this. Component failure is a statistical thing, just like lung cancer and smoking. Just because something or some one has not died yet doesn't mean their is no issue, it just means you haven't taken a big enough sample for long enough to see an issue.
There is a common misconception that if it doesn't go up in smoke immediately then things are working fine. If only electronics was that easy.
Wawa:
The DMM will give random values, depending on when/where during the duty cycle it did the sampling,
and your (slow) vision sees it as dimming.
Most DMM's use dual-slope integrating ADCs, not sampling ADCs, so they are even slower than you vision and average
rapidly changing signals accurately. You can usually determine the duty cycle direct from the DMM
reading as there is an accurate linear relationship.
There is a common misconception that if it doesn't go up in smoke immediately then things are working fine.
I would like to believe that the comment does not include those (human beings, factories, companies) who have exhaustive preventive maintenance plan composed of FIT-TRIM-QCHECK (Fast Inspection of Tools, Tools Review and Inspection Monthly, Quality Check in every 6-month) to minimize the presence of potential smoke in the system/process.
I would like to believe that the comment does not include those (human beings, factories, companies) who have exhaustive preventive maintenance plan composed of FIT-TRIM-QCHECK
It is much better to design a product correctly than to watch it like a hawk for when it fails. Ever thought how you do preventive maintenance on an electronic system? Try it on an iPad.
You are referring to iPod! This is a product which has not been designed to survive for 12 years. It has been designed for one time use. As long as it works fine; otherwise, through it in the dustbin and buy a new one. It has a probable life expectancy. There is, and perhaps, nobody would plan a preventive/corrective maintenance program for it.
Look at the Urea Fertilizer Factory. It is composed of many many subsystems of various nature: electrical, electronic, mechanical, hydraulic, communication, chemical, civil and so many. The life expectancy of the plant is about 40 years. As the process going on, various parts of the plant are slowly getting aged; even, some are over stressed. Without an exhaustive preventive/corrective maintenance program, a plant of this type cannot survive.
Everything is fine with you; but, the complain comes when you say 'common misconception'; it is a misconception, but it is not a 'common misconception'.
Thank you, and I would like to end the debate here!
It is common if a lot of people have it. Given that their are more people who do not know about design reliability than do therefore the misconception is common.
Their is no such thing as preventive maintance of an electronic system no matter how it is designed unless you simply replace chunks of it at intervals.
As you started this pedantic debate it is up to you to end it by ceasing to reply. I look forward to not receiving any from you and I will get back to my pint of beer in the English Lake District.
As you are going to Lake Side for your payers, you deserve to receive the last thanks for your sharp standing in favor your rational argument and objective attitudes. I fully agree with you that the misconception is common among many people, and it is my observation that a few design/development engineers/programmers are largely responsible for it as they are bearing communal/bureaucratic mentalities to hide details to the end users through their lovely abstractions and thus intentionally creating a culture of misconception.
Look at the Arduino's UART related Serial.begin(baudRate, frameLegth) function; it has embedded so many sub-tasks that the common users like me and others ought to believing it a Magic Function. Whence the Arduino Community is striving very hard to educate/help people, thence a few design engineers/programmers at the Steve Jobs fashioned furniture-less multi-room mansion are exercising their 'Uncommon Intellects' by creating such kind of functions.
One missing letter are (r) (prayers and not payers) has created totally opposite meaning! So many times I have scanned the pre-post, alas! I could not see it (the Editor should have a spelling checker!). In some cases, machine is much better than human being. I am sure that should the message be read by a machine it would read as: While you are going to Lake Side (I have intentionally omitted the words English Lake District ; instead, I have placed the word Side for a meaning known to me) for your prayers, ... (One can go into full devotion with overdose; that happened to us of 6 as Customer Engineers in GEC Manchester in 1979 by the Host Company as Equipment Seller.)