Is LoRa affected by local EMI ? – ESP32 Tests.

It was mentioned in a previous post that a LoRa device can be significantly affected, i.e. performance reduced, by the presence of local Electro Magnetic Interference (EMI) from the power switches in USB power banks, read here for more detail;

The Perils of USB Power Banks

The power banks tested could reduce the link budget by up to 20dB, equivalent to cutting receive range\distance by a factor of 10. This impacts portable devices in the main where the LoRa device antenna is close to the source of the EMI.

I did mention in the above post that in equipment where the antenna is local to the driving Micro controller then the EMI that produces can also reduce link performance. The standard reference micro-controller is an ATMega328P running at 8Mhz or 16Mhz with linear power supplies. When compared to a Arduino DUE which runs at 80Mhz and uses switching supplies, the DUE lost around 5dB in link performance, which cuts receiver range in about half, so it is a significant effect.

The new ESP32 based controllers, look very attractive for LoRa projects. Lots of Flash and RAM, up to 160Mhz processor speed, built in Wi-Fi and Bluetooth. There are also some modules such as the Wemos Lolin32 that have built in charger support for a local lithium battery. These modules are native 3.3V, so none of the dark ages stuff and faff of using 5V Arduino Unos or Megas.

My Wemos ESP32 arrived and I needed a way to compare a ESP32 receiver set-up with a reference ATMega one. Using two different board and LoRa devices could introduce errors if the performance of the two different LoRa devices was not the same.

Several of my projects use LoRa devices in Mikrobus sockets so I was able to breadboard first a ESP32 module then a Arduino Pro Mini module using the same LoRa device plugged into the breadboard. The antenna was kept the same as well.

I ran the test first with the ATMega and ESP32 with LoRa parameters of 434Mhz, BW62500, SF12 which are long range settings. I then tested both micro controllers at BW125000 and SF8. The graph of results is below. In the graph a decrease in performance will shift the trace to the left.

ATMega versus ESP32

Some details of how the tests are carried out will be found here;

Can we improve LoRa device performance ?

At SF12 the red line of the ESP32 results is around 3.5dB behind the blue ATMega one, so it looks like the EMI from the faster ESP32 is degrading LoRa performance by that amount.

At SF8 the EMI has a lesser affect, with the ESP32 only loosing about 1dB when compared to the slower ATMega.

Completely screening the receiver circuit and supply can mitigate the amount of EMI the LoRa device sees.

I have one of the ESP32 modules with built in LoRa and OLED display on order and will be checking its performance versus a standard ATMega set-up.

Stuart Robinson

January 2018

Can we improve LoRa device performance ?

Can we improve LoRa performance is a question I have seen asked a few times. If we add additional bandpass filters or low noise amplifiers to a LoRa installation, will it improve performance and range ?

A bandpass filter should limit the amount of external noise coming into the LoRa devices antenna input. A lot of noise could de-sensitise the LoRa receiver. I operate mainly at 434Mhz and there is a bandpass filter made for this frequency. It has a stated performance of;


Centre frequency: 433.92 MHz
Pass band: 431.92 ~ 435.92 MHz
Insertion loss: < @431.92 1.5dB ~ 435.92 MHz

I needed to check this, so lacking a proper signal generator I programmed a LoRa device to scan the frequency band and put the bandpass filter on the input of my RF Explorer.

This was the output, first without the filter and then with.

No Bandpass Filter

With Bandpass Filter

Outside of 427Mhz to 443Mhz the attenuation was around 45dB, which should be good enough to get an idea as to whether a bandpass filter would improve LoRa reception, the insertion loss of 1.5dB looked about right too.

You might be inclined to measure the effects of bandpass filters or low noise amplifiers in a laboratory, but I am more interested in what happens in the real world. So we need a practical testing method to use in the real outdoors.

A LoRa transmitter can be programmed to send packets at power levels from 17dBm to 2dBm. If we send a series of packets that start at say 17dBm and then reduce by 1dBm all the way down to 2dBm, we can use these packets to measure the real world performance of the link.

Imagine we have a working link and all packets from 17dBm down to 10dBm are received. The packets sent at 9dBm and below are too weak to be received. We then change something in the link, a better antenna (TX or RX), add a bandpass filter or a low noise amplifier (LNA) and then run the same test over the same link. Imagine that after such a change we are receiving all the packets down to 5dBm. Whatever change we made has improved the link by 5dB.

