nRF9160 Network connection status NB-IoT. Handling

RE: nRF9160 Network connection status NB-IoT. Handling

Charlie — Tue, 25 Oct 2022 14:21:01 GMT

Hi Tomas,

1) The drone tracking application sounds not quite fit the NB-IoT network. As drone normally has a fast speed and NB-IoT is mostly used by fixed IoT device and need a long time to search and attach to cell station due to its low bandwidth. You can read nWP044 - Best practices for cellular IoT development to learn more considerations you should take for your application development. For your application, if LTE-M is not an option and you do not have limitations on power consumption, 3G/4G/5G modules are better choices than NB-IoT since they are more robust with high speed. Another concern is that the base station antenna is targeting the ground, so your drone will have a worse signal than the ground in the same area.

2) If NB-IoT is your only choice, CEREG should be the correct indicator instead of CSCON as you have realized, but again it is too slow to detect environmental change due to the NB-IoT limitation. In your log file, you did not even get a chance to see +CEREG: 4( limited service due to out of E-UTRAN coverage) before getting +CEREG: 2. The Modem sleep notification %XMODEMSLEEP command may give some fast response when the device goes to sleep because of limited service.

Building an application with the wrong technology will make you struggle a lot, hope you could figure out a proper solution for this application. We can have more discussion if you have other confusion.

Best regards,

Charlie

RE: nRF9160 Network connection status NB-IoT. Handling

optical — Sun, 23 Oct 2022 17:33:37 GMT

Can Nordic provide an application note how to exactly use the %CONEVAL for our case ?

RE: nRF9160 Network connection status NB-IoT. Handling

helsing — Mon, 26 Sep 2022 13:32:15 GMT

Hi Tomas, sorry for the delay.

%CONEVAL will provide you with information about signal power. This could help predicting the conditions.

RE: nRF9160 Network connection status NB-IoT. Handling

helsing — Mon, 05 Sep 2022 13:48:25 GMT

Hi Tomas,

Sorry you have not heard from me. We are still working on this and will get back to you with a comment.

RE: nRF9160 Network connection status NB-IoT. Handling

optical — Mon, 29 Aug 2022 14:35:14 GMT

The logs, which I sent were to reproduce issues when the device in the real world application(for us drone tracking) has poor signal. They were produce by using external antenna port without antenna. The device is able to connect to LTE network in our office even without the antenna. The issues are not severe when the device has good signal.

The signal quality does not address the issue of indicating the user that he is out of coverage or has poor signal or the redundant message sending. The device should be able to work in these conditions.

RE: nRF9160 Network connection status NB-IoT. Handling

helsing — Mon, 29 Aug 2022 14:06:40 GMT

Thank you for the update. So, one of your big challenges here is that your signal is very poor. What is the overall goal here, and what is the application?

RE: nRF9160 Network connection status NB-IoT. Handling

helsing — Mon, 29 Aug 2022 13:17:01 GMT

Thank you for the explanation and sorry for the delay. I am discussing your situation with our team and will get back to you.

RE: nRF9160 Network connection status NB-IoT. Handling

optical — Mon, 22 Aug 2022 14:28:56 GMT

Human LTE connectivity indication. Our application is sending every 3s a message, which ensures that the data plane CSCON should be active all the time. There should not be any power saving or other disconnects from the network. We have mobile usecase of the nrf9160 modem. It switches BTS stations very often. We would like to indicate to the user that this is happening. The connection loss is often lengthy process.

The following log shows scenario when connection to the next cell took "only" 20s in worse signal condition this mas can take much more time.

[15:08:50.733,000] <dbg> dt_coap_client: Data recieved # <- Reponse from Server

[15:08:50.733,000] <dbg> dt_coap_client: Recieved coap id: 7894, token_len: 2, type: 01

[15:08:51.692,000] <inf> dt_modem: Notif: %XSNRSQ: 23,1,132,0

[15:08:53.464,000] <dbg> dt_coap_client: Non Con send Id: 14438

[15:08:53.464,000] <dbg> dt_socket_manager: Send handler: 1

