Yeah so it seems like there might be different timeouts at different levels of the system. From what I’m seeing, some carriers are not actually storing packets for the entire TCP timeout and might only be keeping them for a couple seconds. The reason increasing the TCP timeout on our side (which we did to 90 seconds) helps is that on top of getting the carriers to try to store for longer, it also allows us to keep retrying during that timeout window so even if they’re not doing store and forward, we can hit the time window.
Basically, we’re trying to workaround some weird configs with the local operators.
We’re also going to continue to work with the operators and tweak things on our end so things should keep improving.
So I just tried to send TCP data to the device (pi3b+/nova) and it appears to be working now. So that’s a good sign.
I do have a question though:
I have been using the command line to operate the modem, which means I put the Nova into receive mode before trying to send a message. Wouldn’t putting the Nova into receive mode automatically bring the radio out of any sleep mode/eDRX it may be in? The Nova is only able to receive messages while in receive mode correct?
Is receive mode meant to be the default state that the radio spends most of its time in, except when it is sending messages?
Just wanted to follow-up on Reuben’s comment with some more information after several of us discussed this thread.
Support for Cat-M1 features like eDRX and other power saving modes on inbound connections is a little bit of a multi-faceted problem at the moment, with a combination of simultaneous issues :
Cat-M1 deployments are relatively new to several carriers, and still being rolled out for others
network equipment vendors and gateways are catching up in deploying extended power saving support at the packet delivery level
many networks do not currently implement the store-and-forward features proposed for M1 deployments
specifications around latency and other timings diverge from those of 3G and higher-category LTE
We are finishing the full implementation of eDRX and necessary network changes to accommodate modified timings needed for modules to wake up from Cat-M1 power saving states and receive inbound socket connections. These enhancements for Cat-M1 provide a similar experience as store-and-forward support would have provided, allowing inbound connection requests to go through quickly and successfully even for modules that were in an idle state on the radio channel at the time. This does not affect device-originated outbound connections, or the ability to leverage power savings in general, which are implemented. The upcoming improvements specifically address the waking of modules with device-terminated inbound connections (e.g. SpaceBridge or packets sent via API) and the ability to ensure the opening of a socket connection succeeds quickly and successfully with better handling of edge cases.
We pushed a preview of the upcoming improvements this week to help improve the experience for those who have programmed modules to listen on a socket over Cat-M1 and who were experiencing connection timeouts, by adjusting timings and improving error messages to be more helpful while troubleshooting. This is one of several improvements that we’re pushing out for Cat-M1 inbound connections support as we accommodate trending and now-maturing Cat-M1 operator deployments, noting that we are pushing changes out in phases, like the first one this week, to afford ample testing across a variety of operators and regions. (Also note that these changes are, again, only related to connections originating over SpaceBridge or our API and terminate on sockets that devices are listening on, but do not affect device-initiate outbound connections.)
Receive mode is more an abstraction by our python SDK where it uses AT commands to open a socket on the modem and listen on it. It is not the normal default state of the modem and the ublox does not automatically disable eDRX when listening on a socket