Issue with Receiving Downlink Data on STM32WL Device Using JSON Format in LoRaWAN

[PrathamSalunkhe]

Hi everyone,

I am working on an STM32WL-based device and have successfully operated downlink in LoRaWAN communication when using the following JSON payload format:

{
"devEui": "0102030405060708",
"confirmed": true,
"fPort": 10,
"data": "ESIzRFU="
}

In this case, I sent a base64-encoded data string, and the downlink was successfully received by the device. Here's the relevant log output from the device:

[16:16:14:337] 1735817707s657:RX_C on freq 869525000 Hz at DR 0␍␊
[16:17:20:696] 1735817774s061:MAC rxDone␍␊
[16:17:40:846] +EVT:RX_C, PORT 10, DR 0, RSSI -32, SNR 5␍␊
[16:17:40:890] +EVT:12:1122334455␍␊

However, when I attempt to send the following JSON payload, where I pass individual parameters in the object field instead of a base64-encoded string, the payload is successfully sent from the server, but the STM32WL device only receives the fport value. The data and datasize  fields are both zero on the device.

{
"devEui": "0102030405060708",
"confirmed": true,
"fPort": 10,
"object": {
  "deviceId": 01020304AABBCCDD,
  "cmdType": 01,
  "cmdId": 01,
  "epochTime": 677FAA90
  }
}

Has anyone encountered a similar issue or can suggest how to resolve this?

Thanks in advance for your help!

Best regards,
Pratham

[Andrew Neil]

---

@PrathamSalunkhe wrote:

I am working on an STM32WL-based device and have successfully operated downlink in LoRaWAN communication when using the following JSON payload format:

---

So where, exactly, are you specifying that JSON payload?

Are you sure that your JSON with an object field is valid for whatever system it is that you're using?

ie, what makes you think that the problem is with the STM32WL-based device - rather than elsewhere in the system?

[PrathamSalunkhe]

Hello @Andrew Neil 

Thank you for your response!

I’m using the LoRaWAN_AT_Slave example code, and after the device successfully joins the server, I change its class to CLASS C to receive downlinks.

When I send the JSON payload with base64-encoded data in the data field, it works fine.

Now I’d like to ask: Can I send a JSON payload with different parameters? For example, instead of sending a payload with the data field containing base64-encoded data (which the device successfully receives), I want to send a payload in JSON format like this:

{  
  "devEui": "0102030405060708",  
  "confirmed": true,  
  "fPort": 10,  
  "object": {  
    "deviceId": "01020304AABBCCDD",  
    "cmdType": "01",  
    "cmdId": "01",  
    "epochTime": "677FAA90"  
  }  
}  

With the payload above, the device only receives the fport value, and both data and datasize are zero.

Is it possible to send JSON payloads with different parameters like this? Or do I need to modify the example code to handle such payloads?

I would appreciate further guidance on verifying whether the STM32WL-based device supports downlink payloads with nested JSON objects or if additional modifications are required in the firmware.

Best Regards,
Pratham

[Andrew Neil]

You didn't answer the question:

So where, exactly, are you specifying that JSON payload?

Are you sure that your JSON with an object field is valid for whatever system it is that you're using?

ie, what makes you think that the problem is with the STM32WL-based device - rather than elsewhere in the system?

---

@PrathamSalunkhe wrote:

Now I’d like to ask: Can I send a JSON payload with different parameters?

---

That would depend on whatever it is that you're using to send the data.

[PrathamSalunkhe]

Hello @Andrew Neil 

Thank you for your response!

To clarify:

1. Where I’m specifying the JSON payload:
   I’m specifying the JSON payload on the application server, which queues it for downlink via the LoRaWAN network. The server accepts both payload formats (with the data field and the object field).

2. Validating the JSON with the object field:
   The JSON payload with the object field is accepted by the server without any errors. However, I’m not sure if the STM32WL-based device or the LoRaWAN_AT_Slave example code supports processing such payloads. That’s what I’m trying to confirm.

