Linking two MQTT brokers via radio using LoRa

Just wanted to tell you all about a little LoRa experiment. I ordered two LoRa devices, they worked fine right out of the box with the included firmware but my target was to create a two-way LoRa radio link between two MQTT brokers on different networks. With such a link I should be able to transfer messages between two systems just using radio

Devices I ordered: 2Pcs LILYGO® TTGO 868MHz SX1276 ESP32 LoRa 0.96 Inch Blue OLED Display bluetooth WIFI Module IOT Development Board Sale - Banggood USA

The topology is like this

MQTT Broker (192.168.0.241) <- wifi -> LoRa device <———— 2 way radio link ———— > LoRa device <- wifi -> (192.168.0.242) MQTT Broker

In the NR flow shown you can see that a message is sent every 5 seconds that is transfered via radio to the MQTT broker on the opposite side

The software I have used for both devices is the OpenMQTTGateway, see here LORA gateway | OpenMQTTGateway v0.9.9beta

Seems to be a smart way of transferring non-frequent messages between two brokers over a longer distance without using internet

Best regards, Walter

3 Likes

Just to add, obviously you have to think about security here as well, encrypt the data before sending it, checking the source etc etc but this was just a first test

2 Likes

Nice, you also need to be careful about the amount of data if you are to stay within Lora spec as well. But very neat for tiny packets.

1 Like

What a fascinating project.

It looks like your broker has TLS support that's where you might want to start form security point of view. There are approaches in LoRaWAN spec that might help with device Authentication and session data encryption. As @dceejay says you are running in licence free radio spectrum and it's not like WiFi there are time-on-air/dwell time constrains. What part of the world are you? I can help ensure your acting as a good network citizen, don't worry there are no RF police!!

Keep us posted

Hi there @iiLaw, thank you!

Yes, you are correct, I think here in Europe (Sweden) it is "allowed" to transmit maximum 36 seconds / hour / channel. It is for sure just suitable for shorter and limited amounts of messages but the long distance is the key selling point I think

Regarding encryption, yes, I have look into that a bit. Using TLS is fine but I have to see a little bit here about that. I know the brokers does support it (I actually have it running on another broker I have locally here in my network) and the OpenMQTTGateway does support TLS as well. But then the question is how the data in the payload is handled all the way over the radio since the brokers are not bridged, they are unawere of each other. Maybe I could encrypt the payload data already in Node-RED and decrypt on the other side, using the same method and keys. Makes me think about a general feature, why not have the possibility to always encrypt all messages in Node-RED? A setting in settings.js maybe?

Thank you, yes sure, not suited for video streams :wink:

What data rate/spreading factor are your transmitting at?
Are you using 868/433 mhz ? looks like your using 868mhz (10% duty cycle) there are channel frequency that allow more power and longer TOA (time on air)
What was Band g3: 869.4 to 869.65 mhz - 27 dBm 10% duty cycle (SF7-SF12)

In terms of security LoRaWAN uses a device ID for authentication and shared key (symmetrical key) to encrypt msg herder and payload so your approach of doing this in NR makes sense.

Currently I was just "desktop testing" but it will be very few messages sent if/when I put it in operation

I'm just using the default settings of OpenMQTTGateway, here:

//Default parameters used when the parameters are not set in the json data
#define LORA_BAND             868E6
#define LORA_SIGNAL_BANDWIDTH 125E3
#define LORA_TX_POWER         17
#define LORA_SPREADING_FACTOR 7
#define LORA_CODING_RATE      5
#define LORA_PREAMBLE_LENGTH  8
#define LORA_SYNC_WORD        0x12
#define DEFAULT_CRC           true

Just some experimenting using encryption. Encrypting the payload before sending it and when received, decrypting it, seems to work fine (using AES).

  1. At "Start" a message is encrypted and published to the first broker, the first LoRa device picks this up and sends it to the second Lora device that publish it to the second broker

  2. The received message is printed to debug (for debuggging), decrypted and then printed in clear to debug. After 5 seconds a response message is encrypted and sent back, received, decrypted and printed in clear to debug

1 Like

Nice one ok I'm going to have a look at the docs on OpenMQTTGateway as 868E6 don't mean much.
Other than it's 868 mhz doesn't say frequency is, also I want to look at tx_power to see what unit of measurement is. can you get the length of you message and put it into this time on air calculator The Things Network

1 Like

In this setup I'm not using LoRaWAN, just LoRa for direct communication between the devices

17 mW

I have not tested if my devices supports 250E3 (250 khz) but if so, the time on air would be reduced by 50% for the same message length

The encryption adds of course. Using the encryption nodes (node-red-contrib-crypto-js-dynamic) with the AES algo and encrypting just two chars generates a payload of 44 chars. Encrypting my test message consisting of 27 chars generates a payload of 64 chars

Time on air result is below in image. With the "allowed time on air" 36 seconds/hour I think I should be ok sending approx 260 such messages per hour

1 Like