@pb66 I had read through the code countless times, and not spotted that after the initial wait that rf12_initialize(nodeID, RF_freq, networkGroup); was executed on every loop, because last_rf_rest was not updated. The problem with the firmware I had experienced now makes perfect sense in my own mind.
I have added your suggested line of code to update last_rf_rest and things are working as I would expect. Now that I have found it to work with the reset being done every 60 seconds, I am going to increase the size of the reset timer to something considerably less aggressive too. I’ve had a version of the firmware without the reset running for nearly 20 hours and not had a lockup of the RFM_69 module. I’m probably going to go for doing the reset hourly.
It would be good to get your fix merged into the official source, even if the view is taken that the 60 second resets should stay.
I think the reasoning behind the 60s resets was to react quickly to a lockout to minimise data loss. The lockouts that this “fix” is designed to remedy could happen after many months or a few days, rarely would it occur within hours (especially when you are watching it ).
Perhaps now you have proved it’s necessity (under some even if not all circumstances) it might be considered? I would personally of liked to have gotten to bottom of the issue rather than add the “fix”, as it happens, there were other changes made to JeeLib at the same time this “fix” was reintroduced so we don’t actually even know for sure if it is still needed.
I’ve added a link back here to the github issue in hope it might get looked at again.
I think this is a really good compromise, or perhaps even 6hrs or daily? The problem with resetting every 60s is that you might never recognise if/when an issue exists, conversely without the reset you could lose many days of data before noticing a lockup. If we get reports of rfm data “holes” of up to an hour (or a day might be more noticeable) work could continue to locate and remedy the source of the lockups, however my guess is the 60s reset will most likely be left in.
@pb66
Remember that about the time the “fix” was introduced, we asked JeeLabs to elucidate what they meant by
[you can] check whether a new RFM12B packet was received when you are ready for it. The simplest way is to add a call to rf12_recvDone() in the loop() body, and then simply make sure that the loop will be traversed “reasonably often”.
The purpose of rf12_recvDone() is explained:
The central RF12 driver check is the call:
if (rf12_recvDone()) ...
From the caller’s perspective, its task is to find out whether a new packet has been received since the last call. From the RF12’s perspective, however, its task is to keep going and track which state the driver is currently in.
).