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

[rajeev]

marsal , I think you are not taking into account that your device is a moving device and it will try to probably switch between different cellular  towers when connecting, hence, these packet drops. Unless, your application scenario is stringent w.r.t to no packet drops, this seems to be acceptable for such IoT chipsets.

I could be wrong but these are my 2 cents

[marsal]

Well, I am still seeking a solution without drops, if possible. Does LTE (i.e. not LTE-M) offer such solution, btw?

[dejans]

Hi,

Can you provide more information about your application and its requirements?

Can you share some information about your use case?

Which time in your log fragment corresponds to data loss?

Best regards,
Dejan

[marsal]

Hi,

this is a high-precision GNSS tracker that uses an external ZED F9P RTK chip (connected via UART to the 9161 module) rather than the 9161’s GNSS. The tracker sends NMEA RMC sentences at 5 Hz to an MQTT broker, and I’m measuring the interval between consecutive successful publishes. Because the use case is “moving online tracker for races” it’s important that updates occur without major interrupts.

The application spawns several threads—for example, “read and process GNSS messages from UART,” “publish to MQTT,” “evaluate status,” and “receive RTCM corrections from the RTK server.” After tuning thread priorities, I generally see no gaps exceeding ~250 ms between MQTT publishes, except in one scenario documented in my first log message: LTE-M events such as CEREG… appear immediately before a longer delay occures between publishes (often one to two seconds).

It seems that these occasional gaps aren’t caused by the application itself or MQTT server but by LTE-M signal quality or a cell-switching event. Is there any way to mitigate these interruptions on the LTE-M side?

Here is another example from my logs: I recognize relatively weak RSRP, then CEREG+Cell update and then MQTT transmission gap approx 1,5s.

18:31:17.180 [00:40:06.596,008] ... "lte_rsrp_dbm":-109,"lte_rsrq_db":-10," ...
18:31:18.086 +CEREG: 1,"04D3","0DDD4350",7,,,"11100000","11100000"
18:31:18.125 [00:40:08.416,656] [0m<inf> main: Cell update, cell tac: 1235, cell id: 232604496
18:31:19.424 [00:40:08.769,012] [1;33m<wrn> main: GNSS message cannot be put to queue (Queue full/not processed?)
18:31:19.584 [00:40:08.778,076] [1;33m<wrn> main: Interval between two RMC messages sent to MQTT is high (1701ms)

Please let me know if you need any additional details. Thank you!