mroczis / netmonster-core

Android Telephony SDK bridge with some additional features
Apache License 2.0
334 stars 71 forks source link

Handle invalid LTE RSSI? #77

Closed handymenny closed 8 months ago

handymenny commented 1 year ago

Some devices (especially Samsung devices) may report an LTE RSSI equal or very similar to RSRP, which cannot be a valid value. Some apps in these cases don't report the RSSI value at all or allow the user to replace it with a calculated value.

The first question is how to figure out that RSSI is invalid. I would consider RSSI invalid if RSSP >= RSSI (strict check) or if RSRP - RSSI > RSRQ_MAX (relaxed check)

Then for how to calculate it, if that is the path you want to follow for this library, this formula can be used: RSSI = 10 * log(N) + RSRP - RSRQ Where N is the number of resource blocks. N can be derived directly from the bandwidth, common values are 6, 50 (10MHz), 75 (15MHz), 100 (20MHz). 6 could be used for neighbour cells in some cases, but shouldn't be used for serving cells.

And now comes another question, what if BW isn't available? An average value could be used, e.g. 75. Or an average value according to frequency, e.g. 50 for low bands, 75 for mid bands, 100 for high bands.

Should this kind of post-processing be in netmonster core?

qquiderr commented 1 year ago

on tmobile czech show 20MHz on band 800 or 700, in O2 czech sometimes show BW 15 on 700 or 800.

qquiderr commented 1 year ago

Wrong BW on tmobile: https://ibb.co/zZHjtR1 https://ibb.co/KW4BdHd

and some BW is missing https://ibb.co/Y773gG8 its 3CC, but shows 20+15 (2100+1800) and missing + 10 for 700.

mroczis commented 8 months ago
  1. RSSI, RSRP issue Rules you mentioned do work in theory. Unfortunately values provided by each device may vary. Meaning that some devices do report false-positive RSSI, RSRP, RSRQ values. If you need to be sure about data validity then I'd advise looking for some professional device that guarantees validity of measurements (= not an Android device). I was already playing with formula you mention but it did fit only in 10 percent of all measurement (assuming I know RSSI, RSRP, RSRQ and bandwidth).

  2. Bandwidth issue NetMonster (Core) consumes public data from the device and such data are updated asynchronously (by the system). Meaning that at one point device can update cell information and after some period of time bandwidth info. NetMonster "glues" them together and shows. All data are real-time. There's no guarantee that provided data are 100 % correct.

Generally - if you need reliability, you need to find another device that does not mess up with data. Generally devices with Exynos (and Google Tensor) processors do perform worse compared to Qualcomm.

handymenny commented 8 months ago

I see your point. it's just that in some cases end users prefer "guessed" data to completely invalid data. if I wanted accurate data I wouldn't have opened this issue :)