Jump to content

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


mikejeep

Recommended Posts

all 3 screenshots were taken at the same time. Do I need to be connected to that site to send a diagnostic?

 

Yes.. the diagnostic report (About > Send Diagnostics) takes a snapshot of the data present on your device at the moment you submit it. I would like to see it though. NSG accesses the modem directly with proprietary methods, while SCP relies on what the Android OS is reporting.

 

-Mike

Link to comment
Share on other sites

Yes.. the diagnostic report (About > Send Diagnostics) takes a snapshot of the data present on your device at the moment you submit it. I would like to see it though. NSG accesses the modem directly with proprietary methods, while SCP relies on what the Android OS is reporting.

 

-Mike

sent
  • Like 1
Link to comment
Share on other sites

Your diagnostic report didn't show anything out of the ordinary at all.. this was what was displayed on the screen at the time:

 

Provider: AT&T B2 (310410)
GCI: 011C0B08, PCI: 71, TAC: 4633
UL EARFCN: 18850 (1875.0 MHz)
DL EARFCN: 850 (1955.0 MHz)

 

All of the background data matches up with the display. EARFCN 850 is what the OS was reporting at the time; that is band 2, and the GCI matches the band 2 pattern. I am confident that SCP is showing reliable data, at least according to your device. I don't know where NSG is getting its information.

 

-Mike

Link to comment
Share on other sites

Hey Mike, I got a false positive on B41 earlier. I think I was on either B2 or B4 (it fluctuates often) on T-Mobile. Unless this means it temporarily scanned for B41 on T-Mobile?

 

Edit: I updated to your latest release as well.

uploadfromtaptalk1498877590715.png

Link to comment
Share on other sites

Your diagnostic report didn't show anything out of the ordinary at all.. this was what was displayed on the screen at the time:

 

Provider: AT&T B2 (310410)

GCI: 011C0B08, PCI: 71, TAC: 4633

UL EARFCN: 18850 (1875.0 MHz)

DL EARFCN: 850 (1955.0 MHz)

 

All of the background data matches up with the display. EARFCN 850 is what the OS was reporting at the time; that is band 2, and the GCI matches the band 2 pattern. I am confident that SCP is showing reliable data, at least according to your device. I don't know where NSG is getting its information.

 

-Mike

hey Mike. Both SCP and NSG had a pci of 23. Is that the right record? Another thing, normally if I force my phone to band 66 and it is not available it will connect to hspa. In this case it was locked to band 66, unless there's something I'm not seeing.

 

Edit: also my device is rooted, not using the root method with SCP though. Only on NSG

Link to comment
Share on other sites

Hey Mike, I got a false positive on B41 earlier. I think I was on either B2 or B4 (it fluctuates often) on T-Mobile. Unless this means it temporarily scanned for B41 on T-Mobile?

 

A few of us have seen odd blips of data like that since I added the native EARFCN routines to SCP. The PLMN is most likely wrong, but the rest of the data is probably correct. jefbal99 reported some "Sprint" sightings on the wrong bands in Michigan that pointed to T-Mobile, and I've seen "Sprint" connections around town that I tracked to AT&T. Our devices are probably catching quick glimpses of other networks while scanning for signals. I know in my case it happens when I lose all native (Sprint) service. Sometimes not all of the data from the OS updates at the exact same moment, so you see some stale info with some new info like that.

 

 

hey Mike. Both SCP and NSG had a pci of 23. Is that the right record? Another thing, normally if I force my phone to band 66 and it is not available it will connect to hspa. In this case it was locked to band 66, unless there's something I'm not seeing.

 

Edit: also my device is rooted, not using the root method with SCP though. Only on NSG

 

When you sent the diagnostics, you were connected to PCI 71. I reached out to someone more familiar with the AT&T network that will hopefully be able to share some insight as to what you are seeing.

 

-Mike

  • Like 1
Link to comment
Share on other sites

When you sent the diagnostics, you were connected to PCI 71. I reached out to someone more familiar with the AT&T network that will hopefully be able to share some insight as to what you are seeing.

 

