Duty cycle on sends not 50/50

[IguanaBen]

Reported by bluey on 2 May 2008 22:36 UTC The duty cycle on IR sending is not exactly 50/50. This is because of an asymmetry between pulling the voltage on the LED to 5V vs pulling the voltage on the LED down to ground (and an asymmetry in the LED).

At 150kHz, the duty cycle is 60/40 (4us on, 2.66us off). This works out to having the LED on an extra 0.66us. The duty cycle is approximately

0.5+/- carrier_frequency*0.66us

This offset is clearly more significant at higher frequencies. At 38kHz, the duty cycle is 52.5 / 47.5 but it grows with freq to 60/40 at 150kHz.

This is not a problem since even a 60/40 duty cycle will work for most applications. Is we want to push to higher frequencies (why?) we might want to try to compensate for this offset in the firmware.

These measurements were made by measuring the current flowing through the LED. Attached is a graph of one cycle at 150kHz. 1V = 20mA

[IguanaBen]

Commented by bluey on 28 Mar 2012 15:29 UTC Testing email notifications. Ignore.

[IguanaBen]

Commented by seanyoung on 18 Aug 2014 12:03 UTC Ideally the duty cycle can be set programmaticaly. The duty cycle does depend on the IR protocol used, and I guess an unnecessarily high duty cycle uses more power than necessary.

[IguanaBen]

Commented by bluey on 19 Aug 2014 02:01 UTC I don't think duty cycle will affect power usage -- the IR still has the same amount of transitions from on to off in the same amount of time. The only difference is it so long, short vs short, long, or medium, medium.

I've not seen any IR expecting anything other than 50/50 so it seems like we should aim to be near that.

[IguanaBen]

Commented by seanyoung on 19 Aug 2014 09:30 UTC If the IR led is illuminated for less time in total will there be less power usage? With a duty cycle of 25[it will on for half the time than a duty cycle of 50pct.

NEC IR has a duty cycle of 33[is 25[pct](pct]. http://www.sbprojects.com/knowledge/ir/nec.php

RC-5) http://en.wikipedia.org/wiki/RC-5

RC-6 is 25[pct] http://www.sbprojects.com/knowledge/ir/rc6.php

[IguanaBen]

Commented by jdunn on 19 Aug 2014 13:19 UTC I have to agree with seanyoung that if we reduce the duty cycle on the 38kHz carrier we could improve the power usage. However, I doubt it would really make a huge difference, so let's do some math.

First of all, once you take the overlying protocol into account the actual duty cycle of the LED during transmission is going to be approximately cut in half. For the space encoded signals that seem to be extremely common (especially when we look at the longer signals) it will be cut even further since the spaces average 1.5 times the length of the pulses. Assuming a 50[carrier duty cycle, a back of the envelope approximation says: 0.5 * 0.44 = 0.22, so at the per-signal level we're looking at a 0.22 to 0.25 duty cycle during send. We'll call it <25pct below.

The LED is restricted to drawing <100mA when it's on, but it's on less than 1/4 of the time during actual transmissions: <25[pct] * <100 = <25 mA during transmission and 0 mA during idle or receive. For comparison, the cypress data sheet for the chip we use says it typically pulls "10 mA at 6 MHz" but only 10 uA when sleeping. Now consider normal usage. Most users are dealing with a fix location install where this level of power usage is irrelevant, but taking laptop or embedded users into account you could only power our device for a few seconds whenever you wanted to send. Assuming a fairly annoying 10 second plug-in whenever you wanted to transmit the constant 10mA draw FAR outweights the rare 25mA burst since those bursts last on the order of 50mS.

Reducing the duty cycle, while it would technically reduce power usage, is a waste of time compared to getting the Cypress chip to sleep as often as possible. Unfortunately, the Cypress chip is programmed in an accumulator style assembly language with primitive debugging capabilities and the task of debugging the interactions of sleep with both timer and USB interrupts is daunting. We would be better off designing a new board with the goal of better supporting portable users and using a chip that is less irritating to work with.

Please correct my math if I screwed something up....

[IguanaBen]

Commented by bluey on 20 Aug 2014 04:20 UTC Even though RC5 / RC6 expect a 25[duty cycle (which I didn't know, thanks for the info) I would guess that moving to 25pct duty cycle vs our current 50[would actually reduce the range of our device. We might do a little better with signal detection as the shape is right, but with 50pct less IR power I think that would dominate and most people care more about transmit range than device power. And that power usage is dominated by uC and what it is doing. Might be worth trying though as I could be wrong.

[IguanaBen]