[15:08:53.900,000] <inf> dt_modem: Notif: %CESQ: 10,0,0,0

[15:08:54.102,000] <inf> dt_modem: Notif: %CESQ: 4,0,0,0

[15:08:54.708,000] <inf> dt_modem: Notif: %XSNRSQ: 17,1,132,0

[15:08:56.463,000] <dbg> dt_coap_client: Non Con send Id: 14439

[15:08:56.463,000] <dbg> dt_socket_manager: Send handler: 1

[15:08:59.078,000] <inf> dt_modem: Notif: +CSCON: 0

[15:08:59.261,000] <inf> dt_modem: Notif: %CESQ: 255,0,255,0

[15:08:59.262,000] <inf> dt_modem: Notif: +CEREG: 2

[15:08:59.268,000] <wrn> main: Pausing Socket Manager

[15:08:59.268,000] <wrn> dt_app_flight: Stoping sending task due to network disconnect

[15:09:04.278,000] <inf> dt_modem: Notif: %CESQ: 18,0,4,0

[15:09:04.279,000] <inf> dt_modem: Notif: +CEREG: 5,"5A18","0092A521",7,,,"11100000","11100000"

[15:09:04.285,000] <inf> main: Resuming Socket Manager

[15:09:04.285,000] <inf> dt_app_flight: Resuming network task due to network connect event

[15:09:04.289,000] <dbg> dt_coap_client: Non Con send Id: 14440

[15:09:04.289,000] <dbg> dt_socket_manager: Send handler: 1

[15:09:04.485,000] <inf> dt_modem: Notif: +CSCON: 1

[15:09:04.679,000] <inf> dt_modem: Notif: %CESQ: 21,1,11,1

[15:09:05.481,000] <inf> dt_modem: Notif: %CESQ: 15,0,6,0

[15:09:06.466,000] <dbg> dt_coap_client: Non Con send Id: 14441

[15:09:06.466,000] <dbg> dt_socket_manager: Send handler: 1

[15:09:06.684,000] <inf> dt_modem: Notif: %CESQ: 13,0,0,0

[15:09:06.684,000] <inf> dt_modem: Notif: %XSNRSQ: 22,1,133,0

[15:09:06.828,000] <dbg> dt_coap_client: Data recieved # <- Reponse from Server

The modem between 15:08:50 -> 15:08:59 losses connection. This is time we would like to already indicate the use that the modem is not connected to the network. How to achieve this. The modem must know whether the packets are transmitted. The packets Id: 14438 and Id: 14439 are probably transmitted after new connection 15:09:04.279. Which is after 10s and we would like to show the user in meantime that we are waiting for network connection. We are currently using the CEREG notification, which tells only part of the story in this case 5s of downtime instead of 20s. In worse signal condition the discrepancy is much greater. CSCON would signal 10s of downtime,which is still only a half of the time.

Second use case is similar. During the downtime we would like to eliminate CoaP retransmisions because it does not make sense to send(enqueue) them into modem. They will be transmitted together defeating their purpose and they only consume more data, which raises the cost of the device operation.

You can see in the log that we are pausing sending to the socket when CEREG notification arrives and resuming it when CEREG 5 roaming arrives. We would like to use approach using the CSCON. However, the logic cannot solely depend on the CSCON notification because. The modeme will only make CSCON connection, when data has been enqueued into it. This meas when we would connect the CSCON logic to the pausing and resuming logic it would end up in logical loop. We want to send something -> CSCON=0 -> The CSCON will never be established because we have not enqueued anything.

Without any additional monitoring AT command we cannot determine whether the modem will establish CSCON(has enqueued packets)

RE: nRF9160 Network connection status NB-IoT. Handling

helsing — Mon, 22 Aug 2022 13:28:25 GMT

Hi Tomas,

Sorry this is taking long, I am just letting you know I am still working on this. Could you please add a little more context?

Could you please add some more context to what you would like to achieve?

Best regards,

Håkon

RE: nRF9160 Network connection status NB-IoT. Handling

helsing — Tue, 16 Aug 2022 14:34:01 GMT

Hello Tomas,

Thank you for your request. I am taking a closer look and will get back to you.