No connection or Dismal performance with RN2903 on the Sodaq ExpLoRer and Sodaq ONE

I am experiencing severe issues in connecting between the Sodaq ExpLoRer or the Sodaq ONE to my gateway.

I am using a Gemtek Indoor Femto LoRaWAN gateway. The gateway is positioned on my desk. I am located in Australia and all firmware is set for the Australian standard.

I am using the “LoRaWAN simple send example” Example Sketch from Sodaq Support: http://support.sodaq.com/sodaq-one/lorawan/, and I am having same poor signal issues/no connection with both the ExpLoRer and the Sodaq ONE device.

Often the packets are not received at all. I have sent hundreds of LoRa packets today, and not one has come through to the gateway, at other times I have experienced a connection but dropped packets and extremely poor signal strength.
With the device only 30cm from the gateway I am experiencing RSSI of between -100 and -130 dB. I have tested distances from 10cm to 5m away.

I am setting the device up with APB. I know that the devID, nwkSkey and appSkey are not the issues because I have received some packets from the device.

You might notice from this screenshot that many packets are duplicates. I can not receive an ACK so I am attempting to send them 3 times. If I set it to only send once then it doesn’t work at all. I have tried sending every: 60 secs, 30 secs, 20 secs, 10secs and 5secs. Just to see if it was a frequency issue. Note: There is no duty cycle restriction in Australia.

The sketch is the same as the example sketch but uses SendReqAck() instead of Send(), I have not added anything else (besides my own devID, nwkSkey & appKey). I have checked with the Network Provider and with Microchip and I have ensured that the calibration of the RN2903 is set to the correct values using the microchip config GUI tool:

  • Channels: 0-7 configured to the correct frequencies,
  • SF: 8,
  • DR: 0-3,
  • Rx1: 1000,
  • Rx2, 2000
  • Tx Power: default = 8 but I’ve tried 2, 5, 8, 10 and 20.

Nothing seems to work.

However, when I use off-the-shelf LoRa devices such as trackers and industry sensors the gateway functions correctly with approx -25dB RSSI. Therefore I know the gateway is working.

I have tried using 2 ExpLoRers, 1 sodaq ONE and have attempted with 2 gateways too. They all have the same issue, this points to some kind of configuration issue.
Has anybody else experienced these issues with these boards before?

Any help at all is appreciated.
The code can be seen below.

//LoRaWAN simple send example
#include <Arduino.h>
#include <Sodaq_RN2483.h>
#include <Sodaq_wdt.h>

#define debugSerial SerialUSB
#define loraSerial Serial1

// USE YOUR OWN KEYS!
const uint8_t devAddr[4] =
{
   0x0C, 0x50, 0x01, 0x1A
};

// USE YOUR OWN KEYS!
const uint8_t appSKey[16] =
{
   //APPLICATION KEY GOES HERE
};


// USE YOUR OWN KEYS!
const uint8_t nwkSKey[16] =
{
   //NETWORK KEY GOES HERE
};

// Some complete random hex
uint8_t testPayload[] =
{
   0x7b, 0x22, 0x74, 0x79, 0x70,       //Sodaq in ASCII
};

void setup()
{

   //Wait for serial monitor to be ready
   //while(!SerialUSB);
   SerialUSB.println("Initialising...\n"); delay(1000);

   pinMode(LED_BLUE, OUTPUT);
   digitalWrite(LED_BLUE,LOW);

	debugSerial.begin(57600);
	loraSerial.begin(LoRaBee.getDefaultBaudRate());

   #ifdef beePin
   	digitalWrite(beePin, HIGH);
   	pinMode(beePin, OUTPUT);
   #endif

   debugSerial.flush();
   debugSerial.println("Sleeping for 5 seconds before starting sending out test packets.");

   for (uint8_t i = 5; i > 0; i--)
   {
      debugSerial.print(".");
      delay(1000);
   }
   debugSerial.println("\n");
   debugSerial.flush();


	LoRaBee.setDiag(debugSerial); // optional
	if (LoRaBee.initABP(loraSerial, devAddr, appSKey, nwkSKey, true))
	{

		debugSerial.println("Connection to the network was successful.");
	}
	else
	{
		debugSerial.println("Connection to the network failed!");
	}
}

void loop()
{
	debugSerial.flush();
	// send 10 packets, with at least a 5 seconds delay after each transmission (more seconds if the device is busy)
	uint8_t i = 10;
	while (i > 0)
	{
		testPayload[0] = i; // change first byte

		switch (LoRaBee.sendReqAck(1, testPayload, 5,3))
		{
		case NoError:
			debugSerial.println("Successful transmission.");
			i--;
			break;
		case NoResponse:
			debugSerial.println("There was no response from the device.");
			break;
		case Timeout:
			debugSerial.println("Connection timed-out. Check your serial connection to the device! Sleeping for 20sec.");
			delay(20000);
			break;
		case PayloadSizeError:
			debugSerial.println("The size of the payload is greater than allowed. Transmission failed!");
			break;
		case InternalError:
			debugSerial.println("Oh No! This shouldn't happen. Something is really wrong! Try restarting the device!\r\nThe program will now halt.");
			while (1) {};
			break;
		case Busy:
			debugSerial.println("The device is busy. Sleeping for 10 extra seconds.");
			delay(10000);
			break;
		case NetworkFatalError:
			debugSerial.println("There is a non-recoverable error with the network connection. You should re-connect.\r\nThe program will now halt.");
			while (1) {};
			break;
		case NotConnected:
			debugSerial.println("The device is not connected to the network. Please connect to the network before attempting to send data.\r\nThe program will now halt.");
			while (1) {};
			break;
		case NoAcknowledgment:
			debugSerial.println("There was no acknowledgment sent back.");
         i--;
			break;
		default:
			break;
		}
		delay(60000);
	}
}

When you call Sodaq_RN2483::InitABP() it makes a call to Sodaq_RN2483::resetDevice().

There it uses these constants from Sodaq_RN2483.h:

#define DEFAULT_FSB 2
#define DEFAULT_PWR_IDX_868 1
#define DEFAULT_PWR_IDX_915 5
#define DEFAULT_SF_868 7
#define DEFAULT_SF_915 7

With those default settings, it is setting:

  • SF = 7
  • DR = 3
  • Power Index = 5

It is enabling the following channels:

  • 125KHz Channels 8-15
  • 500KHz Channel 65

If you are using a separate configuration tool you might want to skip the steps at lines 554-556 (Sodaq_RN2483.cpp) and simply return true at that point.

2 Likes

Thank you so much for letting me know.
I didnt realise that the FSB = 2 was setting channels 8 - 15. After correcting this to FSB = 1.

Both devices are sending fine now. Thanks again.