Why is the duty cycle so low?

[PorkRhombus]

One for the designer(s): Looking at the IR LEDs, the gaps between codes seem very long. Before I put any time into changing this, I was wondering if there was a very good reason for it. To let the emitters cool down perhaps? Sure would be nice to go through the codes in 10s rather than 69.

[adafruit_support_rick]

I don't know what you're seeing, but standard IR protocols typically specify a little over 100ms per code. So you should be seeing codes at around 10Hz.

[PorkRhombus]

To see what I'm seeing, just view the emitters through a digital camera. Clearly we aren't transmitting 10 codes per second or we would be done in under 15 seconds. The dead time between codes is taking up more time than the codes themselves.

[Stephanie]

In the loop that sends all the codes, there is a delay line that happens after the code is sent and just before the visible LED is blinked:

Code: Select all

delay_ten_us(25000);

I don't see any explanation as to why that's there, but if I'm reading it right, it is adding a 1/4 second delay between each code.

[PorkRhombus]

Yah. I saw that too. Wondering why it's so long. Maybe it's arbitrary and maybe some TV firmware wants a certain period of quiet around the code. Hoping one of the designers can shed some light on why this number was chosen.

[Stephanie]

It might be necessary to have that dead-time to allow the IR receivers out there to 'reset' or something, so that the TV-B-Gone doesn't interfere with itself?

Just a guess, but I have noticed that the TV-B-Gone interferes with remotes, so after a tv has gone off, the regular remote is useless until the tv-b-gone has finished sending all its codes and goes to sleep. So even with the 1/4 second gap it's sending fast enough to block other remotes.

Still it wouldn't hurt to do some empirical testing, and see if a shorter delay still works.

[PorkRhombus]

We could spend a lot of time guessing and experimenting. I'm just wondering if someone who was involved with that particular design decision could explain it to us.

[Stephanie]

A few people are credited in the source files but the original design was from Mitch Altman. He visits these forums now and then, you could try contacting him and ask.

For what it's worth, I had a project out today that included a tv-b-gone so I just recompiled it and reduced the 250mS delay to 100mS and it 'seems' to work. At least my livingroom tv (the dreaded dynex) still switched off.

The overall run dropped from approx 75 or 80 seconds down to under 45 seconds.

[PorkRhombus]

Re your earlier point, I do not find that my Sony is in 'blackout' as long as the TVBG is running. For example if I hold down the volume up key, the volume does steadily increase although the normally smooth movement of the on-screen display is a little choppy as it obviously pauses each time the TVBG sends another code, but it receives its own codes loud and clear in the gaps left by the TVBG. By the way, I have the gap between codes set to 50 ms !

[Stephanie]

Interesting, perhaps it's just the dynex brand that gets blacked out. Or maybe it's just my unit, hehe.

[PorkRhombus]

So just to close the loop on this one, I edited line 338 of main.c to reduce the delay between codes from 25000 (250ms, 0.25s) down to 5000 (50ms, 0.05s) and it seems to still work fine. The whole extended _NA_ code set runs in 35s now, a great improvement.