Description
My device is in the field and when it first powers on it is able to send messages via NTN (satellite). I see the expected messages at their expected intervals. But after a while, it just stops transmitting them over NTN.
If the device restarts, it will transmit a bunch of messages that had been waiting to be sent, and continue to transmit new messages for a while, but then halt again.
What is going on?
Diagnosis
Here’s how you can diagnose this particular issue. If you see the following behaviors, then likely you are experiencing this issue and you can attempt the workaround listed below.
-
The Notecard is configured to use cellular connections as a primary transport method with NTN as a fallback
For example:{"req":"card.transport","method":"cell-ntn"} -
The Notecard successfully sends Notes to Notehub via NTN and suddenly stops sending Notes via NTN after a given interval where the interval appears to be consistent.
This could be as few as a single Note. The consistent interval may be harder to discern depending on the application. By default it would be 60 minutes, but it would depend on the value of the
secondsfield if it was applied to thecard.transportrequest above. -
The device resumes connecting via NTN after one of the following events:
- Notecard restart
- Notecard connected to Notehub via a cellular connection
- Issuing a
hub.setrequest that changed the device configuration - Issuing a
{"req":"hub.sync","allow":true}request - Issuing a
{"req":"card.wireless.penalty","reset":true}
Or any other request or behavior that may cancel the cellular network registration penalty box.
-
If the device successfully reconnects, it sends up a myriad of Notes that had been waiting on the Notecard until it successfully connected.
The number of Notes is going to depend on your application.
Workarounds
Option 1:
For urgent messages force a sync with {"req":"hub.sync","allow":true}
A common use case for NTN is to only use it to send critical messages or alerts. In this scenario use:
{"req":"note.add","body":{"message":"here's my alert message"}}
followed by
{"req":"hub.sync","allow":true}
Notice the note.add request does not include the "sync":true flag. While common for urgent messages or alerts, you cannot force a sync attempt using this flag on the note.add request.
Option 2
Reach out to Blues Support. The above is predicated on the ability to update your device firmware and may require physical access to your device.
If the above option isn’t available to you, please reach out to the Blues Support team to see how we can help, as there may be other options.
Why is this happening
When using NTN as a fallback, there is a timer that starts when the Notecard transitions to NTN mode. Once this timer expires the Notecard will try cellular mode again. This enables a device to switch back to a cheaper cellular mode even though it’s successfully able to connect via satellite.
Depending on the Notecard configuration, if the Notecard fails to connect to the cellular network after transitioning from NTN mode, it may enter the cellular network registration penalty box.
Once the Notecard is in the penalty box, it won’t attempt using the NTN fallback.
Removing the Notecard from the penalty box resolves the issue. This is why you see a number of possible scenarios where NTN transition resumes. The most common way is via a Notecard restart.
The network registration penalty box is a critical Notecard feature. It prevents devices from adversely impacting cellular networks with constant pings, and preserves battery power for low power applications.
Will this be fixed in Notecard firmware?
Blues recognizes this is an important behavior and plans to incorporate fixes to Notecard firmware updates. Since there are viable workarounds, we do not plan to issue emergency patches but rather provide updates as part of the standard firmware release process.
If you are experiencing a critical issue or have questions about firmware updates, please reach out to the Blues Support team for assistance.