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.