Can't receive downlink payloads to the Sodaq ExpLoRer - RN2903

Hi Guys,

I am having an issue receiving downlink communications from the network Server. I am using MQTT and can see the received packets in the dashboard provided by my Network provider but not on the Sodaq ExpLoRer.

I have set the Publish on my MQTT client to send every 30 seconds to the dldata topic and the Sodaq ExpLoRer sends a packet to the uldata topic every 60 seconds. After sending it checks for a received packet. It always comes back with ‘No Received Payload’. I have played around with different timings and with different Txpara parameters on the Downlink packet structure itself.

Interestingly I noticed that at some point I received a packet, however, because I was sending so much I couldn’t isolate the conditions that cause this one packet to get through. I think there may be a limit on the number of Downlink packets that can be sent/received. This is not specified in the LoRaWAN regional parameters for Australia though.

I have created a simple program to send a blank packet 0x00 every 60 seconds and to count the number of received packets. The MQTT client is publishing every 60 seconds also. These packets are being received on the network server, but not on the device. I will leave it sending overnight to see if it’s a timing limitation.

Is there something that I’ve missed?

My code I used is below:

LoRaTest_RX.cpp


#include <Sodaq_RN2483.h>
#include <Sodaq_wdt.h>
#include <Arduino.h>
#include "RTCZero.h"

#define loraSerial Serial2
#define debug(x) SerialUSB.print(x);
#define debugl(x) SerialUSB.println(x);
#define flush SerialUSB.flush();

//Create an SodaqRTC object
RTCZero rtc;
volatile uint32_t epoch = 1505897247;          //Update before starting program

void printLocalTime();
void receiveData();
volatile int messageCount = 0;

// USE YOUR OWN KEYS!
const uint8_t devAddr[4] =
{
   0x00, 0x00, 0x00, 0x00
};

// Application Server Key 
const uint8_t appSKey[16] =
{
   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
};

// Network Server Key 
const uint8_t nwkSKey[16] =
{
   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
};

void setup()
{
   while ((!SerialUSB) && (millis() < 10000));

   SerialUSB.begin(57600);
   loraSerial.begin(LoRaBee.getDefaultBaudRate());
   //LoRaBee.setDiag(SerialUSB); // optional

   rtc.begin();          //start timer
   rtc.setEpoch(epoch);  //set time

   if (!LoRaBee.initABP(loraSerial, devAddr, appSKey, nwkSKey, false)){
      debugl("ERROR: Connection to the network failed!");
   }

   // Sleeping for 5 seconds before starting sending out test packets.
   for (uint8_t i = 3; i > 0; i--) {
      delay(1000);
   }

}



void loop()
{

   uint8_t bytes;
   uint8_t TX_Payload[] = {0x00};
   uint8_t RX_Payload[5];
   String HEXPayload = "";

   //Send LoRa Transmission
   if (LoRaBee.send(2, TX_Payload, 1)) {
      debugl("--ERROR--");
   }

   //If Transmission Successful
   else {
      //Check if received
      bytes = LoRaBee.receive((uint8_t*) RX_Payload, 4);

      //If Received
      if (bytes) {
         debugl("\n --Message Received--");
         messageCount++;
         printLocalTime();
         debug("Length: "); debug(bytes); debug("\t");
         for(int i = 0; i < bytes; i++){
            HEXPayload += String(RX_Payload[i],HEX);
         }
         debug("Message: "); debugl(HEXPayload);
         debug("\n")
      }

   }

   printLocalTime();
   debug("Messages Received: ");
   debugl(messageCount);

   //Send Every 60 seconds
   delay(60000);

// -- LOOP --
}

void printLocalTime()
{
   debug(rtc.getDay()); flush; debug("/"); flush;
   debug(rtc.getMonth()); flush; debug("/"); flush;
   debug(rtc.getYear()); flush; debug(" - "); flush;
   debug(rtc.getHours()+10); flush; debug(":"); flush;
   debug(rtc.getMinutes()); flush; debug(":"); flush;
   debug(rtc.getSeconds()); flush; debug(" \t"); flush;
}

Extra Info:

The device has a RN2903 LoRa Chip. I am using the Sodaq_RN2843 Library and I had added a few more fields to ensure the channels and SF are set correctly for downlink in Australia.
This is the function I added to the library file “Sodaq_RN2483.cpp”. And I have called the function from the “Sodaq_RN2483::resetDevice” function.

Viewing the diagnostics from this script I can see that these additional commands executed properly.

Added in Sodaq_RN2483.cpp