-Mike

yeah sorry I was home and no longer connected to that site when I sent the diagnostics. If I go back I'll send it again.
  • Like 3
Link to comment
Share on other sites

Question for the masses.. I am working on adding more notification icons for international LTE bands, and I noticed that when choosing to display "LTE [freq]" with the RSRP value, the text is very small. The font is as large as possible to fit within the area provided. Nobody has asked for it, but would anyone prefer the "LTE" text be omitted if displaying like this? That would allow me to match the font used when showing "LTE [band]", which is more visible at small resolutions. This would only impact the particular notification icon configuration that displays frequency and signal strength at the same time.

To summarize, we'll call these Option A (keep things as is) and Option B (get rid of "LTE" part). See below for examples.

Option A: e8e9b1fba3dc81342ac771cfd9ecf7b5.jpg         Option B: 526ff90e124521efeedf25137e33c540.jpg

Any thoughts? Doesn't matter to me (I prefer to show the band), just wanted to toss it out there.

-Mike

Link to comment
Share on other sites

Sorry this took so long to compile, but here are some more details about the changes in the latest version of SignalCheck.. alphabetical for simplicity:

 

Added automatic site note correlation between Verizon B2/B4/B13 LTE sites. (Pro)
Much like Sprint B25/26/41 site notes are shared, Verizon site notes are now shared between bands too.

 

Added Change Log display on first app launch.

Self-explanatory.. also accessible from the Help screen. Will be updated each release.

 

Added indicators for many AT&T, Sprint, T-Mobile, and Verizon LTE bands/cells/carriers.

Mostly self-explanatory.. these are all PLMN+GCI-based. Acronyms are all listed in the glossary on the Help screen. Small cells, DAS sites, Magic Box, Mini-Macro, etc.. good stuff.

 

Added LTE band display (and option to include EARFCN) to neighbor cells. (Pro)

Implemented native LTE EARFCN display and band identification on Android 7+. (Pro)

Android 7+ devices will at last display LTE EARFCN information in SCP without root, hard-coded patterns, or any other special magic -- as long as the manufacturer has properly implemented the routines. Unfortunately, Samsung has not done this on most of their devices; hopefully they get their act together.

 

Added visual notification when any alerts are triggered on Android 6+. (Pro)

Audio/vibrate Alerts will not trigger in newer versions of Android without a visual notification to the user. For now, this means a dismissable notification will appear in the status bar. I am working on gutting the Alerts code and hopefully will have a better solution soon.

 

Implemented Android runtime permissions requirements.

On Android 6+, users will now be prompted to explicitly grant Location, Phone, and Storage permissions to the app due to new Android security requirements. These are not new permission requirements -- each has been in place since nearly the beginning of development. It is simply a new method of requesting they be granted. Failure to grant all of these permissions will prevent the app from functioning properly. There are (crude) protections in place to shut the app down gracefully, but force closes may result if permissions are denied but users still access the app. I am working on improving this handling. Please ask if you have any concerns or questions about permissions!

 

Implemented basic privacy policy.

SignalCheck does not share any data beyond typical crash analytics, however a basic policy was implemented to satisfy Google Play requirements.

 

Removed calculated indicators for T-Mobile LTE bands in some markets due to deployment inconsistencies.

I received detailed information about T-Mobile's US network, and learned why some users saw invalid band information calculated from the PLMN+GCI. In the interest of accuracy, the app will no longer attempt to calculate the LTE band when connected to T-Mobile sites on the East Coast or in most of the West. Compatible Android 7+ devices will show any band/EARFCN information available. Click here for full details.

 

Resolved issue with device freezing while Site Logs were exported. (Pro)

Resolved issue with GSM Site Log export failing. (Pro)

The export function will now run in the background instead of locking up the display. And GSM logs are finally fixed!

 

Resolved issue with incorrect LTE site notes displaying if database had been manually edited. (Pro)

