Is there a set by step guide to setting up Hologram so that the device will have automatic and continuous connectivity as long as there is a compatible carrier in range?
I’ve seen various mentions here that sometimes it is necessary to run commands at startup to initialize a connection to the cellular network. I’ve also seen various people using cron jobs to test for connectivity and periodically restart the Hologram link. Are these measures necessary to have a reliable connection? If so, is there a single source that describes best practices to follow to have a reliable connection so I make sure I do not miss any?
I am specifically trying to set up RaspberryPi’s with Hologram supplied Nova modems such that I am always able to SSH into them, but having no luck. I can get it to work on my desk, but once out in the field it becomes unreachable in a few days even though there is good coverage at the remote location. I can not even figure out how to tell from the Dashboard if the device is still in communication with the cellular network.
I would love if all information regarding continuous connectivity could be compiled somewhere. I think this is the one major issue holding back the success of lots of hologram applications.
I too would appreciate learning more sophisticated methods then cron rebooting a raspberry pi on a regular basis. I’ve had to include this in my script on top of cron jobs testing for Hologram connection.
I have to have remote clients reboot the equipment at least once per week.
For reference if you want the modem to be able to accept data / commands from the cloud it would need to setup a listening socket. This is true for cloud-> device messaging, revere SSH, and Spacebridge. What I am guess is happening is that Hologram’s SDK setup a listening socket but then for some reason it closes (sh*t happens, that’s ok) but there is there is no way to detect or poll for this state so neither Hologram’s SDK nor the users can easily react to a closed connection and re-open.
What would be great is if:
U-Blox gave a URC whenever a listening socket is closed
or 2nd best would be if there as an AT command to poll for listening sockets, atleast this wold allow the SDK or user to poll very often and make sure the connection is up or reset it if closed.
EDIT: I should have read my old post more closely. It looks like you can query socket state for TCP sockets with AT+USOCTL=<socket#>,10
So a possible solution is:
periodically (like could be every 15s) run AT+USOCTL=<socket#>,10 and make sure socket is in a valid state (likely Listening, but could be one of the other TCP states if data transfer is active)
if above is an invalid state, the module is not listening, close the <socket#> and re-configure as needed, something like AT+USOCR=6 then AT+USOLI=<socket#>,22 (protocol = TCP, listen on port = 22)
Thank you for the feedback and all the helpful comments on this thread. I wanted to chime in and provide some more information here to help everyone understand the issue and how to resolve it. At its core, the cellular network was designed for mobile communications with devices that moved around and switched from cell to cell, it was not designed for long term static connections. For this reason, and to preserve their resources, cellular towers will automatically tear down sessions that have been inactive for some time and have not been properly terminated by the cellular device. This behavior is universal across cellular towers and carriers and is not something unique to Hologram SIMs. Now, this becomes an issue when you want to have continuous inbound access to your device like you would if it were using a wired connection or WiFi.
There are a few different approaches to keeping your device connected. One would be to have your device send keep alive messages to avoid the tower deeming your device as inactive and tearing down it’s session. Otherwise it’s common for cellular devices to have to implement a watchdog to reconnect when a connection is lost (your cellphone does this all the time, for instance). The use case and device characteristics will likely determine which method is optimal for your specific situation.
For users using our SDK, please note that the send command should be use as a stand alone command and does not need the device to be in a PPP session by issuing the connect command.
For anyone using Cat-M1 I really like @AndrewGifft’s answer above.
SMS should go through as long as you are registered to the network.
My advice would be to do both, and code with any sort of reliable uptime would include:
Periodic detecting of network connectivity (AT+CREG? being 1 or 5) AND attempting to re-connect if not connected. (you can listen and react to the URC as well if setup)
Periodic detecting of a closed or non-listening socket (see my previous post) AND attempting to re-establish listening socket.
Potentially different communication paths to establish manual re-connection, such as SMS as you mentioned. Others would be a watchdog missing a heartbeat, failed outgoing messages, etc.
Just remember nothing is 100%reliable. If you want to ensure a high uptime for any device you will need code to detect and recover from faults. The tower disconnecting stale data sessions is only 1 such fault, even if it is the most common, but there are many other reasons for a listening socket, or network connectivity to be interrupted.