Roaming SIM card from Soracom sluggish on NB-IoT

[Burt]

Hi,

If I use a roaming Soracom SIM card in NB-IoT mode and with asset_tracker_v2 application, without doing anything fancy, it will take a very long time, over 4 minutes, to connect to an LTE network. But I found Soracom's web page https://www.soracom.io/blog/sim-activation-cellular-modem-fix/. That has given me hints to add

CONFIG_LTE_LOCK_BANDS=y
CONFIG_LTE_LOCK_BAND_MASK="1000"  #band 4

or

CONFIG_LTE_LOCK_PLMN=y
CONFIG_LTE_LOCK_PLMN_STRING="310260" #MCC=Puerto Rico MNC=T-Mobile

or both and either one will greatly speed things up. I am in North Carolina: I do wonder if it is safe to send out units to various places in the US locking down the network like shown or if moving away from my house there will be problems. Do you have ideas about that?

My other question involves suggestion #3 in the Soracom document I linked to: 3. Allow the SIM to pre-cache network information by placing it into a device known to be more efficient at searching. Once it’s connected, the SIM will cache the network information, and will use that cached information to connect much faster when placed back into the original device.

Can you tell me how I can pre-cache network information or (in your opinion) what it is they are telling me to do? I do not see any evidence of "pre-caching" in the SIM: if I do nothing with the LOCK_BANDS or LOCK_PLMN, the system will take 4 minutes to connect EVERY time I reboot--not just the first time like I would expect with caching.

Thanks very much.

Burt Silverman

[JONATHAN LL]

Also,

CFUN=0 should be a better option for some use cases. So if the tracker unit is moving all around then this will help improve time to connection in many cases. Be sure to not over use the command as it will wear out NVM. 

If the tacker is only in one location, or is within a area there only the same network is used then locking like you have tested can be the better option. But if the device leaves the area it will not be able to find a new band to connect to as it is locked. 

Then there is the %XCOUNTRYDATA that is some where in-between. It will help in many cases where deices stays whit in the same country. 

Regards,
Jonathan

[Burt]

Hi Jonathan,

You have mentioned CFUN=0 especially in the case that the tracker unit is moving all around. Actually, our trackers are fixed position, but nevertheless I would like to understand how one would use CFUN=0 in the non fixed position case. Am I correct that you are describing something that is not built into the asset_tracker_v2 code? I am looking to have a clearer high level picture overall. Maybe pseudo code would help me.

I understand that there are some commands like %XBANDLOCK, %XSYSTEMMODE, %XPTW, %XCOUNTRYDATA, +COPS, and %CSUS to which their configuration will be stored in NVM after +CFUN=0. But consider for example what I wrote earlier

CONFIG_LTE_LOCK_PLMN=y
CONFIG_LTE_LOCK_PLMN_STRING="310260"

I think this bit of configuration causes +COPS to execute every time I power up the device. If instead, I made certain to store the configuration just once in NVM and on future power ups relied on the NVM settings, this would not speed up my connect time to LTE noticeably, would it?

If I were to send you logs, what should I configure for that in prj.conf to be useful?

That's all I can think of. Thanks.

Burt

[JONATHAN LL]

Sorry for the delay Burt, 

Using CFUN=0 once should be enough when the device is stationary but sometimes the bastion it connects to change for whatever reason so running the CFUN=0 every once in a while can be smarts, but not often. 

Burt said:

I am looking to have a clearer high level picture overall. Maybe pseudo code would help me.

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/applications/asset_tracker_v2/doc/asset_tracker_v2_description.html this documentation is comprehensive and does provide all the parts of the application.  

And here you can see a flowchart of the prosess: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/applications/asset_tracker_v2/doc/app_behavior.html#real-time-configurations 

Burt said:

If I were to send you logs, what should I configure for that in prj.conf to be useful?

You can follow the info her https://infocenter.nordicsemi.com/topic/ug_trace_collector/UG/trace_collector/enable_tracing.html?cp=11_3_5_3_1 , A modem trace will provide us with the most details about what is happening. 

Regards,
Jonathan

[Burt]

Thanks, Jonathan. I see that Soracom has a help center, their DevZone you might say, so I will contact them next to get their take on pre-caching network information in the SIM. I'm not certain that the asset tracker documentation will move me forward on this ticket's question but reading the Modem module section has given me an idea for investigating a different problem the boss has mentioned: on rare occasions, our (modified) asset tracker has been known to disconnect but not reconnect. Thanks for the link to the tracing instructions, too.

Burt

[Burt]

After all these weeks, I now see that I had misread the suggestion 3 from Soracom. I read only the first few words carefully, about caching network information to the SIM. I completely missed the fact that they were telling me to find a device faster than the nRF9160! That really does seem impractical, and I would not have asked about it if I had read the suggestion more carefully.

Jonathan, you pointed me to the asset_tracker architecture, but you did not point me to any documentation regarding the use of AT+CFUN=0 for speed up. Although the AT Commands Reference explains what gets stored in NVRAM, it does not give me a feel for what amount of speed up time to connection might be. That's what I am looking for, if you can dig up anything from the knowledge inside your company. Thanks.

Burt

[Burt]

Having thought about it, I see how AT+CFUN=0 can be used to lock in a PLMN without having to create a special build with the extra config options. That may be useful. I will close the ticket.