problem about dragino lora shield with Lora library

Projects Networking, Protocols, and Devices
1

Hi ,
I have 433M dragino lora shield with rf98 chip And I also use arduino mega. I used lora sender and lora receiver in both sides and both gave me the same problem Starting LoRa failed. My code is:
#include <SPI.h>
#include <LoRa.h>

int counter = 0;

void setup() {
Serial.begin(9600);
while (!Serial);

Serial.println("LoRa Sender");

if (!LoRa.begin(433E6)) {
Serial.println("Starting LoRa failed!");
while (1);
}
}

void loop() {
Serial.print("Sending packet: ");
Serial.println(counter);

// send packet
LoRa.beginPacket();
LoRa.print("hello ");
LoRa.print(counter);
LoRa.endPacket();

counter++;

delay(5000);
}

Can you help me ?

2

Did you try the tutorial written specifically for the Dragino shields and did that tell your transmitter and receiver shield were working ?

3

If the LoRa library your using is the Sandeep Mistry one then it only works with the Semtech SX127x modules and not the Hope RFM95W modules.
The LoRa.begin code is looking for a RegVersion of 0x12 and the Hope module returns 0x11

4

Riva:
If the LoRa library your using is the Sandeep Mistry one then it only works with the Semtech SX127x modules and not the Hope RFM95W modules.
The LoRa.begin code is looking for a RegVersion of 0x12 and the Hope module returns 0x11

Sure ?

I was not aware that Semtech made 'SX127x modules' although of course they do make the actual RF chip that is the SX127x.

The Hope modules I have here report a RegVersion of 0x12.

5

srnet:
Sure ?

The Hope modules I have here report a RegVersion of 0x12.

Sure? No but looking at Dragino Wiki and then the HopeRF site for the RFM95W datasheet it says on page 85 that RegVersion returns 0x11.

All my modules are Semtech based so cannot confirm this but it just happened I was looking at the Sandeep Mistry LoRa code yesterday trying to figure out if it correctly sets LoRa mode instead of FSK and noticed the .begin fails if the RegVersion returned is not 0x12.

6

Riva:
All my modules are Semtech based so cannot confirm this but it just happened I was looking at the Sandeep Mistry LoRa code yesterday trying to figure out if it correctly sets LoRa mode instead of FSK and noticed the .begin fails if the RegVersion returned is not 0x12.

All the modules are Semtech based, Hope use the chips that Semtech supply them with.

I have been using a mixture of Hope RFM9x and Dorji SX127x LoRa modules for a while these are all SX127x based devices.

As a debug feature my programs often print the register dump at startup, and I have hundreds of logs of the output going back to the beginning of 2016, there are no occurances of a version 0x11, they are all 0x12.

Could be an error in the Hope datasheets (not unheard of) see this comment from Tomas Telkamp formally of Semtech (2nd post);

HopeRF95W not working.

I met Thomas at the recent TTN conference, he gave a talk on 'LoRa from Space';

LoRa from Space

I make a guest appearance at 25:40 .......................

7

srnet:
Could be an error in the Hope datasheets (not unheard of)

What is the world coming too if you cannot believe the datasheets. :confused:

Maybe the bit in the Semtech SX127x datasheet about LongRangeMode only being writeable in sleep mode is also wrong as this is what I was investigating in the LoRa library.

RegOpMode.jpg
RegOpMode.jpg957×446 57.9 KB

8

Riva:
What is the world coming too if you cannot believe the datasheets. :confused:

Well Hope have a bit of history on the topic, I did quite a lot of work on their RFM22B, which used the Si4432.

There quite a few 'inconsistencies' between the proper data sheet for the Si4432 and the one Hope put out.

As for needing to be in sleep mode to switch across to LoRa mode, then fuctional code following that restiction does work.

Its possible due to a 'bug' that its not required, but since the data sheet gives the requirement, if they chose to fix the 'bug', your code would no longer work.

9

srnet:
As for needing to be in sleep mode to switch across to LoRa mode, then fuctional code following that restiction does work.

Its possible due to a 'bug' that its not required, but since the data sheet gives the requirement, if they chose to fix the 'bug', your code would no longer work.

We seem to have hijacked the OP's thread but I was looking at the Sandeep Mistry LoRa library and I could not see where it sets Lora mode when the device is sleeping. Some of the functions set the bit but do not put the module to sleep first. I was going to investigate if it really does switch to Lora mode but other events have consumed my time so did not check.