bool Sodaq_RN2483::setRXParams()
{
   debugPrintLn("[setRX2]");

   bool allOk = true;

   const char* rx2_str = "8 923300000";
   allOk = setMacParam(STR_RX2, rx2_str);
   if (!allOk){
      return (false);
   }
   allOk = setMacParam(STR_RXDELAY1, "1000");
   if (!allOk){
      return (false);
   }
   allOk = setMacParam(STR_AR,"on" );
   if (!allOk){
      return (false);
   }

   return (true);
}

Added in Sodaq_RN2483::resetDevice: - line 554

  ...  return setFsbChannels(DEFAULT_FSB)
                       && setRXParams()       //This function adds Downlink parameters
                       && setPowerIndex(DEFAULT_PWR_IDX_915)
                       && setSpreadingFactor(DEFAULT_SF_915);

Edit: I added a RTC to observe the times that any downlink messages comes in.

Dear Brendan,

Does the RN2903 has the Australian firmware?
You can check with and update it with the RNUpdater:

The issue can be a firewall.
The MQTT can queue a message in the server.
The server cannot send the message to the gateway.

Can you try to only send in RX1 or RX2. If this option is available for you to change.
If the latency is too much the packets will also never arrive on time at the gateway.

I hope this helps you to find the issue.

Regards,
Jan

Hi Jan,

Yes, the RN2903 does have the Australian Firmware.
I did receive one downlink packet though. (out of hundreds) I would have thought if it was the firewall, then this wouldn’t have gotten through at all.

Thanks for your help.

I know this isn’t really related to the ExpLoRer itself, but I still can’t get this working. I used the FirwareUpdater script and ensured that it had the Australian firmware installed.

It doesn’t appear to be the firewall either. I have manually forwarded all packets on ports 8883 and 5003 (as specified by the network provider) to the gateway’s IP address. Now at the network server, instead of its status being ‘-queued-’ it’s saying ‘-failed-’. Any ideas what might be causing this.

Rx1 doesn’t work at all between the RN2903 and the Gateway. This is a known issue with the gateway manufacturer and will be patched in the latest firmware update in October. They have assured me that Rx2 still works fine. I have tried manually sending to Rx2 only, but this isn’t working either. I have contacted the gateway manufacturer and I am just waiting for a reply.

When you say ‘if the latency is too much’ does this refer to the Rx1 and Rx2 delay times? or other latency? I have set the Rx1 and Rx2 delay times per the LoRa Regional parameters spec and have confirmed this with the gateway service provider and gateway manufacturer.

Regards,

Brendan

Hi Brendan,

What is the gateway you use and network operator?

Maybe you can try some other communities with the Australian Firmware issue.
Maybe someone in the things network can help you out, I see that a lot of people are also using the Australian firmware with all kinds of gatways.
https://www.thethingsnetwork.org/forum/search?q=australia
I have tested the RN2903 with a Kerlink IoT Station and a Loriot backend without issues.

When you ping the gateway from the network server. For example if you have a satellite dish connecting the gateway you won’t be able to send any downlink messages due to slow communication.

Regards,
Jan

Hi Jan,
Thanks for getting back to me.
I fixed the issue, it was an issue with the port (8883) and also a bad key in my json packet to be received. However I found that even after fixing this I was only able to receive the first packet only. After that I kept getting an error.

I managed to get it successfully working using the TTN_2903 library instead of the Sodaq_2483 library.
I kept finding the receive message was coming back instead of the “mac tx ok” message causing the program to cast an error and never receive the next packet.

I am currently comparing the TTN library to the Sodaq library to try and identify the problem. Does the receive function on the Sodaq RN2843 library work for others? The TTN library seems to have a lot more in it than the Sodq one.

Regards,
Brendan

Sorry if not related, but I found TTN don’t like sending out data, due to 1% rule.

They removed my post & me from the forum for asking about the 1% rule too much.
TTN says it should shut the gateway down if 1% reached!

Does the TTN send ACKs at all?

https://www.thethingsnetwork.org/forum/t/ack-is-supported-or-not/2661

Sorry if red herring route.

Mark

Hi Mark,

I have no idea if TTN sends acks or not. I don’t use TTN. I am with a commercial provider here in Australia.
I am only using the TTN Library, I do not have an account with them, and there are no duty cycle restrictions here in Australia.

You are lucky, then.

Sorry for the error.
Had to ask.

I would look at this one

not the TTN one. I don’t think TTN know what they are doing! :sunglasses:

Apart from spending backers money.
They don’t want business on TTN yet ask Industry to use their Forum.

Forum link takes you to TTN forum.

They have an active guard TROLL who is building an empire for himself it seems.
Power corrupts, i guess. lol