LowDataRateOptimization not supported for SF other than SF11 and SF12 (solution provided)

[tuxphone]

According to Semtech "the low data rate optimization is usually recommended when a LoRa® symbol time is equal or above 16.38ms" (SX1261-2 Datasheet Rev. 1.2 06/2019, page 39 num. 6.1.1.4

Your radio.c has a RadioSymbTime() function which is exactly checking this. Parameters are bandwidth (one of RadioLoRaBandwidths_t ) and spreading factor.

The problem for combinations like SF 9 and bandwidth 31.25kHz is, that they do not get the SX126x.ModulationParams.Params.LoRa.LowDatarateOptimize register set to 0x01 but instead 0x00 (off).

The glitch is in the RadioSetRxConfig() and RadioSetTxConfig() functions, which do not call the RadioSymbTime() with bandwidth and SF, but instead with bandwidth and CodeRate .

(RadioSymbTime(Bandwidths[bandwidth], coderate) >= 16.38) instead of RadioSymbTime(Bandwidths[bandwidth], datarate) >= 16.38)

Put like that it's rather obvious, but very easy to overlook. So change coderate to datarate in both function and you are set. And you are now officially supporting all bandwidths (not only 125kHz, 250KHz and 500 kHz).

After these changes there should be no need for your OR checks in the problematic IF. Just check symbol time >= 16.38.

I could pull the necessary code changes but wanted to discuss it here first.

PS: I did the full change on my system and have no problems with the tested SF 12/125kHz and SF9/31.25kHz combinations: if( (RadioSymbTime(Bandwidths[bandwidth], datarate) >= 16.38) ) {

Edit: "no problem" means i could now connect a CubeCell capsule to a ESP32 with sx1276 (and RadioLib driver), both set to the above bw/sf combinations.

[Heltec-Aaron-Lee]

I merged your last submission, but there was a problem that SF11 and SF12 could not be received by the gateway. Tried this PR again today and everything is normal. I do not know why...

Anyway, thank you for your support.

[tuxphone]

My previous change didn't include the datarate/coderate fix. So RadioSymbTime was still called with the wrong parameters (wrong in/wrong out :-) ). Now it's working as intendend.

[Heltec-Aaron-Lee]

Yes, I had tested this morning, all worked well.

Thanks. 👍

[steve1427]

Hi, I had a very similar problem posted to Heltec forum. It was suggested that I post it here also in order to see if this is the same problem. See http://community.heltec.cn/t/wifi-lora-32-v2-1-range-and-spreading-factor/6116 for full discussion. In essence:

_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/ 11

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._

Thanks