We have established this 5dB improvement with no actual test measurement equipment, we used just standard antennas and simple LoRa transmitters and receivers. You do need to run this type of test over a large number of iterations but all that needs is patience.

I wrote the required link test software for Arduino, and you can use it any of my tracker or receiver boards. The LoRa parameters of bandwidth, spreading factor and code rate are all configurable as is the frequency. You use the same settings for transmitter and receiver of course. The transmitted packets contain the power level used to send them so they are easy to count.

The typical serial monitor output of the link test software whilst its running is shown below, note that there are lines showing the running totals (there were 94 17dBm packets received in the example below) which are printed in readable form and as CSV so we can cut and paste into a spreadsheet for graphing.

RX SNR,-1dB RSSI,-61dB RXType,T Destination,* Source,1 Length,6 (17dBm)

RX SNR,-2dB RSSI,-62dB RXType,T Destination,* Source,1 Length,6 (16dBm)

RX SNR,-2dB RSSI,-62dB RXType,T Destination,* Source,1 Length,6 (15dBm)

RX SNR,-3dB RSSI,-63dB RXType,T Destination,* Source,1 Length,6 (14dBm)

RX SNR,-4dB RSSI,-62dB RXType,T Destination,* Source,1 Length,6 (13dBm)

RX SNR,-7dB RSSI,-63dB RXType,T Destination,* Source,1 Length,6 (12dBm)

RX SNR,-9dB RSSI,-61dB RXType,T Destination,* Source,1 Length,6 (10dBm)

Mode1 Test Packets 867

Mode1 Test Cycles 93

Mode1 Max Power 17dBm

17dBm,94 16dBm,94 15dBm,94 14dBm,94 13dBm,94 12dBm,93 11dBm,90 10dBm,85 9dBm,71 8dBm,40 7dBm,13 6dBm,5 5dBm,0 4dBm,0 3dBm,0 2dBm,0


So for our real world test, we need a real world situation. For the receiver end I used a Diamond X50 UHF co-linear, a typical antenna for a TTN gateway perhaps. This antenna was on a mast approximately 5M from the ground in an Urban area.

The transmitter node used a simple 1\4 wave wire. TX and RX were my DRF1278F LoRaTracker boards that have SMA antenna sockets. The transmitter was positioned 1.5M off the ground in the middle of a house garden 1km away.

SF7 Tests

We first need to decide on our LoRa parameters for the test, I used 434Mhz, BW125000, SF7, CR4:5.

The minimum LoRa device power, 2dBm, was plenty to cover that 1km, so the transmitter needed to have the output power of the packets reduced a bit. I fitted a 12dB attenuator to the transmitter, I was then receiving packets down to around 12dBm.

The first test was to run with the LoRa receiver connected direct to the base station antenna. Next I put the bandpass filter in-line and ran the test again. Then I removed the filter and ran the test a third time with a SP7000 LNA between antenna and the LoRa device. This is a high performing LNA, costing circa £400. I knew from testing on the $50SAT project that this LNA added 12dB of useful signal gain to the FSK packets from the RFM22B, but how much would it improve LoRa, which is already operating below noise level ?

I also tried a more modest LNA the G4DDK, which can be bought as a kit for around £55.

With the figures collected, I used a spreadsheet and graph to visualise the results, see below. On the graph an improvement in performance will shift the trace to the right.Graph

The bandpass filter seems to have little beneficial effect, reception is in fact slightly worse (shifted left in the graph) and seems to match the reduction expected by the insertion loss of the filter.

The SP7000 LNA did have a beneficial effect link performance improved by around 5dBm, but not a much as would be expected with with non LoRa systems.

The lower cost LNA was also an improvement, at around 4dBm.

From this testing at SF7, then there is a small benefit to using an LNA, but at an increase in complexity and cost. The LNA either needs to be in a receive only path or you need the auto switching of the SP7000 or an additional antenna sequencer.

Next, I will see what happens if you carry out the same tests at SF12, which is operating at 20dB below noise level.

SF12 Tests

