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

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

marsal — Fri, 06 Jun 2025 15:12:21 GMT

Thanks again, dejans, we hope our O2 negotiations will be fruitful. But as our project lasts 9 months already without usable outcome, even a quick "smoke" mesh test could heal the business position for us.

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

dejans — Fri, 06 Jun 2025 14:46:36 GMT

Hi,

[quote user="marsal"]Thanks, here is the idea - this means a rework of the current setup, of course:

10 to 20 trackers in one race + 1 gateway. Distance between trackers and gateway can be up to 1km, direct line of sight. If not enough for the data transfer, an "intermediate" node is expected to be positioned somewhere in the middle between the gateway and the more distant place of the race.[/quote]

The key here is good hardware radiated performance. Otherwise, NR+ 1.9 GHz should be able to handle distances relatively easy.

[quote user="marsal"]Trackers (using our current hardware, btw ;-), ):
a) Sending to the gateway each 200ms data about position/speed/direction (approx 100 bytes each)
b) Receiving from gateway each 1 second GNSS correction RTK data (up to 1KB each second, same for each tracker)
Idea: trackers typically communicate with gateway, if the gateway is not reachable for a tracker and vice versa, they send/receive via another tracker (mesh).[/quote]

NR+ should be able to handle such traffic per tracker node, NR+ sink node connected to Cellular/LTE gateway would be the focus point performance wise.

[quote user="marsal"]Gateway (our current hardware + LTE modem rework):
a) receiving position/speed/direction data from trackers, sending it to an MQTT server via LTE (I guess not via LTE-M for this case)
b) receiving RTK corrective data from another server and sending them to trackers via DECT NR+
c) Some other communication (AGNSS, some controls)[/quote]

RTK correction data would be more of a broadcast type than point-to-point per each tracker node.

[quote user="marsal"]one question regarding the current setup: are you please aware of an implementation with LTE-M NRF9161 where the handover goes smoothly? Which carrier provider?[/quote]

Yes, any cellular provider which supports handover for LTE-M1 which would for example be just about every network in US or Nordics. This feature has been enabled for several years already, and it should not be a big task for any carrier to enable it.

[quote user="marsal"]So, any hints and DECT NR+ firmware to test this warmly welcomed.[/quote]

I recommend that you contact your regional sales manager to discuss the possibilities of going forward with NR+.

Best regards,
Dejan

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

marsal — Fri, 06 Jun 2025 08:45:44 GMT

Thanks, Achim, well, if the modem is connected to a cell with strong signal, it behaves perfectly. If there is cell update, our problems begin and without on-connect handover enabled by MNO they will persist (yes, you are true, we can expect issues even if it were enabled, but not so systemic).

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

Achim Kraus — Fri, 06 Jun 2025 08:10:06 GMT

[quote userid="130765" url="~/f/nordic-q-a/120990/nrf9161-based-lte-m-tracker-data-drops-while-moving-can-it-be-optimized/538359"]but this situation is not optimal, indeed...[/quote]

Such gaps are more or less the nature of radio transmissions, regardless of cellular or other radio technologies.

In some more expensive implementations, a second antenna/receiver is used to minimize the gap. If that pays-off depends on the use-case.

As I wrote above, for the very most use-cases there is a common practice about that, even if this requires some adaptions in the application logic.

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

marsal — Fri, 06 Jun 2025 07:54:25 GMT

I'd like just say thanks again with the hope that DECT NR+ will be able to save our business case.

I am not a network expert but looking at the modem trace just confirms for me what you had stated - there seems really to be no on connect handover, all "handovers" are initiated by the modem (even when the transition is "good" or "bad"):

Just FYI, the modem trace is here: https://e.pcloud.link/publink/show?code=XZEMTtZRiah3HaWN7Q0Pifo1kt09HcMUDTX, I have used a tiny app for testing:

/*
 * Copyright (c) 2018 Nordic Semiconductor ASA
 *
 * SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
 */

#include <modem/nrf_modem_lib.h>
#include <nrf_modem_at.h>
#include <stdio.h>
#include <string.h>
#include <zephyr/drivers/clock_control.h>
#include <zephyr/drivers/clock_control/nrf_clock_control.h>
#include <zephyr/drivers/uart.h>
#include <zephyr/kernel.h>
#include <zephyr/logging/log.h>
LOG_MODULE_REGISTER(main, CONFIG_LOG_DEFAULT_LEVEL);

