NRF9161 based LTE-M tracker data drops while moving – can it be optimized?

[marsal]

Hi everyone,

I’m using a custom board (a tracker) that can travel at speeds up to 65 km/h and transmits data regularly every 200 ms. I expect, therefore, that the inactivity timer should not be activated. While the device is in motion, I’m seeing intermittent data gaps ranging up to several seconds, which is unacceptable for our application.

Could this be caused by non-optimal cell-handover settings? I’ve attached a few logs below for reference.

Any suggestions would be greatly appreciated.

Thanks,
Martin

 

Three log fragments examples, related to data send drops:

 

17:31:57.179 +CSCON: 0

17:31:57.230 <inf> main: RRC mode: Idle

17:31:57.276 +CEREG: 1,"04D3","0DBC2351",7,,,"11100000","11100000"

17:31:57.298 <inf> main: Cell update, cell tac: 1235, cell id: 230433617

17:31:57.371 +CSCON: 1

17:31:57.429 <inf> main: RRC mode: Connected

17:31:57.539 +CSCON: 0

17:31:57.568 <inf> main: RRC mode: Idle

17:31:57.907 +CSCON: 1

17:31:57.926 <inf> main: RRC mode: Connected

***

17:37:54.095 +CEREG: 1,"04D3","0DC18750",7,,,"11100000","11100000"

17:37:54.154 [00:54:10.770,263] <inf> main: Cell update, cell tac: 1235, cell id: 230786896

***

17:38:05.373 +CEREG: 1,"04D3","0DDD4350",7,,,"11100000","11100000"

17:38:05.434 <inf> main: Cell update, cell tac: 1235, cell id: 232604496

***

 

Modem firmware: mfw_nrf91x1_2.0.2

 

Current 9161 modem initiation sequence is:

 

AT+CFUN=0

AT%XSYSTEMMODE=1,0,0,0

AT+CPSMS=0

AT+CEDRXS=0

AT%RAI=0

AT+CSCON=1

AT+CEREG=5

AT+CFUN=1

[Achim Kraus]

marsal said:

I’m seeing intermittent data gaps ranging up to several seconds, which is unacceptable for our application.

marsal said:

5 Hz to an MQTT broker

You chose MQTT. That usually queues the messages and transmit them, when transmission is possible. So, there may be a short gap in the time-stream, but not the data-stream, that's just delayed. If you add the "sensor-time" to the data, you will also be able to have the time-stream available with delays.

I guess, you need to adapt your application to that common practice.

[marsal]

Thanks, well, my interval_between_two_subsequent_successful_mqtt_sends is between 210ms and 300ms in case that there are no cell updates, which is OK for me. When cell update comes, it raises to e.g. 1.5 sec. So the cell update seems really be the case.

Er, I am struggling just now to catch the modem trace... Not sure if UART or RTT approach is better for me. 2.6.3.

[dejans]

Hi,

You could try to capture modem trace using RTT.
There are some resources in the documentation which provide information how to send traces over UART on a custom board, modem tracing with RTT, snippets for nrf91 Series devices and capturing trace data for nRF91 Series modem.

Best regards,
Dejan

[marsal]

Sorry, I am trying RTT. In my app, I do:

### wrk - trace
CONFIG_NRF_MODEM_LIB_TRACE_BACKEND_RTT=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_NRF_MODEM_LIB_TRACE=y

CONFIG_LOG=y
CONFIG_LOG_BACKEND_RTT=y
CONFIG_LOG_BACKEND_RTT_BUFFER_SIZE=4096
CONFIG_SEGGER_RTT_INIT_PRIORITY=40

Then in RTT viewer I cannot see anything logged after "Terminal logging started":

