LoRaWAN Downlink about radiolib HOT 8 CLOSED

Could you share the bytes you send and the bytes you receive please.

along with its example file for uplink communication. I'm also using the same file for downlink reception.

Be aware that you have to use the same file - for Class A configs (the vast majority) a downlink is ONLY sent after an uplink.

from radiolib.

Thanks for looking into this. Yes, I receive the downlinks only after an uplink.

I schedule a downlink of "DEADBEEF" at the Actility side. I receive exactly 4 bytes worth downlink payload from the end-device. However, the received payload changes with each downlink although same payload is sent from NS side. Would it be because some encryption is happening on the downlink payload, and its not yet decrypted?

from radiolib.

I've sent multiple handfuls of downlinks by now and never noticed any trouble. Can you enable debug mode (pretty please not verbose mode) and show the output on your device when one or two downlinks occur?

from radiolib.

Just doing a sanity check / test on the downlink - I'm not a fan of Strings and Strings for a byte array is particularly messy so I'm just reworking it for the other downlink function signature.

from radiolib.

Try this:

uint8_t downlinkPayload[32];
size_t downlinkLength;
state = node.downlink(downlinkPayload, &downlinkLength);
if(state == RADIOLIB_ERR_NONE) {
      if(downlinkLength > 0) {
            Serial.print(F("[LoRaWAN] Downlink:\t"));
            Module::hexdump(downlinkPayload, downlinkLength);
      }
}

Your DEADBEEF should be revealed and you can interpret the downlinkPayload byte array

from radiolib.

        Module::hexdump(downlinkPayload, downlinkLength);

Should have added, you need RADIOLIB_DEBUG turned on for this to work, otherwise it won't compile.

I'm working on a more modular example so will figure the debug output shortly.

from radiolib.

@DavidKrepzi, did this solve your issue?

from radiolib.

Assuming this worked for OP so closing.

from radiolib.