Hello Jared Wolff Community,

I am a somewhat new user to Zephyr and nRF9160 based boards. I’m developing firmware for an edge sensor that will send summary readings data about once a day over a cellular link, using MQTT protocol. Presently I’m experimenting with Nordic Semi’s aws_iot sample app from their sdk-nrf v1.6.1.

On the cloud side I have an account with AWS, and have learned some basics of using S3 buckets there. Also using the account’s MQTT broker facility, and an MQTT client which is part of the cloud account. I’ve set up certificates, the original aws_iot sample app sends MQTT packets to a shadow topic with three sub-topics. I’ve created a couple of test topics on the cloud side, and can publish to them there and see messages appear on the prototype edge device. (Have a serial console enabled there for development)

Problem is, when I back off from having edge prototype send a message regularly, I find that even with repeated MQTT subscription actions, I lose cloud-to-device message delivery when the edge device has the radios in sleep or power down mode for more than about 90 seconds.

In the prj.conf file for this Zephyr based app, there’s an MQTT keep alive parameter set to 1200. If that’s in seconds, that works out to 20 minutes. I don’t see any other project configuration symbols which speak to keep alive or persistence settings.

There is probably something really simple I am missing here, but I’m not sure what I need to ask about. I’ve spent past couple days searching. Came across another developer who needed to enable in a similar Nordic sample a symbol like CONFIG_MQTT_SESSION_CLEAN=y. I found I need to add this in order for firmware to pick up new or altered MQTT topic subscriptions across firmware reboots. But this does not address the issue of edge-received packets stopping when the edge device is radio idle for more than a minute or two.

Thanks ahead of time for any help the community can offer!

  • Ted

    tedhavelka66 are you enabling/configuring PSM? The device won’t communicate until the connection window arrives. For more “real time” applications, it’s advised to keep any power save functionality turned off, especially if you’re device is connected to a power supply.

      Hello Jared,
      For my part I have not enabled any PSM (power savings mode?) options explicitly in my coding amendments to Nordic’s aws_iot sample app. In the prj.conf file I don’t find any direct references to config items relating to PSM. There is a config symbol defined in prj.conf for an MQTT maximum keep alive:

      # MQTT - Maximum MQTT keepalive timeout specified by AWS IoT Core
      CONFIG_MQTT_KEEPALIVE=1200

      But this looks to be specific to Amazon Web Services, and I’m guessing is also a timing attribute measured in seconds. So a keep alive of twenty minutes.
      Searching the sources of my project for references to PSM, I find there are a couple of LTE modem settings pulled in through an unknown-to-me dependency. These appear in a couple of build time artifact files:

      ted@localhost:~/projects/zephyr-based/edge-sensor-and-mqtt-client$ grep -nr PSM ./*
      Binary file ./build/CMakeFiles/app.dir/src/main.c.obj matches
      Binary file ./build/modules/nrf/lib/lte_link_control/lib..__nrf__lib__lte_link_control.a matches
      .
      .
      .
      ./build/zephyr/misc/generated/configs.c:169:GEN_ABSOLUTE_SYM_KCONFIG(CONFIG_LTE_PSM_REQ_RPTAU, 1);
      ./build/zephyr/misc/generated/configs.c:170:GEN_ABSOLUTE_SYM_KCONFIG(CONFIG_LTE_PSM_REQ_RAT, 1);
      Binary file ./build/zephyr/zephyr_prebuilt.elf matches
      ./build/zephyr/zephyr.lst:6805: printk("Requesting PSM failed, error: %d\n", err);
      ./build/zephyr/zephyr.lst:7481: printk("PSM parameter update: TAU: %d, Active time: %d\n",
      ./build/zephyr/zephyr.lst:30524: evt.type = LTE_LC_EVT_PSM_UPDATE;
      ./build/zephyr/zephyr.lst:30531: evt.type = LTE_LC_EVT_PSM_UPDATE;
      ./build/zephyr/zephyr.lst:30684: if ((evt.modem_sleep.type != LTE_LC_MODEM_SLEEP_PSM) &&
      ./build/zephyr/zephyr.lst:30768: "AT+CPSMS=1");
      ./build/zephyr/zephyr.lst:31910: LOG_ERR("Failed to parse PSM configuration, error: %d",
      ./build/zephyr/zephyr.lst:32102: LOG_ERR("Failed to parse PSM configuration, error: %d",
      Binary file ./build/zephyr/dfu_application.zip matches
      ./build/zephyr/.config.old:463:CONFIG_LTE_PSM_REQ_RPTAU="00000011"
      ./build/zephyr/.config.old:464:CONFIG_LTE_PSM_REQ_RAT="00100001"
      Binary file ./build/zephyr/app_to_sign.bin matches
      Binary file ./build/zephyr/app_update.bin matches
      Binary file ./build/zephyr/CMakeFiles/zephyr.dir/misc/generated/configs.c.obj matches
      Binary file ./build/zephyr/libzephyr.a matches
      ./build/zephyr/.config:463:CONFIG_LTE_PSM_REQ_RPTAU="00000011"
      ./build/zephyr/.config:464:CONFIG_LTE_PSM_REQ_RAT="00100001"
      ./build/zephyr/include/generated/autoconf.h:159:#define CONFIG_LTE_PSM_REQ_RPTAU "00000011"
      ./build/zephyr/include/generated/autoconf.h:160:#define CONFIG_LTE_PSM_REQ_RAT "00100001"
      ./src/main.c:622: printk("Requesting PSM failed, error: %d\n", err);
      ./src/main.c:715: case LTE_LC_EVT_PSM_UPDATE:
      ./src/main.c:716: printk("PSM parameter update: TAU: %d, Active time: %d\n",
      Binary file ./src/.main.c.swp matches

      Are the PSM parameter tau and active time the kinds of PSM settings you are asking about?

      • Ted

        One thing I have noticed behaviorally, is that in the first minute or so from firmware start time, messages which I publish to custom topics appear within seconds of my publishing them in the cloud MQTT client. After a minute or so, messages arrive only and just after the firmware on the Thingy91 publishes a message. I take this to mean that the modem is in some power down mode most of the time. The sample app turns the modem on to send to a default, sample topic. That then is the time when messages can be received.

        The firmware sends messages which reach an MQTT broker and subsequent MQTT client in an AWS cloud account. It sends them even with an edge device publishing interval of 15 minutes and longer. But the firmware doesn’t for some reason configure or control the radio of the nRF9160 to pick up pending, queued messages, if the modem or radio is idle more than a few minutes. This seems to be the situation I’m facing, hence my post seeking help for a solution.

          tedhavelka66 Are the PSM parameter tau and active time the kinds of PSM settings you are asking about?

          Yup! You should comment out anything in main.c that is setting/referring to PSM.

          tedhavelka66 But the firmware doesn’t for some reason configure or control the radio of the nRF9160 to pick up pending, queued messages, if the modem or radio is idle more than a few minutes. This seems to be the situation I’m facing, hence my post seeking help for a solution.

          Your MQTT client doesn’t know about how your modem is configured and vice versa. You’ll need to configure both to match your use case.

              Terms and Conditions | Privacy Policy