LOG: J-Link RTT Viewer V8.30: Logging started.
LOG: Terminal 0 added.
LOG: Connecting to J-Link via USB...
LOG: Device "NRF9161_XXCA" selected.
LOG: ConfigTargetSettings() start
LOG: ---Setting ROM table---
LOG: ConfigTargetSettings() end - Took 25us
LOG: InitTarget() start
LOG: InitTarget() end - Took 3.80ms
LOG: Found SW-DP with ID 0x6BA02477
LOG: DPIDR: 0x6BA02477
LOG: CoreSight SoC-400 or earlier
LOG: AP map detection skipped. Manually configured AP map found.
LOG: AP[0]: AHB-AP (IDR: Not set, ADDR: 0x00000000)
LOG: AP[0]: Core found
LOG: AP[0]: AHB-AP ROM base: 0xE00FF000
LOG: CPUID register: 0x410FD212. Implementer code: 0x41 (ARM)
LOG: Feature set: Mainline
LOG: Cache: No cache
LOG: Found Cortex-M33 r0p2, Little endian.
LOG: FPUnit: 8 code (BP) slots and 0 literal slots
LOG: Security extension: implemented
LOG: Secure debug: enabled
LOG: CoreSight components:
LOG: ROMTbl[0] @ E00FF000
LOG: [0][0]: E000E000 CID B105900D PID 000BBD21 DEVARCH 47702A04 DEVTYPE 00 Cortex-M33
LOG: [0][1]: E0001000 CID B105900D PID 000BBD21 DEVARCH 47701A02 DEVTYPE 00 DWT
LOG: [0][2]: E0002000 CID B105900D PID 000BBD21 DEVARCH 47701A03 DEVTYPE 00 FPB
LOG: [0][3]: E0000000 CID B105900D PID 000BBD21 DEVARCH 47701A01 DEVTYPE 43 ITM
LOG: [0][5]: E0041000 CID B105900D PID 002BBD21 DEVARCH 47724A13 DEVTYPE 13 ETM
LOG: [0][6]: E0042000 CID B105900D PID 000BBD21 DEVARCH 47701A14 DEVTYPE 14 CSS600-CTI
LOG: RTT Viewer connected.
LOG: Terminal logging started.


Edit: full .config attached

zephyr.config.txt

[dejans]

Hi,

Have you started data logging?
You can capture modem trace from JLink Viewer by clicking on Logging -> Start Data Logging and saving data log to .bin file.

Best regards,
Dejan

[marsal]

Oh, thank you for your patience, dejans...

Please download the trace from here: https://e.pcloud.link/publink/show?code=XZ0rTqZdiRVUEHQm9hG8n3zxMfHOHDJ2bRy

The trace is from a short car ride, observing cells switching. Thank you very much!

Below is what I did meanwhile (lock for band 20 for Czechia as O2 operator is used who has no other bands for LTE-M. full .config is FYI here: https://e.pcloud.link/publink/show?code=XZmrTqZUNoHFDGILALna6f7gRDrRzMaOtFk):

### LTE
CONFIG_LTE_NETWORK_MODE_LTE_M=y
CONFIG_LTE_LINK_CONTROL=y
CONFIG_LTE_PSM_REQ=n
CONFIG_LTE_EDRX_REQ=n
CONFIG_LTE_RAI_REQ=n
CONFIG_LTE_NETWORK_TIMEOUT=60
CONFIG_LTE_LC_TAU_PRE_WARNING_NOTIFICATIONS=n
CONFIG_LTE_LOCK_BANDS=y
CONFIG_LTE_LOCK_BAND_MASK="10000000000000000000"

And in runtime (possibly duplicate to config), I am sending:
"AT+CFUN=0";
"AT%%XSYSTEMMODE=1,0,0,0";
"AT+CPSMS=0";
"AT+CEDRXS=0";
"AT%%RAI=0";
"AT%%XBANDLOCK=2,\"10000000000000000000\"";
"AT+CSCON=1";
"AT+CEREG=5";
"AT+CFUN=1";

[dejans]

Hi,

Thank you for the trace and additional information.

There seems to be only one cell change in your log. Increased delay which you observed might be normal, but we will check this further. I will get back to you during next week.

Best regards,
Dejan