Fun with LoRa

Introduction

LoRa (short for Long Range) is only the most amazing IoT communication tech this side of Mars. Bursting onto the scene in 2012 with Semtech's acquisition of French firm Cycleo, LoRa has continued to rise in popularity as the go-to wireless communication method for low-power, low-cost IoT sensor devices.

In this tutorial we'll provide a concise overview of what makes LoRa special and offer hands-on examples of using the lastest LoRa radio IC, the SX1262, to send and receive LoRa packets using the IoT.Keystone Innovator Board.

A Bit About the SX1262

The SX1262, launched in 2018, is capable of operating in all major sub-GHz ISM bands around the world at up to 22 dBm power output. Operating in the sub-GHz band (e.g. 868 or 915 MHz) is key to achieving long range in urban indoor, outdoor and industrial environments. It has a microcontroller-friendly interface that consists of 4-wire SPI, a BUSY signal and a RESET line. It's also great that the firmware drivers are open source.

LoRa

The great thing about LoRa, in our mind, is not only that is offers longer range and stronger resistance to interference over traditional modulation techniques but that it describes its operating characteristics in a user-friendly manner. So what does that mean?

With LoRa, there are just 3 parameters, or knobs to turn, that control the critical characteristics of transmission range, data rate and energy consumption. As you might expect, when you configure for longer range, your data rate drops and energy consumption increases, and vice versa.

The main parameters that you need to know about are Spreading Factor, Bandwidth and Coding Rate.

• Spreading Factor (SF). There are just 7 levels from SF5 to SF12, with SF7 being a typical setting for short to medium range setups. As the spreading factor increases, the range increases, the data rate drops, and time on air increases (i.e. the time to send the packet, which is what draws more energy). What's cool is that each of these settings are "orthogonal" to each other, meaning you could setup 7 different transmitters and receiver pairs to operate simultaneously in the same frequency band without interference!
• Bandwidth (BW). There are just 3 main settings here: 125 kHz, 250 kHz and 500 kHz, although the radio will support a few lower bandwidths down to 7.81 kHz for some really special low-bit-rate applications. It should be noted that LoRaWAN, a popular MAC layer that works on top of LoRa, operates with just the 3 bandwidths 125, 250 and 500 KHz. You can push more data through higher bandwidths, so the effective bit rate goes up. As a result, the time on air goes down along with energy consumption. You will, however, take a bit of a hit on range. I will mention that the term "bit rate" is a bit of a misnomer in IoT, as many IoT solutions have no interest in being able to continuously send data. The bit rate just factors into air time per transmission (which often occurs only sparingly with long sleep periods) to save battery power.
• Coding Rate (CR). The LoRa packet engine will perform "Forward Error Correction" coding on your data so that the receiver can actually handle some errors in the transmission without corrupting your data. This feature essentially adds some redundancy to your data payload. There are 4 possible levels here: 4/5, 4/6, 4/7 and 4/8. This means that for every 4 bits of real data, 5, 6, 7, or 8 will be created by the LoRa packet engine for transmission. So as you can see, the amount of data that may actually be transmitted could be up to twice what you think. As you increase the coding rate, you will get longer range because the receiver can tolerate more errors in the transmission. The most common coding rate is the lowest setting of 4/5.

IoT.Keystone

We think LoRa is so cool that we built our own hardware and firmware platform called IoT.Keystone to easily intregrate LoRa technology into low-power IoT sensor designs.

Setting Up

In our open source firmware, available on GitHub, we have an application called LoRa-Radio that offers command-line control of the board and it's SX1262 radio. With the IoT.Keystone innovator board's "USB stick" form factor we just pop it into an available USB port. The OS will register a serial/COM port and we can tune our favorite terminal app to it. Make sure its working at 115, 200 baud N, 8, 1. Also ensure that the terminal app terminates commands entered with LF (line feed), or CR-LF. This is required for the IoT.Keystone firmware to delineate commands. When enter is pressed on an empty line, we'll see the prompt like this:

#0012.4b00.18a7.f322>

Playing Around

You need two IoT.Keystone boards running the LoRa-Radio firmware app. Here we've got a node with ID f319 setup as the transmitter and a node with ID f322 setup as the receiver.

We'll start by setting the same parameters on both:

• Choose an arbitrary frequency 915000 kHz. Technically anything can be used here, but of course the antenna system will be tuned for a particular band. Ours is setup for the 915 MHz ISM band which covers 902 - 928 MHz.

#0012.4b00.18a7.f319> lora set freq 915000
Command OK. Radio mode=STBY_RC status=RFU

• Set the Spreading Factor to 7.

#0012.4b00.18a7.f319> lora set sf 7
Command OK. Radio mode=STBY_RC status=RFU

Then check the current settings before we enter RX listen mode:

#0012.4b00.18a7.f322> lora set
frequency: 915000000 Hz
bandwidth: 0 -> 125
spreading factor: SF7
coding rate: 1 -> 4/5
tx power: 20 dBm
tx size: 0 bytes
tx payload: [ ]
tx timeout: 3000 ms
preamble length: 8 symbols
IQ invert: false
Command OK. Radio mode=STBY_RC status=RFU

