Does using GPIO2 (onboard LED) for GDO0 interfere with signal capture?

[BatrakovSV]

Hi, thank you for your great work on this project

// defining PINs set for ESP32 WROOM module

byte sck = 18; // GPIO 18
byte miso = 19; // GPIO 19
byte mosi = 23; // GPIO 23
byte ss = 5; // GPIO 5
int gdo0 = 2; // GPIO 2
int gdo2 = 4; // GPIO 4

I see that GDO0 is assigned to GPIO2, which is connected to the onboard LED on ESP32 DevKit V1 boards. When I press a button on my remote, the LED lights up — which is actually helpful as a visual indicator.

However, I’m wondering: does the fact that an LED is physically connected to GDO0 (GPIO2) interfere in any way with accurate signal capture or timing? In other words, could the onboard LED’s presence on this pin potentially affect the reliability of decoding or receiving RF data?

Thanks in advance for any clarification!

[BatrakovSV]

Hi,
I'm using the cc1101-tool firmware on an ESP32 Devkit V1 with a CC1101 module to capture data from a remote control using the IC PT2240 chip (433.92 MHz, OOK, 181 baud, 24-bit fixed code). The setup is functional, and recraw 100 successfully records the signal, which can be replayed with playraw 100. However, rx and rxraw do not work as expected:
Issue with rx:
Using rx with the following settings, no data appears in the serial monitor when pressing the remote button:

init
setmhz 433.92
setmodulation 2
setrxbw 250
setdrate 0.2
setsyncmode 0
setpktformat 3
setlengthconfig 2
setmanchester 0
setwhitedata 0
rx

The PT2240 signal is ~181 baud (per MiniKeytoll), and I tried setdrate 0.2 (200 baud) to match. Is there a specific setdrate or setting required for such low-speed OOK signals in rx mode?

Issue with rxraw:
The rxraw 100 command starts but immediately stops:

rxraw 100
Sniffer enabled...
Stopping the sniffer.

This happens regardless of the microsecond value (tried 100, 200, 500). Is this a known bug in the rxraw implementation? Could it be related to setpktformat 3 (asynchronous mode) or another setting?

The RSSI is strong (~-70 dBm), and the remote is transmitting. The recraw 100 command works, so the hardware and frequency are correct. Any advice on getting rx or rxraw to capture the PT2240 signal in real-time?
Firmware: [commit hash or branch, e.g., main branch of mcore1976/cc1101-tool]
Hardware: ESP32 Devkit V1, CC1101 module
Serial baud rate: 115200
Thanks for your help!

19:40:25.924 -> 0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
19:40:25.924 -> configsip: 0, SPIWP:0xee
19:40:25.924 -> clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
19:40:25.924 -> mode:DIO, clock div:1
19:40:25.924 -> load:0x3fff0030,len:4660
19:40:25.924 -> load:0x40078000,len:15576
19:40:25.924 -> load:0x40080400,len:4
19:40:25.924 -> load:0x40080404,len:3152
19:40:25.924 -> entry 0x400805a0
19:40:26.120 -> CC1101 terminal tool connected, use 'help' for list of commands...
19:40:26.120 ->

19:40:26.120 -> (C) Adam Loboda 2023
19:40:26.120 ->

19:40:26.120 ->
19:40:26.152 -> cc1101 initialized. Connection OK
19:40:26.152 ->

19:40:33.295 -> echo 1
19:40:33.295 ->
19:40:40.977 -> rxraw 100
19:40:40.977 ->
19:40:40.977 -> Sniffer enabled...
19:40:40.977 ->
19:40:40.977 -> Stopping the sniffer.
19:40:40.977 ->
19:40:40.977 ->

[mcore1976]

Hi, I would suggest to try with Arduino Pro Micro. With the ESP32 boards I was having a lot of issues including random data coming through its pins. ESP boards do have also watchdog which interrupts the code in unexpected moments and inflicts errors while capturing the radio data. In other words it is preventing from taking accurate capture of the messages.

[BatrakovSV]

Hi, I would suggest to try with Arduino Pro Micro. With the ESP32 boards I was having a lot of issues including random data coming through its pins. ESP boards do have also watchdog which interrupts the code in unexpected moments and inflicts errors while capturing the radio data. In other words it is preventing from taking accurate capture of the messages.

This is how the sniffer (rxraw) is implemented. However, I cannot capture any packets in RX mode. Perhaps the settings need adjustment, or there is an issue with the device configuration.

`} else if (strcmp_P(command, PSTR("rxraw")) == 0) {
setting = atoi(cmdline);
if (setting > 0) {
ELECHOUSE_cc1101.setCCMode(0);
ELECHOUSE_cc1101.setPktFormat(3);
ELECHOUSE_cc1101.SetRx();
Serial.println(F("\r\nSniffer enabled..."));
pinMode(gdo0, INPUT);

    // Clearing the Serial buffer to remove residual characters from the command
    while (Serial.available()) {
        Serial.read();
    }

    // While the user does not enter a new character, we remain in sniffer mode
    while (!Serial.available()) {
        for (int i = 0; i < RECORDINGBUFFERSIZE; i++) { 
            byte receivedbyte = 0;
            for (int j = 7; j >= 0; j--) {  // Collecting 8 bits into a byte
                bitWrite(receivedbyte, j, digitalRead(gdo0));
                delayMicroseconds(setting);
            }
            bigrecordingbuffer[i] = receivedbyte;
        }
        // Every 32 bytes, we output them in hexadecimal format
        for (int i = 0; i < RECORDINGBUFFERSIZE; i += 32) { 
            asciitohex(&bigrecordingbuffer[i], textbuffer, 32);
            Serial.print((char *)textbuffer);
        }
    }
    Serial.println(F("\r\nStopping the sniffer.\r\n"));
    // Returning settings to normal
    ELECHOUSE_cc1101.setCCMode(1); 
    ELECHOUSE_cc1101.setPktFormat(0);
    ELECHOUSE_cc1101.SetRx();
} else {
    Serial.println(F("Wrong parameters."));
}

}
`

[mcore1976]

Yes, on this board even if I clear the Serial input buffer as above in the code, it still gets some data while the sniffer code is operating. This is why it is stopping in a second. I do have a lot of issues with these chinese chips... I think the remedy would be to add some hardware button to stop the recording