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.
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
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.
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.
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’
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
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.
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.
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; https://github.com/MCUdude/MiniCore 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.
recently released a module using the Semtech SX1262 LoRa module. This
is for UHF use and seen as an upgrade to the SX127x devices. I
designed Mikrobus module for it so I could test the device.
I have published an Arduino library for the SX1261 and SX1262, it can be found here; SX126x Library. This library is very similar to the library for the SX1280 2.4ghz library which can be found at the same location.
Standard LoRa modules such as Hope RFM98 and Dorji DRF1278 based on the Semtech SX127x RF chip generally use low cost crystals which whilst it makes the modules cheaper, using LoRa bandwidths below 62500Hz is difficult. If the transmitter and receiver differ in transmission frequency by more than 25% of the bandwidth in use, they wont communicate. At these lower bandwidths even if two devices communicate on the bench when they are at the same temperature, large temperature differences can cause communications to fail.
This frequency error problem is going to be
worse at 868MHz than it is at 434MHz, so its no surprise that The
Things Network uses a bandwidth of 125000Hz, it leads to reliable
communications with low cost devices..
The Semtech SX1262 has internal firmware
support for a temperature compensated crystal oscillator which should
allow the lower bandwidths to be used.
Lower bandwidths potentially provide longer
range, at the expense of packets taking longer to send. Significantly
in a lot of countries the duty cycle for less that 25kHz channels is
often 100% , but the higher bandwidths commonly used by current LoRa
modules are normally restricted to 10% or even 1% duty cycle. So the
lower bandwidths can provide a greater data throughput since you can
run the transmissions continuously.
It is possible to get the standard SX127x
modules to communicate at the lower bandwidths. Once packets are
being received the transmitter and receiver can be kept close in
frequency (mitigating developing temperature differences) by using
the estimated frequency error produced by the SX127x to adjust the
set frequency of the receiver. However packet communications does
need to be established in the first place either by a manual
adjustment of frequency or by initially receiving packets at a higher
The NiceRF SX1262 modules I had worked out
of the box at the lowest possible bandwidth of 7810Hz, which was a
surprise, practical operation at that low bandwidth was just to
difficult with the previous generation SX127x modules.
So how would the modules cope with large
differences in temperature? A transmitter was setup for bandwidth
7810Hz at spreading factor 7 (SF7) using 10dBm of power. The
transmitter was put in a freezer that goes down to -20C. After a
couple of hours in the freezer I was still receiving packets on the
bench receiver at +20c, so the use of the TCXO allows the lowest
bandwidth of 7810Hz to be used even with large variations in
temperature, 40c in this case, between transmitter and receiver.
So what is the amount of frequency shift of
the SX1262 modules when the temperature goes from +20c to -20c? I
theorised you could identify the lower and higher limits of working
reception by adjusting the set frequency of the receiver till
reception of packets stopped.
I was using a frequency of 434.5MHz. So by
adjusting the frequency of the receiver I determined the low
frequency for working receptions was 434,498,250Hz and the upper
frequency was 434,502,050. This is a range of 3800Hz or +/- 24%,
which is closely in line with the data sheet specification of 25%.
Centre frequency was 434,500,150Hz. This was with the receiver at
+20c and the transmitter at -20c.
The transmitter was allowed to return to
room temperature, +20c, and the frequency limit test carried out
again. This time the lower frequency of reception was 434,497,950Hz
and the upper frequency was 434,501,700Hz. This is a range of 3800Hz
or +/- 24%. Centre frequency was 434,499,850Hz.
Thus the shift in frequency of the
transmitter in the temperature range of +20c to -20c was 300Hz or
7.5Hz per c. So if there was a difference in temperature of say +30C
to -60c between transmitter and receiver the frequency difference
between them due to temperature would be 675Hz.
It therefore seems feasible to use a
bandwidth of 20830Hz without worrying about frequency errors and over
a wide temperature range.
At 434MHz, a bandwidth of 62500Hz SF12 would
normally be used for a location tracker and changing to using a lower
bandwidth of 20830Hz should, according to the data sheet, provide an
additional gain of 4.8dB, equivalent to increasing the reception
distance by 74%. Moving bandwidth from 62500Hz SF12 to 20830Hz SF12
would increase on air time of a 12 byte location packet from 1982mS
So how well does the SX1262 actually perform
at the 20830Hz bandwidth, and how to carry out a real world test?
I have some link test software that will
send packets at reducing powers, the SX1262 has a range of 22dBm to
-9dBm. Imagine you want to compare the effectiveness of two antennas.
You will first need to attenuate the transmitter output in some way
to cut the range to a practical value, you can use an SMA attenuator
(20dB possibly) between the transmitters LoRa module and antenna or
attenuate transmissions in some other way by putting the transmitter
in a tin or wrapping it in aluminium foil.
At some distance from the transmitter you
attach antenna A to the receiver and you note it stops receiving
packets sent at -2dBm, no lower power packets are received. The power
level a packet is sent at is made part of the payload so the receiver
knows the powers of the packets received.
Keeping the receiver in the same position
and orientation you fit it with antenna B. This time you receive all
packets down to -5dBm. Thus the real
World performance of antenna B
is 3dBm higher (i.e. it has 3dB more gain) than antenna A.
You can use the same testing method to
compare the effectiveness between two sets of LoRa modem
configurations. I set my link test software to send descending power
first at 62500Hz SF12 and then at 20830Hz
SF12. The receiver software flips reception between the two settings
automatically and displays the results on a display and logs to micro
SD card for later review. The transmitter was placed on top of the
mast on my shed and I took the portable receiver to a hillside
overlooking the city where I live and 4.4km away.
results were interesting, over about 10 test loops the average of
62500Hz SF12 reception down to 0dBm
20830Hz SF12 reception down to -6dBm
So there was a practical difference. I did
notice that there were more packet failures at 20830Hz SF12. At the
limit of reception these time wise longer packets are probably more
susceptible to corruption from noise etc.
Looking at a comparison of bandwidth 62500Hz
SF7, which is a data rate of 2735bps at 10% duty cycle you can only
send at an effective 273bps. At 62500Hz 20830Hz SF7, the data rate is
lower at 910bps, but since you can send at 100% duty cycle you have
over 3 times the data throughput. You also pick up around 5dB of
signal gain. Winner all round really.
In summary the SX1262 is a very useful
addition to the LoRa family, it can be used for longer range
applications due to the TCXO making lower bandwidths practical. The
other probable application is using the 20830Hz or lower bandwidth to
send data on a continuous basis and avoid duty cycle restrictions.
To carry out the above tests I needed to
build a suitable Arduino library and whilst the methods of
controlling the SX1262 are completely different to the SX127x
devices, the SX1262 is very similar in operation to the SX1280 for
which I had already produced a suitable Arduino library. There are
only some slight differences in commands so my testing programs
originally written for the SX1280 worked with only minor changes on
On point to note; the SX1262 now goes down
to SF5 and both SF6 and SF5 now support the use of explicit and
implicit header types. However the changes made to produce these new
features mean that the SF6 output produced by an SX1262 cannot be
read by the earlier SX127x devices. Which is a big shame.
Perhaps of particular interest to those
using TTN applications is the almost identical SX1261 device which
apparently (according to the data sheet) uses the switched DC-DC
converter to significantly reduce power consumption dureing
transmissions. This if it proves to be true could yield a significant
improvement in battery life for projects so powered.
The Arduino library I was working on for the SX1280 has had a couple of flights running a high altitude balloon tracker, and the tracker transmitter and receiver both worked. The library is available for download here;
I have launched a few pico, foil party type balloons, I had not
participated in the launch of a ‘real’ high altitude balloon
(HAB) the latex type that rises to 30km or so then bursts and comes
back to ground.
There was a HAB workshop planned for
25th/26th July in Braunton Devon so I signed up.
Bill, who was running the workshop agreed to
give one of my new 2.4Ghz LoRa trackers a ride up to altitude. The
tracker was a simple design using an ATmega328P processor used with
my own Arduino library for the Semtech SX1280 LoRa device.
The tracker board itself (left in picture above) is not specifically designed as a radio frequency (RF) tracker and does not have connections for directly mounting an RF device. Instead it has the pins to allow a Mikrobus compatible module to be fitted. Mikcroelectronica produce a range of Mikrobus boards under the ‘Click’ brand;
I make my own Mikrobus compatible boards for
the Hope RFM9x, DRF127x, RN2483 LoRa devices and most recently one
for the NiceRF SX1280 LoRa devices. The simple Arduino board can then
be used for 434Mhz, 868Mhz or 2.4Ghz LoRa devices just by using the
appropriate Mikrobus board. The boards can either plug in on sockets,
good for testing or last minute changes, or be soldered permanently
in place for a more compact tracker. The components needed are all
wired through hole types, so the board is very quick and easy to
assembled 2.4Ghz tracker is fairly compact and I choose to use a
standard small Wi-Fi antenna connected to the RP SMA socket.
assembled tracker has pin headers for connection of a GPS and\or
sensors such as BME280 I2C types.
The board can be used with just two AAA
Lithium energisers which will supply around 2.9V for most of the
batteries life. The basic board has a very low quiescent current
regulator so can be used with 3 x AA batteries and still keep the
sleep current of the board below 2uA.
The tracker was fitted into the HAB payload
box, shown below at top left with the small L70 GPS at top right. The
antenna poked out of the top of the box which was not ideal but
the Raspberry Pi in the Sky (PITS) tracker
had two antennas on the bottom, one for FSK RTTY and another for
is the balloon being filled with helium at the launch site.
the balloon shortly after launch with the payload below.
tracker setup was fairly simple, a low cost Wi-Fi yagi on a tripod
and one of my LCD receivers with a SX1280 Mikrobus module in place.
The receiver has its own GPS so when it receives the location data
from the tracker can calculate the distance and direction to the
the tracker was last received on 2.4Ghz LoRa it was one its way down
at a distance of 89.237km and an altitude of 6895km. From the field
tracking location on the North Devon coast the balloon was tracked
till just short of landing using 434Mhz LoRa and FSK RTTY.
balloon, call sign Vincent, landed after crossing the Bristol Channel
from North Devon to land near Newcastle Emlyn, a distance of around
The 2.4Ghz LoRa settings used were bandwidth
406khz and spreading factor 12. The lower bandwidth of 203khz should
provide a bit more range with a bit of fine tuning.
One point to note is that the L70 GPS used,
bought at very low cost from China, stopped working and lost lock
when the balloon went above 10km. It was seen to recover when the
balloon was on the way down at 6895m. The GPS was put into balloon
mode so further tests are required to identify the cause of the
The flight was an interesting test of the
limits of 2.4Ghz LoRa and whilst its not going to replace the
standard UHF LoRa devices for HAB tracking, as the in air range is
only just adequate, reception distance at ground level especially
with trees around is limited to a couple of hundred metres or so.
The ranging or distance measuring is an
interesting feature and the device is capable of some fairly high
data rates, 203kbps for LoRa and the FLRC mode should cover the same
distance but at a data rate of 975kbs.
It was fun to experiment, thanks to all
those involved for the workshop with a special thanks to Bill Harvey
who organised it.
have had the basic send and transmit function of my Arduino Library
for the SX1280 working for a couple of months, but I was keen to
subject the code to a real World test before publishing it. So I
built a small GPS tracker (25g) to use on a high altitude balloon.
SX1280 LoRa devices can calculate distance by measuring the time of
flight of a special packet exchange, I wanted to see how far this
ranging feature would work, I had previously tested it to 40km in a
hilltop to hilltop test.
So I set about converting some balloon
tracking code I had originally written for the SX127X LoRa device to
use my SX1280 library. This software runs as a GPS tracker typically
using an ATMega328P as on an Arduino Pro Mini. The receiver can also
be powered by a Pro Mini, but to run the Micro SD data logging,
display and receiver’s GPS requires a processor with more memory so
I normally use a version of my LCD receiver that has an ATMega1284P
Changing the code to run on the SX1280,
including the remote control functions took a month or more and with
it eventually working I added the SX1280 Ranging capability. For this
function the remote balloon tracker would transmit a short command
that the receiver identifies as a ranging request. The receiver then
initiates the ranging packet exchange process and displays the
results as a distance.
I eventually had a chance to test the
tracker on the 22nd July, weather conditions looked
suitable and the small tracker was fitted to a Qualatex 36” foil
balloon and launched from the Black Rock picnic site between the two
Severn bridges on the West side of the Severn.
I was not using the longest range mode of
the SX1280, I chose a LoRa bandwidth of 406khz as I wanted to avoid
potential issues if the tracker got very cold and the TX and RX
became more than 25% of the bandwidth apart in frequency. Its
possible that further work will show that the lower bandwidth of
203khz, which would give more distance capability, can be used. I am
also looking at implementing an AFC capability in the software.
The balloon rose slower than expected and
was moving horizontally quite quickly. A 2.4Ghz magnetic mounted
antenna on my car’s roof was not receiving strong enough signals to
be able to follow the pico in the car, so I stuck to tracking it from
a playing field with a cheap Wi-Fi yagi.
balloon rose to 7903m where it apparently burst and descended. I lost
contact with it when it was at 3259m altitude and the GPS
calculated distance was 85.325km, direction 57degrees.
The ranging function measured the distance as 85.133km, so with
ranging now known to work at that distance, the flight was a success.
point of lost contact was over the River Stour near
I hope within the next week or so to be able
to send the 2.4Ghz LoRa tracker to around 30km altitude on a latex
The Arduino library seems to work well, with
perhaps some improvements required in the ranging code and an AFC
capability. I particular I need to write a note on how I carried out
the necessary ranging calibration.
The SX1280s LoRa modules can use far higher data rates than the UHF band SX127Xs. At the fastest settings, spreading factor 5 and bandwidth 1625khz, the effective data rate is 203kbs.
High gain antennas such as yagis are very low cost for 2.4ghz since so many are produced for use on WiFi. The yagi below cost me £4.50 delivered from a UK supplier.
what distance would a pair of these yagis, one for each transceiver
allow a line of sight (LOS) data link to operate at 203kbs ? I
decided to find out.
I configured my custom link test software to
run at the 203kbs setting, put the link test transmitter on the mast
on my shed and went to the receiving location North of Cardiff, 4.4km
away that I have used for the SX1280 ranging tests described in a
the yagi connected to the NiceRF module on my receiver, I was getting
packets down to -3dBm.
So at the maximum TX power the SX1280 can
provide, 12dBm, there would be 15dBm of link gain, which suggests a
LOS range at that power of around 25km. Which would be impressive.
I exchanged the yagi antenna I was using for
the receiver of the test packets to a simple 2dBi one, see below;
was then receiving packets down to +5dBm, so the receiving end yagi
was providing me with 8dBm of gain.
The implication was that the simple 2dBi
antennas fitted either end would be on the verge of working over the
4.4km link. So I swapped the transmitting end yagi with a simple 2dBi
one and tried again. Much to my surprise it worked, I received all
the 12dBm packets. This also shows how useful the decending
power method of testing can be in predicting actual link performance.
So with the simplest of antennas a pair of
SX1280 LoRa modules can communicate at 4.4km at 203kbs using only
12mW of transmit power, impressive.
The Semtech SX1280 LoRa devices bring long range LoRa technology to the 2.4ghz bands. The devices allow for much higher data throughput than the lower frequency LoRa devices, data transfer speeds are up to 203kbps.
The SX1280 also has a ranging mode that can measure distance by recording the time of flight of a special packet exchange between two SX1280s.
I have designed some plug in Mikrobus boards for the Ebyte and G-NiceRF SX1280 LoRa devices. The larger green PCBs are an ATMega328P based Mini Logger I also designed. It can be fitted with a single plug in Mikrobus compatible board, see the picture below;
The Mikrobus PCBs shown, the yellow ones, are breadboard friendly so will plug into a standard 0.1″ breadboard, very useful for prototyping.
A complete Arduino based transceiver fitted with an G-NiceRF SX1280 device is shown on the left of the picture above, complete with 2dBi WiFi antenna. The board was programmed in the Arduino IDE.
Semtech publish sample code for the SX1280 but its not directly suitable for the Arduino environment so I used the Semtech code as a basis for writing some Arduino library files.
First Ranging tests
I used a large open field to test the ranging, these were the results;.
Actual Distance Indicated Distance. 0 4.4M 50M 57.6M 100M 103M 150M 148M 200M 201M 250M 253M
So not too bad, the results did seem to be consistent for large open areas. So short distance ranging seems OK, what about longer distances ?
4.4km Ranging test
North of the Cardiff where I live there is a ridge and the location is around 150M higher than where my shed is located in the city. With a SX1280 transceiver on top of the 6M mast attached to my shed there is a relatively clear line of sight from the ridge to the device on the mast, the distance is 4.4km.
I wrote ranging software that would first transmit a ranging request at high power (10dBm!) and report whether the ranging request completed. The transmit power was then reduced and another ranging request made.
Over the 4.4km link the ranging worked down to -14dBm. Thus if the full power was used, 10dBm, this test indicates the ranging may have potential to work at over 69km.
40km Ranging Test
There is a location North of Cardiff (altitude 264m) suitable for a 40km link test to Black Down (altitude 325m) in the Mendips, the other side of the Bristol channel.
At the Cardiff end there was a SX1280 ranging receiver fixed to a pole and another for a basic link test. The view from here towards the Mendips is below;
At the Mendips end I had a matching set of devices, one as the ranging test instigator/transmitter and another for receiving basic link test packets. The results were logged to a micro SD card for later analysis. Basic 2dBi antennas were used at both ends.
At the Mendips end the ranging request transmitter would emit a long beep at the start of the test sequence, send a ranging request at 10dBm, then 9dBm, 8dBm etc. If the ranging request was successful then the would be a short beep. Thus to work out the power level when the ranging stopped working you only had to listen for the long beep and then count the short beeps.
The LoRa settings for the ranging were SF10 and bandwidth 406khz, the longest range settings that the SX1280 allows for ranging mode.
The path used for the ‘4.4km Ranging test’ mentioned above was used to test and calibrate the ranging function. The ground distance was 4.42km as measured on Google maps. The average ranging result from the SX1280 was 24515. This gave a conversion factor to metres of 0.1803.
The average ranging result for the Cardiff to Mendips link was 225982. Applying the 0.1803 conversion factor gives a distance of 40.745km. The distance taken from Google Maps was 40.650km. So the SX1280 ranging produced a measurement of +0.2% over actual. Not bad.
Summary – Distance Potential of the SX1280 ranging and point to point.
The ranging requests were received down to 4dBm over the 40km link. This would imply a potential range of 80km LOS at 10dBm. Even modestly improved antennas at both ends (see antenna comparisons above) could double this range.
The longest range settings for point to point mode, SF12 and bandwidth 203khz should have a link advantage of 8dBm over the ranging settings described above, SF10 and bandwidth 406khz. Converting this 8dBm link advantage over the ranging settings, suggests a potential range for point to point LoRa in the 200km region.
SX1280 Program Code
Semtech publish source code in C++ and a development kit for the SX1280 based on ARM\MBED. I have adapted the code to work under the Arduino IDE, its been tested on ATMega328P and ATMega1284P. There is still some work to do on the ranging part of this code, when it it ready it is my intention to publish it as an Arduino library.
All the parts used in these tests were self funded, no complimentary parts were used.
I have carried out a performance review of the common available GPSs that you might use for a LoRa tracker.
In most cases you will run the GPS in hot fix mode, and unfortunately most of the common GPS breakout boards that you get on eBay etc, are not suited for this in a power miser tracker that needs to survive on batteries for a month or longer. The reasons are explained in the article.
There is data of the performance of 12 common GPSs, signal strength (antenna effectiveness), real world power consumption and hot fix performance over an extended period. There are notes on methods of reducing tracker power consumption.
Choose the wrong GPS and your tracker, powered by a 2800mAhr battery, might only last 14 days. Choose the GPS wisely and the same battery can last 200 days.