mikejeep

Another beta release was just pushed out and should appear on Google Play within the hour.. resolves an issue from 4.492b that caused Sprint LTE sites to get mislabeled (missing carriers and MM/SC/10x10 indicators). Mobile IP address display is also back--nobody told me it was broken, but I just discovered that it hadn't worked for 2 months! This release also *might* resolve the significant bug that caused LTE band information to disappear when the PLMN ID changed (you would just see "LTE" until it connected to another cell).. fingers crossed.. -Mike

Updated the beta again.. fixed a glitch that was causing force closes at startup if you had the Background Service disabled. Figured most people wouldn't have even seen the first update overnight so I'd sneak another one in there.. -Mike

New beta should be available on Google Play within the hour. Fixed numerous bugs, several which first appeared in the beta from last week. Added some of the new stuff, will be adding more and continuing to squash bugs.. -Mike

Yep, same here.. gave up on Google Voice voicemail and switched back to Sprint. It appears you can have Wi-Fi Calling or GV voicemail, but not both. Annoying. Sprint Visual Voicemail app is on Google Play for most devices.. works ok on my Pixel 3 with some minor nuisances. Notifications work but don't include contact name if you have it saved.. no transcription unless you subscribe for a monthly fee, and if you don't, the banner begging you to subscribe remains displayed in the app.. https://play.google.com/store/apps/details?id=com.sprint.vvm -Mike

You are correct, my bad! I dug around and found a loophole in the routine that identifies Mini Macro and Small Cell sites that I think will resolve this. Yes, this is a known issue with the current SignalCheck beta -- all of the System Shortcuts and the Reset Connection feature are also broken. I'm just about done repairing all of that damage.. a new beta will be up tonight that resolves most of it. I will continue working on some less-prevalent bugs that have come up. Moving from targeting Android 7.1 to 9.0 was an enormous change behind the scenes in this release, which I anticipated.. I hope that some of the changes will help improve the app's efficiency. I encourage people to hit "Send Feedback" whenever the app crashes and that screen appears; it files a crash report via Google Play that I have access to. However, sometimes those reports don't contain enough information to help me pinpoint the issue. I have a secondary error collector that does almost the same thing but includes more info that indicates specifically what part of the code triggered it, but depending on the manner of the crash it might not actually have a chance to execute. The more data I can gather about problems, the easier it is to track them down. I monitor a lot of statistics about how the app is performing, not just force closes but also routines that take too long to execute. I'm always trying to improve the numbers.. when a new public version is released it's fun to see the crash numbers plummet when I fix something.. less fun to see them spike.. -Mike

Oh I like this.. sorry if you mentioned it before and it slipped through the cracks. I think matching any Sprint-related PLMN is a good idea, I'm very happy with how that change has worked out so far on active cell. Carrying the concept over to the neighbor cells does make sense. Thanks -- I'll add DA and then DD-DF! That is showing MM because the GCI has an "even" third character and ends in 31.. the typical Sprint configuration for a MM. But I know Shentel uses 0FE and 0FF, so those even/odd rules might not apply in that region. Does Shentel have any mini macros? (oops, see below) -Mike

Hmm I don't remember specifically what you suggested changing about neighbor notes? I looked back at my flagged e-mails and I didn't see anything.. I'm sure it's somewhere but refresh my memory! I didn't realize you had sent diagnostics, I just searched and found a DA and a DD from you -- if you're certain that those sectors are band 14, I'll add them since they don't conflict with any other information I have. No DB or DC? -Mike