Advanced users that make manual edits to site notes in the SCP database should not have future issues.

 

Resolved issue with Location Service restarting when power is connected. (Pro)

In certain situations, connecting a charging cord to the device would start (or restart) the app's Location Service even if the user did not have this option enabled.

 

Updated launcher icon to material and round designs.

Yay, new icons!!

 

Changed AT&T LTE DAS indicators to “iDAS” (indoor) or “oDAS” (outdoor).

Changed PLMN 311940 to Clearwire.

Improved identification of Sprint LTE band 25 second carriers in certain regions.

Improved identification of Sprint LTE connections for prepaid users.

Resolved force closes with Location Service on devices using non-Latin characters. (Pro)

Resolved issue with LTE PCI 0 not displaying.

Resolved issue with provider display showing PLMN instead of name in certain situations.

Resolved issue with some LTE band 30 notification icons not displaying. (Pro)

Significant behind-the-scenes code optimizations.

Updated help screen.

These should all be self-explanatory, but feel free to ask questions.

 

 

Back to working on the next update.. thanks to everyone for their support!!

 

-Mike

  • Like 10
Link to comment
Share on other sites

Not sure if this is intentional or not but band 66 is showing up as band 4.

I think I might have accidentally figured this out. Simple math:

 

NSG EARFCN (66486) - SCP EARFCN (950) = 65536

 

65536 is 2^16, aka the max 16-bit integer. The API specifies it is a 18-bit integer, but I'm guessing something buried inside the OS got messed up along the way.

 

Not sure if it's an HTC glitch or an Android glitch, but I found a similar report discussing issues with EARFCNs above 47000, so I added to it. If anyone wants to 'star' this on the Android Issue Tracker, it might help get the Android developer team's attention.

 

-Mike

  • Like 1
Link to comment
Share on other sites

I think I might have accidentally figured this out. Simple math:

 

NSG EARFCN (66486) - SCP EARFCN (950) = 65536

 

65536 is 216, aka the max 16-bit integer. The API specifies it is a 18-bit integer, but I'm guessing something buried inside the OS got messed up along the way.

 

Not sure if it's an HTC glitch or an Android glitch, but I found a similar report discussing issues with EARFCNs above 47000, so I added to it. If anyone wants to 'star' this on the Android Issue Tracker, it might help get the Android developer team's attention.

 

-Mike

 

I suspect you're right.  AT&T PCS in this area has an EARFCN of 850, not 950. 

 

I starred it as well.  That's... really unhelpful if true. 

 

- Trip

  • Like 2
Link to comment
Share on other sites

Any word from Samsung about native Earfcn support?

 

Nothing since my initial back-and-forth with them. Sent a follow-up status check last week and haven't heard back. Shot a tweet and developer forum post at them too. I was surprised to get any reply initially (I've tried reaching out to them in the past) but it gave me some optimism. I will keep on them.

 

IIRC, back when GCIs were added in Android 4.2, they were the last OEM to properly report those too..

 

-Mike

  • Like 2
Link to comment
Share on other sites

Nothing since my initial back-and-forth with them. Sent a follow-up status check last week and haven't heard back. Shot a tweet and developer forum post at them too. I was surprised to get any reply initially (I've tried reaching out to them in the past) but it gave me some optimism. I will keep on them.

 

IIRC, back when GCIs were added in Android 4.2, they were the last OEM to properly report those too..

 

-Mike

Thanks Mike, I really don't want to root my S8+. Appreciate all you do.

 

Sent from my SM-G955U using Tapatalk

  • Like 2
Link to comment
Share on other sites

The unsigned 16 bit integer range actually is 0-65,535.  So, 65,536 would be the first 17 bit integer.  But I do think that you are on to something.

 

AJ

  • Like 2
Link to comment
Share on other sites

Any word from Samsung about native Earfcn support?

 

