• State Not Answered
  • Replies 12 replies
  • Subscribers 76 subscribers
  • Views 2325 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 284223
Options

LTE-M consuming way to much power to transmit 100 bytes UDP every 15 seconds, please help me understand why.

EDLT

I'm using the UDP sample from SDK 1.8.0 with the following modifications:

  • No PSM
  • No eDRX
  • Send 100 bytes every 15 seconds

This is on the nrf9160-DK board.

I suspect I can improve power consumption by disabling RRC idle mode, but I cannot find any documentation on how to do this.

I am unsure of the actual cDRX timing parameters as what seems like DRX events are sporadic.

Here are some power profile images and a modem trace if that's helpful.

The above image shows large period of almost continuous activity after the TX event for ~5 seconds and then iDRX activity until the next TX event.

This is the activity while RRC connected. 

I am seeing an average of 10mA, with 22mA during the connection period. I was expecting the average current consumption to be 2.5 - 4mA.

7723.trace-2022-02-14T21-46-37.030Z.bin

Parents
  • 0 in reply to JONATHAN LL

    Hi Jonathan,

    Version is 1.6.1.

    Since posting this I was able to make significant improvement using RAI and socket options to get an early RRC release to idle. I guess I'm surprised most by the 2nd power profile image where the signaling is almost constant and there is no discernable/regular cDRX duration and inactivity period.

  • 0 in reply to EDLT

    Jonathan,

    While awaiting an answer about what determines the cDRX duty cycle, I'm wondering if there is a way to know when the modem has finished sending all its data.

    When using the RAI feature, if we send more than 600 bytes or so, I notice there are two outgoing transmissions. I imagine this is because the modem was not able to send out all data before we indicated there was not more data with the RAI_NO_DATA socket option.

    If we can know when all the data has been transmitted, then I can better time the use of the RAI_NO_DATA option to conserve power.

  • 0 in reply to EDLT

    Hi EDLT, 

    Sorry for bringing back an old thread, but your comment here seems to be the only evidence I can find of anyone successfully getting RAI to work on LTE-M. Is this true?

    My LTE-M packets look identical to your original post, at around 120mC and I have ran out of things to try in attempting to get RAI to work. I've had success using RAI on NB-IoT with the %RAI and socket options as you say, but not on LTE-M. Older threads seem to suggest RAI doesn't work on LTE-M, but maybe things have changed? I'm wondering if I have everything right and it is simply the network saying no. 

    Which modem firmware were you using in combination with SDK 1.6.1? Was there anything special you had to do to get things working on LTE-M?

    Many thanks

  • 0 in reply to Jake

    Hi Jake,

    Can you create a new ticket her on Devzone and link or refer to this ticket, this way we can more specifically try to help you with your exact issue.

    We can always update this thread with a link to the new ticket as long as it is public.

    Regards,
    Jonathan

  • 0 in reply to Jake

    Jake,

    Firstly, I've initialized the modem with the following commands

    1. AT%XDATAPRFL=0
    2. AT+CFUN=4
    3. AT%REL14FEAT=0,1,0,0,0
    4. AT%RAI=1

    Then utilizing RAI can be tricky. I've found in my brief experiments that sending upwards of 700 bytes will cause a retransmission - likely because the socket is terminated early before an acknowledge is received. For short bursts (i.e. sending small mqtt payloads) I've used:

    • setsockopt(mqtt_socket, SOL_SOCKET, SO_RAI_ONGOING, NULL, 0);
      • To indicate I'm about to send data
    • mqtt_publish(...)
    • setsockopt(mqtt_socket, SOL_SOCKET, SO_RAI_NO_DATA, NULL, 0);
      • To indicate I'm done sending data and would like an early release

    Note that I've only bench tested and don't yet have evidence that this will work in all cell tower situations.

Reply
  • 0 in reply to Jake

    Jake,

    Firstly, I've initialized the modem with the following commands

    1. AT%XDATAPRFL=0
    2. AT+CFUN=4
    3. AT%REL14FEAT=0,1,0,0,0
    4. AT%RAI=1

    Then utilizing RAI can be tricky. I've found in my brief experiments that sending upwards of 700 bytes will cause a retransmission - likely because the socket is terminated early before an acknowledge is received. For short bursts (i.e. sending small mqtt payloads) I've used:

    • setsockopt(mqtt_socket, SOL_SOCKET, SO_RAI_ONGOING, NULL, 0);
      • To indicate I'm about to send data
    • mqtt_publish(...)
    • setsockopt(mqtt_socket, SOL_SOCKET, SO_RAI_NO_DATA, NULL, 0);
      • To indicate I'm done sending data and would like an early release

    Note that I've only bench tested and don't yet have evidence that this will work in all cell tower situations.

Children
  • 0 in reply to EDLT

    Hi EDLT, many thanks for the reply.

    Interesting, I had experimented with REL14FEAT but without success. I actually had no luck getting NRF_SO_RAI_NO_DATA to work on NB-IoT and ended up using NRF_SO_RAI_LAST with an extra send to get a release. Maybe on LTE-M I need to go back to trying NRF_SO_RAI_NO_DATA as you do. 

    It could also be my use of the NRF_ versions with nrf_socket that is the difference. Or just that my network doesn't support it... I'll see what I can do. 

    Thanks again, and thanks Jonathan. 
    Jake

Related
Terms of service