ESP32 Shield – Adding a LoRa Device

I added the socket headers that allowed me to plug in a LoRa module. The sleep current went from around 8uA to 1.95mA, something definitely wrong. Checking the current consumption figures in the SX127x datasheet and registers it appeared that the LoRa device was in standby mode, despite the fact that the commands to put the LoRa device to sleep were being sent.

I eventually traced this issue to the RESET line on the LoRa device, when the ESP32 enters deep sleep mode it turns off the IO pins and it appeared that during this turn off it causes the LoRa device to reset. I removed the ESP32 IO pin (27) from the LoRa device and the LoRa device then went into sleep mode correctly. An alternative solution was to set pin 27 to an input prior to the ESP32 entering sleep mode. The LoRa device has an internal pull up on RESET so it would not be floating.

Although the ESP32, SSD1306, FRAM and LoRa device were now going into sleep mode, the current was still high, in the region of 290uA, I say ‘region of’ because it was varying.  I recall from the previous build of the shield that the LoRa device would still consume 300uA or so when in sleep mode, but with some of its inputs (SCK, MISO and NSS) floating, this should not be a surprise. So I added the pull ups in order;

Start 280uA.





So it would appear that pull ups on MOSI and SCK are required, and it makes sense to leave the one on NSS to prevent any oddities if the select pin floats low.

Progress so far is that the shield with an ESP32, SSD1306 display, FRAM and SX127x LoRa device has a sleep current of 8uA, although it does vary downwards a bit, sometimes going as low as 7.2uA.

Testing the board with and without the SSD1306, I would conclude that the SSD1306 consumes 0.5uA in when in sleep mode.

Testing the board with and without the LoRa device, I would conclude that the LoRa device consumes, 0.1uA when in sleep mode.

The partially completed board is below, it can powered from battery or USB power.

ESP32 Shield with LoRa

Next: adding the SD card.

ESP32 Shield – a Low Power Journey.

This post is about the build of a very low sleep current ESP32 shield. This is my second version of the shield and incorporates improvements discovered the first build. The original shield seemed to be a surprise to the outside World, the power consumption was in the region of 8uA when complete with SSD1306 display, FRAM, TC75 temperature sensor and SX127x LoRa device.

This blog is a description of the build of version 2 of the shield stage by stage and the measured sleep current as more parts are added.

Sleep currents were measured with a multimeter. I built an adapter that goes inline with the battery with connections for the multimeter and a toggle switch. The switch allows the multimeter to be shorted. Thus with the switch shorting the multimeter there are  no burden voltage issues caused by the multimeter. When the ESP32 goes into deep sleep just flip the switch and read the current (in uA) from the multimeter. With the multimeter measuring a a sleep current of 8uA the voltage across the multimeter was only 0.8mV, which is less than would occur if I was using my uCurrent Gold on the 1mV per uA range.

I started the build by adding fitting the  MCP1700 3.3V regulator. The current consumed with nothing connected to the output of the regulator was 1.6uA, a good starting point.

I fitted the ESP32 and the components required to allow the ESP32 to be programmed via a plug in USB to serial adapter, see picture.

The test program was a version the Andreas Spiess used in the video on deep sleep of the ESP32, see the link below;

I changed the program so that at  start the LED would flash and the ESP32 would go into deep sleep for 30 seconds, when the LED stopped flashing I knew to flip the switch shorting the meter and take the current reading. 

ESP32 just module

OK, so lets add a SSD1306 OLED. The Adafruit library has an option that in effect turns the display off; ssd1306_command(SSD1306_DISPLAYOFF);

The test program writes some text to the screen then flashed the LED and goes into a 30 second deep sleep, this is the result, 7.7uA;


The ESP32 does have 8Kbytes of RTC RAM that will survive deep sleep, so this could be useful for keeping track of what a program is doing when going into and out of deep sleep, however this RAM will not survive reset or power down, so I prefer to add a FRAM to projects. These FRAMs are like EEPROM but they have a limited life, maybe 1,000,000 writes. FRAMs have a write endurance many times greater, up to 100,000,000,000,000 writes, so can be treated as RAM. I added a MB85RC16PNF 2Kbyte FRAM and measured the sleep current, it was only 0.1uA extra;


