SignalCheck - Android app to monitor your Wi-Fi/2G/3G/4G LTE/5G-NR signal strengths

[mc_gusto]

Maybe try checking this out?

http://www.phonearena.com/news/AMOLED-Burn-in-Fixer-promises-an-easy-fix-for-your-Android-smartphone-screens-pesky-burn-in-issues_id64344

 

Came out two days ago...

It's been out for awhile. I've used it several times overnight full brightness. And my screen still looks like this

 

 

Sent from my LGLK430 using Tapatalk

[WiWavelength]

It's been out for awhile. I've used it several times overnight full brightness. And my screen still looks like this

 

AMOLED!  Hello, AMOLED...

 

 

AJ

[EvanA]

Signal check had issues identifying some 10x10 I hit in central IL.

 

 

 

[jeffcarp]

I'm seeing something new in my neighborhood and not sure what to make of what SignalCheck says it is. It's reporting it as 1xRTT which historically would mean horrible performance in the pre NV 2.0 days but my speed test is decent. What am I seeing here?

 

 

[Galaxyguy]

I'm seeing something new in my neighborhood and not sure what to make of what SignalCheck says it is. It's reporting it as 1xRTT which historically would mean horrible performance in the pre NV 2.0 days but my speed test is decent. What am I seeing here?

 

 

That's the infamous android bug. Theres a lot of info on it earlier in this thread. You are truly on LTE, not 1x.

 

Sent from my Note 4

[ingenium]

An update to CellMapper just came out, and it added a new root feature for Qualcomm devices to fetch the band information directly from the modem. No need to deduce it from the GCI. As a result, it also shows the band info for neighbor cells. It works using the "default" device on my Nexus 6P,  /dev/smd11

 

Might be worth investigating to see if this can be used to get more detailed information than what is provided by the Android API. And also to perhaps get around the 1x + LTE bug or stale data. 

[EvanA]

 

 

Might be worth investigating to see if this can be used to get more detailed information than what is provided by the Android API. And also to perhaps get around the 1x + LTE bug or stale data.

I'm sure it can provide more detailed data, but since root is required to read it, I doubt it's worth the time and effort for Mike to implement. I doubt most people who use signal check have rooted devices.

[ingenium]

I'm sure it can provide more detailed data, but since root is required to read it, I doubt it's worth the time and effort for Mike to implement. I doubt most people who use signal check have rooted devices.

 

That depends on the devices being used. For Nexus devices, it's easy to root, and you can even still accept OTAs while rooted using FlashFire.

 

Using /dev/smd11 also allows looking up the EARFCN, which is huge! The Nexus 6P for example doesn't have a functioning engineering screen, but using CellMapper I can now finally lookup the EARFCN (I verified it is reporting the correct values). I suspect CA status may also be available. If so, that would certainly be a valuable addition to SCP. I think a decent number of users would root to be able to have the EARFCN and CA status in their SCP logs. Especially those of us without functioning engineering screens.

 

Screenshot showing some of the data available: https://plus.google.com/+IvanZupan/posts/3aXM3Y6QCC2

 

EDIT: I watched that interface while CellMapper was running, and it appears to be issuing a standard modem AT command ("AT$QCRSRP?"). It looks like it returns a list of neighboring cells and their EARFCN:

root@angler:/ # dd if=/dev/smd11 bs=10000 count=100                            

$QCRSRP: 018,8763,"-095.20",117,8763,"-090.50",025,8763,"-099.20",000,8665,"000.00",000,8665,"000.00",057,40056,"-140.00",000,40056,"000.00"

OK
AT$QCRSRP?
$QCRSRP: 117,8763,"-092.50",018,8763,"-095.80",025,8763,"-102.70",465,8665,"-097.70",223,8665,"-107.60",000,8665,"000.00",000,8665,"000.00",156,40056,"-102.90"

OK
AT$QCRSRP?
$QCRSRP: 117,8763,"-092.40",018,8763,"-094.80",025,8763,"-109.60",465,8665,"-097.70",223,8665,"-107.60",000,8665,"000.00",000,8665,"000.00",156,40056,"-102.90"

