wifi.begin add error in IR receiving code

[fotosettore]

Version/revision of the library used

2.8.5

Describe the bug

The library works really fine and all hex received number are ok.
But if I put wifi.begin in void setup, the numbers in rx mode are random and very rarely the right code is given

To Reproduce

use IRRecvDemo.ino
put #include <WiFi.h> in the sketch and WiFi.begin(net,pwd) in the void setup
complle
please note that net and pwd must be real, so you must be really connected to your router
ESP32S and WROOM 32D give same problem

Example code used

#include <Arduino.h>
#include <IRremoteESP8266.h>
#include <IRrecv.h>
#include <IRutils.h>

const uint16_t kRecvPin = 36;
IRrecv irrecv(kRecvPin);
decode_results results;

#include <WiFi.h>
char NetName[26] = "yournet"; 
char NetPwd[30] = "yourpwd";

void setup() {
  Serial.begin(115200);
  WiFi.begin(NetName, NetPwd);
  irrecv.enableIRIn();  // Start the receiver
  while (!Serial)  // Wait for the serial connection to be establised.
    delay(150);
  Serial.println();
  Serial.print("IRrecvDemo is now running and waiting for IR message on Pin ");
  Serial.println(kRecvPin);
}

void loop() {
  if (irrecv.decode(&results)) {
    // print() & println() can't handle printing long longs. (uint64_t)
    serialPrintUint64(results.value, HEX);
    Serial.println("");
    irrecv.resume();  // Receive the next value
  }
  delay(10);
}`

Expected behaviour

using a samsung tv remote control

Serial monitor :
without WiFi.begin
E0E020DF
E0E020DF
E0E020DF
E0E020DF
E0E020DF
E0E020DF
E0E020DF
E0E020DF
E0E020DF
E0E020DF

with WiFi.begin
D1E21191
E3AB4430
E0E020DF
E0E020DF
4824BC8A
A432D17A
E0E020DF
AA9C7144
55560F29
E0E020DF
834ED9B0
FC7307DE

What brand/model IR demodulator are you using?

VS1838

Circuit diagram and hardware used (if applicable)

+5V power
out pin directly to pin 36. I tried other pins : same problem

I have followed the steps in the [Troubleshooting Guide]

YES

More ...

I wrote here although you said that VS1838 gives problems. I have no problem using it. I have only if i put wifi.begin

may thanks for your patience

[NiKiZe]

Se dumpv3 which has OTA support
One recommendation.. don't include your ssid or password in the sketch, just use WiFi.begin(); it will use last used credentials.

You need to include which protocol it is in your prints, see the faq about unknown protocols.

[fotosettore]

hi
in IRemoteESP8266.h I put the HASH, SAMSUNG, PANASONIC and SONY "decode true".
last test was made on a samsung, but the problems is with all remotes.

here is another example, with a sony remote control

without wifi.begin
10
10
10
10
10
10
10
10



with
10
6F4C7F96
10
10
3119530B
10
C3621478
FFFFFFFFFFFFFFFF
DAE7ABE0
10

In my complete schetch, net and pwd are used inside command because there is a control of these info every time sketch run.
They are inside eprom and they are read every time, because they may have be changed

p.s. sorry I don't understand "Se dumpv3 which has OTA support"

[NiKiZe]

Are your SSID and WiFi password changing every time?

[NiKiZe]

You should probably read the FAQ
But do use https://github.com/crankyoldgit/IRremoteESP8266/tree/master/examples/IRrecvDumpV3 post your output from that command.
Do enable OTA in the code to enable WiFi at the same time.

You need to provide reasonable data to even understand what you are doing here 😉

[fotosettore]

this is one second push "1" on a samsung tv rc
note : the pin used is 36

IRrecvDump is now running and waiting for IR input on Pin 36
Timestamp : 000038.558
Library   : v2.8.5

Protocol  : UNKNOWN
Code      : 0x45587C16 (34 Bits)
uint16_t rawData[68] = {4548, 4448,  548, 1698,  550, 1698,  548, 1698,  548, 578,  576, 552,  576, 552,  546, 576,  548, 576,  576, 1674,  548, 1696,  548, 1700,  548, 576,  576, 550,  576, 554,  548, 574,  550, 580,  572, 552,  576, 550,  548, 1698,  550, 574,  548, 576,  550, 578,  576, 550,  576, 550,  576, 1672,  580, 1668,  548, 578,  574, 1326,  348, 548,  1696, 576,  1650, 570,  1698, 550,  1696, 578 };  // UNKNOWN 45587C16


Timestamp : 000038.666
Library   : v2.8.5

Protocol  : UNKNOWN
Code      : 0x1B2B85A (34 Bits)
uint16_t rawData[68] = {4550, 4450,  548, 1698,  550, 1696,  578, 1672,  548, 580,  546, 580,  546, 578,  550, 578,  578, 550,  574, 1670,  552, 1696,  550, 1698,  552, 574,  576, 548,  550, 576,  550, 580,  548, 576,  578, 546,  550, 580,  574, 1670,  576, 554,  574, 530,  596, 548,  578, 550,  566, 562,  574, 1502,  168, 578,  1672, 574,  552, 572,  1670, 576,  1650, 574,  1696, 574,  1672, 576,  1672, 548 };  // UNKNOWN 1B2B85A


Timestamp : 000038.774
Library   : v2.8.5

Protocol  : SAMSUNG
Code      : 0xE0E020DF (32 Bits)
uint16_t rawData[67] = {4522, 4476,  548, 1698,  576, 1672,  576, 1672,  574, 554,  572, 554,  578, 552,  546, 578,  576, 550,  576, 1670,  574, 1674,  578, 1670,  548, 580,  574, 550,  576, 550,  576, 552,  576, 550,  574, 552,  576, 552,  574, 1670,  578, 530,  596, 550,  574, 554,  574, 552,  576, 550,  576, 1670,  574, 1670,  578, 550,  548, 1698,  576, 1672,  600, 1644,  580, 1668,  576, 1672,  576};  // SAMSUNG E0E020DF
uint32_t address = 0x7;
uint32_t command = 0x4;
uint64_t data = 0xE0E020DF;


Timestamp : 000038.882
Library   : v2.8.5

Protocol  : SAMSUNG
Code      : 0xE0E020DF (32 Bits)
uint16_t rawData[67] = {4522, 4454,  596, 1672,  578, 1672,  602, 1644,  578, 548,  576, 550,  574, 552,  576, 552,  576, 548,  576, 1670,  578, 1670,  574, 1672,  576, 550,  576, 550,  576, 552,  576, 550,  578, 548,  574, 552,  576, 554,  570, 1672,  576, 552,  576, 550,  576, 548,  576, 552,  574, 552,  576, 1650,  570, 1698,  576, 552,  574, 1672,  576, 1670,  578, 1668,  576, 1672,  576, 1670,  576};  // SAMSUNG E0E020DF
uint32_t address = 0x7;
uint32_t command = 0x4;
uint64_t data = 0xE0E020DF;


Timestamp : 000038.990
Library   : v2.8.5

Protocol  : SAMSUNG
Code      : 0xE0E020DF (32 Bits)
uint16_t rawData[67] = {4518, 4454,  570, 1700,  576, 1672,  576, 1670,  576, 550,  548, 578,  548, 576,  576, 550,  576, 550,  574, 1670,  574, 1672,  576, 1670,  548, 580,  576, 526,  572, 576,  576, 552,  576, 552,  548, 576,  576, 550,  578, 1668,  576, 552,  574, 552,  574, 552,  560, 566,  546, 576,  552, 1698,  574, 1672,  576, 548,  578, 1672,  548, 1698,  548, 1700,  574, 1674,  574, 1672,  548};  // SAMSUNG E0E020DF
uint32_t address = 0x7;
uint32_t command = 0x4;
uint64_t data = 0xE0E020DF;


Timestamp : 000039.097
Library   : v2.8.5

Protocol  : UNKNOWN
Code      : 0xF61189EE (34 Bits)
uint16_t rawData[68] = {4520, 4474,  550, 1698,  578, 1670,  576, 1670,  576, 550,  574, 552,  576, 550,  574, 552,  548, 578,  574, 1672,  576, 12,  1658, 552,  1672, 572,  576, 558,  568, 576,  552, 546,  578, 576,  552, 578,  548, 578,  550, 550,  1696, 550,  576, 576,  548, 552,  578, 576,  548, 576,  554, 576,  1670, 550,  1694, 550,  580, 572,  1670, 552,  1694, 574,  1676, 548,  1696, 578,  1670, 548 };  // UNKNOWN F61189EE


Timestamp : 000039.204
Library   : v2.8.5

Protocol  : UNKNOWN
Code      : 0xC25ECA4F (34 Bits)
uint16_t rawData[68] = {4522, 4474,  550, 1696,  582, 1668,  548, 1676,  570, 578,  550, 578,  574, 184,  364, 550,  578, 550,  576, 580,  1642, 576,  1696, 576,  1672, 576,  552, 574,  552, 548,  576, 576,  548, 552,  578, 574,  552, 574,  554, 546,  1702, 572,  552, 578,  550, 550,  576, 548,  578, 576,  554, 572,  1672, 548,  1700, 576,  552, 548,  1700, 574,  1668, 576,  1672, 574,  1676, 572,  1670, 576 };  // UNKNOWN C25ECA4F


Timestamp : 000039.312
Library   : v2.8.5

Protocol  : UNKNOWN
Code      : 0xF96D736E (34 Bits)
uint16_t rawData[68] = {4522, 4472,  604, 1642,  578, 1488,  180, 550,  1698, 548,  576, 550,  580, 574,  550, 548,  578, 576,  550, 576,  1670, 548,  1700, 574,  1672, 574,  552, 548,  576, 578,  550, 548,  578, 578,  548, 578,  552, 548,  576, 550,  1698, 548,  576, 550,  580, 548,  576, 576,  550, 576,  550, 550,  1696, 574,  1674, 576,  550, 574,  1674, 548,  1696, 576,  1672, 574,  1672, 578,  1670, 550 };  // UNKNOWN F96D736E

[fotosettore]

and this is one second push "1" on sony tv rc

IRrecvDump is now running and waiting for IR input on Pin 36
Timestamp : 000221.405
Library   : v2.8.5

Protocol  : SONY
Code      : 0x10 (12 Bits)
uint16_t rawData[25] = {2428, 606,  596, 604,  572, 630,  574, 630,  570, 632,  572, 632,  598, 604,  572, 630,  1198, 604,  572, 632,  572, 630,  570, 632,  572};  // SONY 10
uint32_t address = 0x1;
uint32_t command = 0x0;
uint64_t data = 0x10;


Timestamp : 000221.450
Library   : v2.8.5

Protocol  : UNKNOWN
Code      : 0x1BFE3349 (13 Bits)
uint16_t rawData[26] = {1162, 2400,  628, 574,  630, 572,  630, 598,  604, 572,  630, 626,  578, 570,  630, 572,  632, 1174,  628, 572,  632, 572,  630, 570,  632, 572 };  // UNKNOWN 1BFE3349


Timestamp : 000221.495
Library   : v2.8.5

Protocol  : SONY
Code      : 0x10 (12 Bits)
uint16_t rawData[25] = {2406, 628,  570, 630,  574, 630,  600, 600,  572, 630,  598, 604,  572, 630,  574, 628,  1176, 628,  574, 632,  596, 604,  572, 630,  572};  // SONY 10
uint32_t address = 0x1;
uint32_t command = 0x0;
uint64_t data = 0x10;


Timestamp : 000221.540
Library   : v2.8.5

Protocol  : UNKNOWN
Code      : 0xE9B31C03 (13 Bits)
uint16_t rawData[26] = {2400, 630,  574, 628,  574, 630,  598, 604,  572, 632,  600, 600,  602, 598,  574, 362,  266, 1204,  602, 570,  632, 600,  602, 600,  602, 574 };  // UNKNOWN E9B31C03


Timestamp : 000221.585
Library   : v2.8.5

Protocol  : SONY
Code      : 0x10 (12 Bits)
uint16_t rawData[25] = {2428, 602,  574, 626,  598, 608,  572, 628,  572, 632,  574, 628,  572, 630,  572, 630,  1176, 608,  592, 632,  568, 632,  572, 628,  574};  // SONY 10
uint32_t address = 0x1;
uint32_t command = 0x0;
uint64_t data = 0x10;


Timestamp : 000221.636
Library   : v2.8.5

Protocol  : SONY
Code      : 0x10 (12 Bits)
uint16_t rawData[26] = {2426, 604,  600, 602,  600, 604,  600, 604,  572, 630,  574, 628,  572, 628,  574, 630,  1200, 604,  602, 598,  576, 628,  574, 628,  572, 6076 };  // SONY 10
uint32_t address = 0x1;
uint32_t command = 0x0;
uint64_t data = 0x10;


Timestamp : 000221.675
Library   : v2.8.5

Protocol  : SONY
Code      : 0x10 (12 Bits)
uint16_t rawData[25] = {2402, 628,  574, 628,  572, 630,  572, 630,  548, 630,  598, 604,  584, 618,  572, 630,  1174, 630,  572, 630,  572, 630,  574, 628,  600};  // SONY 10
uint32_t address = 0x1;
uint32_t command = 0x0;
uint64_t data = 0x10;


Timestamp : 000221.720
Library   : v2.8.5

Protocol  : SONY
Code      : 0x10 (12 Bits)
uint16_t rawData[25] = {2428, 580,  594, 630,  572, 630,  572, 630,  598, 604,  598, 604,  572, 632,  570, 632,  1174, 628,  574, 630,  572, 628,  574, 630,  570};  // SONY 10
uint32_t address = 0x1;
uint32_t command = 0x0;
uint64_t data = 0x10;


Timestamp : 000221.765
Library   : v2.8.5

Protocol  : NEC (Repeat)
Code      : 0xFFFFFFFFFFFFFFFF (0 Bits)
uint16_t rawData[26] = {9216, 2426,  602, 598,  604, 574,  630, 574,  628, 576,  628, 572,  628, 598,  604, 570,  632, 1174,  628, 600,  604, 572,  628, 600,  604, 572 };  // NEC (Repeat) FFFFFFFFFFFFFFFF
uint64_t data = 0xFFFFFFFFFFFFFFFF;


Timestamp : 000221.810
Library   : v2.8.5

Protocol  : SONY
Code      : 0x10 (12 Bits)
uint16_t rawData[25] = {2402, 630,  572, 630,  574, 628,  572, 630,  574, 632,  574, 628,  572, 632,  570, 630,  1176, 628,  572, 630,  576, 628,  572, 630,  600};  // SONY 10
uint32_t address = 0x1;
uint32_t command = 0x0;
uint64_t data = 0x10;


Timestamp : 000221.855
Library   : v2.8.5

Protocol  : SONY
Code      : 0x10 (12 Bits)
uint16_t rawData[25] = {2400, 628,  574, 630,  598, 604,  576, 630,  570, 634,  570, 628,  576, 628,  574, 630,  1174, 628,  574, 628,  572, 630,  574, 628,  574};  // SONY 10
uint32_t address = 0x1;
uint32_t command = 0x0;
uint64_t data = 0x10;


Timestamp : 000221.901
Library   : v2.8.5

Protocol  : SONY
Code      : 0x10 (12 Bits)
uint16_t rawData[25] = {2426, 604,  600, 602,  572, 630,  572, 632,  572, 630,  570, 630,  574, 628,  570, 630,  1174, 630,  572, 630,  600, 604,  570, 630,  598};  // SONY 10
uint32_t address = 0x1;
uint32_t command = 0x0;
uint64_t data = 0x10;


Timestamp : 000221.946
Library   : v2.8.5

Protocol  : UNKNOWN
Code      : 0x445EE1F7 (13 Bits)
uint16_t rawData[26] = {2428, 602,  572, 630,  572, 630,  572, 630,  574, 628,  576, 626,  574, 630,  570, 630,  1174, 630,  602, 600,  572, 474,  156, 570,  630, 572 };  // UNKNOWN 445EE1F7

[fotosettore]

at last ... this is sony with OTA disabled

IRrecvDump is now running and waiting for IR input on Pin 36
Timestamp : 000003.663
Library   : v2.8.5

Protocol  : SONY
Code      : 0x10 (12 Bits)
uint16_t rawData[25] = {2396, 634,  568, 634,  568, 634,  568, 612,  592, 632,  568, 634,  568, 634,  568, 634,  1170, 634,  568, 634,  568, 634,  568, 634,  568};  // SONY 10
uint32_t address = 0x1;
uint32_t command = 0x0;
uint64_t data = 0x10;


Timestamp : 000003.708
Library   : v2.8.5

Protocol  : SONY
Code      : 0x10 (12 Bits)
uint16_t rawData[25] = {2396, 634,  568, 636,  566, 634,  568, 634,  568, 634,  568, 636,  568, 634,  568, 634,  1170, 634,  568, 634,  568, 634,  568, 634,  568};  // SONY 10
uint32_t address = 0x1;
uint32_t command = 0x0;
uint64_t data = 0x10;


Timestamp : 000003.753
Library   : v2.8.5

Protocol  : SONY
Code      : 0x10 (12 Bits)
uint16_t rawData[25] = {2394, 634,  568, 634,  568, 634,  568, 634,  568, 634,  568, 634,  568, 634,  568, 634,  1170, 634,  568, 634,  568, 636,  568, 632,  570};  // SONY 10
uint32_t address = 0x1;
uint32_t command = 0x0;
uint64_t data = 0x10;


Timestamp : 000003.798
Library   : v2.8.5

Protocol  : SONY
Code      : 0x10 (12 Bits)
uint16_t rawData[25] = {2394, 634,  568, 634,  568, 634,  568, 634,  568, 634,  568, 634,  568, 634,  568, 634,  1170, 634,  568, 634,  568, 634,  568, 634,  568};  // SONY 10
uint32_t address = 0x1;
uint32_t command = 0x0;
uint64_t data = 0x10;


Timestamp : 000003.843
Library   : v2.8.5

Protocol  : SONY
Code      : 0x10 (12 Bits)
uint16_t rawData[25] = {2394, 634,  568, 634,  568, 634,  568, 634,  568, 634,  568, 634,  568, 634,  570, 634,  1170, 634,  568, 634,  568, 634,  570, 632,  568};  // SONY 10
uint32_t address = 0x1;
uint32_t command = 0x0;
uint64_t data = 0x10;


Timestamp : 000003.888
Library   : v2.8.5

Protocol  : SONY
Code      : 0x10 (12 Bits)
uint16_t rawData[25] = {2396, 632,  568, 634,  568, 634,  568, 634,  566, 636,  568, 634,  568, 634,  568, 634,  1170, 634,  570, 634,  568, 634,  568, 634,  568};  // SONY 10
uint32_t address = 0x1;
uint32_t command = 0x0;
uint64_t data = 0x10;

[fotosettore]

Later I will test it using a different IR receiver
I found TSOP4138
But I don't believe this is a IR rx problem

[NiKiZe]

Now you can see that you have unknown protocol in that case the data is not something that you can go on.
In the other cases you need protocol in combination with the code to make sense.

Now the timing issues, do you have a proper capacitor over the power input of your receiver module?

[fotosettore]

proper capacitor

yes, there are a 1000mF and a 100n on 3v3 and a 10mF near the receiver
Also I try to put a 100ohm between 3v3 and + in of rx.
all worked fine in all conditions and no problems without wifi
I tested the circuit on different places and different boards. no solution
I write on forum only when I have no solution after several tests :-(

why unknown protocol if wifi is on ? i see no relation :-(

[crankyoldgit]

Looking at the raw data, in the UNKNOWN signals, there is a 'blip', you'll find a sub-200us timing value.

A number of things could be causing it. From the hardware demodulator, the microproccessor, or some bug.

As you've noted, it works fine with wifi off. So, that eliminates bugs in the library pretty much. That leaves what changes when wifi is turned on.
Turning on Wifi will increase the current draw on the uProcessor, so it could be stressing the on-board DC power modulator. You might not have enough current being supplied to the board. If i'm understanding correctly, you're powering the demodulator from the 3V3 on the board, which may not have enough current supply.
You've already mentioned it's a problematic IR demodulator. We really don't trust it.

To diagnose this more, we'd need an osciliscope trace on Pin 36, to confirm what the input really is to it, matched up with the output of the program.
That will help rule out the IR demodulator.

We have not had other reports of this problem (that I'm aware of) with the library, so it seems it's something with your particular setup. So, I think we can lower the likelihood its a software issue. I think this is likely to be a power/hardware/circuit issue.

To handle crappy/noisy signals, we do have a few options you can turn on to try to accomodate this sort of problem.
Use the max_skip parameter in IRrecv::decode() to convert those sub-200us messages.

[fotosettore]

hi

you're powering the demodulator from the 3V3 on the board

the power is managed by external ams1117 3V3, powered in 5V 1A. The ams is 1A so i don't think that is a power problem. However I will test better it.
This evening I will test a TSOP4138 too and i will use your advices about max_skip etc.
If the problem will still exist, i will use oscilloscope.
In one way or another it must be solved.

[crankyoldgit]

1 Amp of 3V3 should be heaps.

FYI, the behaviour we are seeing is "something" is causing the "CHANGE" interrupt to trigger prematurely on the input GPIO.
The interrupt is set to trigger when the voltage changes. So it picks up when it rises and when it falls.

When triggered, the interrupt calls an interrupt handler, which just records how long it's been since it last triggered.
That software is pretty well established and fine. I can't recall any recent changes to it off the top of my head.

Something must be causing the interrupt handler to trigger. Be it the hardware, or the software.
It is really odd that it's producing an "even" number of entries in the raw data. That typically shouldn't happen.

It could be some quirk of the ESP32 arduino core. i.e. Wifi causing interrupt handlers to fire accidentally.
What version of the ESP32 core library are you using? Have you tried using the latest, or something much older?
Also, try an earlier revision of this library. e.g. 2.8.3 or something.

[crankyoldgit]

FYI, this looks like a known hardware bug:
espressif/esp-idf@d890a51

[fotosettore]

Really a interesting day, today !
well ... I found two solution about this bug.
Start from this : I cannot use other pins on my esp32 because are all used. Free are 36 (and 39) but I already made pcb using 36 so I was forced to found a solution with this pin.

1. based on you advice, I used max_skip 200 and I modified irrecv.decode(&results) to irrecv.decode(&results,0,200,0) It seems work fine.
2. based on your second advice, I saw the hardware bug info and i added

#include "driver/adc.h"

void setup()
{
    adc_power_acquire();
}

and it seems work fine too (using normal irrecv.decode(&results))

I will be more sure of this test later, because now i tested them in a breadboard (not in my orginal pcb).
last : i tested a TSOP4138 too, but no differences with VS1838

I really HOPE that the situation of breadboard test will be the same on the pcb where all the code with related libraries will be loaded and not only 40 lines for testing :-)

[crankyoldgit]

adc_power_acquire();

You should use that fix instead of max_skip, as using max_skip will cause some protocols to be ignored, and some of the data you've supplied won't be corrected by max_skip as the random blips happen during a large section of a message.
Of course, ideally, don't use those Pins.

[crankyoldgit]

FYI, I've added this problem to the FAQ as well.

[fotosettore]

At last I used
adc_power_acquire();
because, as you said, some remote was more "hard in listening".
The adc at moment does not give problems. My sketch is always on 24h and in some days I will give here final info about running, to be certain all is ok.
Really I want to thanks you and NiKiZe because you were a real help to solve this problem

[fotosettore]

hi
after two full days of test 24h I confirm that all works fine using
adc_power_acquire();
thanks again for help