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

[gnoj]

How about something like "BID: 11393 (2C81)".. I think a majority of people will still refer to the decimal version, and I wan't to keep that distinct.  If I put a dash, people will probably start doing math on the thing...

 

Thoughts/comments from the peanut gallery?  I don't think this will be of much use in my specific area but who knows, maybe it will start pointing to some sort of pattern...

 

This would be a great addition! I often convert to hex when I hand off to a different sector to double-check what direction the tower is in and how they have the sectors configured. This would save me some time from having to jump into my separate base conversion app.

 

If you plan on doing tests like that again, grab Roam Control, it would be much easier.. 

 

I looked into that Roam Control app a bit and discovered that on certain Samsung phones (e.g. the S3), in order to force roaming the app has to disable the PCS band, leaving access to just Band 0. I couldn't find out anywhere if the S4 still has this problem. I asked in the S4 thread first but no one replied. If possible I'd like to test out how extensively the USCC network in Chicagoland (which is PCS only there) has been curtailed.

[mikejeep]

I've noticed some weird things with location and my phone lately. I linked something in the HTC One thread but basically it seems after a couple of hours some apps using location don't seem to work, like Google Now for example. It doesn't seem to use the cell triangulation anymore. When I open Google Maps it says "waiting for location" while it gets a fix instead of giving you the big blue circle based on triangulation, then drilling down. The link I found pinned the problem on the latest Google Play Services version. Here's the link: https://groups.google.com/a/googleproductforums.com/d/msgid/mobile/354d7def-9502-40e2-9bb9-74b5adc79f65%40googleproductforums.co

 

The good thing about Google Play Services is that it gets silently pushed out to all devices with a Google account.. so everyone is basically running the same version.  If there is a glitch, they can push out an update.  No waiting on users to download updates.  Do you have another link?  That one does not work for me, it just goes to the main Google Groups page.

 

-Mike

[Jaggrey]

The good thing about Google Play Services is that it gets silently pushed out to all devices with a Google account.. so everyone is basically running the same version. If there is a glitch, they can push out an update. No waiting on users to download updates. Do you have another link? That one does not work for me, it just goes to the main Google Groups page.

 

-Mike

See if this one works.

https://productforums.google.com/forum/m/#!msg/mobile/a0JsXoeVaNM/1K2oOwYnMPwJ

[mikejeep]

That would be perfect! 

 

Explanation on the PCS BID pattern here:

http://s4gru.com/index.php?/topic/579-network-vision-site-map-new-orleans-memphis-gulf-coast-east-texas-mississippi-and-louisiana-markets/page-220?p=194877&do=findComment&comment=194877

 

Combine that with some other data..and bang..  that thing could display the site ID and sector you were connected to   Dreaming....

 

So I got your magic working in my app, at least displaying the last 3 digits that would match a cascade ID.  Hard-coding the BID examples from your thread, everything adds up right.  Let it out into the wild, and... nada.  Nothing seems to match in my area.  Decoded 051, fairly certain connected site ends in 045.  No 051 sites anywhere near here.  There's an 052 several miles away, but there are 3-4 other sites closer to me that I think I would catch first anyway.  Do you have any confirmed info that this works in Alcatel-Lucent markets?  I was so excited too.. bah!

 

-Mike

[The Dave]

I have also been getting the network failure issues with Google maps, but it seems like that has been happening with Maps in general and not necessarily anything to do with Signal Check

[digiblur]

So I got your magic working in my app, at least displaying the last 3 digits that would match a cascade ID. Hard-coding the BID examples from your thread, everything adds up right. Let it out into the wild, and... nada. Nothing seems to match in my area. Decoded 051, fairly certain connected site ends in 045. No 051 sites anywhere near here. There's an 052 several miles away, but there are 3-4 other sites closer to me that I think I would catch first anyway. Do you have any confirmed info that this works in Alcatel-Lucent markets? I was so excited too.. bah!

 

-Mike

That number is called a Cell ID in Sprint's internal DB. Sometimes it matches up with the cascade number. I should have explained it a bit better and will when I have more time to type.

[jefbal99]

Cascade IDs are not matching up in West Michigan thus far

 

Sent from my SPH-L900 using Tapatalk 4

 

 

[4ginnc]

Or in the Raleigh market that I can find so far.  

 

On a related note, Signal Check on my S3 keeps showing as connected to a Site that's 12 miles away when there are 5 closer to me and usually only one that I always connect to at the house. Signal check and the debug screens are showing that I am on 1900 (Band Class 1) and not on 1x800 so I don't see how I can really be connected to that Site.

 