OK
AT$QCRSRP?
$QCRSRP: 117,8763,"-092.40",018,8763,"-095.80",025,8763,"-100.50",465,8665,"-097.70",223,8665,"-107.60",000,8665,"000.00",000,8665,"000.00",156,40056,"-102.90"

OK
AT$QCRSRP?
$QCRSRP: 117,8763,"-092.50",018,8763,"-094.70",025,8763,"-108.00",465,8665,"-097.70",223,8665,"-107.60",000,8665,"000.00",000,8665,"000.00",156,40056,"-102.90"

OK
AT$QCRSRP?
$QCRSRP: 117,8763,"-092.70",018,8763,"-094.40",025,8763,"-108.20",465,8665,"-097.70",223,8665,"-107.60",000,8665,"000.00",000,8665,"000.00",156,40056,"-102.90"

OK
AT$QCRSRP?
$QCRSRP: 117,8763,"-092.60",018,8763,"-095.70",025,8763,"-107.80",465,8665,"-097.70",223,8665,"-107.60",000,8665,"000.00",000,8665,"000.00",156,40056,"-102.90"

OK
AT$QCRSRP?
$QCRSRP: 117,8763,"-092.90",018,8763,"-094.00",025,8763,"-099.50",465,8665,"-097.70",223,8665,"-107.60",000,8665,"000.00",000,8665,"000.00",156,40056,"-102.90"

OK
AT$QCRSRP?
$QCRSRP: 117,8763,"-092.50",018,8763,"-094.70",025,8763,"-099.90",465,8665,"-097.70",223,8665,"-107.60",000,8665,"000.00",000,8665,"000.00",156,40056,"-102.90"

OK
AT$QCRSRP?
$QCRSRP: 117,8763,"-093.80",018,8763,"-094.30",025,8763,"-101.30",465,8665,"-097.70",223,8665,"-107.60",000,8665,"000.00",000,8665,"000.00",156,40056,"-102.90"

OK
AT$QCRSRP?
$QCRSRP: 117,8763,"-093.50",018,8763,"-095.50",025,8763,"-097.40",465,8665,"-097.70",223,8665,"-107.60",000,8665,"000.00",000,8665,"000.00",156,40056,"-102.90"

OK
AT$QCRSRP?
$QCRSRP: 117,8763,"-092.90",018,8763,"-093.30",025,8763,"-101.80",465,8665,"-097.70",223,8665,"-107.60",000,8665,"000.00",000,8665,"000.00",156,40056,"-102.90"

OK
AT$QCRSRP?
$QCRSRP: 117,8763,"-094.00",018,8763,"-094.30",025,8763,"-108.80",465,8665,"-097.70",223,8665,"-107.60",000,8665,"000.00",000,8665,"000.00",156,40056,"-102.90"

OK
AT$QCRSRP?
$QCRSRP: 117,8763,"-092.90",018,8763,"-095.00",025,8763,"-096.00",465,8665,"-097.70",223,8665,"-107.60",000,8665,"000.00",000,8665,"000.00",156,40056,"-102.90"

OK
^C0+28 records in
0+28 records out
2501 bytes transferred in 34.785 secs (71 bytes/sec)

Each response appears to be PCI, EARFCN, RSRP, PCI, EARFCN, RSRP, PCI, EARFCN, RSRP, etc. I THINK the first one in the list is the site that it's currently connected to. This should be pretty easy to add into SCP. Now, the question is if there are other modem commands that would return CA status... The full list of AT commands can be found at the bottom of this post, including the Qualcomm specific additions: http://forum.xda-developers.com/showpost.php?p=53508236&postcount=268 There may be new commands that have been added since that was posted.

[jeffcarp]

That's the infamous android bug. Theres a lot of info on it earlier in this thread. You are truly on LTE, not 1x.

 

Sent from my Note 4

I see. Thank you. Some of these threads get so long it's hard to sort through. Am I on a particular band when this bug occurs?

