Help with ESP32

[davenlausa]

Hi Sebastien

Thanks for two amazing libraries. I got up and running on RF433any almost instantly and it worked really well. In RF433any, I measured the device parameters (a cheap door sensor sending three bytes on open and close) several times, using both 01_main and 03_output examples (and getting consistent results), and then successfully using 04_react_on_code. So easy!

When I copied the parameters in RF433recv and tried a few examples I just got no response to anything at all, like it wasn't receiving anything. I am using a TTGO T-Display ESP32 with Platformio parameters below (and the device specs).

I believe the library says the ESP32 is supported. I tried pins 15, 25, and 33 with no responses, and then tried on a Uno R3 board using Pin 2. On the R3 board, it worked perfectly on the first try.

I went back to the ESP32 and tried Pin 2, but again no luck.

Could it have something to do with the interrupt not being recognized or responded to on the T-Display? The RF433any library worked perfectly on the T-Display, so with the recv library it feels like either the interrupt is not triggering the evaluation at all, or the filtering parameters are not responding correctly to the signal. Is there any way to use the recv library in a temporary "output all" like the RF433any allows to see what's it's seeing and if the interrupt is even triggering?

Or do you have another is suggestion for what I might try for next steps?

Thanks again for the libraries and any suggestions.

[env:ttgo-lora32-v1] platform = espressif32 board = ttgo-lora32-v1 framework = arduino

lib_deps = sebmillet/RF433recv@^0.3.2

Data: 53 bd 0a

-----CODE START----- // [WRITE THE DEVICE NAME HERE] rf.register_Receiver( RFMOD_TRIBIT, // mod 14047, // initseq 0, // lo_prefix 0, // hi_prefix 0, // first_lo_ign 485, // lo_short 1348, // lo_long 0, // hi_short (0 => take lo_short) 0, // hi_long (0 => take lo_long) 464, // lo_last 14047, // sep 24 // nb_bits ); -----CODE END-----

Data: 53 bd 0e

-----CODE START----- // [WRITE THE DEVICE NAME HERE] rf.register_Receiver( RFMOD_TRIBIT, // mod 14099, // initseq 0, // lo_prefix 0, // hi_prefix 0, // first_lo_ign 483, // lo_short 1349, // lo_long 0, // hi_short (0 => take lo_short) 0, // hi_long (0 => take lo_long) 466, // lo_last 14098, // sep 24 // nb_bits ); -----CODE END-----

[sebmillet]

Hello

thanks for your interest in using this lib.

Difficult to say, as I do not have an ESP32 and don't know this model. What I would do to go forward is a bit tricky but I might help.

That is, I would:

1. Record the raw signal, using RF433snif
2. See (in SIMULATED mode) whether or not, RF433recv does read it correctly, by injecting RF433recv the recorded (during step 1) signal timings.

This'd allow in the first place, to ensure RF433recv has the rights parameters to decode signal.

Hopefully it would not work (!) as it'd mean, the decoding timings need be fixed. If ever such a SIMULATED mode would work, then it'd point to the direction of "something" not running properly with real interrupts.

In short: could you please record signal timings (RF433snif) and post it.

Thanks, Sébastien Millet

[sebmillet]

Sry I didn't ask -> when creating rf object, you can provide a second parameter or not, to explicit (or not) the interrupt number to use. You might do some trial-and-error testing in this area (not specifying second option, or specifying one...), maybe the "calculate interrupt number" logic is defeated on ESP32?

[davenlausa]

Hi Sebastien. Sorry it's taken me a while to collect the data. I wanted to run as much testing as possible without bothering you.

I tried several different values for the interrupt number with no luck.

sniff data.txt

The sniff data is attached. I'm pretty sure it's 10 repeats of the same value in two flavors: 0x53BD0A and 0x53BD0E.

The definitions I'm using for the test are:

define ASSERT_OUTPUT_TO_SERIAL

define ESP8266 // I added this because the ESP32 might be closer to the ESP8266, but it doesn't seem to make

                         // a difference that I can see

define SIMULATE_INTERRUPTS

The test program is attached, which counts to 11 to give me time to activate serial monitor, and it outputs "Before the wait value loop." but doesn't get to the "In this loop." afterwards. test_program.txt

In the SIMULATION definitions I tried to do the long repeating values for treg1, a single 24-bit sequence for treg2 and treg4 (treg3 is your original), but I'm not sure I've done everything necessary to "select" or "activate" them. simulation definition.txt

So fingers crossed it's a timing definition. 8-)

Thanks again.

[sebmillet]

Hello

when sending your timing sniff to RF433any, I get the below:

-----CODE START----- // [WRITE THE DEVICE NAME HERE] rf.register_Receiver( RFMOD_TRIBIT, // mod 14080, // initseq 0, // lo_prefix 0, // hi_prefix 0, // first_lo_ign 480, // lo_short 1336, // lo_long 0, // hi_short (0 => take lo_short) 0, // hi_long (0 => take lo_long) 448, // lo_last 13952, // sep 24 // nb_bits ); -----CODE END-----

Then when using the code above in RF433recv, and hacking test.ino a bit to manage proper timings and the receiver above, I get the below (I reused treg1/reg1): reg1: output_n=1: code received: 24 bits: [53 bd 0e]

So decoding works fine. I attached the three files used to simulate it = updated RF433recv.cpp (so that treg1 has your timings), updated test.ino (so that reg1 has proper decoder) and tmpout1.txt (test plan result ; of course the test "fails" but we are simply interested in tmpout1.txt to see what got decoded).

Could you try with the decoder defined above?

Regards, Sébastien Millet files.zip