Enter RX listen mode on one node before repeating the parameter setup on the other node:

#0012.4b00.18a7.f322> lora rx
Running RX on freq 915000000 kHz at SF7 CR:1 BW:0 preamble:8 IQ invert:false ...
Command OK. Radio mode=RX status=RFU

On the other node, after setting up the same SF, input a payload the transmit. We will make it 64 bytes but only specify the first 4 bytes (0xA 0xB 0xC 0xD):

#0012.4b00.18a7.f319> lora set tx 64 A B C D
Command OK. Radio mode=STBY_RC status=RFU

With that done, time to send it and see if the receiver captures it:

#0012.4b00.18a7.f319> lora tx
TX 64 bytes on freq 915000000 kHz at SF7 CR:1 BW:0 PWR:20 dBm airtime:119 ms timeout:3000 ms  preamble:8 IQ invert:false ...
Command OK. Radio mode=TX status=RFU
#0012.4b00.18a7.f319> [INFO: lora-rf   ] Tx completed.

This 64-byte LoRa transmission took 119 ms at SF7, BW 0 (125 kHz) and CR 1 (4/5).

If we had looked at the other listening node (ID:F322), we'd see this message show up:

#0012.4b00.18a7.f322> [INFO: lora-rf   ] RxDone: size:64 rssi:-52 snr:9 payload:[ 0A 0B 0C 0D 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ]

When power consumption is a factor in a design, the radio is often the highest consumer of power. In these cases, we want to reduce the time that the radio transmitter is on. Let's take a quick look at how the parameters affect the time on air.

What happens to air time when we increase the bandwidth to 500 kHz? When we transmit the same 64 byte packet at SF7, the air time drops from 119 ms to 30 ms in proportion to the bandwidth increase (120/30 = 500/125 = 4).

#0012.4b00.18a7.f319> lora tx
TX 64 bytes on freq 915000000 kHz at SF7 CR:1 BW:2 PWR:20 dBm airtime:30 ms timeout:3000 ms  preamble:8 IQ invert:false ...
Command OK. Radio mode=TX status=RFU
#0012.4b00.18a7.f319> [INFO: lora-rf   ] Tx completed.

What happens to air time when we increase the spreading factor? Setting the bandwidth back to 125 kHz (same as most LoRaWAN uplink channels) and the spreading factor to 10, we find that the air time has jumped from 119 ms to 699 ms.

TX 64 bytes on freq 915000000 kHz at SF10 CR:1 BW:0 PWR:20 dBm airtime:699 ms timeout:3000 ms  preamble:8 IQ invert:false ...
Command OK. Radio mode=TX status=RFU
#0012.4b00.18a7.f319> [INFO: lora-rf   ] Tx completed.

Why would we want to do this? In short, increasing the spreading factor would be done only to reduce packet error rate to an acceptable level. In other words, if you messages aren't getting to your receiver, you turn the SF knob until they do. As a result though, your time on air and power consumption will rise. It is worth noting that LoRaWAN, a MAC layer on top or LoRa, includes provisions for automatically adjusting the node's spreading factor down. Obviously if messages can't get to a gateway in the first place, from the point of view of the network there is nothing to turn down. So LoRa nodes might start with a higher spreading factor transmission setting on the initial messages before the entity they are talking to tells them to turn it down (with a suitably high spreading factor response)!

Lastly, this LoRa-Radio firmware app can also access the SX1262 radio registers directly as shown. There aren't very many when in LoRa mode and that's a good thing!

#0012.4b00.18a7.f319> lora reg get
Content of lora registers:
name                 address value
-------------------- ------- -----
 LoRa Sync Word MSB  0x0740  0x34
 LoRa Sync Word LSB  0x0741  0x44
 RandomNumberGen[0]  0x0819  0x08
 RandomNumberGen[1]  0x081A  0xA5
 RandomNumberGen[2]  0x081B  0x45
 RandomNumberGen[3]  0x081C  0x49
            Rx Gain  0x08AC  0x94
  OCP Configuration  0x08E7  0x38
           XTA trim  0x0911  0x05
           XTB trim  0x0912  0x05
Command OK. Radio mode=STBY_RC status=RFU
#0012.4b00.18a7.f319>

Summary

With LoRa you can send and receive small amounts of data - perfect for IoT - more reliably over longer distances. It has a friendly user interface, describing its main characteristics in terms of Bandwidth, Spreading Factor and Coding Rate.

We've just touched on the main user interface elements of LoRa radio communication without getting into too many details. There many great resources on the Internet that delves into the nuts and bolts like how the bit rate and air time is actually influenced by the settings of spreading factor, bandwidth and coding rate.

In case you are interested, this IoT.Keystone board we're playing with also offers IPv6 -capable mesh networking in the same sub-GHz band but using a different, standardized, and non-proprietary modulation technique (FSK) for higher bit rate command and control applications. There's also a few sensors on-board to test out IoT.Keystone's full sensor-to-cloud capability using LoRa+LoRaWAN or 6LoWPAN.