Questions about infrared LEDs for remotes

[Peabody]

Thanks very much for all this info.  It's really useful.

But I'm afraid I have a more fundamental problem, and it involves the LED driver output on pin 3 of the Arduino produced by the library.  Just to make sure it was ok, I put my DSO150 scope on it, and found that it's not ok.  Some of the positive-going pulses are very weak, and sometimes they are missing entirely.  I tried it with the SendRaw example that comes with the IRremote.h library, and got the same thing.  And the bad pulses don't happen at the same place each time.  I'm actually kinda surprised it works with the Roku puck at all, but I guess most of the time it's close enough.

I don't look forward to going through his code to figure out what's wrong.  Since most of the bits are sent correctly, and the errors occur at different places each time, my guess is the problems result from the Timer 0 interrupt for millis().  He doesn't ever call millis(), but he does call micros() many places.  So it may not be possible to turn off the Timer 0 interrupt.  And of course I could be wrong about that being the problem.  I guess it could even be a problem with my scope, but I think that's not likely at these speeds.

I've had bad luck with Arduino libraries.  Anyway, does anyone know of another IRsend library that I could try?  It's just plain old NEC format, and I have the raw data that's sent.

[Kleinstein]

The slow rise of the collector voltage is not a thermal effect - LTspice very likely does not include a thermal model. The cause is more that the IR diode goes high impedance once the current is very low and this the discharge of capacitance gets very slow. So nothing to worry about.

For more diode current in the circuit, one could use a smaller emitter resistor and the smaller base resistor. The Arduino should be OK delivering some 10 mA.

Weak (low amplitude) pulses look odd - this would be more like a hardware problem, maybe not having the IO pins defined as output and thus using the pull ups only.

[Peabody]

Weak (low amplitude) pulses look odd - this would be more like a hardware problem, maybe not having the IO pins defined as output and thus using the pull ups only.

I flashed a Nano with the SendRaw example, which just sends one command, but I had nothing connected to the output pin except the scope.  And I still get the same result.  The output is the output of the 38K PWM setup on Timer2, so it must be active in both directions.  Looking at the code, the PWM is continuous, but its output is gated to pin 3 only during the ON time, and pin 3 is LOW otherwise.  That should be pretty simple, and it works most of the time, but the ON periods are not always right - too short, or don't happen at all.  I'm going to see if I can write a delay function based on the number of carrier cycles, and turn off the Timer0 millis() interrupt while sending.  Here's his code for the delay:

Code: [Select]

// Custom delay function that circumvents Arduino's delayMicroseconds limit

void IRsend::custom_delay_usec(unsigned long uSecs) {
  if (uSecs > 4) {
    unsigned long start = micros();
    unsigned long endMicros = start + uSecs - 4;
    if (endMicros < start) { // Check if overflow
      while ( micros() > start ) {} // wait until overflow
    }
    while ( micros() < endMicros ) {} // normal wait
  } 
  //else {
  //  __asm__("nop\n\t"); // must have or compiler optimizes out
  //}
}

#endif // SENDING_SUPPORTED

My scope is a little kit scope, so I guess it's possible it's just not reading pin 3 correctly.  But it does fine reading the output of the remote with an IR phototransistor, so it if can keep up with that, it should be able to keep up with pin3 since the two should be identical.  So I assume what it's showing me is what's happening.

 

[Peabody]

Attached is a scope screen capture showing the output of a Roku IR remote's BACK button as captured with an IR phototransistor.  It's normal NEC format with a value of 0x57436699.  Below that are two examples of what the library puts out on pin 3 of a Nano for the same command.  In theory, all three should be the same.  Anyway, I don't want to worry about driving the IR LED until I'm sure the driver pin is behaving correctly.  No point in using lots of current to send the wrong command.  Unless the pin 3 captures are some kind of scope artifact, they look pretty ragged to me.

[Benta]

You need a better 'scope.
There's no way a digital output from a microcontroller will output anything other than high or low. Well, it could be three-state of course, but that makes absolutely no sense, as it wouldn't change from pulse to pulse.

[Peabody]

Maybe so.  But then "high" isn't actually high, but rather just the 38K carrier being on.  The scope did fine reading the IR input which was not demodulated first.  Anyway, I've posted on the Arduino forum asking if someone with a real scope could do the same test.  That would settle the question.

[mikerj]

My completed remote works, kinda, but the IR isn't getting through as well as it should, and some commands are missed at the receiver.  And when I look at the transmitting remote in my camera's live view, I barely see anything, whereas the original Roku remote LED is plainly visible.  So I'm not putting out enough IR.  Attached is the circuit I'm using, which includes a Darlington.  The LED itself is a mystery because I took it from an old remote, which worked fine in its day.

Not all IR LEDs have the same peak wavelength, if the LED you found is not matched to the receiver (which most always include an IR filter) then range will be greatly reduced.

[Peabody]

A guy on the Arduino forum did the same test, and the output was perfect on his scope.  Then I did a bit-banged version of the command, once with the carrier on during the high pulses, and again with the output a solid high during those pulses.  The latter show perfectly on my scope, but the carrier version looks messed up.  So apparently the problem is indeed my scope.  The carrier is throwing it off.

So now I can get back to working on the LED drive.

[Peabody]

I ended up, for now, with a 10Ω resistor for the IR LED, and a Darlington with a 2.2K base resistor.  That's noticeably brighter when viewed in my camera, and seems to work fine in practice with both the Roku and the TV.  I have a 220µFd cap on the power rail, but I'm not sure that's even needed.  The power supply is an 18650 with no regulator, and I think it provides current pretty readily for the LED pulses.  I don't see any variation in Vcc as the pulses are sent.  The final project is here:

https://github.com/gbhug5a/Roku-Sling-IR-Channel-Number-Remote-for-Arduino

[tooki]

A guy on the Arduino forum did the same test, and the output was perfect on his scope.  Then I did a bit-banged version of the command, once with the carrier on during the high pulses, and again with the output a solid high during those pulses.  The latter show perfectly on my scope, but the carrier version looks messed up.  So apparently the problem is indeed my scope.  The carrier is throwing it off.

So now I can get back to working on the LED drive.

Make sure you’re not using an averaging mode. Also, using holdoff might help.