I received a tweet and some DMs from Samsung tonight. They want specifics about which devices are experiencing this issue. If you (and anyone else with a Samsung on Android 7 that does not see any LTE EARFCNs displayed) could go to About > Send Diagnostics and send me a report, that will give me all the information I need. Please include a mention about why you are sending the report so it doesn't get lost in the pile.

 

(EDIT: I already found recent reports from @nowerlater and @Mr.Nuke. Anyone else, feel free to send.)

 

Thanks!

-Mike

  • Like 3
Link to comment
Share on other sites

 

I received a tweet and some DMs from Samsung tonight. They want specifics about which devices are experiencing this issue. If you (and anyone else with a Samsung on Android 7 that does not see any LTE EARFCNs displayed) could go to About > Send Diagnostics and send me a report, that will give me all the information I need. Please include a mention about why you are sending the report so it doesn't get lost in the pile.

 

(EDIT: I already found recent reports from @nowerlater and @Mr.Nuke. Anyone else, feel free to send.)

 

Thanks!

-Mike

 

I keep getting an unable to send diagnostics message when I try to send it.

Link to comment
Share on other sites

I keep getting an unable to send diagnostics message when I try to send it.

Hmm, same here apparently. Something happened on my hosting provider's end, nobody will be able to send any. Will update this post when I get it resolved.. thanks for the heads up!

 

EDIT: It's partially working again.. still fails about 25% of the time, nobody can figure out why. I will keep on it.

 

-Mike

Edited by mikejeep
Link to comment
Share on other sites

For a future build, it would be worth making it possible to dump the disgnostics into a file for later submission.  I have several phones with no service that I am basically unable to send diagnostics as a result.  By the time I'm home on Wifi on those devices, it's too late and I've lost whatever I wanted to show you.

 

- Trip

  • Like 1
Link to comment
Share on other sites

 

I received a tweet and some DMs from Samsung tonight. They want specifics about which devices are experiencing this issue. If you (and anyone else with a Samsung on Android 7 that does not see any LTE EARFCNs displayed) could go to About > Send Diagnostics and send me a report, that will give me all the information I need. Please include a mention about why you are sending the report so it doesn't get lost in the pile.

 

Nevermind.. that was a waste of time. Pretty sure whoever reached out was just some sort of overseas script-reader who cleans out tweets. I was told in broken English that my feedback was "appreciated" and "interesting" but until the phone programming is changed, that feature will not be available. I asked to have it escalated or passed on to an appropriate team, and got a generic "Thanks for being our customer!" back. I didn't expect much from their generic social media support, but I expected more than that..

 

-Mike

Link to comment
Share on other sites

For a future build, it would be worth making it possible to dump the disgnostics into a file for later submission.  I have several phones with no service that I am basically unable to send diagnostics as a result.  By the time I'm home on Wifi on those devices, it's too late and I've lost whatever I wanted to show you.

 

I would like to make the diagnostics more robust, right now it just crudely tries to send it once and bails if it doesn't work. I was mostly concerned with better handling of short-term network interruptions, and hadn't considered that some devices might only be able to send data on Wi-Fi. Definitely something I could improve.

 

-Mike

  • Like 2
Link to comment
Share on other sites

I would like to make the diagnostics more robust, right now it just crudely tries to send it once and bails if it doesn't work. I was mostly concerned with better handling of short-term network interruptions, and hadn't considered that some devices might only be able to send data on Wi-Fi. Definitely something I could improve.

 

-Mike

 

Three of my phone have SIMs and connect to the network, but have no service associated (two T-Mo, one Verizon).  So it's definitely something I've encountered.

 

- Trip

  • Like 1
Link to comment
Share on other sites

Three of my phone have SIMs and connect to the network, but have no service associated (two T-Mo, one Verizon).  So it's definitely something I've encountered.

 

- Trip

 

I know of others who do the same with various carriers.

  • Like 1
Link to comment
Share on other sites

Mike, I've encountered a bug where changing a site note on the 1x side doesn't change them all. I remember the lte notes did the same thing but you fixed that. Any way to address this in future builds? Thanks for all you do!

 

