I have a pair of Windows 10 IoT Core nRF24L01 field gateway projects, one for AdaFruit.IO and the other for Azure IoTHub (Including Azure IoT Central). I use these field gateways for small scale indoor and outdoor deployments.

For larger systems e.g a school campus I was looking for something with a bit more range (line of site + in building penetration) and clients with lower power consumption (suitable for long term battery or solar power).

Other makers had had success with RFM69(proprietary) and RFM9X (LoRA) based devices and shields/hats so I had a look at both technologies.

To kick things off I purchased

• 2 x  LoRa GPS HAT for Raspberry PI
• 5 x LoRa Mini Dev featuring LoRa Technology
• 5 x LoRa Shield for Arduino (In my case Netduino devices as well)

I then did some searching and downloaded two commonly used libraries

• Radiohead by airspayce (Arduino in C/C++)
• Dragino.Lora by emmellsoft (Windows 10 IoT Core C#)

Initially I trialled the emmellsoft Windows 10 IoT Core Dragino.LoRa code on a couple of Raspberry PI devices.

After updating the Windows 10 Min/Max versions, plus the NuGet packages and setting the processor type to ARM the code compiled, downloaded and ran which was a pretty good start.

I could see messages being transmitted and received by the two devices

Packet RSSI: -33, RSSI: -91, SNR: 8, Length: 5

Message Received: CRC OK, Rssi=-91, PacketRssi=-33, PacketSnr=8, Buffer:[55, ff, 00, aa, 01], 2018-07-30 09:27:48

Successfully sent in 110 milliseconds.

Packet RSSI: -15, RSSI: -100, SNR: 9.2, Length: 5

Message Received: CRC OK, Rssi=-100, PacketRssi=-15, PacketSnr=9.2, Buffer:[55, ff, 00, aa, 02], 2018-07-30 09:27:53

Successfully sent in 36 milliseconds.

Packet RSSI: -35, RSSI: -101, SNR: 9, Length: 5

Message Received: CRC OK, Rssi=-101, PacketRssi=-35, PacketSnr=9, Buffer:[55, ff, 00, aa, 03], 2018-07-30 09:27:58

Successfully sent in 36 milliseconds.

I added my first attempt at device configuration for New Zealand (based on EU settings) in Dragino.LoRa\Radio\TransceiverSettings.cs

public static readonly TransceiverSettings ANZ915 = new TransceiverSettings(

RadioModemKind.Lora,

915000000,

BandWidth.BandWidth_125_00_kHz,

SpreadingFactor.SF7,

CodingRate.FourOfFive,

8,

true,

false,

LoraSyncWord.Public);

The LoraSyncWord.Public would turn out to be a problem later!

Then I modified the sender and receiver sample application MainPage.xaml.cs files to reference my settings

private static TransceiverSettings GetRadioSettings()

{

// *********************************************************************************************

// #1/2. YOUR EDITING IS REQUIRED HERE!

//

// Choose transeiver settings:

// *********************************************************************************************

return TransceiverSettings.Standard.ANZ915;

}

I modified one of the RadioHead sample Arduino applications (centre frequency) and deployed it to a LoRa MiniDev device. I could see messages getting sent but they were not getting received by the RPI(s).

So I dumped the registers for the SX127X device in the HopeRF RFM95 module on both devices,

From the device on RPI Hat

SX1276/77/78/79 detected, starting.

1-85

2-1A

3-B

4-0

5-52

6-E4

7-C0

8-0

9-85

A-9

B-2B

C-23

D-0

E-80

F-0

10-0

11-0

12-0

13-0

14-0

15-0

16-0

17-0

18-4

19-0

1A-0

1B-42

1C-0

1D-72

1E-74

1F-9F

20-0

21-8

22-1

23-FF

24-0

25-0

26-4

27-0

28-0

29-0

2A-0

2B-0

2C-9

2D-50

2E-14

2F-45

30-55

31-C3

32-5

33-27

34-1C

35-A

36-3

37-A

38-42

39-34

The LoRa transceiver is initiated successfully.

I printed out the Radiohead and emmellsoft registers then manually compared them using the SX1276 datasheet for reference.

I found the 3 registers which contain the MSB, ISB and LSB for the centre frequency weren’t being calculated correctly (checked this by changing the frequency to 434MHz and comparing the register values to the worked example in the datasheet).

I manually “brute forced” the centre frequency registers in LoRaTransceiver.cs Init() and the RPI could then detect a signal but couldn’t decode the messages.

I went back to the Register dumps and found the SyncWord (odd name as it is a byte) were different. After updating the RPI settings the devices could exchange packets..

const double RH_RF95_FXOSC = 32000000.0;

const double RH_RF95_FSTEP = RH_RF95_FXOSC / 524288.0;

long frf = (long)(Settings.Frequency / RH_RF95_FSTEP);

byte[] bytes = BitConverter.GetBytes(frf);

byte[] x6 = { bytes[2] };

RegisterManager.WriteRegister(6, x6);

byte[] x7 = { bytes[1] };

RegisterManager.WriteRegister(7, x7);

byte[] x8 = { bytes[0] };

RegisterManager.WriteRegister(8, x8);

RegisterManager.Write(new LoraRegisterSyncWord(Settings.LoraSyncWord.Value));

This was not a long term solution, lots of code, and register setting changes with limited explanation…