I repeated the same tests at SF12, and the results were a surprise. Since SF12 operates at up to –12.5dB bellow noise over SF7 (the previous tests described above) I had expected the LNAs to have a lesser effect, the reverse proves to be the case. See the graph below;

Bandpass Fliters and LNAs SF12

Here the the SP7000 LNA (yellow trace) added around 7dB signal gain over the Simple link (blue trace) and the G4DDK (green trace) added 3.5dB. More gain at a lower spreading factors is less of an issue since you can perhaps increase the spreading factor to compensate if you want more distance. However at SF12 you are at the limit, so the extra 7dB of link margin from a good LNA would approximately double the distance the SF12 packets would reach. This could have a significant benefit in some applications.

Stuart Robinson

January 2018

micro:bit Mikrobus Shield

I thought that a micro:bit would be a useful development platform for a simple sensor shield for Internet of Things monitoring applications. With the micro:bit you can quickly switch between programming in MicroPython or C\C++ under the Arduino environment.

The micro:bit has just enough I\O pins to allow for a single Mikrobus socket. These sockets allow the shield to be used with a range of plug in modules, including radio devices and the sockets eliminate the trailing wires that might otherwise be needed. The Mikrobus socket can be used for other devices and Mikroelectronica do a substantial range of compatible click modules, see link below;

Click Modules

microbit Mikrobus Shield Reduced

I have Mikrobus PCBs available to make modules for several of the LoRa devices, such as RFM96, RFM98, DRF1272, DRF1278, build cost of these modules is around £7. Use of a LoRa radio device with the shield will allow for reception of sensor data over several kilometres.

A remote sensor will normally be battery powered and this shield can be configured to run for many months, or years on battery power alone.

A ready built  low cost (£1) Real Time Clock module is used to provide shutdown and wakeup functions. In sleep mode the micro:bit shield consumes a very miserly 0.001uA from the battery. The actual current is likely close to zero, but measuring below 1nA is not so easy. Sleep time can be up to a month.

The battery connects direct to the shield, this would typically be 3 x AA batteries or a single Lithium Ion battery. The shield has its own low drop out regulator supplying 3.3V to the micro:bit and Mikrobus socket. Using the standard 2 Alkaline batteries for the micro:bit supply can be marginal as the supply voltage may be as low as 2.4V for most of the batteries life.

There are pin connectors on board for typical I2C sensors such as the BME280 or discrete sensors such as the DHT11 and DS18B20. There is a connector intended for a serial connection such as a GPS. On the rear of the PCB is a micro SD card socket.

It is straightforward to add text displays such as the ILI9341 or Nokia 5110 via an I2C connected backpack I designed. The I2C display backpack uses an Arduino Pro Mini and is easy to build. The backpack is a good fit for the micro:bit, it allows a display to be added using no additional I\O pins and the code library is very small. The software for the display backpacks has been tested on the micro:bit under MicroPython and the Arduino IDE.










These are the simple commands to drive the display in MicroPython;

WriteText(‘Hello World’)

Driving the display in Arduino is much the same.

So far in the Arduino environment I have tested the functionality of an SPI LoRa module, reading and programming a GPS and SD card read write. And the displays above.

I will next be testing the MicroChip RN2483 which is popular for The Things Network (TTN) applications. I have designed a Microbus PCB to test this module.


Stuart Robinson

Versatile GPS Breakout board

Breakout and TC74


For high altitude balloon tracking it is common to use a Ublox GPS as these are one of the few low cost GPSs that can be configured to work above 18,000m. The MAX M8Q is a popular choice in particular for the smaller Pico trackers where you want the total weight to be 25g or less.

I revised the layout of my previous GPS breakout board, this new one is a lot smaller and is more flexible.

You can fit a ceramic stick antenna, but a bit of guitar wire is lower cost and produces better signals. There are holes on the board to take either a basic ¼ wire antenna (4.75cm @ 1575Mhz) with ¼ ground radials if you choose. The simple ¼ wave antenna wire shown in the picture works well enough, you can improve the signals further by adding 4 off ¼ radials or increasing the antenna wire to ¾ wavelength.

The breakout board can be used with the Ublox GPS serial or I2C interfaces.

