cancel
Showing results for 
Search instead for 
Did you mean: 

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

PrathamSalunkhe
Associate II

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

 

10 REPLIES 10

@PrathamSalunkhe wrote:

Thank you for pointing out the 84 bytes. Could you explain what exactly contributes to this size? .


Just count the characters!

1 character = 1 byte.

 


@PrathamSalunkhe wrote:

 does this imply that JSON payloads are inherently inefficient for LoRaWAN due to their size?.


JSON payloads are inherently inefficient for any use due to their size!

I would be 99.999999999% certain that the JSON is not sent over LoRaWAN - it is purely used as way for you to put data into your network's API.