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

[dkyeager]

Interesting. Until now 06/07/08 along with an 'odd' third GCI character indicated B41 third carrier. Can you confirm that you've only been seeing this with 'even' third characters?

 

 

http://s4gru.com/index.php?/topic/4742-columbus-market-mapspreadsheet/page-219&do=findComment&comment=476707

[bretton88]

Signal check reports a huge battery drain on the note 5, why is that?

[kct1975]

Okay so I have been a big fan of Signal Check, and I still am...but I would like to know why, after the last Google Android Security Update, the Signal Check app crashes whenever I attempt to open the main home screen

 

Please let me know if it is due to a bug in the app or if something is wrong with my phone

[mikejeep]

Signal check reports a huge battery drain on the note 5, why is that?

 

Have you been leaving it on the screen frequently? Do you have Location Service enabled, and if so are you using High Accuracy mode? There really isn't anything else that should noticeably impact battery life. Some of those battery screens are not as accurate and/or report stats in a manner that most users misinterpret. For example, you might leave SignalCheck running in the foreground for 6 hours while you drive. Some devices may report that as "Screen" usage, while others report it under SignalCheck. Other apps may show a percentage that appears to be power usage, but is actually representative of percentage of total power used (i.e. 10% means "10% of the power that has been used", not "10% of total battery capacity"). I do not know of any battery drain issues in any recent releases of the app.

 

Okay so I have been a big fan of Signal Check, and I still am...but I would like to know why, after the last Google Android Security Update, the Signal Check app crashes whenever I attempt to open the main home screen

 

Please let me know if it is due to a bug in the app or if something is wrong with my phone

 

What device and what Android version? My crash monitoring service is only showing a modest number of force closes, mostly nonspecific errors somehow related to notifications. In the overall scheme of things it has only impacted a very small percentage of users. Unfortunately it doesn't report security patch date or build number, only Android version.

 

It seems odd that there would be a code change in a security update significant enough to break something, but I guess anything is possible..

 

-Mike

[bretton88]

Have you been leaving it on the screen frequently? Do you have Location Service enabled, and if so are you using High Accuracy mode? There really isn't anything else that should noticeably impact battery life. Some of those battery screens are not as accurate and/or report stats in a manner that most users misinterpret. For example, you might leave SignalCheck running in the foreground for 6 hours while you drive. Some devices may report that as "Screen" usage, while others report it under SignalCheck. Other apps may show a percentage that appears to be power usage, but is actually representative of percentage of total power used (i.e. 10% means "10% of the power that has been used", not "10% of total battery capacity"). I do not know of any battery drain issues in any recent releases of the app.

 

 

What device and what Android version? My crash monitoring service is only showing a modest number of force closes, mostly nonspecific errors somehow related to notifications. In the overall scheme of things it has only impacted a very small percentage of users. Unfortunately it doesn't report security patch date or build number, only Android version.

 

It seems odd that there would be a code change in a security update significant enough to break something, but I guess anything is possible..

 

-Mike

I always run signal check in the background, with high accuracy mode on. The battery indicator shows SCP at 24-26% usage. My Nexus 5 it would always be a couple %.

[mikejeep]

I always run signal check in the background, with high accuracy mode on. The battery indicator shows SCP at 24-26% usage. My Nexus 5 it would always be a couple %.

 

Again, it could just be a matter of each device displaying identical battery usage in a different fashion. Or the GPS routines on the Note 5 are somehow far less efficient than on the Nexus 5. Your comparison of the same behavior producing different results with different devices is a reasonably strong argument that it's a device issue (if there even is a true "issue"), not an app issue..

 

-Mike

[bmoses]

mike, just wanted to pass along a GCI pattern to you. i've been checking out iWireless in Iowa (which is T-Mobile) and so far everything has worked great for identifying the sectors for AWS which is what they are deploying. the only issue i've found is that they have deployed quite a few 4 sector sites. on these sites the 4th sector has its own GCI that is different than the GCI of the other 3 sectors of the tower, but it ends in 04 and so its not being identified as AWS, it just lists LTE when connected to those sectors. any questions let me know, thanks!

[kct1975]

 

 

 

What device and what Android version? My crash monitoring service is only showing a modest number of force closes, mostly nonspecific errors somehow related to notifications. In the overall scheme of things it has only impacted a very small percentage of users. Unfortunately it doesn't report security patch date or build number, only Android version.

 

It seems odd that there would be a code change in a security update significant enough to break something, but I guess anything is possible..

 

-Mike

Thanks for the reply Mike.

 

The problem that I seem to be experiencing happens when I pull down the Notification Shade, and then tap the Signal Check Notification link. As the Signal Check app starts, about Half of the Time, the app crashes.

 