The board has the pads for a SMD TC74 temperature sensor, if you can solder the Ublox GPS in place you can add this. The TC74 uses the I2C interface and for Arduino adding this sensor to a program does not need a lot of extra memory. Breakout and BMP280

There is a 4 pin 0.1” header, to which you can fit a number of different I2C sensors. Shown in the picture is the board with a BMP280 pressure and temperature sensor. You can also fit a BME280 or a HMC5883L Magnetometer. These modules are readily available assembled, at prices that are lower than buying the individual parts, check on eBay.

You can fit a 0805 LED if you choose and it will flash once the GPS has a fix.

Make sure you have the power and I2C connections correct depending on where you are connecting the breakout board to, there are different layouts of pins on my Locator2 board when compared to the GPS breakout.

The PCB layout and schematic of the GPS breakout board are in the HAB2 repository on Github;

At Last ………

At last I have a LoRa tracker receiver that works well with very weak LoRa signals and is easy to put together. The receiver is based on Arduino and an ATMEGA 1284P with the entire board running on 3.3V and no interference  creating switching power supply in sight.

The receiver can be used as both a highly portable tracker receiver and a desktop terminal application with remote control of the tracker. There is logging of received packets to SD card, a Bluetooth uplink into an Android mapping application, audio uplink of high altitude balloon payloads into FLDIGI, plus a facility to program the receiver over the air to match (bind to) the transmitter settings. There are 3 display options, Nokia 5110, ST7735 TFT and SD1306 OLED. The last local GPS fix and remote fix for the tracker is saved and always available when the receiver is switched on. Thus you can be use the receiver to guide you (distance and direction) to the trackers last known location.

With a Low Drop-out voltage regulator fitted the receiver can run from 3 x AA Alkalines, 4 x AA NiMh or a single Lithium Ion battery.

The board is a modular design with two Mikrobus sockets so whilst I am using it here as a LoRa Tracker receiver, with a LoRa device in one socket and a GPS in the other, it can be used with other MikroElectronica Click modules, with the exception that in portable mode there is no 5V supply.


My LoRa tracker software has had a thorough review and now all the routines for LoRa, GPS, Display etc. are common across the new receiver, HAB tracker, lost model locator and remote sensor applications.

To test the sensitivity of the receiver and compare the performance when it was powered with a battery and via a switching 5v supply as provided by a typical USB power bank, I used my link test software, the transmitter part of the link test (‘LoRaTracker Link Tester1’) is ideal for this purpose.

Link Tester on Mast

Link Tester InternalLink Tester External

The program was configured to transmit a short test packet descending in power from 17dBm to 2dBm. The packet contains the power level at which it was transmitted. The transmitter is put in a metal box, so that the only signals getting out are through the antenna, and a 20dB attenuator fitted in line with the ¼ wave wire. The transmitter then goes on the mast in my garden.Link_Test_CloseUp


I went to my favourite testing place in the North of Cardiff, it overlooks the city and is around 4km from my home.

At the testing place the LoRaTracker receiver software picks up the test packets and displays them on screen, you can readily tell the power with which the packet was transmitted.





With the Lithium battery I was receiving some packets that were being sent at 2dBm, but remember the 20dB attenuator on the transmitter, so the ERP of the packet was  18dBm.






With the USB power bank powering the receiver, I just received some packets sent at -3dBm, but very little else. So the power bank (or presumably its switcher) was loosing me around 15dB in LoRa performance, which is a lot, the reception distance would be around 1/6th of the Lithium battery powered receiver.



There is a reasonable relationship between transmitted power and distance. So based on an assumption that I would have received the 3dBm transmitted (-17dBm ERP) packets, what would be the signal gain if no attenuator and the license exempt power maximum of 10dBm was used ? Also assume that in a typical base station receiving application you are likely to use an omni directional gain antenna of approximately 5dB gain.

So the full improvement would be (10-3) + 20 + 5 dBm = 32dBm.

That equates to around a 40 times distance improvement, so a range of 40 x 4km = 160km could be expected in this set-up.

Here are the links for the beta versions of the software. LoRaTracker_Receiver1   LoRaTracker_HAB1  LoRaTracker_Relay1  and LoRaTracker_Link_Test1.

I will shortly have a few PCBs and 1284P (programmed with boot loader) available for sale.

