• State Not Answered
  • Replies 11 replies
  • Subscribers 69 subscribers
  • Views 515 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 331614
Options

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

_rm
/**
* 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
what is the actual behaviour?
Parents
  • 0
    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.
  • 0 in reply to helsing

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

    a) the overlap 

    b) the actual behaviour

  • 0 in reply to _rm

    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

  • 0 in reply to _rm

    Hello again,

    So the overlap is a mistake. It unfortunately likely got that way when we slowly got support for lower and lower values. Thanks for pointing this out to us!

    When it comes to the behavior, it is likely a similar problem in the code and not just the documentation. So eg. either the value 0 or -1 is used for RSRP between -141 dBm and -140 dBm. In any case, this does not look like a big issue to me, as you can essentially interpret values 0 and -1 in the same way, right?

    Regards,

    Elfving

Reply
  • 0 in reply to _rm

    Hello again,

    So the overlap is a mistake. It unfortunately likely got that way when we slowly got support for lower and lower values. Thanks for pointing this out to us!

    When it comes to the behavior, it is likely a similar problem in the code and not just the documentation. So eg. either the value 0 or -1 is used for RSRP between -141 dBm and -140 dBm. In any case, this does not look like a big issue to me, as you can essentially interpret values 0 and -1 in the same way, right?

    Regards,

    Elfving

Children
  • 0 in reply to Elfving

    This should be fixed in upcoming version of NCS and MFW.

    Thanks again for the report.

    Regards,

    Elfving

  • 0 in reply to _rm

    Hello again Richard,

    Just a quick update. It turns out that the AT command specification follows the RSRP and RSRQ values specified by 3GPP TS 36.133 chapters 9.1.4 and 9.1.7. Because these values come directly from the 3GPP specifications, we’re most likely not going to change the AT command specifications or the LTE LC API. 

    This might be an error in the spec. The way it’s currently specified is ambiguous. It is hard to know if this is intentional or not.

    Either way, like I mentioned earlier, this would must likely not be a practical problem. If you believe the way it currently is will turn into an issue for you and your application, please let me know.

    EDIT: Okay, there will be an update after all, but we are unsure about when it will be done.

    Regards,

    Elfving

  • 0 in reply to Elfving

    Thanks for the update.

    you can see in another post that using the location lib to directly resolve raw location values to lat,lon position via nrfcloud/here calls from the device is not the approach I follow. Therefore handling the raw values myself became a topic.

    I can not estimate how big the position error can become through the value glitch and when I explain what I developed I feel uneasy to say: I just ignored some points and can't give any estimation for the effects of ignoring these points. 

    Also i just want to understand.

    For that reason I also would be happy to read more about the calculations nrfCloud does to derive lat,lon,precision from cells and wifi.  

    Best regards

  • 0 in reply to _rm

    Understood.

    _rm said:

    For that reason I also would be happy to read more about the calculations nrfCloud does to derive lat,lon,precision from cells and wifi.  

    For that request it would be better if you could create another DevZone ticket. We try to keep the tickets tidy here by having them focused on one topic each.

    Regards,

    Elfving

Related