I have several notecards in the same place that connect using Cat-M1 and suddenly one of them has changed to GSM.
- Will this notecard eventually do a new scan and switch back to Cat-M1?
- What would be the conditions for a notecard to do a new scan?
- What could the host processor do to force the notecard to do a new scan?
In which country you are located? I ask because only a few countries have both M1 and GSM as options, so this is a curious issue you’ve run into!
Otherwise, to answer your question, your Notecard will stay on its existing RAT until there is a failure, then it will try another scan. You can also perform a card.restart to restart the Notecard and have it perform a new scan.
The notecards are in Canada.
Is there a way to force a restart with a command from the notehub directly to the notecard without programming the host MCU to scan an inbound queue and perform the restart command?
There is no such command available, but it’s an interesting idea so I’ll be letting our product team know about your interest.
Another option that just occurred to us is to use the card.wireless API to force the Notecard to use M1. For instance:
I thought about forcing the mode but, in fact, I only want to use the most efficient “RAT” without preventing communication if, for some reason, M1 is not available.
In my design, I have wired the notecard reset pin to a GPIO of the MCU. What would be the differences between a hard reset and the command card.restart?
card.restart is preferred over a hard reset as it flushes all in-memory buffers before restarting (this includes configuration data, modem data usage counters, new notes, etc). All of that would be lost with a hard reset.
If you reset the Notecard with a soft or hard reset, the first sync after booting will transfer much more data than a typical sync, as we try to ensure that we are in sync with the Notehub and we re-authenticate over TLS. Therefore, we really don’t recommend heading down this path if you foresee resetting on a regular basis.
Are you looking at the RAT property in
_env.dbs? If it’s the latter, the data in that event can be stale and not 100% up to date.
I’m looking at the _session.qo.
Thank you for the info.