Reboot of my phone didn't help, as I was thinking it might be related to the bug Mike mentioned once before about the location being stuck on some phones.  When I roam (which usually happens for a few feet as I move away from the window) it shows I am connected to Alltel and the BSL changes to the usual address that it shows for that site.

 

Any ideas?  Really seems unlikely to me that I'm connected to the Site 12 miles away when I usually barely get a signal from a Site 3.5 miles away because of all the trees.

[chamb]

Or in the Raleigh market that I can find so far.  

 

On a related note, Signal Check on my S3 keeps showing as connected to a Site that's 12 miles away when there are 5 closer to me and usually only one that I always connect to at the house. Signal check and the debug screens are showing that I am on 1900 (Band Class 1) and not on 1x800 so I don't see how I can really be connected to that Site.

 

Reboot of my phone didn't help, as I was thinking it might be related to the bug Mike mentioned once before about the location being stuck on some phones.  When I roam (which usually happens for a few feet as I move away from the window) it shows I am connected to Alltel and the BSL changes to the usual address that it shows for that site.

 

Any ideas?  Really seems unlikely to me that I'm connected to the Site 12 miles away when I usually barely get a signal from a Site 3.5 miles away because of all the trees.

I am having similar issues.  Going through areas that always had the Base Station address showing properly are now showing a strange address that apparently is cached somewhere.  Most of the addresses are correct and normal, but this one crazy address somehow keeps coming up at times while the actual BID does vary and looks correct.   This one bad address shows up many many miles away from the address and can not be correct.    It almost has to be cached in my phone somehow and may be showing up when Google is slow or something.   Can the cache be cleared of the Base station addresses and be started over??

[digiblur]

Cascade IDs are not matching up in West Michigan thus far

 

Sent from my SPH-L900 using Tapatalk 4

 

They aren't going to unless Sprint just happened to match up the Cell IDs in their database with the Cascade IDs.

[Flompholph]

...

Added caching of BSL addresses; geocoding server will only be queried if the BSL is “new” to that device. (Pro)

Once a location is geocoded, it will be saved on the device and displayed if the same coordinates are reported again, without a query to the remote geocoding server.  These queries are not very data-intensive, but it will still result in a lot less of a network impact by the app.  Also, if you experience the bug that causes the geocoding to stop working, any cached addresses will still be displayed.  BSL addresses that are “new” will be cached and displayed in bold the first time to inform you that this is a new site.

 ...

-Mike

Caching is a new feature Google does the conversion to an address. I did experience the same thing the address sticks as you move tower to tower. Clicking on the address takes you to the right connected tower(the red dot moves address stays the same). Maybe an issue in between saving the address to cache and sending to Google to convert to an address. Maybe the next version will have a "clear bsl cache" in setting. That way if you do encounter this issue just clear the file try it again.

[digiblur]

Caching is a new feature Google does the conversion to an address. I did experience the same thing the address sticks as you move tower to tower. Clicking on the address takes you to the right connected tower(the red dot moves address stays the same). Maybe an issue in between saving the address to cache and sending to Google to convert to an address. Maybe the next version will have a "clear bsl cache" in setting. That way if you do encounter this issue just clear the file try it again.

I think you could just clear the data on app to do that.

[digiblur]

Nice to see the developer thought of things. All 1x800 alerts and displays work even when the device is reporting that it is in a roaming state. Nice job!

 

Looks funny saying roaming now when I am on 1x800.

[mikejeep]

Caching is a new feature Google does the conversion to an address. I did experience the same thing the address sticks as you move tower to tower. Clicking on the address takes you to the right connected tower(the red dot moves address stays the same). Maybe an issue in between saving the address to cache and sending to Google to convert to an address. Maybe the next version will have a "clear bsl cache" in setting. That way if you do encounter this issue just clear the file try it again.

It's not anything Google does, it's something I implemented myself. When you connect to a site for the first time, it saves the address that is returned. However, it is very reliable because I do not cache the BID -- just the latitude/longitude that is returned. I want to explain how it works, because most would probably assume the app worked in a different manner...

 

Upon connecting to a CDMA 1X site, your device receives the System, Network, and Base Station IDs (SID/NID/BID in the app). It also receives the Base Station Location (BSL) in the form of latitude/longitude coordinates. All of these bits of data come from the site itself; SignalCheck just displays them on your screen. Whenever the BID changes, the app clears the BSL field and starts the process below to update it.

 

To generate the street address BSL, SignalCheck takes the latitude/longitude the site is broadcasting, and checks the app's cache to see if those exact coordinates have been previously saved, resulting in one of the following:

• If those exact coordinates are not in the cache, SignalCheck sends a query to a remote geocoding server (I believe it is Google's; it's all part of an internal Android geocoding routine) to request the nearest street address to that point. This is when the BSL changes to "Click for map...". When the response returns an address, that address is saved in SignalCheck's cache and BSL is updated accordingly. If a response is never received, "Click for map.." stays there until the next time a valid BSL is received either from a geocoding request or the cache.

   

• If those exact coordinates are already in the cache, SignalCheck grabs the saved street address from the cache and displays it as the BSL. No remote queries, no delays.

Again, each entry in the SignalCheck cache really only consists of two things: a latitude/longitude pair, and a street address. The BID is not cached at all, and this is on purpose. If a site starts broadcasting different coordinates for whatever reason (even if they only differ by .00001), SignalCheck will get the street address of these new coordinates automatically the first time you connect to that site. Future connections will use that newly cached address.

 

If you are seeing strange addresses, perhaps the coordinates of a site have been changed. SignalCheck is showing you the street address of the coordinates it is being given, unless there is a new bug and this is the first time I'm hearing of it.

 

If you do want to clear the cache, it's easy -- go to Settings > Apps > SignalCheck Pro > Clear Data. FYI, this will reset your SignalCheck preferences to the defaults as well.

 

Hope that helps!

-Mike

[mikejeep]

Nice to see the developer thought of things. All 1x800 alerts and displays work even when the device is reporting that it is in a roaming state. Nice job!

 

Looks funny saying roaming now when I am on 1x800.

 

Uhhh yeah I did that on purpose!  Haha.. actually it basically ignores the roaming flag, used to display an asterisk next to the carrier name when roaming, but I'm phasing that out since you can see the actual carrier names now.  I was going to ask why your device was reporting roaming if you were on 1x800, but I thought about it for a minute and I think I might know whatcha did for yourself... 

 

-Mike

[gnoj]

If you are seeing strange addresses, perhaps the coordinates of a site have been changed. SignalCheck is showing you the street address of the coordinates it is being given, unless there is a new bug and this is the first time I'm hearing of it.

 

If you do want to clear the cache, it's easy -- go to Settings > Apps > SignalCheck Pro > Clear Data. FYI, this will reset your SignalCheck preferences to the defaults as well.

 

I have also experienced this issue where the address has stuck, even though the BID has changed and Google Maps confirms I'm connected to a different site then the one named. Refreshing/restarting the app didn't fix it, so I assumed the problem was that the app accidentally cached the wrong address to a set of coordinates. Clearing the cache indeed fixed the problem, but of course that's not a great solution since that also deletes all the other accurate cached addresses.

 

If the app provided access to an editable list of sites, that could allow the user to remove the info just for that site. That would also provide a nice log of sites encountered. Alternatively, perhaps you could do something to prevent the app from caching two or more coordinates to the same address, and if the app does so for it to recognize that it did that and rescan?

[mikejeep]

I have also experienced this issue where the address has stuck, even though the BID has changed and Google Maps confirms I'm connected to a different site then the one named. Refreshing/restarting the app didn't fix it, so I assumed the problem was that the app accidentally cached the wrong address to a set of coordinates. Clearing the cache indeed fixed the problem, but of course that's not a great solution since that also deletes all the other accurate cached addresses.

 

If the app provided access to an editable list of sites, that could allow the user to remove the info just for that site. That would also provide a nice log of sites encountered. Alternatively, perhaps you could do something to prevent the app from caching two or more coordinates to the same address, and if the app does so for it to recognize that it did that and rescan?

 

Aha, interesting.. so there may be a bug buried in there somewhere!  Perhaps at some point the wrong address got attached to coordinates, but I don't know how that could happen, it saves the coordinates and the associated street address at the same time.. strange.

 

The cache is an SQLite database, stored on most devices in /data/data/com.blueline.signalcheck/databases/signalcheck_cache.db (yes, that's two data's.. don't ask me, that's how Android works).

 

I wasn't aware of any issues with the cache, but perhaps I need to look into it further.  I pull my cache .db file every few days and look through it to make sure nothing looks out of place, and it's been great so far.  If someone wants to send me their cache.db file and let me know what address is coming up wrong, it might help me figure out where the issue is.

 

-Mike

 

P.S. Logging is in the works.. 

[Flompholph]

Aha, interesting.. so there may be a bug buried in there somewhere!  Perhaps at some point the wrong address got attached to coordinates, but I don't know how that could happen, it saves the coordinates and the associated street address at the same time.. strange. The cache is an SQLite database, stored on most devices in /data/data/com.blueline.signalcheck/databases/signalcheck_cache.db (yes, that's two data's.. don't ask me, that's how Android works). I wasn't aware of any issues with the cache, but perhaps I need to look into it further.  I pull my cache .db file every few days and look through it to make sure nothing looks out of place, and it's been great so far.  If someone wants to send me their cache.db file and let me know what address is coming up wrong, it might help me figure out where the issue is. -Mike P.S. Logging is in the works.. 

It seemed to skip the change to "click for map" on my device not a big deal as long as I check the map to. The address in the pic should read youngwood park, youngwood. It heald the address for the tower to the south an 800. I will see if the db is still there later.

[digiblur]

Uhhh yeah I did that on purpose!  Haha.. actually it basically ignores the roaming flag, used to display an asterisk next to the carrier name when roaming, but I'm phasing that out since you can see the actual carrier names now.  I was going to ask why your device was reporting roaming if you were on 1x800, but I thought about it for a minute and I think I might know whatcha did for yourself... 

 

-Mike

 

Yeah I made me a PRL with the first level priority set having the 800SMR SIDs and even a wild card 800SMR SID scan for kicks.  They are set to roaming indicators.  Next level is PCS.  If I don't want 800SMR since I could be on the fringe with only a few sites here having it, I just toggle my phone from Auto to Sprint Only and 800SMR is gone with no PRL write procedure.

[4ginnc]

Aha, interesting.. so there may be a bug buried in there somewhere!  Perhaps at some point the wrong address got attached to coordinates, but I don't know how that could happen, it saves the coordinates and the associated street address at the same time.. strange.

 

The cache is an SQLite database, stored on most devices in /data/data/com.blueline.signalcheck/databases/signalcheck_cache.db (yes, that's two data's.. don't ask me, that's how Android works).

 

I wasn't aware of any issues with the cache, but perhaps I need to look into it further.  I pull my cache .db file every few days and look through it to make sure nothing looks out of place, and it's been great so far.  If someone wants to send me their cache.db file and let me know what address is coming up wrong, it might help me figure out where the issue is.

 

-Mike

 

P.S. Logging is in the works.. 

 

Thanks for the input Mike.  I have a thought, not sure how your code works but just thinking out loud here, knowing where I usually connect to the site that's showing me the bogus address.  It's a remote location that I go through sometimes to pick the kids up from school.  I usually hand off between a few sites on the way, and the location that I'm seeing is on a site that briefly pops up before/after I'm roaming in that area.

 

Is it possible that, at the time I went through that area, the connection to the geocoding server didn't work and that later when the device was finally connected to the internet again that request went through and returned that address for a later request?

 

I'll try to pull the SQLite db from my S3 later today and send it to you.

 

Thanks for the help.

[RCM]

 

P.S. Logging is in the works.. 

 

[4ginnc]

Mike, just PM'd you my signalcheck_cache.db file.  Definitely see some off entries with several GPS coordinates showing the same address when they are actually different towers.

 

Let me know if there's anything else you need.

[WiWavelength]

P.S. Logging is in the works.. 

 

But I hope not over logging...

 

http://www.youtube.com/watch?v=bRgeJfLfzbg

 

AJ

[mikejeep]

With 4ginnc's help, I think I figured out the cache problem, it's definitely a bug in the app.  Looks like it might be related to getting a delayed geocoding response back, after the BID has changed again -- I think somebody suggested something like that in an earlier post.. good thinking!

 

I will try to get it fixed, but I don't want to make any promises about when it will be ready, I might not get to it until the middle of next week.

 

Until I can get a fix released, you have a few options:

• Delete the signalcheck_cache.db file from your device (wipes out your entire BSL cache)
• Clear the app data on your device (wipes out your entire BSL cache and app preferences)
• Manually edit the .db yourself and remove all entries that are listed more than once (most amount of work, least amount of data loss)

-Mike

[4ginnc]

Removed my signalcheck_cache.db file and like magic, I'm back at home again.