cyborg5 / IRLib2

Library for receiving, decoding, and sending infrared signals using Arduino
GNU General Public License v3.0
393 stars 140 forks source link

RCMM protocol sender disables delayMicroseconds()? #20

Open caliban17 opened 7 years ago

caliban17 commented 7 years ago

I am attempting to send RCMM protocol IR codes and wrote a very simple test sketch. Weirdly the call to delayMicroseconds after each send does not work at all (no matter what value I attempt to delay, the 3 'sends' are always 17.4 microseconds apart, which I assume is the loop overhead.) I tested delayMicroseconds() with another sketch (not using the IRLib2) and it works fine on my UNO board.

/*

IRsendRCMM mySender; //declare a sender object

const uint8_t SEND_REPEATS = 3; // total number of times to send an IR message const uint16_t SEND_DELAY = 90; // delay between repeats in microseconds (us) const uint32_t CODE_IR = 0x23802603; //code for button '3'

/***** *

void setup() { Serial.begin(115200); delay(2000); while (!Serial); //delay for Leonardo Serial.println(F("Every time you press a key is a serial monitor we will send.")); }

void loop() { if (Serial.read() != -1) { //send a code every time a character is received from the // serial port. sendSkyNZ(CODE_IR); Serial.println(F("Sent signal.")); } }

cyborg5 commented 7 years ago

How are you measuring the resulting gap between signals? Keep in mind that 90 micro seconds isn't very long. I set up your output sketch and change your SEND_DELAY to "1". I sent the signals using one Arduino and receive them using a second one and the autoResume sample sketch. The "Gap" value was about 17,000 micro seconds. But it varied up or down a few hundred. Changing your SEND_DELAY to value as small as 90 is barely going to make a measurable difference. Are you sure you didn't want to use "Delay (SEND_DELAY);" instead of delayMicroseconds (SEND_DELAY);? I changed SEND_DELAY to 1000 and got measurable results.

Also if you look at the code for sending RCMM it always concludes the transmission with a space of space(27778-extent);

where "extent" is the total length of the transmitted code. I don't exactly recall where I got that number 27778 from but that is the reason for some of the delay between signals. You always have to end a transmission with a reasonable amount of blank space so that the receiver can detect that you really ended a frame of data. The IRP notation for 12 and 24 bit versions of the product, doesn't show what the closing space should be. The 32-bit version says 100m so I can't really say why I put 27778. I must've gotten that number from some other reference.

Whether or not my trailing space is correct or not, your delay of 90 microseconds is still pretty insignificant. Why did you pick that value? Why is the inter-frame timing important to you?

cyborg5 commented 7 years ago

Add the following code to your sketch.

uint32_t Value= micros();
 delayMicroseconds(SEND_DELAY);
 uint32_t Duration=micros()- Value;
 Serial.print("gap duration ="); Serial.println(Duration,DEC);

I get a consistent value of 92 which is as accurate as the micros() can measure.

caliban17 commented 7 years ago

Hi Chris Extreme thanks for all of your help so far, I'm very grateful and impressed.  I am attempting to build a two-button Sky TV remote for my aging mother here in New Zealand, and so am trying to replicate the Sky IR signals.  I have been using the AnalysIR software & hardware to measure the difference between the actual Sky remote and my generated signal.  Like you I send from my uno to the AnalysIR nano and shield.From my research/testing, The Sky signals appear very similar to the Australian Foxtel remote but with a different device number.  In any case the Sky remote always sends three repeated signals (RCMM) as a block, and they are 90 microseconds apart - so I've tested that one correct signal doesn't trigger the TV to action, so I'm trying to replicate the 3-burst and hence my problem/question. I was trying to get my head around why the delayMicroseconds statement wasnt being executed at all? because it might have some bearing on what I perceive as my next problem - that when I incorporate your send code with my full sketch that responds to button pushes (that includes debouncing timer checks), the measured timing of the IR signals being sent varies quite wildly (compared to the test sketch here, where the measured timings are very similar for each identical send)  I suspected that maybe your send statement is run ayschronously thus my delayMicroseconds statement is run 'simultaneously' with the send thus being swallowed, or maybe both use the same timers, conflicting or something, that might have something to do with the flakey send values I get when also polling millis timer for debouncing in the main loop? I edited your   space(27778-extent);   line in IRLib_P11_RCMM.hto  space(20000);space(20000);space(20000);space(20000);space(10000); (suspecting that space argument maxs at 32,000 ish) and indeed got the 90 microsecond delay between sends I was after.  I am very interested in what you might think is upsetting the send timings - but I'll continue to test/experiment.  Cheers Grant Campbell Mobile: (0210) 278-3185

On Saturday, 25 March 2017 6:43 AM, Chris Young <notifications@github.com> wrote:

How are you measuring the resulting gap between signals? Keep in mind that 90 micro seconds isn't very long. I set up your output sketch and change your SEND_DELAY to "1". I sent the signals using one Arduino and receive them using a second one and the autoResume sample sketch. The "Gap" value was about 17,000 micro seconds. But it varied up or down a few hundred. Changing your SEND_DELAY to value as small as 90 is barely going to make a measurable difference. Are you sure you didn't want to use "Delay (SEND_DELAY);" instead of delayMicroseconds (SEND_DELAY);? I changed SEND_DELAY to 1000 and got measurable results.Also if you look at the code for sending RCMM it always concludes the transmission with a space of space(27778-extent);where "extent" is the total length of the transmitted code. I don't exactly recall where I got that number 27778 from but that is the reason for some of the delay between signals. You always have to end a transmission with a reasonable amount of blank space so that the receiver can detect that you really ended a frame of data. The IRP notation for 12 and 24 bit versions of the product, doesn't show what the closing space should be. The 32-bit version says 100m so I can't really say why I put 27778. I must've gotten that number from some other reference.Whether or not my trailing space is correct or not, your delay of 90 microseconds is still pretty insignificant. Why did you pick that value? Why is the inter-frame timing important to you?— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

caliban17 commented 7 years ago

Yes, I also consistently got 92 Cheers Grant Campbell Mobile: (0210) 278-3185

On Saturday, 25 March 2017 6:51 AM, Chris Young <notifications@github.com> wrote:

Add the following code to your sketch.uint32_t Value= micros(); delayMicroseconds(SEND_DELAY); uint32_t Duration=micros()- Value; Serial.print("gap duration ="); Serial.println(Duration,DEC);

I get a consistent value of 92 which is as accurate as the micros() can measure.— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

cyborg5 commented 7 years ago

If you did space(20000);space(20000);space(20000);space(20000);space(20000);space(10000); then what you got was 90 milliseconds not 90 microseconds. That is why I suggested you use "delay(90)" and not "delayMicroseconds not (90)"