Add LTE SNR to cellular dashboard + redesign of measurement values

[high3eam]

Is your feature request related to a problem? Please describe. Next to RSRP and RSRQ values for cellular readings, it would be great to have SNR readings of the primary cellular cell as well for mobile network measurement analysis.

Describe the solution you'd like Adding a new SNR value to the Cellular Details screen which displays values in db.

Describe alternatives you've considered Netmonster and Cellmapper display SNR values without root as well.

Additional context Reference Signal-Signal to noise ratio values via API (Netmonster app debug screen):

[christianrowlands]

I like the idea of adding SNR to the display. My only concern is that it will take up more vertical screen real estate, but I will play around with different layouts to see if I can fit it in.

[christianrowlands]

Well, it took a lot more work than I was anticipating because of some issues with the Android API (namly the fact that the value is reported wrong in the getAllCellInfo method but correct in the getSignalStrength method), but I have it working. Let me know if you have any thoughts or ideas on how to lay it out better.

[high3eam]

@christianrowlands Wow, that was extremely fast. I think it looks good.

Perhaps I would modify the three gaugemeters for RSRP, RSRQ and SNR and replace them with horizontal bars. Biggest benefit: It would take away less screen real estate. Something like this (please forgive my bad paint skills):

Would like to hear your thoughts.

[christianrowlands]

Yeah, I like those horizontal bars more. Good idea. I will see what I can work up. Thanks!

[christianrowlands]

I worked this up... any thoughts?

[high3eam]

@christianrowlands Looks clean 👍

Do you think it would be a good idea to add units (dB for RSRQ and SNR, dBm for RSRP) in/next to/under the horizontal bars? Because they display just numbers at the moment but the units are different.

Also, perhaps a small tweak, what do you think about centered values? As I understand from the screenshot, the values are white with colored background, next, they get the same color as the bar if there's enough room right next to it and they also follow along the right edge of the colored bar (as seen for the SNR value). Wouldn't it be more pleasing for the eye visually to keep values in the center? Like the other values without bars also do?

Love to hear your opinion.

[christianrowlands]

Good suggestions... I like them both. Here is an updated screenshot

[christianrowlands]

I have also been playing with the colors to improve them a bit. They are certainly better than before, but I am still not super happy with them. They are a bit too bright I think.

[high3eam]

@christianrowlands In my opinion, it looks fantastic now. Easy to see quickly if the reception and channel quality is good or not. Also, the dashboard size is smaller than with the donuts. I also agree with you on the colors, perhaps a darker color tone would fit a little better, but it does not bother me much the way it is at the moment. Thanks! 👍

[high3eam]

@christianrowlands Just tested the debug apk from 2180377 on a Xiaomi 13 Pro on Android 14, I think the new layout looks fantastic.

I think the "/Band" addition next to NR-ARFCN in NR-SA mode is missing, in LTE mode, EARFCN/Band is the description of the field.

Missing "/Band" in NR-SA mode

---

Additionally, since there is no gnb id displayed in NR-SA mode and there are different gnb id lengths defined by 3GPP, I was wondering if it would be possible to implement an option in settings to set the gnb id length for a specific operator. Like: The user enters a PLMN and can define the appropriate gnb id length (e.g. 24+12). That way, a correct gnb id and sector id could be displayed on the NR dashboard and even logged to csv/geopackage.

Cellmapper does this, too, but not in an elegant way (reports by users to Cellmapper admins -> hardcoded lengths baked into source code).

What do you think? Should I open a separate request for that?

[christianrowlands]

Good catch on the missing "/Band". I will fix that.

Thanks for testing out the changes. I am kind of impressed you knew where to go look for the APK!

As for the gnb id, I have wanted to get that displayed for NR since I added support for it but that variable length has made it hard. There is an issue open with Google to add support in their API to get the number of bits associated with the gnb id, but I doubt they are going to add that: https://issuetracker.google.com/issues/319966463

Where do you typically look up the provider specified gnb id length?

Yes, I could add a setting that takes in a map of PLMNs and corresponding bit length of the gnb id. Let me think through how I want to accomplish this.

I really wish that NR was the same as LTE and it was a fixed length. I am not sure the added complexity is worth it, but 🤷

[high3eam]

