Electronics > Projects, Designs, and Technical Stuff
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:
--- Quote from: Kleinstein on September 24, 2019, 05:59:11 am ---
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.
--- End quote ---
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: ---// 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
--- End code ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version