Hi,
I have been developing on the nRF9160 for a while now, and we have a product on the market that sends data over NB-IoT or LTE-M networks. I have recently been trying to add a new feature where the end user can test out their signal strength before they install the product, in case the need to use a better (and more expensive) antenna. Initially all was fine, but I was testing a number of things, like how it worked on each network, with and without PSM, etc. Essentially I made it so whenever this feature was triggered, it would turn off the modem, disable PSM, turn the modem on, record the signal strength every x seconds, then when all the data was collected, send in an MQTT message and power down the modem. At the end it would make sure that the next time it needed to use the modem, that it would initialise everything again, as it does when the modem is first powered up, or after it fails to connect.
Whilst testing this I noticed that something I had done had made it so the first time it connects to a network, it always timed out. The timeout was something I implemented myself, to save battery. It basically just runs in a loop until the modem gets the LTE_LC_NW_REG_REGISTERED_ROAMING or LTE_LC_NW_REG_REGISTERED_HOME status, and lte mode as 7 or 9.
I could see from my debug printing that the modem was connected to a network, and getting valid levels of signal, but the registration was still set as LTE_LC_NW_REG_SEARCHING. I couldn't understand why this started happening, and why it only happened on the first attempt, so I reprogrammed that unit back to an older version of firmware, which I knew didn't have that problem - but the issue was still there. I went back to my first release version, and again it happened.
My next thought was something to do with the Sim card. so I used a different one (same brand), and it still happened, and another one that is locked to Vodafone with a different APN. Again it happened. Consistently the unit cannot register on the first attempt, and other units can, so I thought it had to be something in the modem flash that's gone wrong or something, so I use a version of the AT client program to talk to the modem via AT commands, and use the factory reset command to try get rid of the issue, but still no luck. I tried reprogamming the modem firmware, and using an older version of modem firmware, still happens.
I eventually give up and just use a new unit to develop on, and this time implemented it in a slightly different way, making sure that the modem was definitely either in sleep mode or powered down when the signal check feature was started, incase something went wrong with two threads trying to talk to the modem at the same time or similar. All was going fine, until I found this new unit started doing the same thing!
Do you have any idea what could have triggered this?
Is there a way to completely reset the modem? (I used both AT%FACTORYRESET=0 and AT%FACTORYRESET=1 )
Is there a debug AT command that will list all settings that I can compare the two strange units and units that don't have this problem?
I am using SDK 1.6.1 and Modem FW 1.3.1. The exact code of what I have added in to create this feature is below (with debug stuff and our own non-modem related functions removed)
lte_lc_power_off();
lte_lc_psm_req(false);
lte_lc_power_on();
modem_info_init();
modem_info_rsrp_register(rsrp_callback);
k_timer_start(&signal_check_timer, K_SECONDS(period), K_SECONDS(period));
while(sig_check_time_period_complete < num_values_to_record)
{
k_sleep(K_SECONDS(1));
}
k_timer_stop(&signal_check_timer);
sprintf(str, "[I] Signal Check Values - %u, %u, %u, %u, %u", CSQ_arr[0], CSQ_arr[1], CSQ_arr[2], CSQ_arr[3], CSQ_arr[4]);
printk(str);
//Do stuff with flash and NFC - 10-100ms
send_messages(0,1,0,1); //MQTT message to our server with the signal check values
lte_lc_power_off();
modem_init_flag = false; //Tells our modem thread to reinitialise modem stuff next time it runs
Thanks,
Damien