#include <zephyr/net/net_context.h>
#include <zephyr/net/net_core.h>
#include <zephyr/net/net_if.h>
#include <zephyr/net/net_ip.h>
#include <zephyr/net/socket.h>


/* To strictly comply with UART timing, enable external XTAL oscillator */
void enable_xtal(void) {
    struct onoff_manager *clk_mgr;
    static struct onoff_client cli = {};

    clk_mgr = z_nrf_clock_control_get_onoff(CLOCK_CONTROL_NRF_SUBSYS_HF);
    sys_notify_init_spinwait(&cli.notify);
    (void)onoff_request(clk_mgr, &cli);
}

char *msend;
char atb[500];


int main(void) {
    int err;

    printk("The AT host sample started\n");

    err = nrf_modem_lib_init();
    if (err) {
        printk("Modem library initialization failed, error: %d\n", err);
        return -1;
    }
    enable_xtal();
    printk("Ready\n");


    msend = "AT+CFUN=0";
    LOG_INF("Initialization sequence of modem, %s", msend);
    err = nrf_modem_at_cmd(atb, sizeof(atb), "%s", msend);
    LOG_INF("at response (%d): %s", err, atb);

    msend = "AT+CEMODE=0";
    LOG_INF("Initialization sequence of modem, %s", msend);
    err = nrf_modem_at_cmd(atb, sizeof(atb), "%s", msend);
    LOG_INF("at response (%d): %s", err, atb);

    // syntax: if %, this character must be doubled for nrf_modem_at_cmd!
    // disable GNSS, LTE-M only
    msend = "AT%XSYSTEMMODE=1,0,0,0";
    LOG_INF("Initialization sequence of modem, %s", msend);
    err = nrf_modem_at_cmd(atb, sizeof(atb), "%s", msend);
    LOG_INF("at response (%d): %s", err, atb);

    msend = "AT+CPSMS=0";
    LOG_INF("Initialization sequence of modem, %s", msend);
    err = nrf_modem_at_cmd(atb, sizeof(atb), "%s", msend);
    LOG_INF("at response (%d): %s", err, atb);

    msend = "AT+CEDRXS=0";
    LOG_INF("Initialization sequence of modem, %s", msend);
    err = nrf_modem_at_cmd(atb, sizeof(atb), "%s", msend);
    LOG_INF("at response (%d): %s", err, atb);

    // syntax: if %, this character must be doubled for nrf_modem_at_cmd!
    //  disable RAI
    msend = "AT%RAI=0";
    LOG_INF("Initialization sequence of modem, %s", msend);
    err = nrf_modem_at_cmd(atb, sizeof(atb), "%s", msend);
    LOG_INF("at response (%d): %s", err, atb);

    // if %, this character must be doubled for nrf_modem_at_cmd!
    //  runtime bandlock mask
    //  CAN VERIFY AT%%XBANDLOCK?
    msend = "AT%XBANDLOCK=2,\"10000000000000000000\"";
    LOG_INF("Initialization sequence of modem, %s", msend);
    err = nrf_modem_at_cmd(atb, sizeof(atb), "%s", msend);
    LOG_INF("at response (%d): %s", err, atb);

    msend = "AT+CSCON=1";
    LOG_INF("Initialization sequence of modem, %s", msend);
    err = nrf_modem_at_cmd(atb, sizeof(atb), "%s", msend);
    LOG_INF("at response (%d): %s", err, atb);

    msend = "AT+CEREG=5";
    LOG_INF("Initialization sequence of modem, %s", msend);
    err = nrf_modem_at_cmd(atb, sizeof(atb), "%s", msend);
    LOG_INF("at response (%d): %s", err, atb);

    msend = "AT+CFUN=1";
    LOG_INF("Initialization sequence of modem, %s", msend);
    err = nrf_modem_at_cmd(atb, sizeof(atb), "%s", msend);
    LOG_INF("at response (%d): %s", err, atb);


reset_socket:

    int sock;
    struct sockaddr_in server_addr;
    const uint8_t keepalive_payload[1] = {0x42};

    /* (Re)create UDP socket ------------------------------------------------ */
    sock = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
    if (sock < 0) {
        LOG_ERR("socket() failed: %d", errno);
        k_msleep(500);
        goto reset_socket;
    }

    memset(&server_addr, 0, sizeof(server_addr));
    server_addr.sin_family = AF_INET;
    server_addr.sin_port = htons(12345);

    /* 8.8.8.8 -> binary ---------------------------------------------------- */
    inet_pton(AF_INET, "8.8.8.8", &server_addr.sin_addr);

    LOG_INF("Socket ready, entering keep-alive loop");

    /* Keep-alive loop ------------------------------------------------------ */

#define INTEVALRESET 20

    int intervalreset = INTEVALRESET;  // how many loops to try to reconnect
    for (;;) {
        ssize_t sent = sendto(sock, keepalive_payload, sizeof(keepalive_payload), 0, (struct sockaddr *)&server_addr,
                              sizeof(server_addr));

        if (sent < 0) {
            int err = errno;
            LOG_WRN("sendto() failed: %d, resetting socket", err);
            close(sock);
            k_msleep(100);
            goto reset_socket;
        } else {
            LOG_INF("Keep-alive sent (%zd bytes)", sent);
        }

        // tick wait loop
        k_msleep(500);

        // reconnect trial?
        intervalreset -= 1;
        if (intervalreset <= 0) {
            intervalreset = INTEVALRESET;

            msend = "AT+CGATT=0";
            LOG_INF("Initialization sequence of modem, %s", msend);
            err = nrf_modem_at_cmd(atb, sizeof(atb), "%s", msend);
            LOG_INF("at response (%d): %s", err, atb);

            k_msleep(500);

            msend = "AT+CGATT=1";
            LOG_INF("Initialization sequence of modem, %s", msend);
            err = nrf_modem_at_cmd(atb, sizeof(atb), "%s", msend);
            LOG_INF("at response (%d): %s", err, atb);

            /*

                        msend = "AT+CFUN=4";
                        LOG_INF("Initialization sequence of modem, %s", msend);
                        err = nrf_modem_at_cmd(atb, sizeof(atb), "%s", msend);
                        LOG_INF("at response (%d): %s", err, atb);

                        k_msleep(1);

                        msend = "AT+CFUN=1";
                        LOG_INF("Initialization sequence of modem, %s", msend);
                        err = nrf_modem_at_cmd(atb, sizeof(atb), "%s", msend);
                        LOG_INF("at response (%d): %s", err, atb);

            */
        }
    }
}

