RSSI when snr>0

[manvendra88]

Updated packetRSSI
(RSSI=-139+16/15*PacketRssi) for cases when snr>0
[https://www.mouser.com/ds/2/761/sx1276-1278113.pdf, Section 5.5.5 Note-3]

[sergio303]

I think this PR is wrong. packetSNR correction should be applied when SNR < 0, from the pdf:

Packet Strength (dBm) = -157 + PacketRssi + PacketSnr * 0.25 (when using the HF port and SNR < 0)

Also HF and LF port midband threshold is not 868E6, more likely 525E6 or any other freq between bands but not IN bands. Take a look at Semtech's reference code:

                    int16_t rssi = read_register( REG_LR_PKTRSSIVALUE);
                    if (snr < 0) {
                        if (_rf_settings.channel > RF_MID_BAND_THRESH) {
                            _rf_settings.lora_packet_handler.rssi_value =
                                    RSSI_OFFSET_HF + rssi + (rssi >> 4) + snr;
                        } else {
                            _rf_settings.lora_packet_handler.rssi_value =
                                    RSSI_OFFSET_LF + rssi + (rssi >> 4) + snr;
                        }
                    } else {
                        if (_rf_settings.channel > RF_MID_BAND_THRESH) {
                            _rf_settings.lora_packet_handler.rssi_value =
                                    RSSI_OFFSET_HF + rssi + (rssi >> 4);
                        } else {
                            _rf_settings.lora_packet_handler.rssi_value =
                                    RSSI_OFFSET_LF + rssi + (rssi >> 4);
                        }
                    }

RF_MID_BAND_THRESH is 525E6 and offsets are -164 and -157.

[manvendra88]

Correct me if I am wrong. The following snapshot is for the correction of packetStrength for snr<0 which is different from the RSSI. Maybe, we can incorporate a function for it in this library.

The point I am concerned about is the RSSI value for the cases when the transmitter is close to the receiver. In other words, when signal strength is above -80 dBm or so. For this, on the same page, in the note, the doc has specified the RSSI correction when snr>0.

Lora-net/LoRaMac-node#420 : Here is the discussion on the same in LoRaMac library.

Correct me if I am wrong. :)

[sergio303]

I think the documentation is a bit confusing on this. My understanding is that there are two registers RegPktRssiValue (0x1A) and RegRssiValue (0x1B) working like this:

It seems RegRssiValue is an instant RSSI value meant to be used by sampling it during packet reception and offers better linearity and precision. Due to difficult implementation (you'd have to detect packet start and end via ValidHeader and RxDone IRQs and do the sampling and averaging in code) I have not seen any driver implementation using this approach.

On the other hand RegPktRssiValue offers an averaged RSSI value of the last packet received, calculated by the chip itself. In the documentation the RSSI value calculated from this register is called PacketStrength (I think to differentiate it from the RSSI value you could calculate from the RegRssiValue register) but, in practice, this register is what is used to calculate the "RSSI" value on all driver implementations.

Now, about calculating RSSI from RegPktRssiValue:

• Value has to be corrected by an offset (-157 for the HF port and -164 for the LF port). Threshold used to differentiate ports is wrong in actual implementation, causing a 7db RSSI jump on 868E6 freq.

• if SNR < 0 it should be further corrected by adding the SNR value (PacketSnr * 0.25). I have some doubts if SNR should be converted to a positive value before adding it, or is added as a negative value effectively decreasing the RSSI. Will check implementations from Semtech and LoRaWAN lmic to see how they have coded this.

• if RSSI is strong (>-100dBm), linearity is not guaranteed on the RSSI value we get from RegPktRssiValue register. I think the documentation here switches from PacketStrength naming to RSSI naming. To address this, the slope can be corrected by multiplying the RegPktRssiValue by 16/15. According to docs this is done when SNR >= 0, but Semtech code implementation does this correction for all SNR values, maybe code is wrong or it does not matter much and is a simplification.

I'll take a look at different implementations and see if I can draw further conclusions, but when in doubt I think a good idea is to mimic Semtech code behaviour, as the docs are not very clear on some aspects.

[morganrallen]

@sergio303 thank you very much for this detailed research, my time has been pretty tight lately and this is an extremely helpful overview. Let us know what your additional research yields and hopefully the three of us can get a solid solution together in the next week or two.

[sergio303]

after taking a look at project LoRaMac-node (where Semtech people maintain code and response to issues), I think I've found an issue response by Semtech that clarifies this:

Lora-net/LoRaMac-node#143

Looking at point 2, it seems like datasheet specification is incomplete (overlooking situations where RSSI is high and SNR is negative), and the recommended approach is to apply the 16/15 scaling factor for all SNR values. I've checked and that's the way it's implemented in latest Semtech drivers.

I'll submit a PR on the coming days implementing this approach. Also, does it make sense in the library to have packetSnr as a float ? just a fast bit shift would suffice to divide register by 4, but changing it may break code using the library, don't know if I should change this.

[IoTThinks]

When I start to enable LNA, in some cases, SNR < 0.
So I look again this PR.

LoRaMac has not changed the calculation yet.
https://github.com/Lora-net/LoRaMac-node/blob/master/src/radio/sx1276/sx1276.c#L1151

However, RadioLib changed the calulation.
https://github.com/jgromes/RadioLib/blob/master/src/modules/SX127x/SX1278.cpp#L403

Hence, when SNR < 0, the RSSI is reduced, too.

@morganrallen @sandeepmistry : Should we fix this?
This PR seems wrong to me, btw. Should fix for snr < 0.

[sandeepmistry]

@IoTThinks after reading @manvendra88's comment in #291 (comment) I believe there is some confusion. Here is my understanding, please correct me if I am misunderstanding something.

1. For packet RSSI when SNR >= 0:

rssi = -157 + 16/15 * PacketRssi
or
rssi = -164 + 16/15 * PacketRssi

This would be an improvement if "very good RSSI precision is needed ..."

2. There could be a new API for packet strength, however it seems this pull request is changing the packet RSSI to now be packet strength.

[IoTThinks]

I see your point.

Normally, RSSI implies packet strength.
Semtexh would want to take SNR into account to better estimate of packet strength. However, they don't want to mess up the RSSI meaning.

If snr > 0, Packet Strength = Packet RSSI
Else if snr < 0, Packet Strength = Packet RSSI + SNR.

Wondering how much SNR can go low below 0?
"High sensitivity: down to -148 dBm"

So SNR can go down until -148 dBm?

If yes, then the Packet Strength can go down to -200.