As I mentioned, these problems seemed to have started after the latest Android Security Update downloaded and installed.

 

I have a Nexus 6 with the latest Security Update. As you requested, below is a screenshot with all of the information you requested...

 

[WiWavelength]

Mike...

 

You might want to see this post.  It could explain the SignalCheck Pro "bug" of simultaneous CDMA1X and LTE signal metrics display on many recent handsets.

 

 

I do wonder, also, if a temporary switch from e/CSFB to SRLTE mode on certain Android handsets could explain the SignalCheck Pro "bug" in which CDMA1X and LTE signal metrics get displayed simultaneously -- usually in low LTE signal conditions.  That simultaneous monitoring of both networks supposedly was not possible on e/CSFB single radio path handsets.  Maybe SRLTE solves the mystery.

 

http://s4gru.com/index.php?/topic/7164-iphone-6s6s-plus-user-thread/?p=477344

 

AJ

[jefbal99]

Mike...

 

You might want to see this post.  It could explain the SignalCheck Pro "bug" of simultaneous CDMA1X and LTE signal metrics display on many recent handsets.

 

 

http://s4gru.com/index.php?/topic/7164-iphone-6s6s-plus-user-thread/?p=477344

 

AJ

Hasn't this been the thing that many users have speculated about since this issue first started coming up?

[WiWavelength]

Hasn't this been the thing that many users have speculated about since this issue first started coming up?

 

I think that "many users" was me.  I also pointed out that e/CSFB single radio path means single Tx, not necessarily single Rx.  And I am the first to bring up the possibility of SRLTE.

 

AJ

[jefbal99]

I think that "many users" was me.  I also pointed out that e/CSFB single radio path means single Tx, not necessarily single Rx.  And I am the first to bring up the possibility of SRLTE.

 

AJ

You definitely have the technological background and specific knowledge, but many in this thread have speculated that somehow the OS in monitoring both the CDMA and LTE channels.  Essentially saying that Android and the app weren't broken or to blame, just working as defined in the modem.

 

No one has mentioned a specific technology or reason, just best guesses as to why a single Tx path device would be displaying two different networks.

[dkyeager]

Hasn't this been the thing that many users have speculated about since this issue first started coming up?

 

Phones are looking around to maintain and use the LTE Available List by SID-NID-BID so they can more quickly connect to LTE.  http://s4gru.com/index.php?/topic/3060-signalcheck-android-app-to-monitor-your-2g3g4g-lte-signal-strengths/page-172&do=findComment&comment=432284

[S4GRU]

You definitely have the technological background and specific knowledge, but many in this thread have speculated that somehow the OS in monitoring both the CDMA and LTE channels. Essentially saying that Android and the app weren't broken or to blame, just working as defined in the modem.

 

No one has mentioned a specific technology or reason, just best guesses as to why a single Tx path device would be displaying two different networks.

That's the point. Many wondered if something 'like that' was happening. But few ever talked about it technically and with certainty. And only one figured it out specifically and did the leg work. I don't recall any discussions specifically of two receive paths but only one transmit path. This is truly unique and likely explains the question that has plagued us all for awhile. AJ's effort should not be minimized because people wondered and guessed.

 

Using Tapatalk on Note 8.0

[dkyeager]

Given the threat of patent lawyers, I would assume a slightly different explanation will ultimately be found for Android phones.  I only saw this issue on CA phones.  The common view was it was a bug, I saw it as a benefit. 

 

WiWavelength's work is well researched and definitely a welcome addition for S4GRU.

[ingenium]

Given the threat of patent lawyers, I would assume a slightly different explanation will ultimately be found for Android phones. I only saw this issue on CA phones. The common view was it was a bug, I saw it as a benefit.

 

WiWavelength's work is well researched and definitely a welcome addition for S4GRU.

Sprint CA phones, or phones capable of CA on any carrier? Because the Nexus 6 got this "issue" after the Marshmallow upgrade, but didn't have it with Lollipop.

 

Sent from my Nexus 6P

[dkyeager]

Sprint CA phones, or phones capable of CA on any carrier? Because the Nexus 6 got this "issue" after the Marshmallow upgrade, but didn't have it with Lollipop.

 

Sent from my Nexus 6P

Correct addition. It takes a village.

 

Sent from my LGLS991 using Tapatalk

[WiWavelength]

Sprint CA phones, or phones capable of CA on any carrier? Because the Nexus 6 got this "issue" after the Marshmallow upgrade, but didn't have it with Lollipop.

 

If this actually is SRLTE, it seems a capability that was added to Android radio firmware with Marshmallow and beyond.

 

