We’re in the planning stages for an e-mobility device that will have two superstates: HOME (connected to WiFi) and AWAY (connected to cellular). Its behavior in each state will be significantly different, including the frequency and volume of the data it syncs to Notehub.
A couple of questions regarding how we’ll need to handle this with the Notecard Cell+WiFi:
In terms of a definitive flag for determining which transport mode the Notecard is using at any given time, is it correct that the “cell”:“true” and “wifi”:“true” response members of the ‘card.status’ request would be the best choices to key off of for this state management? Or is there another Notecard flag somewhere (perhaps a single response member instead of two separate members) that would be better to use for this?
Does the Notecard configuration allow for any auto-switching of Notehub connection settings based on its current transport mode of Cell vs. WiFi? Or is this something the MCU host application will need to handle itself? For example, using a continuous connection with “sync”:true when connected to WiFi, but automatically switching to a periodic connection with longer inbound/outbound interval times when falling back to a Cellular connection.
In terms of a definitive flag for determining which transport mode the Notecard is using at any given time, is it correct that the “cell”:“true” and “wifi”:“true” response members of the ‘card.status’ request would be the best choices to key off of for this state management? Or is there another Notecard flag somewhere (perhaps a single response member instead of two separate members) that would be better to use for this?
The card.status is the best way to determine this. However, be careful, as those flags are only going to be set when those connections are active.
It’s very possible that neither "cell" and "wifi" will be set to true, especially when operating in periodic mode.
Does the Notecard configuration allow for any auto-switching of Notehub connection settings based on its current transport mode of Cell vs. WiFi? Or is this something the MCU host application will need to handle itself? For example, using a continuous connection with “sync”:true when connected to WiFi, but automatically switching to a periodic connection with longer inbound/outbound interval times when falling back to a Cellular connection.
There’s nothing built in for auto switching based on transport mode.
There is a built-in way to change your mode when USB/line power changes, which depending on your requirements might be something you’re able to leverage: Low Power Design - Blues Developers.
Are you running the project on line power or battery power?
Thanks TJ, that’s good to know. That could cause some issues if there are times when neither of those members are available in between syncs. What about the ‘net.modem’ member of the card.wireless response? It seems to return two distinct strings depending on cell/wifi mode. Will this value always be available in between syncs?
We’ll always be running on line power (supplied by a higher voltage battery and DC/DC converter), so the USB behavior won’t help us in this case. But good to know for the future.
What about the ‘net.modem’ member of the card.wireless response? It seems to return two distinct strings depending on cell/wifi mode. Will this value always be available in between syncs?
It’s still not guaranteed to always be there. I just tested a fallback (wifi → cell), and net was coming back as an empty object while I was waiting for the cellular connection.
Personally I’d add a third state to your firmware that’s something like NO_CONNECTION, where you do nothing but poll card.wireless or card.status for a successful connection.
If you’re operating in continuous mode you’re almost always going to have a connection, but it’s a good idea to handle for no connection because it does come up—for example when a device first starts up, or if a user places the device somewhere where neither cellular or Wi-Fi will work (e.g. a metal box, the woods, etc).