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

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

_rm — Thu, 19 Sep 2024 08:57:59 GMT

i made a ticket

regards

richard

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

Elfving — Thu, 19 Sep 2024 08:50:08 GMT

Understood.

[quote user="_rm"]

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.

[/quote]

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

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

_rm — Wed, 18 Sep 2024 19:29:16 GMT

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

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

Elfving — Wed, 11 Sep 2024 12:15:39 GMT

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

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

_rm — Mon, 02 Sep 2024 13:48:00 GMT

great, looking forward to that.

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

Elfving — Mon, 02 Sep 2024 12:10:01 GMT

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

Thanks again for the report.

Regards,

Elfving

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

Elfving — Thu, 22 Aug 2024 13:40:03 GMT

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

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

Elfving — Thu, 22 Aug 2024 12:30:19 GMT

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

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

_rm — Fri, 16 Aug 2024 12:36:45 GMT

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

a) the overlap

b) the actual behaviour

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

helsing — Fri, 16 Aug 2024 10:06:17 GMT

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.

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

helsing — Fri, 16 Aug 2024 09:20:22 GMT

Hi Richard,

We are looking into this and will get back to you.