So 7.8uA for an ESP32, SSD1306 display and a 2Kbyte FRAM, looks promising.

Next:  Adding SPI devices.

Power measurements can be useful !

A previous blog post looked at how you can use a cheap (£20) power meter to make accurate measurments on the power output of LoRa radio devices.

I was following the guide and program for a creating a simple TTN node that Andreas Spiess presented in a video;

The program provided uses the LMIC library. The program works fine and the packets show up in the TTN device console.

I wanted to add some of my own diagnostics, so I borrowed some routines from my tracker software thats reads back the LoRa device registers after a packet send and displays the frequency, bandwidth, spreading factor, coding rate and power level the LoRa device was set to.

I had assumed the power level for a TTN node would be set to 14dBm/25mW due to legal restrictions, but the LoRa device was inmdicating it was s set to 16dBm/40mW .

I knew that my ‘calibrated’ 868mhz LoRa module was about 1dBm below the power it should be (see the previous blog post) so I hooked that module and the TTN node software to the power meter. The node program copde was set to send a SF12 packet at start up so there would be enough time for the power meter to display it.

The power meter displayed 15dBm, which is consistent to it actually being programmed for 16dBm as my diagnostic code had suggested. 

Now the appropriate register for power level is RegPaConfig and its set in radio.c of the LMIC library;

