• State Verified Answer
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 68 subscribers
  • Views 558 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 317324
Options

Proprietary PSM

mjaszczykowski

Dear Nordic,

Could you please advise how to interpret the version in this context?

The modem firmware v2.X - is it the version that does not exist right now?
If yes, when you are planning to release it?

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.5.0/nrf/samples/cellular/lwm2m_client/sample_description.html#modem-proprietary-psm

Best regards,
Marcin

  • +1

    Hi,

    This refers to modem firmware v2.0.0 (and later), which is only available for the nRF9161 SiP, which again is currently available for sampling to selected customers only.

    For information on future plans and roadmaps, please contact our sales representative for your area. If you do not know who that is, please ask in a private case or private message for us to let you know, or use our sales related questions form for your future plans and roadmap questions or for more information about the nRF9161.

    Regards,
    Terje

  • 0 in reply to tesc

    Unfortunately PSM is often not supported on roaming.

    What is the correct and most power efficient procedure to emulate proprietary PSM on a nrf9160?

    Eg. after reaching Active Time do one or more of following calls:

    •  lte_lc_deinit() ??
    •  lte_lc_offline() ??
    •  lte_lc_power_off() ??

    Thx, Matthias

  • 0 in reply to mjm987

    Answering my own question...

    I guess following should work to emulate a "Proprietary PSM" cycle:

    1. PSM is not supported by the active network operator if event LTE_LC_EVT_PSM_UPDATE indicates evt->psm_cfg.active_time <= 0
    2. In this case do follwing after transmission work:
    3. Do close(server_socket)
    4. Execute lte_lc_offline()
    5. Sleep until time is reached for next transmission then:
    6. Execute lte_lc_normal()
    7. Wait (using a semaphore) until event LTE_LC_EVT_NW_REG_STATUS indicates LTE_LC_NW_REG_REGISTERED_HOME or LTE_LC_NW_REG_REGISTERED_ROAMING
    8. Then perform a socket connect (ev. getaddrinfo(), socket(), connect(), ev. setsockopt() to set recv timeout etc.
    9. And send/recv what you want.

    In my simple udp tests after initial setup a transmit cycle including socket reconnect and send/recv of a short frame takes ~185 mC at 3.3V whereas a send/recv in a PSM cycle (where no reconnect is needed) takes ~100 mC. During inactive period the supply current is same (12.5 uA using a nrf9160 feather module if all other periphery is set suspended).

    But unfortunately previous procedure is still not reliable: after going offline for power saving and reactivating by lte_lc_normal(), it often takes long for re-registering to the previously active network operator with silly switching forth and back between operators as seen here:

    [00:00:28.225,921] <dbg> main: set_pm_resume: resume
    [00:00:28.225,860] <dbg> main: lte_handler: LTE_LC_EVT_MODEM_SLEEP_EXIT
    [00:00:29.176,483] <dbg> main: lte_handler: Network registration status: 2
    [00:00:29.176,544] <dbg> main: lte_handler: LTE cell changed: Cell ID: 12902406, Tracking area: 41300
    [00:00:29.176,544] <dbg> main: lte_handler: LTE_LC_EVT_LTE_MODE_UPDATE
    [00:00:29.258,758] <dbg> main: lte_handler: RRC mode: Connected
    [00:00:39.677,673] <dbg> main: lte_handler: RRC mode: Idle
    [00:01:08.447,875] <dbg> main: lte_handler: LTE cell changed: Cell ID: 17154569, Tracking area: 1515
    [00:01:08.521,850] <dbg> main: lte_handler: RRC mode: Connected
    [00:01:23.481,170] <dbg> main: lte_handler: RRC mode: Idle
    [00:01:33.592,498] <dbg> main: lte_handler: RRC mode: Connected
    [00:01:36.087,524] <dbg> main: lte_handler: RRC mode: Idle
    [00:01:36.138,183] <dbg> main: lte_handler: LTE cell changed: Cell ID: 12902406, Tracking area: 41300
    [00:01:36.220,489] <dbg> main: lte_handler: RRC mode: Connected
    [00:01:42.614,715] <dbg> main: lte_handler: Network registration status: Connected - roaming

    Does anybody have a better approach?

    Regards, Matthias

  • 0 in reply to mjm987

    Would love to hear what you ended up with here! We're running into networks that don't support PSM and need a more power conservative option.

Related