Can UK Radio Amateurs use LoRa ?

I gave a short talk recently on the use of 2.4Ghz LoRa.  One item that was raised during the talk was the legality of Amateur license holders using LoRa. It has been suggested in the past that LoRa is outside the scope of an Amateur radio license, because it is proprietary and ‘encrypted’.  I could not recall the relevant part of the Amateur license at the time, so I decided to check what the UK Amateur licence conditions actually are.

There does seem to be a general assumption that ‘encrypted’ messages cannot be sent under the Amateur radio license. But that is not what the UK Amateur license Terms, conditions and limitations actually appears to say.

11(2)(b) of the UK Amateur license Terms, conditions and limitations says;

“Messages sent from the station shall not be encrypted for the purposes of rendering the Message unintelligible to other radio spectrum users”

Clearly there is a reason here behind the specific use of the word ‘purposes’. If the objective of the condition was to make clear that Amateurs could not use encryption in messages (in all circumstances) then you would expect the following wording or similar;

“Messages sent from the station shall not be encrypted such that the Message is unintelligible to other radio spectrum users”

So the intention behind the use of ‘purposes’ appears to be to permit Amateurs to use ‘encrypted’ messages as long as the purpose behind (using the encryption) is not to render the message unintelligible to other radio spectrum users. So if the purpose of using LoRa is for long range or low power uses, then even if LoRa were to be considred encrypted it appears to be permitted.

If the Amateur is using ‘encryption’ then if the messages can be read by other users of the radio spectrum by for instance publishing the decoding key, that would appear to be permitted also.

There does seem to be an assumption that LoRa by its nature is encrypted, this seems to be a false to me. LoRa is encoded for sure, like a lot of radio protocols are, but the purpose behind the encoding is purely functional, its not to obscure or restrict access to or encrypt the data within. Its also very difficult to see why an encoding method that can be easily read either by readily available LoRa devices or open source decoders (such as SDRs) can be considered ‘encrypted’.

Maybe the Amateur radio license conditions have not kept up with modern communication techniques, but then it is for the regulator to amend them.

Note that these are my own views and maybe Ofcom (the UK regulator) takes a different view.

Just how long can a lora sensor battery last?

Remote lora sensors are most often battery powered and a long battery life is desirable. If you have to keep changing batteries every few weeks, its wasteful, expensive and takes up a lot of time.

So we develop strategies to make a sensor operate with as little power as possible. A ATmega328P processor (as used in Arduino Pro Minis) running at 3.3V can have a deep sleep current of under 1uA. Add a good choice of voltage regulator, such as MCP1700, and the deep sleep current of the board will be around 2uA. That’s good and would give a long battery life, the only significant use of power would then be when the processor is woken up, reads the sensor and transmits the payload before going back to sleep.

How then to wake up the processor from deep sleep ? The are several add on options, use a TPL5010 to provide an interrupt pulse to wakeup the processor. Or maybe a TPL5110 to power the whole node on and off. These TPL devices have a very low operating current themselves, under 0.1uA typically.

Or you could use a real time clock (RTC) to provide an alarm wakeup. There are RTCs such as PCF8563 that are low cost and have a very low backup current.

The ATmega328P does have its own very low current internal timer, the watchdog. The maximum time of the watchdog is however only 8 seconds. Thus you can only use the watchdog to sleep the processor in multiple units of 8 seconds. This 8 seconds is not very accurate, but does it really matter if you get a sensor reading every 11 minutes instead of every 10?

A ‘bare bones’ ATmega328 with the watchdog timer active uses around 6uA in deep sleep. For a 15 minute sensor reading interval you need a software loop that counts 112 x 8 second sleeps. Clearly when the processor wakes up there is current used both in a power on time and the time the code is actually active counting those 8 second sleeps. How much power in total this takes is a bit unclear and its not so straightforward to measure.

As part of the development of the SX12XX library;

I wrote sensor transmitter and receiver programs. The transmitter was based on a SX1278 lora device, standard 3.3V Arduino Pro Minis and BME280 sensor. The receiver was an SX1278 LoRa device and a SSD1306 OLED display. See the \examples\SX127X\Sensor folder in the library for the programs.


One of the issues with reading remote sensors is that you need to be sure the receiver is picking up valid data from your sensor and not data from some other source. There could well be other LoRa devices in an area and it would not be good for a receiver to get an apparent alarm that was not from one of your own sensors.