We are negotiating with the local O2 MNO, we will see...

Now, I am trying the only option we possibly have, to try to force reconnect when we observe the low quality signal. Our best option found so far is something like (shown in the code):

"AT+CGATT=0";

wait 500ms

"AT+CGATT=1";

but this situation is not optimal, indeed...

Thanks again!

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

marsal — Tue, 03 Jun 2025 15:48:09 GMT

This is really a puzzle for us. We did run other bunch of tests today on both O2 and Tmobile network in the area where is clearly no issue with the signal strength/quality (always better than -90dBm). We were observing dropouts up to 15s, typically related to cell update, but not always. So if I understand well, both Tmobile and O2 networks in the Czech Republic are currently not suitable to run LTE-M devices which are moving for a businss case which needs uninterrupted data delivery?

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

marsal — Wed, 28 May 2025 14:40:25 GMT

Thanks, dejans,
one question regarding the current setup: are you please aware of an implementation with LTE-M NRF9161 where the handover goes smoothly? Which carrier provider?
Thx!

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

dejans — Wed, 28 May 2025 14:30:21 GMT

Hi Martin,

Thank you for providing additional information.

We will discuss this internally. I will get back to you during next week.

Best regards,
Dejan

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

marsal — Wed, 28 May 2025 08:12:27 GMT

Thanks, here is the idea - this means a rework of the current setup, of course:

10 to 20 trackers in one race + 1 gateway. Distance between trackers and gateway can be up to 1km, direct line of sight. If not enough for the data transfer, an "intermediate" node is expected to be positioned somewhere in the middle between the gateway and the more distant place of the race.

Trackers (using our current hardware, btw ;-), ):
a) Sending to the gateway each 200ms data about position/speed/direction (approx 100 bytes each)
b) Receiving from gateway each 1 second GNSS correction RTK data (up to 1KB each second, same for each tracker)
Idea: trackers typically communicate with gateway, if the gateway is not reachable for a tracker and vice versa, they send/receive via another tracker (mesh).

