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

[mikejeep]

Also might be easy thing to add I hope.

 

The third band 41 carrier for Samsung markets appears to end in GCI 06/07/08(?).

 

I saw some discussion about that but wasn't certain it had been confirmed. Would it be most consistent to identify it as B41³ ?

 

-Mike

[lilotimz]

I saw some discussion about that but wasn't certain it had been confirmed. Would it be most consistent to identify it as B41³ ?

 

-Mike

I suppose.

 

Also please note #squared or #cubed etc doesn't mean carrier aggregation is live. It just means that the GCI correspond to an additional LTE carrier being live and could mean CA is live band 41 but not so for band 25 (no CA on b25 deployed currently).

[mikejeep]

I suppose.

 

Also please note #squared or #cubed etc doesn't mean carrier aggregation is live. It just means that the GCI correspond to an additional LTE carrier being live and could mean CA is live band 41 but not so for band 25 (no CA on b25 deployed currently).

 

Got it. I'm aware of the potential for CA confusion; I started using "B##²" as a simple way to indicate a second carrier. Looking back now, perhaps "B##-2" might have been better, but it's been so long I think the resulting end-user confusion would be even worse.

 

-Mike

[Trip]

Trip, could you PM me a screenshot? The new scheme just uses the default Material theme, so it shouldn't be wildly different. On my 3 Nexus devices the headers are slightly brighter but everything is still clearly visible. I intended to add theming options soon but I could accelerate that if it's an issue.

 

Mike,

 

I've e-mailed it to you.

 

- Trip

[Flompholph]

That is a big hole I do need to add error checking to. In the meantime, you don't need to uninstall, you can just Clear Data through your device's Settings menu. When you import, it does automatically create a backup of your existing data so you could then re-import that file. But I agree that needs to be addressed sooner rather than later. I need to create some reference documentation for those features too.

-Mike

I didn't think of that thanks. There are some neat toast meassages at least.

[WiWavelength]

I suppose.

 

Also please note #squared or #cubed etc doesn't mean carrier aggregation is live. It just means that the GCI correspond to an additional LTE carrier being live and could mean CA is live band 41 but not so for band 25 (no CA on b25 deployed currently).

 

mikejeep is the developer, so he gets to make the ultimate call.  But I know that I have stumped for months for a switch to a "Bxx#2" and "Bxx#3" type carrier numbering scheme.  He is concerned that will increase user confusion.  However, user confusion already is rampant.  Frequently, we have to remind or educate users that "B41^2" does not necessarily indicate 2x CA -- and that "B25^2" does not indicate 2x CA at all, no way, no how.

 

AJ

[lilotimz]

I saw some discussion about that but wasn't certain it had been confirmed. Would it be most consistent to identify it as B41³ ?

 

-Mike

 

I've confirmed that the 3rd B41 carrier for Samsung markets end in 06/07/08...

 

Hoping a quick Beta update to identify that is sent out soon! They are mass launching it now!

[Overstew]

I've confirmed that the 3rd B41 carrier for Samsung markets end in 06/07/08...

 

Hoping a quick Beta update to identify that is sent out soon! They are mass launching it now!

..Anything for Nokia markets?

[mikejeep]

I've confirmed that the 3rd B41 carrier for Samsung markets end in 06/07/08...

 

Hoping a quick Beta update to identify that is sent out soon! They are mass launching it now!

 

Soon™ -- aka however fast Google Play decides to publish what I uploaded a few minutes ago...

 

-Mike

[ingenium]

It crashes for me when I have the background service disabled and either exit the app (via home, back, or task switcher, but not the in app exit command) or when I try to open preferences. It seems the broadcast receiver for the background service may be getting terminated prematurely.

 

