I want to implement a feature in our product whereby we provide near-real time information about cellular signal strength to customers during the installation process. The device is being installed in an area of a building that often has poor cellular connectivity, so having the ability to report signal strength frequently during the installation process enables the customer to test different locations and place the device in the best possible location.
To that end, I have been testing the card.wireless API call and notice that it does not update signal strength very frequently after establishing a connection with the cell tower. It seems that I’m able to refresh it by invoking hub.set with mode = "off"to force the Notecard to disconnect from the cell tower, then calling hub.set with mode = "continuous" to reconnect to the cell tower.
Implementing this logic seems risky, as I want to avoid configuring the Notecard to not connect to the cell tower and permanently losing contact with the device. However, I can’t seem to have the Notecard refresh the cellular signal strength values any other way.
Is there an alternative method for updating the card.wireless info without force disconnecting the Notecard from the cell tower? In other modems I’ve been able to send AT commands to get the latest signal strength info, so I believe there should not be any technical limitations here.
As you’re seeing, card.wireless is always going to return information from the most recent connection (not from the moment at which the request is made). The only way to get “current” signal strength is to do as you’re proposing (although I agree that’s not advisable) or to use periodic mode in hub.set and re-establish connections at a shorter cadence with outbound or voutbound.
I got one thing wrong: if using periodic mode, use inbound or vinbound as outbound will only establish a connection if there are pending Notes to sync! Alternatively you can keep using continuous mode, but set a short duration of 2 minutes or so.
Could I possibly turn this into a feature request for the Notecard? Conceptually, it would be great to send a request like {"req": "card.wireless", "refresh": True} which causes the Notecard to get the latest cellular signal quality numbers without disconnecting from the cell tower and ending the session.
Currently, the latency between refreshing the latest cell signal quality stats and routing them through a Notehub Route is something like 2-3 minutes in a typical scenario. For our application, this is pretty costly. The cost of labor to install the devices onto an elevator can be hundreds of dollars an hour, so the difference between a 5-minute installation process and a 15-minute installation process is significant at scale. Being able to get the latest cell signal quality every 15-30 seconds for a short period of time during the setup process would have a big impact on the cost of installation in our case.
As we are looking ahead to shipping 1K+ devices in the next few months, we are focusing in on developing a smooth and (relatively) painless installation process. We can already see that this kind of latency will be a big pain point for our customers (think: move the device to location A, wait for 5 minutes, check our app to see the signal strength, and repeat until you find a good spot for the device). Being able to install a set of these on a bank of elevators in an hour vs. over 4 hours is a big deal for us.
Hi @JordanAbacus ,
Thank you for this suggestion. I agree that it would be extremely valuable to be able to monitor the cellular signal during installation. Unfortunately it is not trivial to modify card.wireless for rapid updates in our hardware / firmware architecture.
However we are working on a near term solution for the installation scenario you described.
I understand your application involves a host CPU that is communicating with the Notecard via i2c or LPUART ? How would the host CPU handle a situation where the Notecard stopped responding to JSON requests on i2c and LPUART during the installation signal check ? I ask because to provide the rapid signal strength updates we may have to lock the host CPU out so that it is not fighting the Notecard and trying to start a data session.