Micropython/lora, how do RSSI readings work?

[davefes]

I seem to hit a limit of -110dBm when various errors start creeping-in. I never see anything less than -110dBm. I worked-out how to turn rx_boost on "lna_boost_hf":"rx_boost" ... no change. Resetting the board the first RSSI reported is always -115dBm then reads -110dBm even when moving the units further apart. Tried various sf values at a bw = 125kHz

With other software on the same Hope Radio RFM96W and same STM32F411 dev board I would get down to -120dBm before errors became noticeable (sf = 8, bw = 125kHz).

Any hints on what I should expect would be helpful.

[davefes]

Interrupts allow reduced power consumption and may also improve receive sensitivity (by removing SPI bus noise during receive operations.)

I have both dio0 and dio1 connected. Where has that 10+dB disappeared to? I am also looking at RSSI at the receiver-end and generally they are within +/-1dB

[davefes]

Digging into the RSSI code for three Lora implementations I find:

in Wei's LoRa

def packetRssi(self):  # REG_PKT_RSSI_VALUE = 0x1a
    return (self.readRegister(REG_PKT_RSSI_VALUE) - (164 if self._frequency < 868E6 else 157))

in ulora:

rssi = self._spi_read(0x1a)  # REG_1A_PKT_RSSI_VALUE
if snr < 0:
    rssi = snr + rssi
else:
    rssi = rssi * 16 / 15

if self.freq >= 779:
    rssi = round(rssi - 157, 2)
else:
    rssi = round(rssi - 164, 2)

in micropython/lora

# units: dBm
rx_packet.rssi = self._reg_read(_REG_PKT_RSSI_VALUE) - (157 if self._pa_boost else 164)

1. Looks like Wei uses 868MHz to change an offset.
2. ulora modifies the REG_1A_PKT_RSSI_VALUE by 16/15 and uses 797MHz for the offset change
3. micropython/lora modifies the _REG_PKT_RSSI_VALUE dependent on PA_BOOST

For the Hope Radio RF96 (RFM96W) PA_BOOST covers all frequency bands that the frequency synthesizer addresses. I do not understand why RSSI would need changing dependent on PA_BOOST ... unless other chips can/can not use PA_BOOST.

That 16/15 in ulora at -110dBm would give a reading of 16/15 * -110 = -117dBM. I don't know if that is documented or a fudge value to get more "accurate" readings.

At the end of the day it will be the actual range and resultant packet loss that is important. However, it would be nice to know why at a Packet Error Rate (PER)= 1%, that the displayed values of -108/109dBm are about 27/28dB worse than manufacturer's specs.

[mendenm]

Historically, RSSI is total received signal + noise, not 'useful' signal. Maybe you have a lot of interference, so even though the RSSI is around -110 dB, the noise floor is the same. Can you check for interference sources?

[davefes]

@mendenm One of the things I tried was shifting the test system away from the house. We are off-grid in a remote location, possibly 4-5 WiFi routers within a kilometre radius (3 of them mine).

Your comment about RSSI ... an observation when using ulora was that when the RSSI got down to -120dBm the SNR went from 0 to a very large negative value, ie -60. I would have thought that when RSSI was say -130dBM that the SNR would be -10dB. However, this is a side-issue as I want to move my LoRa links to using micropython/lora to get reliable_delivery.

[davefes]

Found yet another RSSI implemenation:

    def packetRssi(self, rfi="hf"):
        packet_rssi = self.readRegister(REG_PKT_RSSI_VALUE)
        return packet_rssi - (157 if rfi == "hf" else 164)

Ignoring ulora's approach of calculating RSSI when SNR <0 it seems that this 157/164 is frequency-based not related to PA_BOOST state. The RFM96W datasheet section 5.5.5. RSSI in LoRaTM Mode does mention that these values need tweaking depending on lna_boost etc.

[projectgus]

After @davefes also opened this issue:
micropython/micropython-lib#770

... this was confirmed as a bug in the micropython-lib driver.

(I just saw this discussion now.)