static void configPower () {
#ifdef CFG_sx1276_radio
// no boost used for now
s1_t pw = (s1_t)LMIC.txpow;
if(pw >= 17) {
pw = 15;
} else if(pw < 2) {
pw = 2;
// check board type for BOOST pin
writeReg(RegPaConfig, (u1_t)(0x80|(pw&0xf)));
writeReg(RegPaDac, readReg(RegPaDac)|0x4);

#elif CFG_sx1272_radio
// set PA config (2-17 dBm using PA_BOOST)
s1_t pw = (s1_t)LMIC.txpow;
if(pw > 17) {
pw = 17;
} else if(pw < 2) {
pw = 2;
writeReg(RegPaConfig, (u1_t)(0x80|(pw-2)));
#error Missing CFG_sx1272_radio/CFG_sx1276_radio
#endif /* CFG_sx1272_radio */

I have CFG_sx1276_radio selected so the power level is set by this line of code;

writeReg(RegPaConfig, (u1_t)(0x80|(pw&0xf)));

Which writes the pw variable into the power setting register. If pw is 14 (for 14dBm?) the power level of the device is according to the datasheet;

Pout=17-(15-OutputPower). ‘OutputPower’ is what is written to bits 3-0 of RegPaConfig and if its 14 the actual power level selected appears to be;

Pout=17-(15-14) = 16dBm.

This is in line with my diagnostic print, which suggests the power level is being set to 16dBm when 14dbm is expected.

Is it possible the LMIC code should be;

writeReg(RegPaConfig, (u1_t)(0x80|(pw&0xf)-2));

Measuring Power

When your using or experimenting with radio devices there is often the need to measure power levels at radio frequencies. This can be the power output of a small radio module, 10mW at 433Mhz or the signal power seen by a receiver, –100dBm. The receiver power is often referred to as the RSSI.

Measuring RF power under 100mW, with accuracy, is not so easy as a lot of RF power meters of the type used by radio amateurs often have a minimum power input in the 1W region.

There are now available some low cost RF power meters, which have a wide frequency range of up to 8Ghz and measure power in dBm from –5dBm to –55dBm. One such is shown in the picture, it was purchased on eBay for around £20.

If these meters can measure only from –5dBm to –55dBm, and you want to measure the 2dBm output from a LoRa module you need to use an inline attenuator, 20dB or 30dB for example. With the power meter connected through the attenuator and the LoRa module set to transmit a 2dBm carrier,  if the power meter is accurate, then it ought to display –28dBm. See picture for the setup. The LoRa module is on a plug in Mikrobus module, so it can easily be moved between different controller boards.


And here lies a problem, how do you know your (cheap) power meter is accurate?

The simple way is to take the power meter somewhere and get it calibrated, but I decided it would be more useful to calibrate the transmitted power output of a LoRa module and then keep it as a reference. If I know that a specific LoRa module puts out 9.8dBm when set to 10dBm, I can be keept as a long term reference and as long as I take care when using it, always have an antenna connected for instance, then it ought to be stable for quite some time.

In the centre of Cardiff is Eagle labs;

It’s run by Barclays and Legal & General with RadioSpares providing equipment in the electronics lab. Part of this equipment is a spectrum analyser (RSSA PRO 3032X) and it’s got a  proven calibration history. So my plan was to book a session at Eagle labs and use their spectrum analyser  to ‘calibrate’ the power output of a 434Mhz and 868Mhz LoRa module.

I wrote a simple test program that for the 433Mhz and 868mHz modules that transmitted RF carrier for a couple of seconds at 17dBm, 10dBm and 2dBm, I used a 20dB attenuator between the LoRa module and the spectrum analyser.

I got these results for 434mhz;

LoRa device programmed power output       17dBm          10dBm               2dBm

Measured power 434mHz                            -4.6dBm        -11.3dBm          -18.6dbm

LoRa device actual power 434mHz              15.4dBm         8.7dBm            1.4dBm   


For the 868Mhz tests I have included the readings of the power meter with a total of 30dB of attenuator in line, these were the results;

LoRa device programmed power output       17dBm           10dBm               2dBm

Measured power 868mHz                            -4.1dBm         -10.3dBm          -18.5dbm

LoRa device actual power 868mhz               15.9dBm         9.7dBm             1.5dBm    

Power meter indication (30dB att)                -13.1dBm       -19.3dBm           -27.6dBm

Power Meter corrected  +29dBm                   15.9dBm        10.7dBm             2.6dBm  


The key point from the above measurements is that I know that my 868mHz module puts out 15.9dBm when set to 17dBm. 

With a 30dB attenuator in use the power meter indicates –13.1dBm. Now 30dBm (because of the attenuator) below an actual power of 15.9dBm is –14.1dBm, so with the power meter actually reading –13.1dBm, its reading 1dBm lower than it should be. The power meter has an offset you can set, so if I set the offset to 29dBm, then when the actual power is 15.9dBm, the power meter will read 15.9dBm due to the effect of the attenuators. 

I know that all sounds a bit long winded, but the end result is that I have a relatively cheap power meter (£20) that has been adjusted to give accurate results. Of course its entirely possible to calibrate the power meter directly, but since I now have a LoRa module that puts out a known amount of power I can keep it and use it to check this or other power meter or attenuators in the future. And then of course with enough attenuators in line, I can also use the calibrated LoRa modules to check the RSSI readings of various radio receivers.

Phantom Packets – Is this the reason ?

After consulting Semtech, the reason why these phantom packets are seen becomes clear.

This is my current understanding of the issue but testing is continuing …………….

The LoRa receiver will occasionally falsely see noise from the receiver itself as a packet preamble and header. Since its noise from the receiver this explains why the phantom packets are seen even in heavily screened receivers underground.

The header is protected with only a 6 bit CRC so there is a 1:64 chance that this noise will pass a valid header check.

When sending LoRa packets you have the option of using a payload CRC (16 bit) or not. If there is a payload CRC enabled a flag bit is set in the header. When receiving the packet the LoRa receiver tests for this payload CRC enabled flag and carries out the CRC check on the payload.

The trap you can fall into is in assuming that since your application only sends packets with CRC on the payload enabled, on packet receipt you only need to check the RegIrqFlags register PayloadCrcError bit. If its set there is a CRC error, if it clear then you assume your packet is valid. But it may not be.

When one of the phantom packets is received (which are just noise remember) there is a probability that the false header both passes the header CRC check and does not have the payload CRC enabled bit set. If this bit is not set in the header then the LoRa receiver does not carry out a payload CRC check and the CRC error flag is left clear.

There are some LoRa software libraries that on packet receipt appear to check the header for the payload CRC enabled flag and then check the payload PayloadCrcError flag as appropriate. This makes sense if your receiver software is designed to automatically cope with packets that use a payload CRC and those that do not.

So in summary to ensure that you do not read phantom packets as valid, you should consider;

1. Sending packets with the payload CRC enabled.

2. Checking the RegHopChannel register RxPayloadCrcOn bit, if its is clear, dump the packet, it could be a phantom.

3. If the RegHopChannel register RxPayloadCrcOn bit is set, check the RegIrqFlags register for the PayloadCrcError bit, if that is set dump the packet, it could be a phantom.



A LoRa mystery – Phantom packets but deeper

Despite the shielding of my LoRa receivers being able to resist 50mW at 5cm it was possible that there could be a Megawatt LoRa transmitter somewhere close that was the cause of the phantom LoRa packets I was seeing at 868Mhz bandwidth 500khz and spreading factor 7. It’s unlikely there would be such a powerful transmitter nearby that I did not know about, but it seemed a good idea to eliminate it as a possibility.

What I needed was a test area that was in a relatively remote, was underground and with no openings to the outside world. Fortunately up in the hills nearby is a disused railway tunnel, it’s at a height of 439m AGL, the tunnel is 600m long and curved so that in the middle there is no line of sight to the outside world. The tunnel is some 40m underground in the middle. There is a quiet road nearby with a few cars, the nearest building is 1km away. There are a few further buildings 3km away.

I went to the tunnel on a wet afternoon with my brother (Neil) to see if there would be any difference in the number of phantom packets received and their signal strengths in the middle of this tunnel. I used two receivers heavily screened as before and took the precaution of eliminating all possible EMI producing gadgets, phones off, cameras off, I even took the battery out of my car key fob.

With the two receivers on the floor I could still hear the beeps indicating phantom packets at the same rate as I had been getting in my workshop and local field.  Looking at the logs the receivers produced later it was clear that the signal strengths in the workshop were the same as I was seeing deep underground and a very long way from any LoRa transmitters.



ReqIrqFlags 0x50
CRC and Header OK
Packet data 9E,62,C8,7C,55,B2,6F,E1,40,8A,F8,D4,B1,99,0C,33,EA,E1,58, (packet data truncated)
Valid Packets 7  CRC Errors 2  Header Errors 0

Reported signal strength in all the tests, with an antenna on a tall mast, with small antenna on the bench, with an SMA terminator on the antenna socket on the bench, heavily screened on the bench and now with a heavily screened receiver deep underground were always the same, –112dBm to –114dBm and with SNRs of –11dB or –12dB. My assuimption would be that the source of the phantom packets was the receiver itself.

With  the microprocessor in use (ATMEGA328) being put to sleep this suggests the source of the phantom LoRa packets may be the LoRa device. If that is the case how can it be that the CRC is valid for about 70% of the phantom packets? My logging software was printing out the contents of the ReqIrqFlags register and that indicates a valid header (which has its own CRC) as well. 

What are the chances of the CRCs for header and payload being valid in a packet that’s some sort of random occurrence of noise?


A LoRa Mystery – Phantom Packets.

I had noticed  while testing LoRa links at 868Mhz with different receiver types that I was seeing a number of ‘phantom’ packets that I did not recognise. I initally thought these were just LoRa packets from the surrounding environment. 

The receiver I was using was listening on Bandwidth 500Khz and spreading factor 7, which is not the typical packet settings used by LoRa for Internet of things applications. I was using these settings as I needed a fast data rate and only a hundread meters or so of range. These phantom packets being quite short range I thought must be coming from somewhere nearby.

I used some LoRa SD card logging software I had written to check out the details of these phantom packets. I could leave the receiver running for long periods to see how many packets were received. I did fing a bug in the software which explained some odd RSSI and SNR values I had been seeing but I was still curious as to where the packets were coming from.


LoRa Receiver


With the receiver running on the bench with an antenna I was getting around 5 to 10 phantom packets per hour, these were a mixture of packets with valid CRC and those where the CRC check had failed. Packets varied in length from a few bytes up to 200+. The reported RSSI and SNR was always around –110dBm and –10dB respectively which suggested a single source of the packets. 

I put an SMA terminator in place of the antenna and was surprised to see that I got around the same results, 5 to 10 packets per hour and similar RSSI and SNR values.

As a check to see if these phantom packets were actually coming from the great wide world I put my reference 868Mhz antenna (1/4 wave vertical with radials) on top of the 8.5m mast attached to my workshop. I got the same results as I had when the receiver was sat on the bench with an SMA terminator on it. The assumption might be that the source of the phantom packets was therefore very local, interference from my PC or the lights perhaps ? That however would not explain why I origionally seen these packets in the middle of a large field.

For some of the LoRa link testing I had been doing recently I needed to cut the range of the LoRa transmitter (at spreading factor 12) to just 50m or so. Fitting an SMA terminator in place of the antenna was not enough. Even putting the receiver in a die-cast aluminium box was not enough. What did work very well was wrapping the transmitter in aluminium foil. That cut the reception range to 10m or so and it was easy to adjust the range out to 50m by using a pin to put small holes in the aluminium foil.

LoRa Test Transmitter











 Screened Transmitter












If the aluminium foil was so effective at preventing the RF getting out, it ought to be effective at preventing RF getting in. So I wrapped a LoRa receiver in foil and also put it in an   aluminium box. A LoRa transmitter sending packets at 17dBm (50mW) had to be within 5cm of the box for the receiver to pick up the packets, there was a buzzer on the receiver so I could tell when packets were received. So if real world packets were getting through all that shielding they had to be very powerful indeed.

Screened Receiver

With the receiver now wrapped in foil and consequently very well screened I was still receiving phantom packets and with the similar RSSI and SNR values as before. Perhaps the phantom packets were a result of electro magnetic interference (EMI) coming from the receiver itself, but if so how could the CRCs be valid ?

I modified my logger software to put the Arduino Pro Mini to sleep and have it wake up when a packet was received using an interrupt from the LoRa devices DIO0 pin. I even powered down the SD card. Thus the only active electronics running (and thus possibly generating EMI) was the LoRa device itself listening for a packet.

With only the LoRa device itself active and with it heavily screened from the outside world, still the phantom packets appeared.

These phantom packets do seem to be coming from the receiver itself; when I ran two identical receivers next to each other on the bench, each would receive phantom packets but not at the same time. If the source of the packets was external then you might expect at least some duplicate receptions.

This does not appear to be just an issue with the 500khz bandwidth setting, IO have also seen phantom packts when the 125khz bandwidth setting is used.

Maybe the LoRa receiver is fooled into starting packet reception by noise but then why does reception complete with a valid payload CRC and a valid header CRC as well?

Adventures with the ESP32

As part of a project to check if locally generated electromagnetic interference (EMI) would affect LoRa receiver performance at its weak signal limits I needed a ESP32 board that I could plug Mikrobus modules into. Faster microcontrollers, such as the ESP32 are becoming the norm, which is understandable, they are cheap, fast, have lots of memory and in the case of the ESP32, have built in Wifi and Bluetooth. Faster microcontrollers, however, generate more EMI, so I wanted to do a LoRa reception comparison with various microcontrollers. For the comparison to be valid I needed to use the same LoRa module for different controller boards, the easiest way to achieve that was to have the LoRa device on a plug in Mikrobus board, there are some details of Mikrobus modules here;


The RFM98 module above is assembled using my own low cost PCBs, in this case the Mikrobus module PCB is modified from standard to allow access to all the LoRa device DIO pins. The advantage of having a controller board that accepts Mikrobus modules is that it is easy to re-purpose the controller board simply by fitting a different type of Mikrobus module, see the Mikroelectronica link above for the possibilities.

But which ESP32 board to use ?  There are several, the Wemos Lolin 32 seems popular, but I really wanted to be able to plug in a choice of batteries and not be restricted to a Lithium battery. The NodeMcu32s fits the bill, its one of the smaller ESP32 boards and provides access to the voltage(battery) in pin. The board is shown below.


Designing a Mikrobus module PCB for the NodeMcu32s was easy enough, I use Eagle, but what had me stuck was which of the pins of the NodeMcu32s you could you use as inputs, outputs, interrupts or analogue and more importantly which pins did you need to avoid using for fear of interfering with the ESP32 itself or the attached flash.

I decided to design my board layout first and then check that I could get the functions I wanted out of the pins, the functions I needed were;

Outputs, flash an LED, drive a chip select.

Inputs, read a switch or interrupt.

Analogue, read a battery voltage for instance.

Pulse Width Modulation, not needed for my board, but useful for the Mikrobus sockets.

UART transmit and receive, two channels.

I2C, read and write to a FRAM and SSD1306 OLED display

Micro SD card read and write.

LoRa device, read and write

So as well as checking the basic pin functions, I needed test programs for each of the above to confirm it would all work in practice. After a couple of days of testing and checking I worked out which pins you can use on the NodeMcu32s and which ones to avoid, they are listed below, with comments against each pin.


0 Input, shared with the IO0 switch on the board, this switch needs to be pressed, pin held low, to download a program

1 TX output from serial console, I made no connection to this pin

2 Output, shared with the LED on the board

3 RX input to serial console, I made no connection to this pin

4 Analogue, used to read battery level

5 Output, SPI SS, used for chip select on LoRa device

6 Could not use, appears to be used by flash

7 Could not use, appears to be used by flash

8 Could not use, appears to be used by flash

9 Could not use, appears to be used by flash

10 Could not use, appears to be used by flash

11 Could not use, appears to be used by flash

12 Input, can be used as a switch input, but be sure to leave it floating during programming. There is a pull up to VCC on the board and when this pin is high the correct voltage for the Flash is selected. If the pin is low programming will fail

13 Input, Serial1 RX, you can select any of the available input pins for the RX when defining the Serial1 instance

14 Input, Serial1 TX, you can select any of the available input pins for the TX when defining the Serial1 instance

15 Input and Output, LoRa device DIO2 interrupt input or PWM output

16 Input, Serial2 RX, you can select any of the available input pins for the RX when defining the Serial2 instance

17 Output, Serial2 TX, you can select any of the available input pins for the TX when defining the Serial2 instance

18 Output, SPI SCK, used for the LoRa device and SD card

19 Input, SPI MISO, used for the LoRa device and SD card

21 SDA, used for the SSD1306 display and I2C FRAM

21 SCL, used for the SSD1306 display and I2C FRAM

23 Output, SPI MOSI, used for the LoRa device and SD card

25 Output, used for chip select on SD card

26 Analogue, used to read battery level

27 Output, used for the RST on the LoRa device

32 Output, PWM

33 Input only, used for used for reading external switch

34 Input only, needs external pull-up, used for reading DIO1 on LoRa device

35 Input only, needs external pull-up, used for reading DIO0 on LoRa device

36 Input only, needs external pull-up, used for reading DIO3 on LoRa device

39 Input only, needs external pull-up, used for reading external switch

EN Input, External reset, pull to ground for reset.

VIN External power input. Intended supply is 4 x AA Alkaline or NiMh batteries.

It is not clear why pins 6 to 11 are provided on the board, you do not appear to be able to use them. These pins are not present on some other ESP32 boards such as the Wemos Lolin32.

Although the pin mappings above are the defaults for the NodeMcu32 board you can map the pins for SPI, I2C, UART or PWM to any available pins, although not 6,7,8,9,10,11,12. I have also not tried redirecting these interfaces to 34,35,36,37.

There are some capacitors associated with pins 36 (VP) and 39 (VN) but they did not appear to interfere with the relatively slow interrupts you will get from a LoRa device for instance.

Program space

I have a program that I use for LoRa link testing, it receives LoRa packets and logs the SNR, RSSI and contents to the Serial monitor and SD card. When compiled for an Arduino Pro Mini the program consumes this much space;

Sketch uses 19562 bytes (63%) of program storage space. Maximum is 30720 bytes.
Global variables use 1292 bytes (63%) of dynamic memory, leaving 756 bytes for local variables. Maximum is 2048 bytes

For the NodeMcu32s it consumes this amount of space;

Sketch uses 159701 bytes (12%) of program storage space. Maximum is 1310720 bytes.
Global variables use 12348 bytes (4%) of dynamic memory, leaving 282564 bytes for local variables. Maximum is 294912 bytes.

So although the NodeMcu32s reports as having 1,310,720 bytes of available Flash, compared to 30,720 for the Pro Mini, compiled ESP32 programs consume that space at around 8 times the rate for an ATMega328 program, so you don’t have as much useable program space as you might think.

Lost in a (wet or dry) Forest

So just how far will LoRa transmissions go in a forest that is wet?

I decided to find out.

Local to me is a park that has in the middle of it an area of forest and undergrowth around 300M x 200m. I wanted a location where I could create a reference test, so at one end of the forest, the left mark in the map below, I placed a stick on the ground in the undergrowth and held it in place with pegs. I would use this to line up the tip of the antenna on the test transmitter. Thus in subsequent tests the antenna would be in the same location.

Wet or dry forest pic1

On the map the test route distance between the two marks is 200m. The forest is fairly overgrown with a lot of low level vegetation. Below are some pictures of the ‘forest’ so you can appreciate the depth of the undergrowth. The first picture below is from the transmitter location on the left of the map looking towards the receiver location on the right.

Wet or dry forest pic2

The second picture, below, is from the receiver looking towards the transmitter.

Wet or dry forest pic3

This third picture is the test transmitter, an Arduino Pro Mini and RFM98 LoRa device placed in a metal box. A ¼ wave wire antenna is used for the transmitter and receiver. The transmitter is shown bellow with a 10dB attenuator in place to reduce the signal from the antenna to both legal levels, 10dBm in the UK, and to provide a practical range for the receiver. The test transmitter is on the ground amongst the vegetation (worst case location perhaps). The receiver was held in my hand with the tip of the ¼ wave wire antenna at around 1.5M from the ground.

Wet or dry forest pic4

The test method involves sending a series of packets at descending power, 17dBm to 2dBm. The power level used to send the packet is part of the data in the packet. The receiver can then tell the power used to send the packets it is receiving. So if the receiver stops receiving packets at 10dBm, you have quantified how much power is needed to cover the distance.

The LoRa settings were, 434.4Mhz, bandwidth 62.5khz, spreading factor 8, code rate 4:5, explicit mode. This represents a data rate of 1562bps.

At the time of the test its had been raining overnight and for most of the morning. It was raining heavily during the test, the forest was very wet. The test transmitter had a 10dB attenuator in place.

Packets sent at 6dBm power were the lowest received, so taking account of the 10dB attenuator, the packets were in effect being transmitted at -4dBm or 0.4mW.

The first test was with the forest fairly wet and a couple of weeks later it had been dry for several days so I repeated the test with the same equipment with the antennas in the same position and location. This time the packets were just received at -9dB, so the dry forest was 5dB better than the wet. Or more simply when the forest was wet, signals were reduced by around 5dB.

So big question, if the transmissions had been at 10mW (normal ISM band limit) then how far might the signals propagate in worst case (wet) conditions?

If packets are sent at 10dBm but -4dBm is enough to cover the 200m then there is a link margin at 200m of 14dBm. Thus if the forest is assumed to be uniform an extra 14dB on link gain should increase the distance by 5 times, or to 1000m.

If the full 17dBm (50mW) of the transmitter was used the distance covered could increase to 2200m.

There is more, for this test the signals were being sent at a LoRa data rate of 1562bps, if the data rate was lowered to 150bps, which is fine for a lot of data gathering and control applications, range would increase by a further 3 times when using the same power.

The first LoRa received from Space !

During the The Things Network (TTN) conference in Amsterdam recently Thomas Telkamp arranged to borrow some time on the maritime satellite NORSAT2 and used it’s SDR to transmit LoRa as the satellite passed over Amsterdam.

The LoRa was transmitted on 162Mhz at 26dBm (400mW) into an approximate 6dB gain steerable yagi which was pointed to the horizon and at Amsterdam during the pass, data rate was 292bps.

The TTN receiver was a standard Microchip LoRa 169Mhz device with a simple antenna that was placed on the roof of a two storey building in the industrial area just to the North West of Amsterdam center. The LoRa was received as soon as the satellite cleared the horizon, a range of 2763km.

There was a challenge (prize) to be the first one to receive the LoRa during the conference. One of my own very simple handheld Arduino Pro Mini receivers fitted with a 433Mhz LoRa module (i.e. the wrong one for the frequency) and a telescopic whip antenna was good enough to receive the first LoRa on 162Mhz. The insertion loss of 162mhz into a 433Mhz receiever had been estimated by Thomas at around 20dB!  The receiver was just left propped against the window of my hotel bedroom . I received packets close to the limit of reception with an SNR of -18dB.


LoRa from Space


The Video of the ‘LoRa from Space’ presentation can be viewed here;