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
If the application triggers a transmission in very slow interval (multiple hours, or even days), and the device sleeps in between, the transmission hangs up.
Identified the root cause: The point in time, when transmission is allowed again, is controlled by globalDutyAvail. This is intended to be a value in the future, if we want to wait, and it is a time in the past, when it is allowed to transmit. But if we have for several hours no transmission, then the globalDutyAvail will be back in the past more and more, and at about 9hours it will wrap-around, and the transmission will be forbidden, because it looks like that the globalDutyAvail is in the future.
Possible bug fix: We need to avoid that globalDutyAvail is too far in the past. This can be reached by cyclically checking and correction of the global globalDutyAvail, and also the band-specific avail times.
Environment
Version of LMIC being used 3.2.0 (sorry, this is very old, but my impression is that this issue is still present)
Version of Arduino IDE being used. 1.8.5
Network provider: The Things Network
Region: EU868
Board: selfmade Arduino pro mini with RFM95W
CPU: AVR
Radio RFM95W
To Reproduce
Trigger a transmission or multiple. Wait, until globalDutyAvail turns from "future" into "past", and after several hours it wraps-around into "future". Try a transmission, this is blocked because the globalDutyAvail is seems as "not yet reached".
Expected behavior
No matter how long are the gaps between two transmissions, the globalDutyAvail shall never wrap around from the past to the future.
Describe the bug
If the application triggers a transmission in very slow interval (multiple hours, or even days), and the device sleeps in between, the transmission hangs up.
Identified the root cause: The point in time, when transmission is allowed again, is controlled by globalDutyAvail. This is intended to be a value in the future, if we want to wait, and it is a time in the past, when it is allowed to transmit. But if we have for several hours no transmission, then the globalDutyAvail will be back in the past more and more, and at about 9hours it will wrap-around, and the transmission will be forbidden, because it looks like that the globalDutyAvail is in the future.
Possible bug fix: We need to avoid that globalDutyAvail is too far in the past. This can be reached by cyclically checking and correction of the global globalDutyAvail, and also the band-specific avail times.
Environment
To Reproduce
Trigger a transmission or multiple. Wait, until globalDutyAvail turns from "future" into "past", and after several hours it wraps-around into "future". Try a transmission, this is blocked because the globalDutyAvail is seems as "not yet reached".
Expected behavior
No matter how long are the gaps between two transmissions, the globalDutyAvail shall never wrap around from the past to the future.
Additional context
I prepared and tested a fix, see uhi22@c9b6bd6
The text was updated successfully, but these errors were encountered: