Jump to content

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


mikejeep

Recommended Posts

Would any part of the PLMN request require SU or root access? I'm still convinced that I have a bad firmware flash from Sprint but just trying to eliminate possibilities.

No, it's all done through standard Android routines that do not require root. To dive into it a little deeper, Android reports a PLMN value from a few different places: the TelephonyManager suite, the ServiceState suite, the SIM card, and the new LTE routines on Android 4.2+. SignalCheck monitors all of these values, and as the app has matured, I have improved the logic it uses to choose which one is valid. But OEMs are very inconsistent in this area, especially on native CDMA devices that only use the PLMN for LTE. This is a major reason why B41 is so hard to get working smoothly across all devices, it relies on the PLMN.

 

-Mike

  • Like 1
Link to comment
Share on other sites

The latest Chromecast update allows full-screen mirroring to your TV. I guess you could ask why anyone would cast SignalCheck to their TV.. but the better question is, why not? ;)

 

uploadfromtaptalk1405115257547.jpg

 

-Mike

  • Like 14
Link to comment
Share on other sites

Any idea what's causing this? Normally my tablet sits on airplane mode while on wifi but I forgot to change it back after work on Saturday. Neither the site logger or location is enabled as far as I can tell. This happened on my Samsung galaxy tab 3

a2aty2up.jpg

Link to comment
Share on other sites

Any idea what's causing this? Normally my tablet sits on airplane mode while on wifi but I forgot to change it back after work on Saturday. Neither the site logger or location is enabled as far as I can tell. This happened on my Samsung galaxy tab 3

How long had your device been booted for when you took that screenshot? Did you leave SignalCheck on the screen for a long time? Did you have poor signal or was it constantly switching sites? Nothing in the app forces the phone to stay awake when its in the background, so 9 hours of keep-awake time hints that it was on-screen for that much time.

 

All of the reported battery issues I have investigated have turned out to be fluke/random/one-time blips, or related to something else. The app doesn't do much except listen for signal changes, especially if you had logging and location disabled. I intentionally don't have it poll for any information at specific intervals or anything like that to minimize battery impact. If your signal doesn't change, the app doesn't do a thing.

 

-Mike

Link to comment
Share on other sites

How long had your device been booted for when you took that screenshot? Did you leave SignalCheck on the screen for a long time? Did you have poor signal or was it constantly switching sites? Nothing in the app forces the phone to stay awake when its in the background, so 9 hours of keep-awake time hints that it was on-screen for that much time.

 

All of the reported battery issues I have investigated have turned out to be fluke/random/one-time blips, or related to something else. The app doesn't do much except listen for signal changes, especially if you had logging and location disabled. I intentionally don't have it poll for any information at specific intervals or anything like that to minimize battery impact. If your signal doesn't change, the app doesn't do a thing.

 

-Mike

It had roughly 20-25 hours of uptime since last reboot. I had looked at signal check earlier but it wasn't pulled for more than a few minutes, it was minimized by pressing the home button. I was connected to my airave, so signal should have been fairly strong. I don't know if its related, but my nexus will connect to 1x on the airave and then bounce evdo around between it and the macro sites. I didn't really pay attention if it was doing that on the tablet or not, but I've never had it keep awake on my phone before.
Link to comment
Share on other sites

So far it's looking like a fluke, I've had it with me at work today going all over the city and scp doesn't even register on the battery use screen. I'll look at it later tonight at home after its been connected to my airave for a while. I only posted in case there was some setting I might have had on and didn't realize. When the site logger/GPS feature came out I turned it on and didn't realize how large a drain it was. I just wanted to make sure I wasn't missing anything since it normally sits in airplane mode with only WiFi 95% of the time.

Link to comment
Share on other sites

I've been a big fan of Signal Check for a long time, but have never had it tell me the band I'm on. I've been eagerly reading the forums and looking for an update for what I assumed was a problem with my tower reporting numbers correctly to my phone.

 

While troubleshooting some data issues I was having, I came across a fix that unknowingly fixed my issues with Signal Check as well. It's a long story, but it basically involves properly restoring the phone making sure you do a couple key things so (I think) a corrupt data profile can get restored.

 

My steps here: http://forum.xda-developers.com/sprint-htc-one-m8/general/fix-data-issues-t2819915

 

The lesson here might be to not necessarily blame Signal Check if its not working right.

  • Like 1
Link to comment
Share on other sites

In the same note, I did another ##786# on my Torque to wipe my data before taking it to a Sprint store, and it fixed my Chameleon error with SCP. I had no other problems with it other than it lost the Sprint bootscreen and replaced it with Android, so I knew my software got corrupted somehow.

  • Like 1
Link to comment
Share on other sites

I tried looking though pages and pages of this thread to see if I could find an answer to what I noticed when I was traveling.  I did try a couple of key work searches but nothing came close to what I discovered....  I have the PRO version and when I am in my home market I can see what tower I am connected to in the BSL line for a simple example 123 Random Rd, City.  Now this past week I went on vacation and I was in SC/NC.  I noticed on that line "click for map" .  I am in a Samsung vendor market and in the NC/SC when I was in a Alcatel Lucent vendor market.  I did look to see if there was a setting I messed around with and changed on accident, but I couldn't find anything.  Maybe its because I am using an older phone (LG OG)?  Or is it because of the Vendor difference?  Once I got back into a Samsung area it started showing the street address.  Anyone help me out with this or direct me to where this is in the thread that I may of missed?  

 

Thanks, Josh

Link to comment
Share on other sites

"Click for map" is just a place holder until your phone has data to send the location to Google for an address.

 

I was wandering if in the logs 3 columns could be added best_signal_lat, best_signal_long, and best_signal_dbm . That way we can track band 26 and 41 or even band 25 easier. And see what tower maybe broadcasting after a trip if we didn't notice it at the time.

  • Like 1
Link to comment
Share on other sites

"Click for map" is just a place holder until your phone has data to send the location to Google for an address.

 

I was wandering if in the logs 3 columns could be added best_signal_lat, best_signal_long, and best_signal_dbm . That way we can track band 26 and 41 or even band 25 easier. And see what tower maybe broadcasting after a trip if we didn't notice it at the time.

I kept the app open for over 10 mins each time I checked when I was down there because I thought that was the issue was data was slow, but it just sat there, I even did a data connection reset and that did nothing new for me..... Like I said once I got back into a Samsung area it shows the address right away no issue..... 

Link to comment
Share on other sites

I kept the app open for over 10 mins each time I checked when I was down there because I thought that was the issue was data was slow, but it just sat there, I even did a data connection reset and that did nothing new for me..... Like I said once I got back into a Samsung area it shows the address right away no issue.....

 

I had no issues this weekend going from Ericson to ALU to Samsung. Did you reboot your phone over the trip? Signal check saves your previous bsl you might of ran into the android bug then came back to previously save bsl towers.

http://www.bluelinepc.com/signalcheck/help/#bslstuck

  • Like 1
Link to comment
Share on other sites

Mike, at the Sporting KC friendly last night, my Nexus 5 made its first band 41 acquisition.  However, I noted an MCC-MNC discrepancy between engineering and SignalCheck Pro.  Any insight?

 

2urqa14.png

 

2iscbh2.png

 

AJ

Link to comment
Share on other sites

I was wandering if in the logs 3 columns could be added best_signal_lat, best_signal_long, and best_signal_dbm . That way we can track band 26 and 41 or even band 25 easier. And see what tower maybe broadcasting after a trip if we didn't notice it at the time.

 

Ah, that is an interesting idea.. although I would have to do some work to make sure I can add those columns to existing database files without corrupting them. I'll put that as a priority to work on.

 

I do want to apologize to everyone for my lack of any updates lately.. I have been absolutely swamped at work, which is sucking away all the free time I need to work on my master's.. leaving less than no time for SignalCheck. :( I'm still trying to find exactly what is crashing Android L, I wanted to at least get that out; I might just push an update that disables all notifications if it detects Android L as a temporary fix, since that would be quicker.

 

I kept the app open for over 10 mins each time I checked when I was down there because I thought that was the issue was data was slow, but it just sat there, I even did a data connection reset and that did nothing new for me..... Like I said once I got back into a Samsung area it shows the address right away no issue..... 

 

As Flompholph pointed out, that is just a placeholder, and there is a known Android bug that causes the address geocoder to randomly stop working, and requires a reboot to get going again. You might have been seeing the address "right away" in the other areas because the app had previously cached them (which circumvents that bug nicely and does not use any data transfer).

 

Mike, at the Sporting KC friendly last night, my Nexus 5 made its first band 41 acquisition.  However, I noted an MCC-MNC discrepancy between engineering and SignalCheck Pro.  Any insight?

 

This issue has been my nemesis since B26 and B41 started lighting up, and I'm seeing others report it to SpenceSouth and the LTE Discovery crew in their app, so I know it's not just me. For some reason, phones are not always reporting the same PLMN to the engineering screen and to the OS. For a long time I thought it was a bug in my code that runs if the PLMN changes, but now that I'm seeing similar issues with other apps, it makes more sense. It appears to be very random as to when it does or does not report the same values. Sadly I would expect the N5 to be the most well-behaved, but it seems to suffer from the same issues that other devices do. I don't know if it's a network issue, an Android bug, an engineering screen bug, or lousy programming in the radio firmware. I'm still looking for solutions but it's really just a case of the device feeding the app (or the engineering screens) bad data.

 

-Mike

Link to comment
Share on other sites

This issue has been my nemesis since B26 and B41 started lighting up, and I'm seeing others report it to SpenceSouth and the LTE Discovery crew in their app, so I know it's not just me. For some reason, phones are not always reporting the same PLMN to the engineering screen and to the OS. For a long time I thought it was a bug in my code that runs if the PLMN changes, but now that I'm seeing similar issues with other apps, it makes more sense. It appears to be very random as to when it does or does not report the same values. Sadly I would expect the N5 to be the most well-behaved, but it seems to suffer from the same issues that other devices do. I don't know if it's a network issue, an Android bug, an engineering screen bug, or lousy programming in the radio firmware. I'm still looking for solutions but it's really just a case of the device feeding the app (or the engineering screens) bad data.

 

-Mike

In my experience, the N5 has been the best at reporting the correct band, but I've never thought to check and see if the PLMN in Signal Check was the same one that the engineering screen was showing.

 

I did find that with the G3, I was having the issue where the PLMN didn't update for quite some time while I was on B41, and by the time it did update, I was back on B25.

Link to comment
Share on other sites

Ah, that is an interesting idea.. although I would have to do some work to make sure I can add those columns to existing database files without corrupting them. I'll put that as a priority to work on.

 

I do want to apologize to everyone for my lack of any updates lately.. I have been absolutely swamped at work, which is sucking away all the free time I need to work on my master's.. leaving less than no time for SignalCheck. :( I'm still trying to find exactly what is crashing Android L, I wanted to at least get that out; I might just push an update that disables all notifications if it detects Android L as a temporary fix, since that would be quicker.

 

 

As Flompholph pointed out, that is just a placeholder, and there is a known Android bug that causes the address geocoder to randomly stop working, and requires a reboot to get going again. You might have been seeing the address "right away" in the other areas because the app had previously cached them (which circumvents that bug nicely and does not use any data transfer).

 

 

This issue has been my nemesis since B26 and B41 started lighting up, and I'm seeing others report it to SpenceSouth and the LTE Discovery crew in their app, so I know it's not just me. For some reason, phones are not always reporting the same PLMN to the engineering screen and to the OS. For a long time I thought it was a bug in my code that runs if the PLMN changes, but now that I'm seeing similar issues with other apps, it makes more sense. It appears to be very random as to when it does or does not report the same values. Sadly I would expect the N5 to be the most well-behaved, but it seems to suffer from the same issues that other devices do. I don't know if it's a network issue, an Android bug, an engineering screen bug, or lousy programming in the radio firmware. I'm still looking for solutions but it's really just a case of the device feeding the app (or the engineering screens) bad data.

 

-Mike

