rtl_433_Callback stops receiving messages

[mozgy]

Hello,

any idea why rtl_433_Callback stops receiving messages after some time?

I'm trying to plot sensor data and, well picture describes it the best -

it's especially visible in RSSI part.
My loop() is -

void loop( void ) {

  ArduinoOTA.handle();
  webServer.handleClient();
  rf.loop();

}

esp32 is working fine all the time ..

[NorthernMan54]

I had noticed a similar issue where after an extended period of time the CC1101 simply goes deaf, and sending a command to the CC1101 would wake it up again. I have spent some time looking into it, but have not been able to find the cause and trigger for the issue, I was looking at the various CC1101 registers thinking it may have entered sleep mode to no avail. I find that after about 12 to 24 hours it occurs.

To work around the issue I added a simple counter in the void rtl_433_ESP::loop() to set the frequency every 2000 loops

ie

  if (_enabledReceiver)
  {

  ledFlash++;        // workaround for a deaf CC1101
  if (ledFlash > 2000)
    {
      ledFlash = 0;
      ELECHOUSE_cc1101.SetRx(433.92); // set Receive on
    }                        // workaround for a deaf CC1101

    currentRssi = ELECHOUSE_cc1101.getRssi();
    if (currentRssi > minimumRssi)

PS The counter is called ledFlash as I had started with blinking the LED thinking something in the code stopped calling getRssi

[mozgy]

Looks like it's documented errata -

RXFIFO_OVERFLOW Issue Radio stays in RX state instead of entering RXFIFO_OVERFLOW state

Workaround is -

When the radio is stuck in RX state like this, it will draw current as in RX state, but it will
not be able to receive any more data. The only way to get out of this state is to issue an
SIDLE strobe and then flush the FIFO (SFRX).

Gonna study library code more ..

[Dattel]

Same problem here....
CC1101 goes into a deaf state - this occures about 10-15 minutes after boot.
Using OpenMqttGateway with rtl_433 plugin and TI-CC1101 module.

Your fix with frequently SetRX to prevent this state seems to work for me as well... currently running about 12h without problem.

Anything i can contribute to investigate?

[Dattel]

Hey again... But it seems, that the CC1101 continues entering the deaf state randomly after 1-2 days... are you aware of these?

[NorthernMan54]

@Dattel - Is this beyond the current workaround ?

[Dattel]

Unfortunately yes, today i came home and the recipient-indication-lamp was on continuously... Last value received hours ago. :-(

no serial connection at that time, so i can't provide any data.. It was not the first time, the days before i thought there was some problem with the power, so i just restarted the device.

[NorthernMan54]

That’s weird as mine have been stable since I applied the work around.

…

On Nov 15, 2021, at 2:44 PM, Dattel ***@***.***> wrote:  Unfortunately yes, today i came home and the recipient-indication-lamp was on continuously... Last value received hours ago. :-( — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[Dattel]

i just attached a screenlog session on ttyUSB and try to write the output from the next days to a file :-) maybe that helps

But Wait a minute: maybe by build-process reverted my change and it's fixed... try to reflash the device and wait for some days..

[Dattel]

Sorry for the confusion...
I updated my device recently for some testings and the build-process reverted the changes, so i assumed to have the patch installed, but it wasn't...
So I rebuild with the included fix from above and the device was running fine for 24h (and possibly more)- much more flickering on the indication LED now - i interpret this as a positive sign. So i finally detached the ttyUSB console yesterday evening and the device is still running fine. Will give feedback in case anything stange occurs.

[NorthernMan54]

Latest release enables this workaround by default #18