• State Verified Answer
  • Locked Locked
  • Replies 8 replies
  • Subscribers 75 subscribers
  • Views 1795 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 272833
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Asset Tracker V2 failed_data buffer not filling

Jelmer

I'm testing my own firmware based on the current Asset tracker V2 code (AWS cloud).

The code generally runs well, but when reception drops (simulated by disconnecting the antenna), the firmware does not detect that a packet has not reached AWS. Which results in data loss.

The readme states:

The application has LTE and cloud connection awareness. Upon a disconnect from the cloud service, the application keeps the sensor data that has been buffered and empty the buffers in batch messages when the application reconnects to the cloud service.

Although I can't find anywhere where the firmware detects that the LTE link fails or drops. 
After the antenna has been removed, RSRP drops to zero, ring buffers get filled with data, cloud_module sends data. And then data_module ACKs the pending data. The data never gets moved to the failed_data list.

I feel like I'm missing something, but I'm not sure what it is. All data seems to be acked, no matter the connection status.

- Is there a connection with the MQTT QOS config?

- After a while "aws_iot" sends "aws_iot.mqtt_evt_handler: MQTT_EVT_DISCONNECT: result = -116" which then triggers "modules_common: cloud: Message could not be enqueued, error code: -35" and a reboot. This also results in data loss of course. How come that the modem doesn't detect a packet didn't get acked? What are the timeouts, and where can I find them?

Thanks!

Jelmer

  • 0 in reply to simensr

    Thanks for your help .

    Some more arguments from our side to make the SDK compatible with both 1.2.3 and 1.3:

    - Currently MFW 1.2.3 wrongly reports the online status of the modem in the AT command. This has decent consequences for the user application using this modem firmware. It seems like the bug has been there for at least a year. We'd consider this a high priority bug.
    - Luckily the bug can easily be fixed with a couple lines of code in the SDK, without breaking compatibility with the future modem firmware versions.
    - Upgrading modem firmware to 1.3 might be a solution, but is not supported by Nordic for the hardware in question, and Nordic has mentioned to keep supporting this hardware, since AFAIK there's already large deployments of these chips in the field (rev 1).

    So we don't see why you wouldn't fix this bug with a patch in the SDK. The alternative would be to release mfw 1.2.4, which could fix the issue, but will be extremely costly on the Nordic side and the customer side (testing and certifying a whole new modem firmware + pushing and upgrading large modem firmwares for all the devices currently deployed vs just pushing a smaller new version of the user app).

  • +1 in reply to Jelmer

    Hi! . There is currently a fix in PR for this issue. It would be great if you could test and review https://github.com/nrfconnect/sdk-nrf/pull/5353 to see if it resolves the issue you are seeing.

  • 0 in reply to simensr

    Took me a while to verify this, but that PR seems to fix my issue.

    Thanks to the team for implementing the fix!

Related
Terms of service