[Trip]

I'm sure it can provide more detailed data, but since root is required to read it, I doubt it's worth the time and effort for Mike to implement. I doubt most people who use signal check have rooted devices.

 

I just rooted my LG Leon LTE (T-Mobile) to test it and it does work.  He already has airplane mode toggle, a root-only function, in the software.  And for T-Mobile with its complete lack of consistency on the sector ID with respect to Band, this would be a huge help.

 

I'm another vote in favor.

 

Now to see if I can root the Moto E I have for Verizon...

 

- Trip

[Dkoellerwx]

I see. Thank you. Some of these threads get so long it's hard to sort through. Am I on a particular band when this bug occurs?

Nope. When you briefly lose them reacquire LTE, many devices running Android 5.1+ will indicate a simultaneous 1x and LTE connection for a time. Whether this is actually a bug or not is unclear. It's theorized this has something to do eCSFB issues while connected to a weak LTE signal. While this is happening, SCP is not able to pull current GCI, PCI or TAC values so the band indicator does not work.

 

Sent from my Nexus 5 using Tapatalk

[jeffcarp]

Nope. When you briefly lose them reacquire LTE, many device running Android 5.1+ will indicate a simultaneous 1x and LTE connection for a time. Whether this is actually a bug or not is unclear. It's theorized this has something to do eCSFB issues while connected to a weak LTE signal. While this is happening, SCP is not able to pull current GCI, PCI or TAC values so the band indicator does not work.

 

Sent from my Nexus 5 using Tapatalk

That makes a lot of sense. This just started a couple of days ago in a location that I am at every day and has had a very solid 2xCA service for a while. The last couple of days the service has been bouncing all over the place between different bands and even back to 3G so they must be doing something in the area.

[caspar347]

Random feature idea that popped into my head: option to automatically turn on the location service only when connected to a new GCI/site. And when strongest_RSRP/RSSI for the connected site is more than 5dBm stronger than the previous recorded entry the app could temporarily enable location for a set (but adjustable) minimum amount of time to allow for an accurate lock. Could save battery life significantly by keeping location off while a user is connected to their usual sites but still maintain very high log accuracy and capture new sites etc. You could even make the dBm cutoff adjustable.

 

I don't know if something like this is feasible but it would be pretty cool.

[Sim-X]

Updated my Sprint M9 to latest MM build this weekend. The "Reset Mobile Connection" button appears to no longer function. It did prompt for root access which I granted of course, adjusted the delay time to 8000ms (from the default 4000). Checked SuperSU root has been granted just isn't working. Worked fine on previous build. Is this a known issue? I actually used it on a some what regular basis.

 

Everything else seems to be working fine, I mainly use the Widget on my home screen. I do block the notification in the status bar as the settings don't let me turn it off. I like to keep my status bar clean.

[mikejeep]

An update to CellMapper just came out, and it added a new root feature for Qualcomm devices to fetch the band information directly from the modem. No need to deduce it from the GCI. As a result, it also shows the band info for neighbor cells. It works using the "default" device on my Nexus 6P,  /dev/smd11

 

Might be worth investigating to see if this can be used to get more detailed information than what is provided by the Android API. And also to perhaps get around the 1x + LTE bug or stale data. 

 

That is huge! I'm struggling to find time to dig into app-related things lately (life is good, that's all!), but I'll look into it. I would LOVE to get something like this implemented, even if it's only for a limited subset of devices.

 

I'm sure it can provide more detailed data, but since root is required to read it, I doubt it's worth the time and effort for Mike to implement. I doubt most people who use signal check have rooted devices.

 

Not necessarily true. SignalCheck users tend to be on the nerdier side, and many of us just happen to be rooted as well. I don't mind implementing features that require root because it's better than not implementing them at all (i.e. the "Reset" feature and a few other goodies, like direct PRL Updates for some Nexus users).

 

