LTE Link connecting is blocking?

[ExAg]

Hi

In the mqtt_simple example there is a line "modem_configure();" which establishes the LTE Link connection. If connecting the LTE link is not possible (for example no signal), this function never returns.

1. Is this the intention of this function or is there a possibility to configure a timeout?

2. Is it normal, that this function needs several minutes to establish the LTE link, if a provider is present?

regards

ExAg

[Simon]

1. Is this the intention of this function or is there a possibility to configure a timeout?

The reason it is blocking is due to some semaphores inside w_lte_lc_init_and_connect(..) in lte_lc.c. It will wait for the at_handler() to run and if the response is appropriate it will give up the semaphore and the program continues. See code below

//From w_lte_lc_init_and_connect() in lte_lc.c

k_sem_init(&link, 0, 1);
        //k_sem_init(&link, 1, 2);

	at_cmd_set_notification_handler(at_handler);

	if (at_cmd_write(normal, NULL, 0, NULL) != 0) {
		return -EIO;
	}

	k_sem_take(&link, K_FOREVER);

You can set a timeout, by running k_sem_take(&link, timeout_in_ms); where you specify the timeout in timeout_in_ms. 

Be aware that this may cause some unwanted results/race conditions etc., but I am not sure specifically what may happen.

 

2. Is it normal, that this function needs several minutes to establish the LTE link, if a provider is present?

 I will look into this and come back to you.

Best regards,

Simon

[Simon]

ExAg said:

2. Is it normal, that this function needs several minutes to establish the LTE link, if a provider is present?

The time to establish an LTE link varies depending on the signal strength and the network, it may more than 5 minutes at worst. If the network settings are stored on the modem, the connection only takes some few seconds. The network settings are automatically stored to the modem when the modem is turned off, through the call to AT+CFUN=0.

Best regards,

Simon

[ExAg]

Hi Simon

Thank you for your answers. So its most likely an issue of our national telecom provider. I will discuss this with them. Because these long connection times have a big influence of the total power consumption of an battery powered IoT device out in the field.

The SIM card is specially for IoT purpose (for the M1 Network; NB is not yet supported at the moment).

Best regards
Michael

[Simon]

ExAg said:

Thank you for your answers. So its most likely an issue of our national telecom provider

 Yes, based on the trace you sent. If you sent more traces from other delays, we can confirm this with more certainty.

Best regards,

Simon

[ExAg]

Hi Simon

Here are some more trace files for you to analyse if you want. Today there was no single LTE connection attempt shorter than about 2 minutes. But I think you will see that in the trace files.

Traces11_11_2019.zip

I had some difficulties to record the traces this time because the connection between the Trace Collector and the eval board or the connetion between the LTE link monitor and the eval board were lost relatively often. I have no idea why...

Best regards
Michael

[Simon]

Thank you. I have provided the trace files internally and will report to you as soon as I get a reply.

Best regards,

Simon

[Simon]

I got a reply:

"Delays in these new logs are caused by SIM Refresh.
In most logs only the third profile is able to register, first two got reject with cause #14 or #15.
It's up to the SIM card how quickly it will change the profile.

cause #14
IMSI: 901430000623824
Mobile Country Code (MCC): International Mobile, shared code (901)
Mobile Network Code (MNC): EMnify GmbH (43)

cause #15
IMSI: 206018874001895
Mobile Country Code (MCC): Belgium (206)
Mobile Network Code (MNC): Proximus (01)

OK
IMSI: 295050900053251
Mobile Country Code (MCC): Liechtenstein (295)
Mobile Network Code (MNC): Telecom Liechtenstein AG (05)"

Hopefully, this helped you.

Best regards,

Simon