Update – Portable LoRaTracker Receivers

As I have commented on before, it’s a shame the Arduino DUE was not more suitable for a portable tracker receiver, cheap and powerful, but the loss in sensitivity due to local EMI getting into the LoRa antenna was too much. There was also similar a reduction noted with the GPS that have the integral ceramic antenna.

Its taken a while to go through all the testing and checking to be sure that the new receivers will work well, but I eventually finished and the initial PCB’s are due in a couple of weeks.

There are planned to be two receivers, both have the same layout as the previous DUE based one you will have seen and use Mikrobus sockets for the LoRa device and GPS.

The first receiver is a shield that plugs into a standard Arduino Mega 2560 (as low as £6.50 delivered!!) and uses 4 x 8way logic level converters to shift between the 5V logic of the Mega and 3.3V logic used by all the receiver components. It should be quick to put together and the only SMT components are an I2C FRAM, a regulator and micro SD card socket. Plug in a display, my low cost Mikrobus LoRa and GPS modules, a battery into the Mega base power input, and your good to go. It did take a while to confirm that all the bits would work through logic level converters.

The second receiver is a single PCB, same layout as before, based on the ATMEGA 1284P running at 8Mhz. This is laid out to allow it to run from a small battery pack and eventually I plan to get a simple case for it made so it can be packaged up as a complete portable receiver. Although the Atmega 1284P is supposedly compatible with both the 328P and 2560 Atmel processors it took a while to check out that all the bits of hardware would work correctly within the Arduino IDE.

If the PCB’s are OK, there will be a few for sale. The long term plan is to make the receivers available as a part kit, all the bits you need apart from the display, GPS, batteries and Mega 2560 base in the case of that receiver.

Mikrobus Modules

Whilst my boards are intended to be used as LoRa receivers with a GPS, the MikroBus sockets allow either board to be used for other purposes, there is a wide variety of modules available from Mikroelektronika;

The kits will contain the PCB’s to make your own (very low cost) Mikrobus modules for the receiver. I currently have PCB’s for Dorji DRF1278F and Hope RFM9x LoRa modules, two types of GPS, and one to take the low cost Bluetooth, ESP01 Wi-Fi and NRF24L01 Wireless modules.


The Perils of USB Power Banks

In the document Part 6 – Testing and Comparing I mentioned a simple method of testing the relative effectiveness of various transmitters, receivers and antennas, using a series of descending power transmissions, a summary of the technique is below;

Descending Power Tests

Software can be written so that the LoRa transmitter sends packets starting at one power, reduces the power by 1dBm then sends another packet.

The received packet has the dBm level used for transmit within it so the receiver can record, count and then display how many packets have been received that were sent at a particular power.

With a bit of imagination this simple method of testing can be very useful, we don’t all have easy access to a handy anechoic chamber and expensive signal analysers.

It’s not going to be practical to place the transmitter many kilometres away for testing, however it is possible to significantly attenuate what is emitted from the transmitter by fitting a 50ohm terminator to the antenna socket and putting it all in a tin box with lid on, see picture.


For the tests described here the transmitter was sending packets at bandwidth 62.5Khz, code rate 4:5 and spreading factor 12. The limit of reception at this mode is -20dB below noise level, so a small level of electromagnetic interference (EMI) may disrupt the LoRa signals. With the transmitter in the tin box as shown and sending packets starting at 17dBm down to 2dBm a receiver fitted with a conventional 434Mhz antenna will pick up packets at 100M or so at an open field and a lot less in a built up area.



Initial Test results

For the initial tests the Arduino base was powered from an external 3S Lithium battery, approximately 12V. I had both an Arduino DUE base and a ATMEGA 2560 3.3V\5V switch-able base.





The transmitter was placed on the far side of my house and the receiver on my workshop bench around 20M away. The position of the receiver antenna was kept consistent throughout.

To show how the tests results can be read take two examples, its not important what the set-ups were. First set-up A and then set-up B, the summary line lists dBm and number of packets received;

Example Set-up A results

Summary 17,22 16,22 15,22 14,20 13,17 12,18 11,7 10,4 9,4 8,2 7,1

You can see that packets from 17dBm down to 12dBm were good then reception tailed off.

