nRF9160 connected yet not connected

[Lukas Kuhs]

I'm sorry, I don't know how this is reproduceable.

Yesterday and today my connection does not work. Sometimes. Yesterday it was OK early in the morning and in the afternoon. Today it was OK until the afternoon.

I did not change the setup, just rebooting from time to time and flashing new firmware, but anything else is fine.

Is it my firmware or the "new" changes? No, yesterday I flashed an old image and it stayed in error state.

Is it the SIM card? My 1nce SIM card is active and still enough volume remaining.

Is it the location? No, yesterday I was in a different location than today.

Powering off (for some seconds without VCC) the DK did not help, changing to another 1nce SIM did not help, changing to an iBasis SIM did not help...

I digged a little bit deeper into it, enabling more debug prints...

*** Booting Zephyr OS build v2.6.99-ncs1  ***
LTE_LC_EVT_MODEM_SLEEP_ENTER:	Modem sleep enter: type=4=LTE_LC_MODEM_SLEEP_FLIGHT_MODE, time=-1
LTE_LC_EVT_MODEM_SLEEP_EXIT: 	Modem sleep exit: type=4=LTE_LC_MODEM_SLEEP_FLIGHT_MODE, time=0
LTE_LC_EVT_CELL_UPDATE: 		LTE cell changed: mcc=0, mnc=0, id=31364867, tac=26553, earfcn=0, timing_advance=0, measurement_time=0, phys_cell_id=0, rsrp=0, rsrq=0
LTE_LC_EVT_LTE_MODE_UPDATE: 	LTE mode changed: mode=7=LTEM
LTE_LC_EVT_RRC_UPDATE:			RRC mode=Connected
LTE_LC_EVT_NW_REG_STATUS:		Network registration status: Connected - roaming
LTE_LC_EVT_PSM_UPDATE:			PSM parameter update: TAU=3600, ActiveTime=-1



AT+CGMI:    	Nordic Semiconductor ASA
AT+CGMM:        nRF9160-SICA
AT+CGMR:        mfw_nrf9160_1.3.0
AT%SHORTSWVER:  nrf9160_1.3.0
AT%HWVERSION:   nRF9160 SICA BQA
AT%XNETTIME?:  	1
AT%XCBAND=?:  	%XCBAND: (1,2,3,4,5,8,12,13,18,19,20,25,26,28,66)
AT%XBANDLOCK?:  "",""
AT+CIND=?: 		+CIND: ("service",(0,1)),("roam",(0,1)),("message",(0,1))
AT+CIND?:   	0,0,0
AT%XOPCONF?:   	1
AT+CEDRXS=?:   	+CEDRXS: (0-3),(4-5),("0000"-"1111")
AT+CEDRXS?:   	
AT+CESQ:     	99,99,255,255,15,27 => rsrq=-12.000000dB rsrp=-113dBm
AT+CEINFO?:  	0,1,C,8,1,-114,0 => rsrp=-114dBm cinr=0dBm
AT%XMONITOR: 	5,"","","26201","67B9",7,3,"01DE9703",333,1444,27,25,"","11100000","00000110","01001001" => Registered, roaming === mcc=262 mnc=1 tac=0x67b9 act=LTE-M (E-UTRAN WB-S1) band=3 cellid=31364867, physcellid=333 earfcn=1444 rsrp=-113dBm snr=1dB
AT+COPS?:    	0,2,"26201",7



... IP DNS resolution possible...
... sending data possible, but socket unstable
... reeiving data fails



LTE_LC_EVT_RRC_UPDATE:			RRC mode=Idle
LTE_LC_EVT_CELL_UPDATE: 		LTE cell changed: mcc=0, mnc=0, id=30581005, tac=26553, earfcn=0, timing_advance=0, measurement_time=0, phys_cell_id=0, rsrp=0, rsrq=0

As can be seen, connection seems OK at first glance, yet MCC and MNC are both 0 in some of the queries. I have never seen this before.

