there seems to be an overlap problem for rsrp and for rsrq in documentation and code comments

[_rm]

looking at  https://github.com/nrfconnect/sdk-nrf/blob/main/include/modem/lte_lc.h

/**
* RSRP.
*
* * -17: RSRP < -156 dBm
* * -16: -156 ≤ RSRP < -155 dBm
* * ...
* * -3: -143 ≤ RSRP < -142 dBm
* * -2: -142 ≤ RSRP < -141 dBm
* * -1: -141 ≤ RSRP < -140 dBm
* * 0: RSRP < -140 dBm
* * 1: -140 ≤ RSRP < -139 dBm
* * 2: -139 ≤ RSRP < -138 dBm
* * ...
* * 95: -46 ≤ RSRP < -45 dBm
* * 96: -45 ≤ RSRP < -44 dBm
* * 97: -44 ≤ RSRP dBm
* * @ref LTE_LC_CELL_RSRP_INVALID : not known or not detectable
*/
int16_t rsrp;

/**
* RSRQ.
*
* * -30: RSRQ < -34 dB
* * -29: -34 ≤ RSRQ < -33.5 dB
* * ...
* * -2: -20.5 ≤ RSRQ < -20 dB
* * -1: -20 ≤ RSRQ < -19.5 dB
* * 0: RSRQ < -19.5 dB
* * 1: -19.5 ≤ RSRQ < -19 dB
* * 2: -19 ≤ RSRQ < -18.5 dB
* * ...
* * 32: -4 ≤ RSRQ < -3.5 dB
* * 33: -3.5 ≤ RSRQ < -3 dB
* * 34: -3 ≤ RSRQ dB
* * 35: -3 ≤ RSRQ < -2.5 dB
* * 36: -2.5 ≤ RSRQ < -2 dB
* * ...
* * 45: 2 ≤ RSRQ < 2.5 dB
* * 46: 2.5 ≤ RSRQ dB



there seems to be an overlap problem for rsrp and for rsrq

* * -1: -141 ≤ RSRP < -140 dBm
* * 0: RSRP < -140 dBm

* * -1: -20 ≤ RSRQ < -19.5 dB
* * 0: RSRQ < -19.5 dB

see also https://docs.nordicsemi.com/bundle/ncs-2.4.3/page/nrf/libraries/modem/lte_lc.html , ... 

what is the actual behaviour?

[helsing]

The assignment of '0' to RSRP when it's less than -140 dBm and to RSRQ when it's less than -19.5 dB is a design choice made to handle extreme cases where the signal quality is poor. This approach simplifies the handling of extreme cases by grouping them into a single category ('0' in this case), probably making it easier to identify and handle poor signal quality situations in the code.

For RSRP, any value less than -140 dBm is considered bad, indicating a weak signal. Similarly, for RSRQ, any value less than -19.5 dB is considered bad, indicating poor signal quality. By assigning '0' to these ranges, it probably allows for a simplified way to quickly identify these poor signal conditions.

[_rm]

well,  this doesn't answer any part of my question.

a) the overlap 

b) the actual behaviour

[Elfving]

Hello Richard, and sorry about the delay. Håkon is currently a bit busy, so I will handle this case in the meantime. 

I do not know much about this subject myself, but I do see the overlap that you are referring to. I've forwarded your inquiry to the appropriate team, and will let you know once I hear from them.

Regards,

Elfving