I then repeated the test with the same shield, LoRa module and antenna plugged into an Arduino DUE, the results were slightly worse, reception good down to 14dBm or 13dBm;

Example Set-up B results

Summary 17,17 16,17 15,17 14,13 13,12 12,7 11,4

The conclusion would be that Setup B has an effect on the reception of LoRa signals, reducing sensitivity by around 2dBm.

To get the printed console output show above I needed the PC USB terminal connected but I was really interested in the performance as a portable receiver. When the transmitter starts its test sequence (at 17dBm) it sends a control packet which causes the receiver to issue a long beep and LED flash. For each packet received it then sends a short beep and LED flash. Thus you only have to count the short beeps to find the limit of performance of a particular setup. Counting the beeps makes outdoor testing easy and this was the method I also used for a 40km hilltop to hilltop test.

Now, if you count the number of beeps for each 17dBm to 2dBm loop you know the limits of sensitivity of each setup. For instance if for subsequent loops of a setup (A) you count 4,5,5,6,5 beeps, the average is 5 so the limit of sensitivity is (17-5)+1 = 13dBm.

If you repeat the test with another setup (B) and the count is 10,9,9,10,10, the average is 9.6 so the limit of sensitivity is (17-9.6)+1 = 8.4dBM. Therefore in approximate terms setup B is 4.6dBm more sensitive than setup A.

Note the tests do not measure absolute sensitivity, but there are a quick and easy way of comparing different setups or hardware to within 1dB performance wise.

Comparing Different Setups

The purpose of this article was first to see if there was a difference in LoRa performance between the Arduino DUE and ATMEGA 2560 Shield bases and second to check if powering the receiver via an up or down converter affected performance.

Performance of Different Shield bases

The receiver test software will run on either the Arduino DUE or ATMEGA 2560 shield bases with RFM98 or DRF1278F LoRa modules. The same MikroBUS shield PCB, LoRa module and antenna were used for all tests.

The first test was with the shield bases powered from a 12.6V 3S Lithium Polymer battery plugged into the shield bases external power input. The results were;

Arduino DUE sensitivity 15dBm

ATMEGA 2560 sensitivity 10.4dBm

So the DUE looses around 4.6dBm when compared with the ATMEGA, and would have only around 60% of the range or distance, this is significant.

Putting the DUE receiver into a metal box reduces the difference between the DUE and ATMEGA receivers to around 1.5dBm, so it is reasonable to assume that most of the noise\EMI is coming in through the antenna.

Using USB Power banks

Initially these appear to be a very good option for powering a portable receiver. They are cheap, plug into the USB port on a shield base and have built in charging and battery protection.


They are normally based on a single Lithium Ion battery so have a boost circuit to provide a 5V output.

I powered a ATMEAG2560 base from an external 12V battery as before then tried the same test with the power coming from a selection of 3 power banks

External 12V LiPo, sensitivity to 4dBm

Power bank 1, sensitivity to 12dBm

Power bank 2, no reception at 17dBm !

Power bank 3, no reception at 17dBm !

This is a surprising result, although the receiver could receive packets down to 4dBm when powered from an external Lithium battery, there was no reception at all with two of the power banks even for the most powerful 17dBm packets. The conclusion is clear, the 3 power banks tested are not suitable for powering a portable LoRa receiver.


Avoid power banks for powering portable LoRa receivers, unless poor performance is acceptable to you.

The Arduino DUE, whilst it is fast, has a worse performance to the slower ATMEGAs.

Next, some tests on up and down converters.

A Better Tracker Receiver

Simple ReceiverFor some time I have been aware that my LoRa Trackers would be a much better system if it was possible to quickly and simply build a portable receiver. A DIY design would be preferred; this keeps the build cost low.

The current tracker boards, or one of the small 50mm x 50mm shield PCBs can be used for a portable receiver which works well enough but it can take a while to build and you do end up with a PCB that has a lot of external stuff such as displays, switches, GPS and the like. The current receivers are based on the Arduino Pro Mini and though this has adequate resources for the tracker transmitters, there is a distinct lack of program space and memory for a full featured receiver where you may want to include logging to SD card for instance.