3. Why I think the issue might be with the STM32WL-based device:
   When I send a payload with the data field containing base64-encoded data, the device receives and processes it correctly. However, when I use the object field with nested parameters, the device does not receives any data.

I’d appreciate any guidance on whether this is supported by the STM32WL firmware or if adjustments are needed in the firmware.

Best Regards,

Pratham

[Andrew Neil]

You still haven't said what Application Server you're using.

Or what Network.

---

@PrathamSalunkhe wrote:

The JSON payload with the object field is accepted by the server without any errors.

---

Maybe the Application Server just silently ignores it?

Maybe some other part of the network discards it?

---

@PrathamSalunkhe wrote:

Why I think the issue might be with the STM32WL-based device:
When I send a payload with the data field containing base64-encoded data, the device receives and processes it correctly. However, when I use the object field with nested parameters, the device does not receives any data.

---

That doesn't answer the question of why you think, specifically, that the problem lies in the device - rather than elsewhere in the network.

Does the network give any logs to show what was actually sent?

The device itself never sees the JSON - just the pure binary data that it represents.

Do you have any other devices which do receive the data?

[Andrew Neil]

Duplicate here from @anupam1511 ?

are you working together?

[PrathamSalunkhe]

Thank you for your insights!

• Application Server: I am using AWS IoT Core as the application server.
• Network: I don’t receive detailed logs from the network, but I can verify on the gateway (RAK7289) that the downlink is received when sent from the server.

Regarding your point about the device only seeing the binary data:
Could you confirm if there is any JSON parsing function or downlink parsing functionality in the firmware library? After the downlink is received, the data seems to be stored in the following structure:

typedef struct LmHandlerAppData_s
{
    uint8_t Port;
    uint8_t BufferSize;
    uint8_t *Buffer;
} LmHandlerAppData_t;

Before the data gets stored in the buffer (in hexadecimal format), where is it being parsed? Specifically, how does the firmware handle and map JSON fields to binary data?

As for your query about duplicates: yes, @anupam1511  and I are colleagues, but we’re working on different projects. We’re both using LoRaWAN communication, which is why there’s some overlap in our discussions.

Looking forward to your guidance!

[Andrew Neil]

---

@PrathamSalunkhe wrote:

• I can verify on the gateway (RAK7289) that the downlink is received when sent from the server.

---

And that's both in the case of using just 'data' and also in the case of using 'object' ?

But this still doesn't guarantee that the data is (correctly) passed-on by the Gateway.

---

@PrathamSalunkhe wrote:

Could you confirm if there is any JSON parsing function or downlink parsing functionality in the firmware library? 

---

I would think that unlikely in the extreme: JSON is grossly inefficient - which is completely at odds with a low-data protocol like LoRaWAN.

eg,

{
"devEui": "0102030405060708",
"confirmed": true,
"fPort": 10,
"data": "ESIzRFU="
}

takes 84 bytes for just 8 byes of payload!

[PrathamSalunkhe]

Thank you for pointing out the 84 bytes. Could you explain what exactly contributes to this size? My understanding is that it might include the overhead of the JSON structure itself (e.g., field names, formatting, and metadata) in addition to the payload data. If that’s correct, does this imply that JSON payloads are inherently inefficient for LoRaWAN due to their size?

To clarify my use case:
I’m looking to send a more complex JSON payload like the following:

{
    "devEui": "0102030405060708",
    "confirmed": true,
    "fPort": 10,
    "object": {
        "temperatureSensor": { "1": 25 },
        "humiditySensor": { "1": 32 }
    }
}

For example, if my device has temperature and humidity sensors, and I need to send configuration or commands to it in such a structure, would this be feasible with LoRaWAN communication? I understand that LoRaWAN is designed for low-bandwidth communication, but can such nested JSON objects be supported?

If not, would converting the JSON into a more compact binary format be the recommended approach? Any suggestions on how to handle such cases would be greatly appreciated.