Sent from my SM-G955U using Tapatalk

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

    • On Reddit, someone asked (skeptically) if the US Cellular buyout would result in better service.  I'd been pondering this very issue, and decided to cross-post my response here: I've been pondering the question in the title and I've come to the conclusion that the answer is that it's possible. Hear me out. Unlike some of the small carriers that work exclusively with one larger carrier, all three major carriers roam on US Cellular today in at least some areas, so far as I know. If that network ceases to exist, then the carriers would presumably want to recover those areas of lost service by building out natively. Thus, people in those areas who may only have service from US Cellular or from US Cellular and one other may gain competition from other carriers backfilling that loss. How likely is it? I'm not sure. But it's definitely feasible. Most notably, AT&T did their big roaming deal with US Cellular in support of FirstNet in places where they lacked native coverage. They can't just lose a huge chunk of coverage whole still making FirstNet happy; I suspect they'll have to build out and recover at least some of that area, if not most of it. So it'd be indirect, but I could imagine it. - Trip
    • Historically, T-Mobile has been the only carrier contracting with Crown Castle Solutions, at least in Brooklyn. I did a quick count of the ~35 nodes currently marked as "installed" and everything mapped appears to be T-Mobile. However, they have a macro sector pointed directly at this site and seem to continue relying on the older-style DAS nodes. Additionally, there's another Crown Castle Solutions node approved for construction just around the corner, well within range of their macro. I wouldn’t be surprised to see Verizon using a new vendor for their mmWave build, especially since the macro site directly behind this node lacks mmWave/CBRS deployment (limited to LTE plus C-Band). However, opting for a multi-carrier solution here seems unlikely unless another carrier has actually joined the build. This node is equidistant (about five blocks) between two AT&T macro sites, and there are no oDAS nodes deployed nearby. Although I'm not currently mapping AT&T, based on CellMapper, it appears to be right on cell edge for both sites. Regardless, it appears that whoever is deploying is planning for a significant build. There are eight Crown Castle Solutions nodes approved for construction in a 12-block by 2-block area.
    • Starlink (1900mhz) for T-Mobile, AST SpaceMobile (700mhz and 850mhz) for AT&T, GlobalStar (unknown frequency) for Apple, Iridium (unknown frequency) for Samsung, and AST SpaceMobile (850mhz) for Verizon only work on frequency bands the carrier has licensed nationwide.  These systems broadcast and listen on multiple frequencies at the same time in areas much wider than normal cellular market license areas.  They would struggle with only broadcasting certain frequencies only in certain markets so instead they require a nationwide license.  With the antennas that are included on the satellites, they have range of cellular band frequencies they support and can have different frequencies with different providers in each supported country.  The cellular bands in use are typically 5mhz x 5mhz bands (37.5mbps total for the entire cell) or smaller so they do not have a lot of data bandwidth for the satellite band covering a very large plot of land with potentially millions of customers in a single large cellular satellite cell.  I have heard that each of Starlink's cells sharing that bandwidth will cover 75 or more miles. Satellite cellular connectivity will be set to the lowest priority connection just before SOS service on supported mobile devices and is made available nationwide in supported countries.  The mobile device rules pushed by the provider decide when and where the device is allowed to connect to the satellite service and what services can be provided over that connection.  The satellite has a weak receiving antenna and is moving very quickly so any significant obstructions above your mobile device antenna could cause it not to work.  All the cellular satellite services are starting with texting only and some of them like Apple's solution only support a predefined set of text messages.  Eventually it is expected that a limited number of simultaneous voice calls (VoLTE) will run on these per satellite cell.  Any spare data will then be available as an extremely slow LTE data connection as it could potentially be shared by millions of people.  Satellite data from the way these are currently configured will likely never work well enough to use unless you are in a very remote location.
    • T-Mobile owns the PCS G-block across the contiguous U.S. so they can just use that spectrum to broadcast direct to cell. Ideally your phone would only connect to it in areas where there isn't any terrestrial service available.
  • Recently Browsing

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