One particular problem with developing a receiver is that it is di fficult to accommodate all the variants of different LoRa modules, GPSs and other devices. A modular design would be preferable, whereby it would be possible to plug in a range of different modules. Mikrobus Modules

I chose to use the Mikrobus standard for the modules, there are other module types but there is already a wide range of Mikrobus (Click) modules available, so the shield base would not be restricted to just one purpose. I could not find a Mikrobus module for the Dorji DRF1278F and Hope RFM9x LoRa devices I use in my trackers so I designed my own module PCBs for those and one for a GPS as well, see pictures. One other advantage of using modules in this way is that if the actual device, LoRa or GPS, is assembled onto the module and is faulty, there is no risk of causing damage to the main PCB if it has to be replaced.

An Arduino DUE shield base is native 3.3V (which is needed for most of the receiver components) has plenty of program space, memory, input\output pins and it’s fast too. Using a pre built shield base has the distinct advantage that all the difficult SMT assembly is already done for you. The clone versions of DUE cost as little as £10.

The receiver then will be a shield PCB that plugs into an Arduino DUE. I planned for two versions of the shield, a small one to build a hand-held device intended for portable operation and a larger desktop shield that could take up to 5 Mikrobus modules.

A portable receiver is easy to assemble using the smaller two Mikrobus socket shield PCB. Fit the pin headers and a few other components and plug into an Arduino DUE base, see pictures below. If this is to be a development shield you should fit sockets for the Mikrobus modules and displays. For a compact low profile receiver just solder the Mikrobus modules and display direct to the shield PCB. 

Bare Shield Arduino DUEMikroBus Shield Underside


The portable shield has the following features; they don’t all have to be fitted;

Two Mikrobus sockets.

Choice of display, Nokia 5110 LCD (very good out of doors), ST7755 TFT display or a SD1306 OLED.

5 Way Navigation Switch.Shield V3_1

Micro SD card.

Pads for SPI or I2C FRAM memory.

Two LEDs and a Buzzer.

Header for HC06 Bluetooth module for link to Android mapping.

Audio output socket for AFSK uplink at 600 baud into FLDIGI.

Reset supervisor for DUE base.

Analogue voltage reference for DUE base.

The small shield has the option to fit a small power distribution PCB. This is to allow a cased unit with power switches to be built which will run from an internal USB power bank and charging from the USB programming connection. To facilitate a cased unit the PCB has connectors for an external SD card module, LEDs, displays, navigation switch and power switches.

There are two UART Serial headers on the underside of the small shield; one intended for a ESP01 WiFi device and another for a HC05\06 Bluetooth module, either of which could be used for an external GPS. There will shortly be a Mikrobus module that can take the popular BME280 and BMP280 pressure and environment sensors, the DS18B20 temperature sensor or the DHT11 sensor. So with LoRa and sensor Mikrobus modules fitted together with an external Ublox GPS (£10ish on eBay) the shield would then be a fully functional and low cost HAB tracker transmitter.

A completely new version of the tracker receiver software is nearing completion and this allows it to be used for high altitude balloon (HAB) tracking or as a lost model locator. Fitted with an optional local GPS the receiver will calculate and display distance and direction to the remote tracker. Received telemetry can be logged to an SD card and the last GPS co-ordinates permanently saved to FRAM. The software integrates a serial terminal interface to remote control the distant HAB tracker. The receivers LoRa and frequency settings can be programmed in an over the air bind process received from the tracker transmitter or the tracker transmitter can be remotely programmed from the receiver. Thus it’s no longer necessary to unpack the tracker from a payload or model to make last minute adjustments to LoRa or frequency settings. 

The receiver has an audio uplink for an Internet connected PC to upload tracking data into Spacenear as well as a Bluetooth link to a mapping application on an Android phone or tablet.

When it’s all fully tested and there has been a live flight test, I hope to make the Shield PCB and the PCB of Mikrobus modules available for sale. Further Mikrobus PCBs are in progress for ESP01 Wifi, HC06 Bluetooth, NRF2401 RF and the various Bosch environment sensors. Large Shield


This is the large version of the Mikrobus shield, it also plugs into an Arduino DUE base. It can take the Nokia 5110 display or ILI9341 2.4” and 2.8” displays with SD card. There are 5 Mikrobus sockets, 3 on top 2 on the underside. Shown on the left with two LoRa modules, GPS and 2.8” display.



