Unexpectedly low RSSI with SX1276

[trullock]

I have a pair of these next to each other on my bench driven by ESP32s: https://www.soselectronic.com/en/products/hoperf/rfm95w-868-s2r-1-180936

The chips are marked SX1276 (seemingly not the HopeRF marked "RF96" chips as advertised)

With this approximate code for TX:

SX1276 radio = new Module(PIN_NSS, PIN_DIO0, PIN_RST, RADIOLIB_NC)

radio.setSyncWord(123);
radio.setFrequency(868);
radio.setBandwidth(62.5);
radio.setSpreadingFactor(7);
radio.setCodingRate(5);
radio.setOutputPower(7); //deliberatly small for bench testing

int state = radio.transmit(myBuffer, 36);

And this for RX:

SX1276 radio = new Module(PIN_NSS, PIN_DIO0, PIN_RST, RADIOLIB_NC)

radio.setPacketReceivedAction(setFlag);
radio.setSyncWord(123);
radio.setFrequency(868);
radio.setBandwidth(62.5);
radio.setSpreadingFactor(7);
radio.setCodingRate(5);

My packets are being received with an RSSI of -98dBm and a SNR of about 10, which seems extremely low?

I'm using stub antenna which are supposedly 868MHz, but removing the antenna makes little difference.

After getting nowhere I switched to https://github.com/sandeepmistry/arduino-LoRa and setting it up in the same way for TX and RX:

LoRa.setSyncWord(123);
LoRa.setCodingRate4(5);
LoRa.setSpreadingFactor(7);
LoRa.setSignalBandwidth(62.5E3);
LoRa.setTxPower(7);

LoRa.begin(868E6);

I'm getting an RSSI of -18dBm and SNR of ~10

I've fiddled around with all of the settings above in RadioLib and I can't make any noticable difference. Is there some other setting I'm missing which Sandeep's library has on by default?

Thanks

[jgromes]

LoRa modem of the SX127x can report two different RSSIs - average RSSI of the last packet, and current instaneous RSSI. Which one are you measuring?

As far as I can tell LoRa.h library calculates the RSSI similarly to RadioLib, with the notable differences that:

1. It does not include SNR in the calculation, so it will be incorrect for cases where SNR < 0 (not your case, but still)
2. The offsets are applied at different frequencies, though this should only cause about 7 dBm difference. It is possible that this could be incorrect in RadioLib, but still doesn't explain the large difference.

The SX127x datasheet also mentions that above -100 dBm and SNR >= 0, the RSSI measurement should be corrected by a factor of 16/15, but neither library does that and the effect should also be minimal.

[trullock]

Apologies, I missed that off. I'm reporting packetRSSI in both cases

I don't believe this is (just) a reporting thing, the range with RadioLib was terrible, so I'm inclined to think theres genuine TX power/other real differences

[jgromes]

I tested the SX127x driver with an RF power meter, the output power should be correct. Are you using the correct pin as the RF output? SX1276 has two options for that. By default, RadioLib uses PA_BOOST output.

One more thing to check is the current limit, RadioLib sets it to 60 mA by default.

I will also note that the sync word you have is rather unusal, as Semtech recommends to only use either 0x12 or 0x34.

[trullock]

Given you haven't said "Oh you haven't set setting X", and because of the clear quality and obvious rigorous testing your lib has been through I'm confident RadioLib isnt "buggy" and its probably me.

The board in question has a single ANT pin, which I believe is switched between RFO and PA automatically (i've tried 17dB (RFO) and 20dB (PA)) separately to avoid issues here with no behaviour difference.

I'm going to get a power meter on it soon and report back

Re Sync Word, does it matter? I thought I could use anything other then 0x34 (reserved for LoRaWAN)

[trullock]

OK I'm a moron, im calling begin() after setting all the settings, so theyre being defaulted back.

Would be nice if the settings that are overridden in the default params of begin() threw or at least warned if theyre called before begin()

[jgromes]

im calling begin() after setting all the settings

Perhaps next time start by sharing all your code ;)

Would be nice if the settings that are overridden in the default params of begin() threw or at least warned

That creates a lot of corner cases that would have to be handled. For example, you could call begin() and then at some point reset() - should the configuration methods warn at this point?

The board in question has a single ANT pin, which I believe is switched between RFO and PA automatically

That seems unlikely, it would require additional RF combiner (so that the output from RFO is not sent back to PA output and vice-versa). In all off-the-shelf boards I have seen, only one of them is selected and the other one is left floating.

Re Sync Word, does it matter? I thought I could use anything other then 0x34 (reserved for LoRaWAN)

That's hard to say for certain, it's not a sync word in the classic sense (a binary sequence after preamble to distinguish start of packet and different networks). Different LoRa sync words do not actually guarantee that the packet will not be received/passed into the user application as if the sync word had matched, so it seems it has some impact on sensitivity.

[trullock]

Thanks for all your help, I really appreciate it

If sync-word is as you say, what is the proper way to separate "your" messages from "mine"?

[HeadBoffin]

There is no 'proper' way, it's up to you and your payload, but typically it's some magic words at the beginning & possibly the end - two bytes is usually enough at the front and if you want to, two at the end. Then add a CRC check, again 16bit should be enough. If the payload format has some meta data that you can reliably identify then that usually suffices as magic words.

Other useful elements mirroring LoRaWAN techniques include a counter that can be checked to ensure you've got a packet that's at least +1. Or timestamp from the devices, again checked it's greater than the previous value rec'd.

Encryption at various levels of security with a CRC allows you to decrypt & check the CRC - or even a CRC on the outside and the inside - are potentially useful.

[trullock]

Thanks for the help.

You mean add my own CRC inside the payload? Or are you refering to the LoRa built-in CRC?