mfw 1.3.5, NCS 2.4.1
I received a
+CGEV: APNRATECTRL STAT 0,1,86307
from the modem.
I'm wondering, if that is processed by a pdn_event_handler_t.
If not, how does the application know that?
mfw 1.3.5, NCS 2.4.1
I received a
+CGEV: APNRATECTRL STAT 0,1,86307
from the modem.
I'm wondering, if that is processed by a pdn_event_handler_t.
If not, how does the application know that?
I use
Indeed, that's non-blocking; this seems like a bug to me (in libmodem).
I have a tentative fix which I would like to share with you, it would be very helpful if you could give it a go. Can you please create a private ticket for this?
Yes. I will do that in 2h.
I opened that private ticket.
In the meantime, my device is able to "overcome" the triggered rate-limit.
Assuming the idea behind that is to prevent devices from "flushing too much unintended data", in my case it's simply triggered by a FOTA. That results in two questions for me:
- if the device (or the device owner) should decide, if the traffic is intended or unintended, I would consider to be able to "delegate" that to a server. But with the current API, the app will mainly get noticed, when the limit is already reached. If the app get noticed "short before", server communication will still be possible and with that it will easier to make usage of that "rate limit / cost limiting" feature. I see therefore two extension, a "pre limit warning" event, and to report more details in %APNRATECTRL when the status is "0". Adding the remaining "number of packets" and remaining time of the period will help to improve such application specific usage.
- if this "rate limit" isn't a "hard limit", is it really required to switch the modem off and on? Or are other implementations also possible, e.g. a reset command for the "rate limit" state?