To increase reliability the sensor sender program takes a CRC value for the actual sensor data and this is sent out with the sensor data packet. The receiver also carries out additional checks on the incoming data using a simple form of packet addressing. The first byte of the packet indicted the type of packet being sent. The receiver can thus reject any packets that don’t match. The sender also sends out a single byte destination address and that must match the address setup for the receiver. Again if the receiver gets a packet that does not have that byte matching it will reject it.

Finally the receiver checks that the CRC of the sensor data matches the CRC sent as part of the packet. That is 8 + 8 + 16 = 32 bits of error checking. So potentially there is maybe only a 1:4294967295 chance of the wrong data being read.

The BME280 sensor used was the 3.3V version which does not have a regulator on it, so the full benefit of the BME280 in deep sleep mode can be achieved.

The ATmega328P was programmed with the mini-core bootloader through the Arduino IDE. I used a 3.3V ‘Pro Mini’ board of my own design (shown below) which has a MCP1700 regulator so the deep sleep current is circa 2uA. Its easy enough to replicate this approach with other hardware just do a Google search for ‘Bare Bones Arduino’

loraTracker Pro Miser

I discharge tested a very small LiPo battery, marked as 150mAhr, on my iCharger 106B and it indicated a capacity around 155mAh.

So how long would this battery power a sensor node, shown below, if the sensor reading was sent out as LoRa at spreading factor 7 bandwidth 125000hz every 15 minutes?

The sensor was started on 20/12/19 and the battery then reported (remotely of course) as 4218mV. The sensor has now been running for two months with no intervention required and the battery is down to 4068mV.

The battery (only 150mAhr remember) looks like it has a lot of life left yet. But even if it expired tomorrow the average usage would be only 77mAhr a month. A set of 3 AA Alkaline might have a capacity of 2000mAhr, so they would have a life of 2 years+ on this basis.

How long the battery will actually last I do not know, but it does look like the humble ATmega328P is perfectly capable of acting as a long battery life node, with no additional components required to manage sleep mode.

Stuart Robinson

Library for SX12XX lora devices

For some time I had thought that an Arduino library for lora that included useful application examples would be helpful for those intersted in working with lora devices.

The Semtech SX127x lora devices are well supported already with several Arduino libraries but often the examples are limited in function. The newer SX126x (UHF) and SX128x (2.4Ghz) lora devices are not compatible with the standard SX127x libraries so having already produced a library for both the SX128x and SX126x devices I set about writing a library for the SX127x in the same style as the SX126x and SX128x devices. A common library structure and set of function calls across all the lora devices should mean that an application written for say the the SX1276 lora device @ 434Mhz can easily be adapted for the SX1280 @ 2.4Ghz.

The first part of the library, supporting the SX127x devices is completed and the link is below. Support for SX126x and Sx128x will be added in the coming weeks, using the example programs to ensure the libraries are compatible.

The provided examples provided includes sketches for;

A basic register print test

Transmitter and receiver of a character array; “Hello World” etc

Transmit and receive a data structure with a mix of variable types.

Transmit and receive a mix of variable types, bytes, integers, floats and character arrays by writing direct to the SX127x buffer.

A link test transmitter and receiver.

A packet logger.

A received packet frequency error check.

A lora RSSI receive meter with display.

Transmitter and receiver for remote control of devices such as LEDs. Tranmitter can be handheld with a low sleep current of 2uA.

Joystick transmitter and receiver for remote control of RC servos.

BME280 low sleep current sensor transmitter (7uA) and receiver with display.

GPS tracker transmitter and receiver with display.

The example programs will all fit comfortably in a Atmel ATMega328P as used on an Arduino Pro Mini. A simple to build board based on a 3.3V 8Mhz Arduino Pro Mini to which lora modules can be plugged in was developed, see the picture of the board below. There is a fuller description of the board in the ‘Evaluation Board’ document in the library.

Easy Mikrobus DIP 231219

The board complete with a lora modules plugged in and being used as a GPS tracker is shown below;

Currently the only tested versions of the programs are for the ATmega328. I normally change the standard bootloader to the one supplied with the MiniCore core for the Arduino IDE; This bootloader allows the Watchdog to work correctly and provides a few more bytes of program memory. Several of the example programs have already been tested and work on a small ESP32 board I built. After further testing these programs will be added to the examples.