@christianrowlands Some id lenghts from providers in Germany are known to the public due to insiders. So I use these. I do not think this is something that can be calculated from Signaling. IIRC a flag that advertises the specific id length is in progress or has been specified already in Release 17 (TS 38.331 -> gNB-ID-Length-Reporting-r17), but I haven't seen it configured by any operator, yet:

gNB-ID-Length-Reporting-r17 Table of flags

In Network Signal Guru for example, the developers have also added an option to set a custom id length:

Custom id length in Network Signal Guru

Nevertheless, this is information that I normally only get from network operators directly. So I think that a custom map or table for the id length is the best option at the moment so that users can define their own. And I agree with your last two sentences 😅

Btw. for my own calculations from CellID to different id lengths, I use tools such as cidresolver.truong.fi at the moment.

[christianrowlands]

Thanks for the screenshot of Network Signal Guru. I had not heard of that app, and it looks pretty cool. It seems that they were able to do what I was not and get diag access on newer devices such as the Pixel 6 (although to be fair, I actually stopped trying at the Pixel 5... I guess I should have kept going). I might have to revive NS+ and try it on a Pixel 6.

I will work something up for the custom map setting and see how it works. And since I am doing that, I might as well update the cellular calculators portion of NS to include an NR gnb id calculator (I have one for LTE already). That CIDResolver calculator link you provided is very nice; I might try to mimic that in the NS calculators. 😉

[high3eam]

@christianrowlands Honestly, I'd be very interested in testing/debugging NS+ (rooted) with both my rooted Xiaomi devices (12T Pro and 13 Pro). Modem level values are much more reliable than API ones.

[christianrowlands]

You should give it a shot as it is right now. I had a random person submit a PR to add support for the Xiaomi 9T device a couple months back. I was not able to test it myself since I don't have that device, but I am guessing they got it working. Here is the code change they submitted: https://github.com/christianrowlands/android-network-survey-rooted/commit/84654bc8761a4d6fc5c75c49f4b7d4c3604880cb

As of right now the app is INCREDIBLY basic. You can't even view the values in the app. Instead, it logs the raw SIBs and other over the air messages to a pcap file, and then you open the pcap file in wireshark to look at the data.

[pm4rcin]

@christianrowlands when we talk about the layout. When you scroll down to see neighbors and e.g. there's 2 of them present and then some more are appended to that list even though you are at the bottom it's not automatically scrolled down but screen stays at the same position which IMO is inconvenient. If you don't get what I mean I can send video.

[high3eam]

@pm4rcin I think I get what you're saying. This could be solved either by configuration of static height for neighbor area, or by "attaching" to the bottom, if the user already scrolled to the bottom at the last touch input. Not sure what is the best approach, I kind of like the static height idea, so that a defined max. amount of neighbor cells can be displayed at any given time, for example 8 max.

[christianrowlands]

Yeah, good point @pm4rcin . I have run into this as well where I keep having to scroll down to monitor the neighbors.

I like both solutions that you came up with @high3eam , and I am leaning towards attaching it to the bottom if the user has scrolled to the bottom. This seems to match a lot of other similar examples I can think of such as logcat or a terminal. The fixed height would also work, but I don't really want to have another scrollview inside of the other scroll view since that tends to make a bad UX.

[christianrowlands]

I went ahead and implemented the "attach" to the bottom when you are scrolled all the way down. It does make the top view jump around a bit, but you can easily stop it by scrolling up just a pinch. If after you both try it out it bothers you then I can look at a fixed neighbor height, or some other solution.

[high3eam]

@pm4rcin Debug-Artifact Download. Works great in practice. De-Attaching mechanism is simple by swiping up a little. I like it so far.

[pm4rcin]

That's what I asked for. Works fine on my end. Another thing that is not present is that the app doesn't show 5G-NSA but it only shows LTE on Data Network. It could be done because an app Privacy Cell can show it. Also the GPS module looks like taken straight from the GPSTest but it's not fully up-to-date because it lacks SouthPAN (Australia / New Zealand) SBAS satellites. Also the the Avg C/NO signal indicator on SkyView just doesn't move no matter if signal is really good or bad it stays on the same position.

[high3eam]

@pm4rcin I think it's time for a separate issue for all these additional things, just to keep track of all the feedback :)

[christianrowlands]

Agreed @high3eam .

@pm4rcin , I created new issues for each item you brought up. I will respond with comments there.

[christianrowlands]

I am closing this issue now that the new ones are created. Let me know if I missed anything from this thread, and thank you both for the suggestions!