Random feature idea that popped into my head: option to automatically turn on the location service only when connected to a new GCI/site. And when strongest_RSRP/RSSI for the connected site is more than 5dBm stronger than the previous recorded entry the app could temporarily enable location for a set (but adjustable) minimum amount of time to allow for an accurate lock. Could save battery life significantly by keeping location off while a user is connected to their usual sites but still maintain very high log accuracy and capture new sites etc. You could even make the dBm cutoff adjustable.

 

I've been testing out some options to turn on location/logging when plugged in, so this is along the same lines. There are a lot of half-working features like this I'm testing on my own devices. Progress is slow because I'm learning how to code as I go!

 

-Mike

[mikejeep]

Updated my Sprint M9 to latest MM build this weekend. The "Reset Mobile Connection" button appears to no longer function. It did prompt for root access which I granted of course, adjusted the delay time to 8000ms (from the default 4000). Checked SuperSU root has been granted just isn't working. Worked fine on previous build. Is this a known issue? I actually used it on a some what regular basis.

 

Everything else seems to be working fine, I mainly use the Widget on my home screen. I do block the notification in the status bar as the settings don't let me turn it off. I like to keep my status bar clean.

 

Hmm I'm not sure why this would be happening. My Nexus 5X is running 6.0.1 and has no issues. Have you tried clearing SCP's permission out of SuperSU and then re-adding it when prompted?

 

-Mike

[ingenium]

That is huge! I'm struggling to find time to dig into app-related things lately (life is good, that's all!), but I'll look into it. I would LOVE to get something like this implemented, even if it's only for a limited subset of devices.

 

 

Not necessarily true. SignalCheck users tend to be on the nerdier side, and many of us just happen to be rooted as well. I don't mind implementing features that require root because it's better than not implementing them at all (i.e. the "Reset" feature and a few other goodies, like direct PRL Updates for some Nexus users).

 

 

I've been testing out some options to turn on location/logging when plugged in, so this is along the same lines. There are a lot of half-working features like this I'm testing on my own devices. Progress is slow because I'm learning how to code as I go!

 

-Mike

Just saw this post after I replied to your post in the LTE Discovery thread. I'd be happy to help you implement the feature if you want. As I said in that post, feel free to take the code I submitted on github to Signal Detector. It's hopefully commented well enough that you'll be able to follow it. I just threw out the earfcn data for neighbor cells in that implementation because it was more a proof of concept and a little tricky to match up to the PCIs from the Android API (ie B25 and B26 show the same PCI, so you have to guess based on reported signal strength which one to assign the earfcn to)

 

Sent from my Nexus 6P

[mikejeep]

Just saw this post after I replied to your post in the LTE Discovery thread. I'd be happy to help you implement the feature if you want. As I said in that post, feel free to take the code I submitted on github to Signal Detector. It's hopefully commented well enough that you'll be able to follow it. I just threw out the earfcn data for neighbor cells in that implementation because it was more a proof of concept and a little tricky to match up to the PCIs from the Android API (ie B25 and B26 show the same PCI, so you have to guess based on reported signal strength which one to assign the earfcn to)

 

My hero! I would have killed to have read your posts about 8 hours ago.. I've been working on implementing this all day. I have tackled a majority of the issues, but it literally took all morning. Figuring out the exact modem command had me hung up for a bit (escape characters tripped me up but I figured it out after I finished my Cheerios) and I was struggling to figure out the best way to read the response from the appropriate device without choking the phone. Your code takes a slightly different approach than my implementation, but I think there's enough there to get me over the hump. Shame on me for not looking at S4GRU earlier.. I would be done by now. THANK YOU!

 

-Mike

[ingenium]

My hero! I would have killed to have read your posts about 8 hours ago.. I've been working on implementing this all day. I have tackled a majority of the issues, but it literally took all morning. Figuring out the exact modem command had me hung up for a bit (escape characters tripped me up but I figured it out after I finished my Cheerios) and I was struggling to figure out the best way to read the response from the appropriate device without choking the phone. Your code takes a slightly different approach than my implementation, but I think there's enough there to get me over the hump. Shame on me for not looking at S4GRU earlier.. I would be done by now. THANK YOU!

 