Gateway (our current hardware + LTE modem rework):
a) receiving position/speed/direction data from trackers, sending it to an MQTT server via LTE (I guess not via LTE-M for this case)
b) receiving RTK corrective data from another server and sending them to trackers via DECT NR+
c) Some other communication (AGNSS, some controls)

So, any hints and DECT NR+ firmware to test this warmly welcomed.

Thank you!

Martin

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

dejans — Wed, 28 May 2025 07:26:25 GMT

Hi,

[quote user="marsal"]Possibly another option is to try DECT NR+ instead of LTE-M + and a gateway having also an LTE modem!?[/quote]

Can you provide details how you intend to use this setup?

Best regards,
Dejan

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

marsal — Thu, 22 May 2025 08:40:49 GMT

Indeed, we are already in communication with our cell provider and they are promising to optimize the network for us :-). Possibly another option is to try DECT NR+ instead of LTE-M + and a gateway having also an LTE modem!?

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

dejans — Thu, 22 May 2025 08:33:58 GMT

Hi,

It is great to hear that you found answers beneficial.

Best regards,
Dejan

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

marsal — Wed, 21 May 2025 14:58:08 GMT

Thanks a lot, indeed, dejans!

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

dejans — Wed, 21 May 2025 12:43:55 GMT

Hi Martin,

There is nothing on UE side which could be done to improve your use case. Everything is up to network configuration.

Network works in connected mode, but it could maintain connection better if it would support handover. You should contact the carrier and ask whether they support handover for LTE-M. Overall handover is controlled by the network and UE cannot do anything to trigger it.

UE can only try connection re-establishment for recovering connection problems which might cause too long delay for data transmission with regard to your requirements.

Best regards,
Dejan

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

marsal — Tue, 20 May 2025 13:38:26 GMT

Let me still ask: does this meant the the network doesn't work in "Connected" mode for LTE-M (Rev14)? Or should I somehow set nrf9161 to allow this? Thanks again!

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

marsal — Tue, 20 May 2025 08:22:00 GMT

Thx, dejans!

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

dejans — Thu, 15 May 2025 08:18:57 GMT

Hi Martin,

[quote user="marsal"]In general, my question would be if the described settings are OK and/or what could be done more. [/quote]

Connection re-establishment is triggered due to sync loss to serving cell (T310 expiry). This is normal operation for moving UE. Data paths are suspended for time of connection re-establishment. Parameters which control re-establishment are given by the network. There is nothing which could be done from UE side to avoid this interruption. You could contact the carrier regarding network support for LTE-M handover.

Best regards,
Dejan

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

marsal — Fri, 09 May 2025 10:45:17 GMT

Thanks, dejans, a lot!

Well, the best case could be that the descibed changes could have improved the behavior described in the very first email.

I have made the changes described in the previous email with trace link and only then I was recording the trace. Before the change, at the same path, I had observed number of cell switch changes with 1-2 secs data transfer breaks. In general, my question would be if the described settings are OK and/or what could be done more. Big thanks again.

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

dejans — Fri, 09 May 2025 09:57:05 GMT

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

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

marsal — Wed, 07 May 2025 12:04:02 GMT

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";

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

dejans — Wed, 07 May 2025 09:38:23 GMT

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

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

marsal — Tue, 06 May 2025 17:56:55 GMT

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

devzone.nordicsemi.com/.../zephyr.config.txt

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

dejans — Tue, 06 May 2025 05:36:39 GMT

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

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

marsal — Fri, 02 May 2025 06:00:33 GMT

Ok, I will struggle to get the modem trace, it is a little tricky here for me: I am using two uarts in my custom board, uart0 for logging and bidirectional "manual" communication with AT library and uart1 for the communication between GNSS chip and 9161. My understanding is that I must rework this all to enable uart1 just for the modem trace.

Umm, could a periodical RTK server data read which I have in my app be the cause of this data-drop-when-cell-switch behavior? Or is it really network (and not nrf9161) related?

Any idea even even before getting the modem trace would be highly appreciated...

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

marsal — Thu, 01 May 2025 09:23:16 GMT

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.