Connection quality is not perfect, but yesterday I had values about 10-20dB worse and it still worked perfectly.

What else should I do to find out the problem?

What can I query to make the connection good again?

This is the modem trace:

trace-2021-10-29T15-49-39.724Z.bin

I'm glad for any help.

[Kazi Afroza Sultana]

Hello Lukas,

Thanks for your query.  Sorry, It is a bit late reply because this ticket arrived in weekend.

Our technical team has looked at the modem trace file and they can not find anything immediately wrong in the modem trace. The device connects to the network, performs a successful DNS lookup, sends a UDP packet to the server, get a reply, then sends 4 more packets without getting a reply from the server. 

**What else should I do to find out the problem?

What can I query to make the connection good again?**

Is it possible to download the latest version of nRF9160-DK application and modem firmware since it shows AT+CGMR command that version is old one (mfw_nrf9160_1.3.0)? Could you also please tell us which hardware (version no) you are using and what application (for example asset tracker or at-client etc) running on it?  You may have to update the nRF for Cloud certificates from nRF cloud. 

Please try this and let us know if still same problem continues. 

Best Regards,

Kazi Afroza Sultana

[Lukas Kuhs]

Hello Kazi,

thank Your for looking into it.

I updated to 1.3.1. Problem still persists. Hardware version is 1.0.0 PCA10090 (2021.6) Application is taken from UDP sample and then extended to use MQTT-SN. So no certificates involved.

I'm wondering what

mcc=0, mnc=0

means. How could the device do DNS and send some packets successfully without a valid connection?

Best regards,

Lukas Kuhs

[Kazi Afroza Sultana]

Hello Lukas,

I can see from the log file that it (LTE_LC_EVT_CELL_UPDATE: LTE cell changed: mcc=0, mnc=0.....) shows mcc and mnc zero but from the command AT%XMONITOR, it's not zero. You can see the PLMN id 26201 which is MccMnc. 

AT%XMONITOR: 5,"","","26201","67B9",7,3,"01DE9703",333,1444,27,25,"","11100000","00000110","01001001" => Registered, roaming === mcc=262 mnc=1 

Could you please tell where did you print MccMnc in your source code? I mean where it is printed, and from where it gets the mcc and mnc. 

Best Regards,

Kazi Afroza Sultana

[Lukas Kuhs]

Yes, I already wrote so in my initial question, that it is only in some of the queries.

This is the code for printing (omitting the other cases):

static void lte_handler(const struct lte_lc_evt *const evt)
{
	switch (evt->type) {
	case LTE_LC_EVT_CELL_UPDATE:
		printk("LTE cell changed: mcc=%d, mnc=%d, id=%d, tac=%d, earfcn=%d, timing_advance=%d, measurement_time=%lld, phys_cell_id=%d, rsrp=%d, rsrq=%d\n", 
                          evt->cell.mcc,
                          evt->cell.mnc,
                          evt->cell.id,
                          evt->cell.tac,
                          evt->cell.earfcn,
                          evt->cell.timing_advance,
                          evt->cell.measurement_time,
                          evt->cell.phys_cell_id,
                          evt->cell.rsrp,
                          evt->cell.rsrq);
		break;
	}
}

The handler is registered like so:

lte_lc_connect_async(lte_handler);

And this works fine. And I'm quite sure that it always had worked well.

[Lukas Kuhs]

Hmm... There are two problems.

"Yesterday" (refereing to ticket creation) there was a bad connection. "Today" (refereing to ticket creation) there was a software bug that led to the server rejecting some of the packets, but connection seemed to have been OK "today". So my main problem is fixed. Thank You for helping with this!

Questions remaining to be able to cope with bad connection situations better in the future:

* Why is the debug print incorrect (showing mcc=mnc=0)? This is misleading...

* Which queries do You recommend to find out connection quality?

* What can I query to try to renew the connection, change operator or somehow get a connection?

Best regards

Lukas