It’s great to know that we can send messages back to a device through a connected SIM card.
My question is: whats the cost or cons in having a network connected 24/7.
If I had something like this in python on a linux SoC, like Raspi, what are the implications?
hologram = HologramCloud(dict(), network=‘cellular’)
result = hologram.network.connect()
hologram.openReceiveSocket()
This allows me to always be listening for incoming messages. But, my understanding of cellular is still coming along. Are cellular modules designed to always be on? Is there concerns, hardware wise, in keeping a connection always going? Does it consume a lot of energy (and therefore not ideal on battery power)? Is it using a lot of cellular data to stay open? Does it stay open reliably 24/7, or does it tend to disconnect randomly? Is a ‘always connected’ cellular modem common place in IoT scenarios?
I know thats a lot of questions, but it seems pertinent to ask considering many will be looking to receive data into their devices pushed from cloud driven events.
Using:
Raspi Compute 3+ with a U-Blox SARA R410M module
The main downside is the energy usage as you mentioned. It’s going to use a lot more power to stay connected all the time rather than turn the radio on once an hour or whatever you need to send the message.
That being said, if you need it to be constantly listening for messages that’s basically your only option to get a realtime response to the message. If you’re ok with not getting the message immediately you can switch to using SMS and then turn the radio on every few minutes for a minute or so just to receive any SMS messages that might be queued up.
On the outbound side, if you’re sending very frequently, like every second, then it may make sense to leave the radio on all the time as at that point you’re not really saving much.
The other concern is that if the connection is idle for hours with no data either direction, sometimes the local tower might disconnect you. You’ll want to check every so often if you’re still connected and reconnect to make sure things stay up.
There is very little data usage inherent in keeping the connection up. Would mainly just be your pings every so often making sure the connection is still going. That being said, you’ll want to make sure that the raspberry pi doesn’t have automatic updates turned on as if those run over the cell connection while it’s up you could rack up a ton of charges.
As for the modem hardware itself, it’s totally safe to leave it turned on all the time.
Hi,
You suggest to, “check every so often if your’re still connected…” How would you recommend performing this check?
On a Linux system, once a PPP connection is established, the Nova cannot respond to any AT commands–or am I mistaken? If I can’t send AT commands to check the Nova’s status, how can I know if the connection has dropped?
Compounding this problem is that even when the Nova does lose its cellular connection, it tries to hide this fact in the hope that it will regain a connection. During the period without a connection, the device caches data to send when it regains a connection. If, however, the device is powered down before it regains the connection it appears the cached data is lost.
The fundamental problem, imho, is that the SARA R410 can only be accessed via a single dev (e.g. /dev/USB2). A $5 ZTE MF190 USB 3G dongle doesn’t have this limitation.
I’ll be most grateful for any helpful suggestions.
Thank you very much for your bash script. I had done something similar early on. My script checked for a ppp0 stanza using ifconfig. I think your script is more efficient…
But, here’s the problem: the Nova tries to hide the fact that it doesn’t have a connection so the ppp0 network interface doesn’t get torn down, possibly for a very long time.
If you’re skeptical, here’s the experiment I have conducted (I just did it again to be sure)…
Preparation
You’ll need a way to be able to reduce the signal strength to/from the Nova on demand. I did this by making a poor-man’s “Faraday Cage” using aluminum foil. My Nova is in a 3D-printed case I made. The case also includes a u.fl-to-SMA adapter cable, so the SMA connector sticks out of the case at one end (and the USB connector sticks out the other end). I have attached a very short (2") SMA antenna.
By wrapping the case in numerous layers of aluminum foil, coupled with the poor performance of the 2" antenna, I can weaken the signal to the point where my server is no longer receiving any data from the Nova. Furthermore, I can slide the case into the foil, to get the device to stop sending, and also slide it out to strengthen the signal and regain connectivity.
Experiment
Okay, here’s the experiment:
establish a connection from the Nova to the server and watch data come in (in my case the data are GPS location packets every 30 seconds)
run your bash script (“ip link show ppp0”) on the device with the Nova and observer that ppp0 is UP.
slide the Nova into the Faraday cage and note that data is no longer arriving at the server. Wait for a few minutes to be sure no data is arriving. (My device, attached to the Nova, displays console messages when it sends location packets, and it continues to show these messages while no data is arriving at the server)
run your script (“ip link show ppp0”) and observe that it still indicates that ppp0 is UP, long after data stopped arriving at the server.
slide the Nova back out of the Faraday cage and observe that, suddenly, a bunch of location packets arrive at the server and continue to arrive (every 30 secs in my case).
run your script again and see that ppp0 is UP.
Interpretation of Results
the Nova lost connectivity while in the Faraday cage
the shell script never detected that connectivity was lost
the Nova cached the data packets it was asked to send during the period where it didn’t have connectivity. (So, it must have known it lost connectivity.)
when the Nova regained connectivity it sent the cached packets
I’ll add that in a separate experiment, where I power off the Nova while it has cached packets, those packets are lost. That is, when the Nova is powered up and connected it does not send the previously cached packets.
Conclusion
The shell script you offered, like the one I wrote in past, does not reliably detect whether or not there is ppp connectivity. With respect to whether or not there is a ppp connection, the script gives false positives (but reliable negatives).
I have investigated two other approaches, but I won’t trouble you with the details unless you are interested.
First all, thanks @Reuben for your answers. Good clarification. For my purposes, turning on the radio every 15 min or so to check for any incoming SMS messages should work nicely. Do you have an idea how long SMS messages are cached? And, if that eats up any data to turn on and check for incoming SMS?
To your situation, @mbrenner, might I suggest using ‘hologram modem signal’ in conjunction with a cron job checking for a ppp network. That would at least allow you to become aware you’re in a “Faraday Cage”.
But it may not solve the problem where the operator (Verizon, AT&T, etc) drops the connection from inactivity.
Thanks for the suggestion but, as I mentioned, once a ppp connection is established it is NOT possible to sent AT commands to the Nova. The “hologram modem signal” command, under the covers, sends AT commands to request signal strength information:
AT+CSQ: gets RSRP
AT+CESQ: gets RSRQ, RSRP
The Nova can detect signal strength, but not the reason(s) behind the signal strength. From the device’s point of view, there is no detectable difference between being inside a Faraday Cage or just very far from a tower.
I’ll add that simply disconnecting the antenna from the Nova might, at first, seem a reasonable way to simulate a very weak signal, but the Nova is able to detect whether or not an antenna is attached and it may (or may not) be programmed to behave differently (as compared to a weak signal). That’s the reason to use a Faraday cage: the device does not know it’s in one.
Sorry I missed this post. Simply turning on the radio doesn’t use data, but if the device starts routing traffic over it then it could so you should be careful of that. I believe SMS stays around for longer than 15 minutes so that time interval should be ok. If it doesn’t seem to work, then let us know.