Plus here is a sneak preview of a really small matchbox sized LoRa receiver, it really is complete with LoRa device, display, GPS, battery and charger. It’s all you need to track a LoRa equipped HAB or lost model..Matchbox Receiver

UBLOX MAX M8Q GPS Breakout Board


GPS Breakout Finished

For those that want to build their own GPS Breakout board, I sell a PCB that allows you to do just that. Primarily designed for my own HAB tracker boards it can be used for other trackers and has both the Serial and I2C interfaces on the 8 way pin header. A previous article described how to attach this GPS board to my tracker boards.

For HAB tracking you can miss out most of the components. You if you wish can fit a small Lithium battery with some DS sticky tape and the components to trickle charge it from the trackers supply or fit an LED for the time pulse pin. My own tracker boards can have the components fitted to turn off the power supply to the GPS, whereby the battery will backup the GPS and allow it to be used in hot fix mode.


On the rear of the PCB are the pads for a small inductor, this helps to protect the GPS antenna input against static damage, a problem to which the UBLOX GPS are very prone to. The inductor can be omitted but take great care when handling the assembled break out board. If your UBLOX GPS takes a long time to get a fix, or never does, a probable cause is static damage to the antenna pin. The GPS data sheet does mention this as an issue.

You can fit the JTI_ANTENNA-1575AT43A40 ceramic stick antenna, but the board can also be used used with a 1/4 wave or 3/4 wave wire antenna and 1/4 wave radials. This will significantly improve GPS reception over the ceramic antenna, which in turn can significantly reduce power consumption, especially if hot fix mode is in use. The fitting of the wire antennas is described here fitting wire antennas. For these latest GPS breakout boards you will need to use Ernie Ball Custom Gauge 9 wire. Inductor on PCB


Taking suitable antistatic precautions, fit the inductor to the rear of the PCB



Ceramic antenna on PCB



If your fitting the ceramic antenna add it now.



Now position the GPS carefully in place and solder all the pads. I added C1 for some extra on board decoupling.

Add the 0.1” pin headers as shown in the first picture or solder the breakout PCB direct to one of my tracker boards and your ready to go.

Reception distances at UHF – My 1000:1 rule.

I often get asked what range you can get in ‘typical conditions’ using LoRa. There is a simple answer;

“There is no such thing as typical conditions.”

On several occasions constructors have got in touch and said; “I am only getting 1KM, yet you are quoting hundreds of KM, what is wrong with my set-up?” The answer to that is also simple;

“There is probably nothing wrong”.

It is not commonly understood how much the range\distance of communications at UHF can vary. Of course most people expect a difference between an urban area and hilltop to hilltop, but the actual differences are often a surprise. Are the communications over flat or hilly terrain, in urban, rural or forest or perhaps ground to satellite or ground to high altitude balloon?

I was fortunate during the radio testing for the $50SAT project to be able to develop a real world rule of thumb. Whilst testing the Morse beacon (on 437Mhz) I wondered if cutting the transmit power between dits and dahs would make an audible difference, there was an advantage in doing so as it saved around 33% of the battery power.

So I set-up the $50SAT transmitter board running the Morse beacon in my garden and wandered away up the road with my Yaesu FT60 hand-held till the Morse beacon was only just audible above the background noise. This was at a distance of 1km. I live in an urban area and its relatively flat.

The very same $50SAT transmitter board was put into orbit in November 2013. Some months later I was walking into town (it was a nice day) and $50SAT passed at approx 1200km distance. I heard the Morse Beacon very clearly with my Yaesu FT60.

In an urban environment the limit of reception was 1km, yet with the exact same transmitter and receiver and clear line of sight, the reception distance was 1200km, probably more.

That is where my 1000:1 rule comes from.

Thus whilst you might get 400KM with LoRa from the ground to a high altitude balloon, do not be surprised if at ground level in a city you get 400M or less.

This difference is also why it is so difficult to compare reception at different locations. I might get 1KM in my locality, the same equipment might cover anywhere between 250M and 10KM+ elsewhere. The differences are a good reason to be clear about the conditions applying to a reception report, preferably with pictures of the area.