-Mike

You're definitely welcome! I initially tried using read commands and doing it all with 1 root shell session, but it kept choking and getting out of sync. The only way I could reliably get it to work was using 2 root sessions, one reading the output of cat line by line looking for one that has the info we want, and the other using echo to issue the commands. If you use cat, remember to call kill() on destruction rather than close(), otherwise it will hang waiting for the shell to be idle which it never will unless you figured out how to terminate the cat command :-) I kept wondering why it would hang then crash any time I tried to disable the feature from the app preferences

 

Sent from my Nexus 6P

[swintec]

does this work on the Nexus 5X with cell Mapper?

[ingenium]

does this work on the Nexus 5X with cell Mapper?

At least one person reported that it does: https://plus.google.com/+IvanZupan/posts/e6vnjWWLppJ

[ingenium]

From the list of devices on this post (https://plus.google.com/+IvanZupan/posts/3aXM3Y6QCC2), it appears to work on the Snapdragon 801, 810, and 410. Reported not working with the Nexus 6 (Snapdragon 805) and Nexus 5 (Snapdragon 800). I find it odd that it works with the 801 but not the 800 or 805. I'm going to have a friend with my old Nexus 6 double check for me and will report back. 

 

Mike, the comments on that post give some more information about the different smd devices used on various phones and might help you out. I particularly found the comment about mknod interesting (learned something new about Linux there!). For what it's worth, on my Nexus 6P /dev/smd11 has major number 224 and minor number 11. Not sure where he came up with major number 245 to test for the Nexus 5... We might have to try to comb through the Android source code for device specific information. The major number should correspond to the kernel driver being used.

 

I did notice though that after running "ls -l /dev/smd*" that /dev/smd11 is the only smd## style file owned by "radio". That might be a good way to determine which file to use on a given device, ie:

ls -l /dev/smd[0-9] /dev/smd[0-9][0-9] | grep radio | grep -oE '[^ ]+$'

Btw, ls -l also shows the major and minor numbers for each file in /dev.

[swintec]

i cant seem to get it to work on my nexus 5x but i could be doing it wrong i suppose.

[ingenium]

i cant seem to get it to work on my nexus 5x but i could be doing it wrong i suppose.

Can you enable full logging in SuperSU, try it again, and then look at the 2 recent log entries in SuperSU and see if one of them lists an error? 

 

Or, preferably, open a root adb shell and type: 

ls -l /dev/smd*

and post the output? It's possible CellMapper is just using the wrong file by default on the 5X, which you can change in the CellMapper settings. The above output will tell us which file it should be using.

[RyanThaDude]

On my N6

 

crw-rw---- 1 system    system       230,   0 1970-03-21 05:14 /dev/smd0
crw------- 1 root      root         230,   1 1970-03-21 05:14 /dev/smd1
crw------- 1 root      root         230,  11 1970-03-21 05:14 /dev/smd11
crw------- 1 root      root         230,   2 1970-03-21 05:14 /dev/smd2
crw------- 1 root      root         230,  21 1970-03-21 05:14 /dev/smd21
crw------- 1 root      root         229,  11 1970-03-21 05:14 /dev/smd22
crw------- 1 root      root         230,  27 1970-03-21 05:14 /dev/smd27
crw------- 1 root      root         230,   3 1970-03-21 05:14 /dev/smd3
crw------- 1 root      root         230,  36 1970-03-21 05:14 /dev/smd36
crw-rw---- 1 system    system       230,   4 1970-03-21 05:14 /dev/smd4
crw-rw---- 1 system    system       230,   5 1970-03-21 05:14 /dev/smd5
crw-rw---- 1 system    system       230,   6 1970-03-21 05:14 /dev/smd6
crw-rw---- 1 bluetooth net_bt_stack 230,   7 1970-03-21 05:14 /dev/smd7
crw------- 1 root      root         230,   8 1970-03-21 05:14 /dev/smd8

Edited February 20, 2016 by RyanThaDude