40

It was indeed added as a temp fix against occasional rfm lockups. But there is something odd about that “fix” as reading the code it actually resets after the first 60s from power up and then every single main loop iteration after that because the last reset counter is never incremented so now minus 0 will always be greater than the 60000ms interval.

I found it difficult to believe this aggressive resetting wasn’t causing issues and pointed out this error on a couple of occasions, but I’ve never heard of any actual cases where it was an issue, perhaps the pre-compiled hex uses a specific combination of Libs and/or PIO compiles the code in a way that this doesn’t manifest as a problem.

@adtyne Instead of deleting the reset line, try adding a line to set last_rf_rest (note the typo) when the rfm is reset to see if that yields different results eg

if ((now - last_rf_rest) > RF_RESET_PERIOD) {
      last_rf_rest = now;
      rf12_initialize(nodeID, RF_freq, networkGroup);                             // Periodically reset RFM69CW to keep it alive :-(
    }

I don’t personally run any FW’s that have this rather crude 60s reset in as I have never had the issue with rfm’s locking out, it isn’t an issue that effected everyone so you maybe ok to just remove the reset, perhaps this too is a quirk of PIO and or the pre-compiled hex’s? We never got to the bottom of the lockups due to this “fix” being rolled out!

1 Like