I wiped data and tried again, but the problem persists. If I then manually edit the preferences file to enable the persistent background service (since I can't change it in the app), then it doesn't crash on exit since the service stays running. If I select "exit" from the menu it works correctly. If I then go into preferences and disable the background service, it crashes on app exit again using any method other than "exit" from the overflow menu in the app.

 

Sent from my Nexus 6P

[lilotimz]

Minor nitpick. It's Dl/UL earfcn (center frequency) and not channel.

[mikejeep]

It crashes for me when I have the background service disabled and either exit the app (via home, back, or task switcher, but not the in app exit command) or when I try to open preferences. It seems the broadcast receiver for the background service may be getting terminated prematurely.

 

I wiped data and tried again, but the problem persists. If I then manually edit the preferences file to enable the persistent background service (since I can't change it in the app), then it doesn't crash on exit since the service stays running. If I select "exit" from the menu it works correctly. If I then go into preferences and disable the background service, it crashes on app exit again using any method other than "exit" from the overflow menu in the app.

 

Sent from my Nexus 6P

Ahhh no matter how much I test, I always miss something. Thank you for the detailed feedback, you made it easy for me to pinpoint the problem! I pushed out an update an hour ago, that should resolve it.

 

-Mike

[mikejeep]

Minor nitpick. It's Dl/UL earfcn (center frequency) and not channel.

Ah, hadn't thought much about that. I just kept the same terminology that's been in place for HTC devices from the beginning. I believe I got that from the engineering screens.

 

-Mike

[Trip]

Soon™ -- aka however fast Google Play decides to publish what I uploaded a few minutes ago...

 

-Mike

 

Mike,

 

Thanks first for dealing with the text color issue.  It was really causing me a problem over the weekend when I was driving around in the bright sunlight.

 

Second, my T-Mobile phone has shown me the EARFCN a handful of times, but otherwise shows nothing, including right now as I sit at work on the DAS outside my door.  I had to switch it to smd0 before it showed anything.  This despite Cell Mapper showing it consistently.  Is this the sort of thing sending a report back to you would be helpful with?

 

- Trip

[Overstew]

Hello Mikejeep,

 

Looks like other apps read the signal fine on my work DAS, but not Signalcheck.

[Trip]

Second, my T-Mobile phone has shown me the EARFCN a handful of times, but otherwise shows nothing, including right now as I sit at work on the DAS outside my door.  I had to switch it to smd0 before it showed anything.  This despite Cell Mapper showing it consistently.  Is this the sort of thing sending a report back to you would be helpful with?

 

I just confirmed /dev/smd0 is actually invalid on my device; I needed smd11.  So I've switched that back and, at the moment, I have EARFCN.  I'll keep an eye on it on the walk to the Metro and see if it behaves.

 

Also, just in case you missed this:  https://code.google.com/p/android/issues/detail?id=195574

 

- Trip

[lilotimz]

Well well well.. 

 

 

 

[mikejeep]

Looks like other apps read the signal fine on my work DAS, but not Signalcheck.

 

Thanks for the update.. since other apps see the DAS, I am fairly confident that it's related to the bug that appears to be fixed in the latest beta. A couple new glitches have already popped up in testing that I'm working on ironing out now, but it shouldn't be too long before I'm able to get a public update out.

 

I just confirmed /dev/smd0 is actually invalid on my device; I needed smd11.  So I've switched that back and, at the moment, I have EARFCN.  I'll keep an eye on it on the walk to the Metro and see if it behaves.

 

Also, just in case you missed this:  https://code.google.com/p/android/issues/detail?id=195574

 

I eventually hope to gather the proper /dev/* paths for as many devices as I can, so the app can default to the most appropriate configuration based on the device. smd11 came up the most when I was researching it, which is why that's the blanket default for now. I can't find anything that works on the N6. If anyone confirms the proper settings for other devices, please share it here so myself and others can benefit!

 

I am well aware of the new EARFCN support built into Android N, I've been following a few of those bug trackers for awhile.. awesome to see it finally coming down the pipe, even if it's rather broken at the moment. As was the case with the major additions to the Android 4.2 API, it will probably be some time before it's widely supported -- but I really hope I'm wrong.

 

-Mike

[Trip]

Thanks for the update.. since other apps see the DAS, I am fairly confident that it's related to the bug that appears to be fixed in the latest beta. A couple new glitches have already popped up in testing that I'm working on ironing out now, but it shouldn't be too long before I'm able to get a public update out.

 

Mike,

 

It seems you were right.  I updated again and now the EARFCN is much more consistent.  It doesn't pop up right away, but after the first update of a connected cell, I see the EARFCN.  (My T-Mobile phone is the one that has a really slow update frequency.)

 

- Trip

[mikejeep]

 

 

It seems you were right. I updated again and now the EARFCN is much more consistent. It doesn't pop up right away, but after the first update of a connected cell, I see the EARFCN. (My T-Mobile phone is the one that has a really slow update frequency.)

I think you replies to my comment to Overstew..? In any case, you mentioned something important I wanted to explain -- the EARFCN data. It takes quite a bit longer to get the return from the modem than it does to get the other signal information. My current approach is to show the EARFCN data on the first screen refresh after it becomes available. To ensure this information is never stale, it is flushed once the device changes to a new sector (or site). Because of this, the EARFCN data typically disappears for a moment. But I'd rather have it disappear instead of showing (and logging) stale info.

 

-Mike

[Trip]

I think you replies to my comment to Overstew..? In any case, you mentioned something important I wanted to explain -- the EARFCN data. It takes quite a bit longer to get the return from the modem than it does to get the other signal information. My current approach is to show the EARFCN data on the first screen refresh after it becomes available. To ensure this information is never stale, it is flushed once the device changes to a new sector (or site). Because of this, the EARFCN data typically disappears for a moment. But I'd rather have it disappear instead of showing (and logging) stale info.

 

-Mike

 

I did respond to your response to Overstew, but it was still relevant because I hadn't gotten the second update before I left for work that morning.

 

I more or less figured out that was what it did.  Not to make more work for you, but is there any way to have an option to allow it refresh again as soon as the EARFCN becomes available?  In the general case that probably doesn't matter, but given that this phone in particular sometimes goes 20 seconds between updates otherwise, it can be quite the waiting game.

 

And I agree, I'd rather have no data than bad data.

 

- Trip

[mikejeep]

Not to make more work for you, but is there any way to have an option to allow it refresh again as soon as the EARFCN becomes available? In the general case that probably doesn't matter, but given that this phone in particular sometimes goes 20 seconds between updates otherwise, it can be quite the waiting game.

I want to, but that was the problem that held up getting the update out. I cannot reliably confirm that the signal data and EARFCN are in sync. The way the data would be updated on the screen could cause a stale EARFCN to be displayed/logged. Waiting to refresh the screen until the modem returned a result proved to be unstable, and the time it takes the result to come back varies. The method currently in place gets the information displayed as quickly as it can without sacrificing reliability. If I can figure out a better method in the future, I will implement it.

 

-Mike

[Trip]

I want to, but that was the problem that held up getting the update out. I cannot reliably confirm that the signal data and EARFCN are in sync. The way the data would be updated on the screen could cause a stale EARFCN to be displayed/logged. Waiting to refresh the screen until the modem returned a result proved to be unstable, and the time it takes the result to come back varies. The method currently in place gets the information displayed as quickly as it can without sacrificing reliability. If I can figure out a better method in the future, I will implement it.

 

-Mike

 

Understood.  Kind of disappointing but not your fault in the slightest.  Here's hoping Android N takes care of this once and for all. 

 

- Trip

[mikejeep]

New SignalCheck Pro updates pushed out to Google Play for EVERYONE this afternoon! Will post full details tonight or tomorrow, check the website change log for a summary.. enjoy!

 

-Mike

[kg4icg]

Have it up and running now.

 

Sent from my LGLS996 using Tapatalk