AJ

[jefbal99]

Appears as a change when going from 5.1.1 to 6.0.1 in the Android Wear AOSP changelog.  I'd wager a bet a similar find would be in the 5.1.1->6.0 AOSP changelog too

 

https://android.googlesource.com/platform/packages/services/Telephony/+/5cb43e4

[greenbastard]

Sprint CA phones, or phones capable of CA on any carrier? Because the Nexus 6 got this "issue" after the Marshmallow upgrade, but didn't have it with Lollipop.

 

Sent from my Nexus 6P

Probably so since I never had this issue with my Sprint Galaxy S5 on Marshmallow (Does not have CA). Never saw both 1x and LTE on SCP.

 

My Nexus 5x  (a CA phone) sees this issue a lot (mostly after losing and regaining LTE). For many, this may seem like a cool feature, but for me its something I hope they fix in an update so the phone relies on eCSFB exclusively. When this 'bug' (or feature...it's all relative) appears, all SMS are routed through 1x instead of LTE. With 1x, messages take about 4-5 seconds to send (which is not really an issue unless you're used to LTE's quickness...which I am). Incoming SMS on the other hand take sometimes up to 30 seconds to receive. It's really annoying and a step backwards IMO. With LTE, SMS are almost always instant. For quick measure, you can text 'Usage' to 1311 on LTE and then do the same on 1x to compare the time consumed for each to receive a reply.

 

But most annoying thing about this 'issue' is that your phone has to drop LTE for a fraction of a second (almost like a slight ping) to retrieve/send SMS (just like how old single path phones used to drop EVDO to receive/send messages before the LTE days) If you have a live stream going or are doing a video chat, prepare for timeouts.

[Joski1624]

Again, it could just be a matter of each device displaying identical battery usage in a different fashion. Or the GPS routines on the Note 5 are somehow far less efficient than on the Nexus 5. Your comparison of the same behavior producing different results with different devices is a reasonably strong argument that it's a device issue (if there even is a true "issue"), not an app issue..

 

-Mike

Yup, I've also got a device that likes to blame SignalCheck for battery drain even if I leave it off for a majority of the battery discharge duration. I don't perceive any noticeable difference in battery drain regardless if SCP is running or not. The real culprit is the screen, but the phone will only blame the screen if I leave SCP off the entire time.

[Ascertion]

Hey @MikeJeep,

 

Did we ever find the solution to the T-Mobile S7 not displaying WCDMA/HSPA+ signal?  In Signalcheck it just shows No Connection.  It doesn't matter where I am, as long as it's on WCDMA.

[kct1975]

Mike,

 

I just thought I would mention that I am still having a few small issues with SCP.

 

Just recently, over half of the time I open the SCP screen, all I get is a completely blank screen.

 

Also frequently, instead of seeing the SCP signal bars I get 'Status Icon' symbol and message.

 

Just for reference, I have a Nexus 6 that is running Stock Android with the latest May Security patch.

 

As I mentioned before, I can easily live with the minor bugs that I am currently experiencing, it's just that I want to let you know about them.

[Trip]

I'm not sure if this is a bug or an unsupported behavior.  I took this picture this morning while sitting in the Crystal City Metro station.

 

 

Look carefully at the PCI of the connected cell versus the PCI of the neighbor cell.

 

In Crystal City and Pentagon City Metro stations, the 02 and 1A sectors of 0303DFxx are used with PCI 403.  In Pentagon Metro, the 01 and 19 sectors of 0303DFxx are used with PCI 234.  So in my database, I set the notes for each of the sectors differently to match where they actually belong.  That is, 0303DF02 and 0303DF1A say "Crystal City/Pentagon City (U)" while 0303DF01 and 0303DF19 say "Pentagon Metro (U)".  Despite this, the note for the 01/19 sector is showing even though I'm connected to 1A in the picture.  (But then the correct note is used for the neighbor cell!)

 

I know that the sectors are linked so that the app is smart enough to link newly-seen sectors together (as well as connecting B41 with B25/B26) and when you set a site note from within the app it rewrites all the associated ones, which is all fine and preferred, but I didn't think it did that when reading back out of the database as well. 

 

Thoughts?

 

- Trip

[Flompholph]

So Pentagon Metro(U) is listed first in the db? Maybe mikejeep is looking just at the 0303DF part and then finds the first note. That will cause an issue with small cell/DAS because I know in Cleveland a group of small cells (ODAS?) share the same GCI like yours but separated by sectors. Like what you are doing they are separated by different notes because they are in different places.

 

Easy way to test would be include in the note for each sector Sector 01, Sector 02, then Sector 03. Then see which ones show up over and over.