You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The reason will be displayed to describe this comment to others. Learn more.
In its simplest form its what is described in EnviroDIY/ModularSensors#347 Will add more detail there -
but for TinyGSM is an update that doesn't do ANY updates to flash after system initializations.
Its in my fork, (not a PR) and it has extra debugging added to trace what is calling waitResponse(caller_fn_id,timeout_ms) - called in so many place difficutl to decode debug.
I find it easier to compare with Meld classic 3.18.3 to see the changes that are not related to waitResponse()
My tracking in testing neilh10/ModularSensors#21
In the end, possibly the real fix is in 2) DigiXbeeWiFi forcing a sw reset.
ee6f129There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you explain this to me?
ee6f129There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In its simplest form its what is described in EnviroDIY/ModularSensors#347 Will add more detail there -
but for TinyGSM is an update that doesn't do ANY updates to flash after system initializations.
Its in my fork, (not a PR) and it has extra debugging added to trace what is calling waitResponse(caller_fn_id,timeout_ms) - called in so many place difficutl to decode debug.
I find it easier to compare with Meld classic 3.18.3 to see the changes that are not related to waitResponse()
My tracking in testing neilh10/ModularSensors#21
In the end, possibly the real fix is in 2) DigiXbeeWiFi forcing a sw reset.
I have it running with 0.32.2/Mayfly1a3 pushing to https://monitormywatershed.org/sites/tu_rc_test07/