WiFi LoRa 32 (V2.1) Range and Spreading Factor

#1

Hi,

I’ve been experimenting with two WiFi LoRa 32 V2.1’s (915Mhz - AU915 band) with the example “LoRaSetSpread” programs. The devices are fitted with the Heltec spring antennas and enclosed in the little plastic cases exactly like in the Heltec web page - ie https://heltec.org/project/wifi-lora-32/

The max range I seem to be able to achieve in the open air is about 300 metres with a spreading factor of 10. Probably not much better than WiFi. What should I expect?

I have tested a commercial product recently, also with only inbuilt antennas, and I was able to achieve 10 times this range.

There are a couple of anomalies however.

1 - The RSSI degrades to -120 or so when reception cuts out which tallies with what I know about LoRa, but the SNR remains around 6ish. If the Heltec is computing SNR in the normal LoRa way, this would mean the signal is 4 times the noise floor which should be plenty, but this seems at odds with the RSSI. Some other LoRa devices I have played with recently work down to a SNR of -17 or so, ie where the signal is about 1/50th of the noise floor. Maybe Heltec is measuring SNR differently?

2- I have also played with the spreading factor, but this doesn’t seem to greatly increase the range as expect. In fact, when I set a spreading factor of 12, the devices do not appear to communicate at all even when sitting along side one another.

Any suggestions welcome.
Thanks
'Steve

#2

Well, that’s weird.
When I use the standard Arduino LoRa library “LoRa” by Sandeep Mistry rather than the Heltec library, I can get spreading factor 12 to work. Further more, the SNR degrades as expected and the achievable range is greater.
If anyone knows what’s going on, I’d be grateful.
Cheers
Steve

#3

You can compare the power settings of the two banks.

#4

Hi navi, I’m not sure what you are getting at there?

I have found however, that if I reduce the transmit power to about 12 or less
Ie
LoRa.setTxPower(12,RF_PACONFIG_PASELECT_PABOOST);
Then the spreading factor of 12 appears to work.
It appears to be related to the transmitter, not the receiver as I can reduce the signal strength at the receiver by simply moving the two units further apart, but this does not help.

Cheers
Steve

#5

If the distance is too close, the power needs to be lowered.

#6

This is the latest official SNR calculation method, you can replace the previous one and have a try.

float LoRaClass::packetSnr()
{
return (((int8_t)readRegister(REG_PKT_SNR_VALUE) +2) >> 2);
}

#7

Thanks navi, I’ll look at the SNR calc. Sure, if the range is short, the power need not be high, but even when the range is not short, if the tx power is greater than about 12ish, the transmitter seems to have a problem when using a spreading factor of 12. This did not appear to be the case when the Arduino LoRa library is used instead of the heltec library.

#8

Have you tried other levels of spreading factors? How do they perform?

#9

Hi navi,
Yes I have. Any spreading factor except 12 seems to work at full power (20). It’s only spreading factor 12 that seems to cause this issue. I’m looking at the transmissions with a software defined radio, and certainly the transmission is a lot longer with spreading factor 12,
Rgds
Steve

#10

Thank you for your reply, we will also conduct experiments.

#11

Hi everyone,
I’m just new with this module, a complete noob let’s say. I do have a gateway operating with LoraWan, and I enabled a Lora channel on it to try with this sensor. I don’t seem to find an example where I can set the band, frequency, bandwidth, spreading factor. Could you point me to a sample that I could use for initial tests?

Thanks in advance,
chabral.

#12

Which product did you buy?

#13

Hi @navi, I bought the Wifi LoRa 32 (V2) without the plastic shell (https://heltec.org/project/wifi-lora-32/). I followed the steps to install the libraries in Arduino IDE, and I deployed a few examples to the module for testing.

Thank you,
chabral.

#14

This example has related configuration.

#15

Hi navi,
I’ve conducted a few more experiments. (I’m just using a simple program based on the Heltec LoRaSetSpread example.)
I have found

1-(As mentioned before) When the spreading factor is 12, the power needs to be about 12 or less for reliable operation. This isn’t the case when the basic LoRa.h library is used instead of heltech.h.
2-If I change the bandwidth to 500E3, then I can use power 20 with spreading factor of 12.

I have also tried loading the heltec.h version in one LoRa 32 V2.1 and the LoRa.h version in another with the following result
3- If the spreading factor is 12 (on both of course), the device with the LoRa.h library used does not receive the packet from the device with the heltec.h library, but the device with the heltec.h library does receive the packet from the LoRa.h library, however, the payload is corrupted.
4-Reducing the power in the device with the heltec.h library doesn’t fix this corruption.
5- If I use a spreading factor of 11, the device compiled with the LoRa.h library and the device compiled with the heltec.h library happily swap packets between them with no issues.

My general conclusion is something unexpected seems to be affected in the heltec.h library when a spreading factor of 12 is set.

Admittedly, I’m not expert here, but there does seem to be an anomaly.

Cheers

#16

Thank you very much for the information, we will conduct an experimental check.

#17

I found this thread while trying to get my CubeCell to communicate with a WiFi LoRa 32 board. It works perfectly when both boards are set to a spreading factor of 8, but it doesn’t work at all when they’re both set to 11.

Very strange. I’m digging around in the source files but I don’t see any reason for this behavior.

This is a problem for me, because I already have a network of WiFi LoRa 32 devices, and I can’t easily re-flash all of them to use a different spreading factor.

#18

I’ve tracked the issue down to the code controlling the LowDatarateOptimize param:

If you remove this bandwidth-checking logic and simply replace it with this:

SX126x.ModulationParams.Params.LoRa.LowDatarateOptimize = 0x00;

Your CubeCell device will be able to communicate with the WiFi LoRa 32 with its default spreading factor of 11.

#19

Maybe your issue is related to the fix merged here:

you should post your issue in that link above so the proposed solution can be rechecked against your situation…

cheers,
Jay

#20

Thanks Jay.
I just did that.
Cheers