A new database entry would be added because the app would see it as a new PLMN and GCI. So that would result in the same GCI having multiple entries, but the new entry would be copying in the old entry's site note. If the Logger is running, the new entry will be populated with all of the cell info available. Hypothetical example.. you have a local Sprint site 123456AA that you logged months or years ago under 310120. Next week, your phone suddenly starts reporting everything as 312530 like several of us experienced recently. So, when you hit 123456AA for the first time: Previous versions of SignalCheck would not find anything in the database, and consider it a brand new site. A new log entry would be created as 312530/123456AA. There would be no site note, because the app didn't look beyond 312530 for it. The new logic implemented in this beta would initially not find anything in the database, but then in searching all of the Sprint PLMNs it would see the 310120 entry. A new log entry would be created as 312530/123456AA, using the site note pulled from the original log entry. In both instances, you're getting a new (potentially bogus) database entry. The new method pulls the existing site note over. Similar logic can be applied to Clear sites, which report a different PLMN. Many devices do not update the PLMN and GCI at the same time; therefore, there are probably duplicate entries in your log, half of which have no site note. I know I had a ton of Clear GCIs logged with Sprint PLMNs and vice versa. Yes, half of them are wrong. But until networks and/or devices behave differently, this problem is going to continue. I see this new logic as a solution so that instead of blank site notes, you get an accurate site note stored for the "new" cell you hit. The only potential issue is that if GCIs are legitimately duplicated across the Sprint network under different PLMNs, and you happen to connect to both sites. Then a site note will be pulled that really shouldn't be. But that's a very very slim potential compared to the 99.99% of times this feature is going to benefit users IMHO. It's tricky, because there's no easy way to know if a PLMN ID is accurate or a hiccup. But the app is only as good as the data that is passed to it. -Mike

The sectors you hit (0B and 14) will appear in the app as band 26 without EARFCN info *if* you have enabled the "Use New Sprint/Samsung Indicators" option under General Settings. They are part of the new Samsung configuration that has been rolling out recently, but do not apply to all regions right now. 02 is also band 26, and there are several other sectors for the other bands/carriers. -Mike

Until now, SignalCheck would query the database for a site note with an exact match on the current PLMN+GCI pair. If it didn't match an existing entry, it would pull no note (and if the Logger was running, it would create a new entry). The new logic in this beta still carries out that step first, but if there is no match and it's a Sprint-owned PLMN (including Clear/Virgin/Boost/Prepaid/etc), it then queries the database again using all of the known Sprint PLMNs in active use and the given GCI. If it finds one match, it uses that note. If it finds multiple matches (which shouldn't really happen), it defaults to the note with the longest string of text--basically to avoid selecting a blank note. The burst of 312530 IDs that showed up for a bit (mine are back to 310120 also) got me to think in this direction, but since flipping between Sprint/Clear sites sometimes results in a mismatched PLMN+GCI pair, this same solution should cover that oddity. Hopefully that makes sense? Kind of tricky to explain. It's not perfect, but in theory it should resolve most issues. -Mike

I swore I replied to your messages last month, but I don't see anything in here.. not sure what happened, sorry about that. Your second carrier sectors for band 2 and band 4, as well as band 14, are significantly different from the information I have.. and it's the first info I have about a band 2 third carrier. I have B3-B6 as a band 2 second carrier in some markets, and B5-B8 noted as a band 4 second carrier in some markets. The app will make an educated guess if EARFCN is available and there is a conflict. I have D7-D9 as band 14. I am guessing you have a fairly substantial collection of logs to support the sectors you spelled out. Are you confident that they are in use across your area and not one-off sites? Things change over time, so I appreciate it when people get me information "from the field" to help keep things updated! Thanks, -Mike

Yes sir! I was talking to a few people elsewhere, forgot to mention it in here. I have been scrambling trying to come up with a solution for those who are suddenly landing on PLMN ID's other than 310120, thus rendering their site notes useless.. I think I figured it out. It might also clear up the duplicate GCI problem that's mostly prevalent when hopping between Sprint/Clear sites. Fingers crossed! If it solves that issue (along with a few other nice changes) it'll go public Soon™. -Mike

Mine is set to mobile preferred, but connects to wifi calling fairly consistently where I do not have a solid mobile signal. It's one of my favorite features, works great. If you set to wifi preferred, it will almost always use wifi when available. -Mike

You can go into Settings and disable the automatic time zone feature while the kinks get worked out. I had to do that last year when I kept hitting local sites that were an hour off. -Mike

Sure, I can do that. I'll just have to make new icons because there are no "LTE 750" ones yet. I'll make a note to get this done It will be in the next beta update so you can make sure it works properly. Aiming for late next week right now. Glad it's useful for you! Unfortunately, I don't know of a method to select LTE bands yet.. the Voice Band Selection menu is built into Android, I just wasn't aware of it until someone showed it to me. LTE band selection is a different animal, that's usually configured on an engineering screen which is 1) inaccessible to third-party developers and 2) different on each device. But if I can find a way, I'd love to do it! -Mike