My issue seemed to be less of the system reporting erroneous data and more of me just not properly handling the PLMN ID as it switched between B41 and B25/B26 sites (which fortunately wasn't a bad fix).  I don't know how you handle the data as you check for B41, but from what I have seen of SignalCheck screenshots it seems that it is always 311490 that is reported instead of 311870 when that bug pops up... Do you pull the PLMN ID value directly from the system, or is there a chance you may be inadvertently returning the same constant string during your check?

 

I don't know if that helps or not, but feel free to bounce ideas off of me if you need to.

Link to comment
Share on other sites

My issue seemed to be less of the system reporting erroneous data and more of me just not properly handling the PLMN ID as it switched between B41 and B25/B26 sites (which fortunately wasn't a bad fix).  I don't know how you handle the data as you check for B41, but from what I have seen of SignalCheck screenshots it seems that it is always 311490 that is reported instead of 311870 when that bug pops up... Do you pull the PLMN ID value directly from the system, or is there a chance you may be inadvertently returning the same constant string during your check?

 

I don't know if that helps or not, but feel free to bounce ideas off of me if you need to.

 

Well crap.. I got my hopes up based on seeing a few of your posts, maybe it is on me after all! I'll shoot you a PM later tonight with some details.. thanks!

 

-Mike

Link to comment
Share on other sites

Well crap.. I got my hopes up based on seeing a few of your posts, maybe it is on me after all! I'll shoot you a PM later tonight with some details.. thanks!

 

-Mike

Not a problem, I know what a pain tracking down some of those bugs can be... Happy to help.

 

Sent from my Nexus 5 using Tapatalk

Link to comment
Share on other sites

The interesting part is that we know both 311-490 and 311-870 are valid Sprint/Clearwire MCC-MNCs.  So, it is not as if the OS is reporting some invalid 310-000 or default 310-120 -- as is the case on some handsets.  I wonder, then, if the network is transmitting both PLMNs.  That is definitely possible.

 

AJ

Link to comment
Share on other sites

Ah, that is an interesting idea.. although I would have to do some work to make sure I can add those columns to existing database files without corrupting them. I'll put that as a priority to work on.

 

I do want to apologize to everyone for my lack of any updates lately.. I have been absolutely swamped at work, which is sucking away all the free time I need to work on my master's.. leaving less than no time for SignalCheck. :( I'm still trying to find exactly what is crashing Android L, I wanted to at least get that out; I might just push an update that disables all notifications if it detects Android L as a temporary fix, since that would be quicker.

 

 

As Flompholph pointed out, that is just a placeholder, and there is a known Android bug that causes the address geocoder to randomly stop working, and requires a reboot to get going again. You might have been seeing the address "right away" in the other areas because the app had previously cached them (which circumvents that bug nicely and does not use any data transfer).

 

 

This issue has been my nemesis since B26 and B41 started lighting up, and I'm seeing others report it to SpenceSouth and the LTE Discovery crew in their app, so I know it's not just me. For some reason, phones are not always reporting the same PLMN to the engineering screen and to the OS. For a long time I thought it was a bug in my code that runs if the PLMN changes, but now that I'm seeing similar issues with other apps, it makes more sense. It appears to be very random as to when it does or does not report the same values. Sadly I would expect the N5 to be the most well-behaved, but it seems to suffer from the same issues that other devices do. I don't know if it's a network issue, an Android bug, an engineering screen bug, or lousy programming in the radio firmware. I'm still looking for solutions but it's really just a case of the device feeding the app (or the engineering screens) bad data.

 

-Mike

I did restart my phone twice on Vacation, I even un-installed and reinstalled the app. (just to see if that helped and it didn't, and there was no update available).  I have the LG Optimus G (Old phone now but I love it!!!!)  

 

I am not making a big deal out of it, I was just telling what I observed and asked if maybe it was a bug or something, lol

Link to comment
Share on other sites

At my home Signal check shows B41, LTE engineering showing B25. Nexus 5 attachicon.gifuploadfromtaptalk1406427145518.jpgattachicon.gifuploadfromtaptalk1406427158130.jpg

 

Sent from my Nexus 5 using Tapatalk

I've had that happen a few times myself, SignalCheck Pro would show B41 but the Engineering Screen would should B25. I have also had SignalCheck Pro show B26 but in fact it was B25.

Link to comment
Share on other sites

At my home Signal check shows B41, LTE engineering showing B25. Nexus 5 attachicon.gifuploadfromtaptalk1406427145518.jpgattachicon.gifuploadfromtaptalk1406427158130.jpg

 

Sent from my Nexus 5 using Tapatalk

That almost looks like Signal Check got stuck. None of the data it is showing is matching up with your engineering screen.

Link to comment
Share on other sites

That almost looks like Signal Check got stuck. None of the data it is showing is matching up with your engineering screen.

that's what I was thinking as well. I can't figure out why, but it has happened a few times.

 

Sent from my Nexus 5 using Tapatalk

Link to comment
Share on other sites

I've had that happen a few times myself, SignalCheck Pro would show B41 but the Engineering Screen would should B25. I have also had SignalCheck Pro show B26 but in fact it was B25.

 

Yes, the B41 indicator has some very annoying and relatively random problems; I'm still digging into them. The B26 issue will be fixed in the next update, I already figured out what I broke there :)

 

-Mike

  • Like 5
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • large.unreadcontent.png.6ef00db54e758d06

  • gallery_1_23_9202.png

  • Similar Content

  • Posts

    • Was at the Yankees vs Tigers game today and besides being a terrible day to have good seats, T-Mobile had great speeds via the stadium's DAS. I consistently saw 500-600Mbps on 5G and on LTE I got upwards of 200Mbps. I noticed that the stadiums DAS is broadcasting 140MHz n41 while macros that surround the stadium are at 80MHz. 
    • Throwed Roll Lambert's Cafe 
    • I've now seen how things work in Kobe, Hiroshima, and Osaka, as well as some areas south of Osaka (e.g. Wakayama, Kinokawa), and tried three more SIMs. The two physical SIMs (different branding for each) both use IIJ, which provides a Japanese IP address/routing on NTT, aleit LTE-only, so latency is ~45ms to Tokyo. The catch with NTT is that it uses two frequency bands (B42/3500 MHz LTE, n79/4900 MHz NR) that you're not going to get on an Android sold in the US, and I'm guessing that B42 would be helpful speed-wise on that network, as it doesn't have B41. I also found one place that doesn't have cell service: a vending machine in the back of the Osaka Castle tower. Or, rather, the B8/18/19 signal is weak enough there to be unusable. Going back to 5G for a moment, I saw a fair amount of Softbank n257 in Hiroshima, as well as in some train stations between Osaka and Kobe. 4x100 MHz bandwidth, anchored by B1/3/8, with speeds sometimes exceeding 400 Mbps on the US Mobile roaming eSIM. Not quite the speeds I've seen on mmW in the States, but I've probably been on mmW for more time over the past few days than I have in the US over the past year, so I'll take it. My fastest speed test was actually on SoftBank n77 though, with 100 MHz of that plus 10x10 B8 hitting ~700 Mbps down and ~80 Mbps up with ~100ms latency...on the roaming eSIM...on the 4th floor of the hotel near Shin-Kobe station. Guessing B8 was a DAS or small cell based on signal levels, and the n77 might have been (or was just a less-used sector of the site serving the train station). I'm now 99% sure that all three providers are running DSS on band 28, and I've seen 10x10 on similar frequencies from both NTT and SoftBank IIRC, on both LTE and 5G. I also picked up one more eSIM: my1010, which is different from 1010/csl used by US Mobile's eSIM unfortunately, as it's LTE-only. On the bright side, it's cheap (10GB/7 days is like $11, and 20GB for the same period would be around $15), and can use both KDDI and SoftBank LTE. It also egresses from Taiwan (Chunghwa Telecom), though latency isn't really any better than the Singapore based eSIMs. Tomorrow will include the most rural part of our journey, so we'll see how networks hold up there, and from tomorrow night on we'll be in Tokyo, so any further reports after that will be Tokyo-centric.
    • I think the push for them is adding US Mobile as a MVNO with a priority data plan.  Ultimately, making people more aware of priority would allow them (and other carriers) to differentiate themselves from MVNOs like Consumer Cellular that advertise the same coverage. n77 has dramatically reduced the need for priority service at Verizon where the mere functioning of your phone was in jeopardy a couple of years ago if you had a low priority plan like Red Pocket. Only have heard of problems with T-Mobile in parts of Los Angeles. AT&T fell in between. All had issues at large concerts and festivals, or sporting events if your carrier has no on-site rights. Edit: Dishes native 5g network has different issues: not enough sites, limited bandwidth. Higher priority would help a few. Truth is they can push phones to AT&T or T-Mobile.
  • Recently Browsing

    • No registered users viewing this page.
×
×
  • Create New...