LTE-M: sending data on trigger and periodic event

Hello!

I am using NRF1960 Feather boars and NRF Connect v1.7.0 for developing firmware.

I have a task to send data to server using LTE-M in 2 cases:

  • periodically status update (for example every 3 hours);
  • on trigger event (For example, if somebody push button, device need to connect some information for server as soon as possible (in best scenario under 2 seconds, if possible))

I must use some power saving mode - PSM during inactivity time, to save battery.

The question is - how to correctly implement that?

I have read some tutorials about implementing LTE-M:

As I understand, I could use TAU timer for periodically sending data to server. As before sending data, TAU process is needed, it is recommended to make data interval equal to TAU timer or multiply of that. But how exactly can I achieve that? How to synchronize those 2 events, that after TAU timer expires, it automatically send data after TAU procedure?

But what would be suggested way to request data from server during trigger event?

Could it be good idea to to do these steps avoiding to use TAU timer (to be honest I do not understand purpose of TAU timer if TAU procedure is done before sending data automatically)?

  • Initialize LTE module
  • Sending modem to offline mode
  • And then using regular timer or trigger event send LTE modem to normal mode (lte_lc_normal() and send all status data or request needed data)
  • And again send modem to offline mode

I would be glad to hear some advices or some some tutorials who which explains how to achieve this correctly to optimize battery usage, data usage (LTE-M usage costs) and  get some small data from server under couple of seconds in trigger event.

 

  • So, I tested your programm and it works almost correctly. Here is log file:

    Connecting..
    Connected to COM28!
    *** Booting Zephyr OS build v2.6.99-ncs1  ***
    Hello World! circuitdojo_feather_nrf9160
    %XMODEMSLEEP: 4
    Modem going to type 4 sleep for -1ms
    %XMODEMSLEEP: 4
    Modem going to type 4 sleep for -1ms
    %XMODEMSLEEP: 4,0
    Modem has exited sleep. Type: 4
    [00:00:00.271,118] <dbg> lte_lc.init_and_config: System mode (1) and preference (0) are already configured
    [00:00:00.292,999] <dbg> lte_lc.at_handler: %XMODEMSLEEP notification
    [00:00:00.296,356] <dbg> APP.lte_handler: Modem going to type 4 sleep for 8589934591ms
    [00:00:00.296,508] <dbg> lte_lc.lte_lc_system_mode_set: Sending AT command to set system mode: AT%XSYSTEMMODE=1,0,0,0
    [00:00:00.313,049] <dbg> lte_lc.at_handler: %XMODEMSLEEP notification
    [00:00:00.316,406] <dbg> APP.lte_handler: Modem going to type 4 sleep for 8589934591ms
    [00:00:00.352,905] <dbg> lte_lc.at_handler: %XMODEMSLEEP notification
    +CEREG: 2,"AE38","003E0A26",7
    Not registered to a network
    Cell update. TAC: 44600, ID: 4065830
    LTE mode update: 7
    +CSCON: 1
    RRC update: Connected
    [00:00:02.229,003] <dbg> lte_lc.at_handler: +CEREG notification: +CEREG: 2,"AE38","003E0A26",7
    
    [00:00:02.229,187] <dbg> lte_lc_helpers.parse_cereg: Network registration status: 2
    [00:00:02.229,217] <dbg> lte_lc_helpers.parse_cereg: LTE mode: 7
    [00:00:02.287,902] <dbg> lte_lc.at_handler: +CSCON notification
    +CEREG: 1,"AE38","003E0A26",7,,,"00100001","00000110"
    Registered to a network
    PSM update. TAU: 3600, AT: 60
    [00:00:04.083,160] <dbg> lte_lc.at_handler: +CEREG notification: +CEREG: 1,"AE38","003E0A26",7,,,"00100001","0~
    [00:00:04.083,465] <dbg> lte_lc_helpers.parse_cereg: Network registration status: 1
    [00:00:04.083,465] <dbg> lte_lc_helpers.parse_cereg: LTE mode: 7
    [00:00:04.083,496] <dbg> lte_lc_helpers.parse_psm: TAU: 3600 sec, active time: 60 sec
    
    +CSCON: 0
    RRC update: Idle
    %XT3412: 3599999
    +CEREG: 1,"AE38","003E0A1C",7,,,"00100001","00000110"
    Cell update. TAC: 44600, ID: 4065820
    [00:00:14.364,501] <dbg> lte_lc.at_handler: +CSCON notification
    [00:00:14.367,736] <dbg> lte_lc.at_handler: %XT3412 notification
    [00:00:15.029,205] <dbg> lte_lc.at_handler: +CEREG notification: +CEREG: 1,"AE38","003E0A1C",7,,,"00100001","0~
    [00:00:15.029,449] <dbg> lte_lc_helpers.parse_cereg: Network registration status: 1
    [00:00:15.029,479] <dbg> lte_lc_helpers.parse_cereg: LTE mode: 7
    [00:00:15.029,510] <dbg> lte_lc_helpers.parse_psm: TAU: 3600 sec, active time: 60 sec
    
    %XMODEMSLEEP: 1,3539950
    Modem going to type 1 sleep for 3539950ms
    [00:01:14.417,877] <dbg> lte_lc.at_handler: %XMODEMSLEEP notification
    [00:01:14.421,691] <dbg> APP.lte_handler: Modem going to type 1 sleep for 4298507246ms
    %XT3412: 5000
    TAU pre-warning: 5000ms to TAU
    %XMODEMSLEEP: 1,5000
    Modem waking up from sleep in 5000ms
    [01:00:09.507,263] <dbg> lte_lc.at_handler: %XT3412 notification
    [01:00:09.512,054] <dbg> lte_lc.at_handler: %XMODEMSLEEP notification
    %XT3412: 0
    

    And loooking at 50. and 52. line strange thing happen. "printk" and "LOG_DBG" gives different output. Not sure, why???

    It comes from your code:

    case LTE_LC_EVT_MODEM_SLEEP_ENTER:
    	printk("Modem going to type %d sleep for %lldms\n", evt->modem_sleep.type, evt->modem_sleep.time);
    	LOG_DBG("Modem going to type %d sleep for %lldms", evt->modem_sleep.type, evt->modem_sleep.time);

    Answering to questions:

    Which SDK version are you using?

    sdk-nrf v1.7.0

    And which toolchain version?

     NCS Toolchain 2.1.1

    Did you install the SDK and toolchain with the Toolchain Manager or did you install them manually?

    I installed Toolchain with toolchain manager, but SDK using plugin:

    circuitdojo.zephyr-tools

    from websitehttps://github.com/circuitdojo/zephyr-template/

    I guess, I mixed wrong SDK and Toolchain version!

  • I originally tested on NCS v2.1.0, and did not see any difference between printk and LOG_DBG.

    However, if I go back to 1.7.0 or 1.8.0, I see the same difference that you do, while it is gone in 1.9.0.

    So it looks like some change introduced in NCS v1.9.0 removes the printk/LOG_DBG mismatch, but I haven't yet found out what causes the change in behavior.

Related