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.
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?
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?
A 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 _session.qo or _env.dbs? If it’s the latter, the data in that event can be stale and not 100% up to date.