Go Down

Topic: Need help scoping IRremote.h library output on pin 3 (Read 169 times) previous topic - next topic

ShermanP

I'm working on a remote control, and I'm using the IRremote.h library.  My remote works most of the time, but not always.  Before working on changing the powering of the IR LED, I decided to check the unloaded output of pin 3 on my scope to see if it looked ok.  It didn't.  Attached is a scope screen capture of the output of a Roku IR remote BACK button, using an IR phototransistor as a sensor.  My scope captured it quite well, and it turns out to be NEC format, with a value of  0x57436699.  The NEC format has all the ON spikes the same duration, but a zero or a one is indicated by the duration of the OFF time following the spike.

Below that are two independent captures of pin 3 running the SendTest sketch shown below.  It just uses the library routine to send the same command.  In theory, all three screen captures should be the same.  But the library output looks very ragged, and in some places just doesn't send the same bits. And it looks different every time.

But there is a question in my mind about my scope, which is the DSO150 kit scope from Banggood.  It did fine capturing the Roku output, so I think what it's showing me on pin 3 should also be accurate.  But it would be great if someone with a "real" oscilloscope would run the test sketch on a Nano, capture the output on pin 3, and see if it looks like what I get.

If it looks equally ragged on a real scope, then I think the library needs some work.  My guess is that the Timer0 millis() interrupt is still running, and may be messing things up.  Millis() isn't called, but micros() is.  But maybe a better way is to turn off the millis() interrupt, and instead count the ON and OFF times in terms of 38K carrier cycles.  Well just speculating about that. If the problem is my scope, then maybe nothing needs to be changed.

I realize this is asking a lot, but there is at least the potential that better IR for everyone might result.  Thanks very much.

Code: [Select]


//SendTest.ino

#include <IRremote.h>

IRsend irsend;

void setup() {
}

void loop() {
  irsend.sendNEC(0x57436699, 32);
  delay(5000); //5 second delay between each signal burst
}


arduarn

#1
Sep 25, 2019, 02:39 am Last Edit: Sep 25, 2019, 02:41 am by arduarn Reason: added image inline
Don't have a 328 device to hand, but here is one from a 32u4 (Micro):



Is your phototransistor really a phototransistor and not perhaps an IR receiver module for remote controls? If it is a module then the carrier is probably being removed from the signal, hence the "open" pulses you see in the top plot.
The other two plots may then have the carrier, screwing up their appearance.

ShermanP

#2
Sep 25, 2019, 04:55 am Last Edit: Sep 25, 2019, 05:57 am by ShermanP
Thanks very much, arduarn.  I really appreciate your checking this out.  So it turns out it's a problem with my scope after all.  The output looks perfect on your scope.

It really is just a phototransistor as far as I can tell.  It's just a two-pin LED-like device.  But you're right that the positive pulses should be solid because of the carrier.  Anyway, I've written some bit-banging code to test this, which I can run with a solid high output during the pulses, or with carrier during the pulses.  And I suspect you are correct that the carrier is what's confusing my scope.

Thanks again for your help.  Now I can get back to the LED drive circuit.

Edit:  The solid high pulses look fine on my scope, but the pulses with carrier look messed up.  So I think that confirms it's a problem with my scope.

Go Up