Jump to content

mikejeep

Honored Premier Sponsor
  • Posts

    3,284
  • Joined

  • Last visited

  • Days Won

    197

Everything posted by mikejeep

  1. It might be a contributing factor.. but even so, if it's showing B41 in the provider name, it should be showing it on the icon as well. I'm not sure why it would show on one and not the other. In other news, guess who might have finally gotten a Lollipop test environment working.. and already fixed the Alerts.. -Mike
  2. Please send me a diagnostic report (About > Send Diagnostics) the next time you see that; please include your username or e-mail and a brief mention why you are sending the report so I can keep track of it properly. Thanks! -Mike
  3. Sort of. As has been mentioned countless times, there's no standard method to get the actual LTE band in Android, so apps rely on identifying GCI patterns to make educated guesses. Unfortunately T-Mobile is not consistent with this method, so it's not as reliable as band identification on Sprint or AT&T. I'm trying to get it so if SCP shows a band, it's definitely correct.. if it can't be certain, I'd rather have it not show a specific band. Too many people are showing LTE Discovery screen shots next to conflicting engineering screen shots. I do not want to go down that road. I'm convinced your phone has a mind of its own.. you have more issues than anyone else that I can't seem to replicate!! Still looking into this. Neighbor cells are very mysterious on some devices; it's hard to determine what's going on. Trying to see if I can at least get it to show the dB of whatever neighbor cell it might be seeing. As you guys can see, there are a lot of different isolated issues that I have been trying to resolve. I've been spending a ton of time on them with not many results, but I am working on it, and hopefully will have some sort of update soon.. -Mike
  4. Thanks. Does the current public version (4.27) work fine? Trying to think of what I changed recently or what would have been changed in 5.1 that would affect non-CDMA devices like that.. If anyone else on AT&T or T-Mobile would like to join the beta crew to also help work this out, please PM me. -Mike
  5. Thanks for the heads up. What device(s) was this on? Were they connected to LTE, or another connection type? I've tested it on my Nexus 5 with T-Mobile and it seems to work fine, and I also have some AT&T beta users that haven't reported any issues. -Mike
  6. Getting big? I think that happened awhile ago since we're at over 3,100 posts and counting! I do have plans to improve the WiFi features of the app. Notification options are on the list, as is an option for "real time" WiFi updates, instead of just updating when the cellular signal changes like it does now. Just been trying to focus on improving the primary features, like LTE and logging. Ha, it must be a secret! Does it always say 1, or does it change at all? There really isn't anything I can do about the missing PCI, it just reports an invalid value.. -Mike
  7. A new Google Play Services update has been rolling out over the past couple of weeks, perhaps its related to that.. http://android-developers.blogspot.com/2015/03/google-play-services-70-places-everyone.html -Mike
  8. Much appreciated. But I've always considered the purchase price your lifetime pass, nothing more is necessary. If I was relying on this to get rich, the project would have ended 2 years ago! If you really want to make a donation related to the cause, you can find the appropriate link on the upper right-hand corner of this page.. -Mike
  9. Excellent! Sadly the duplicate GCI bug is not gone.. I thought it was, but this morning I have several bogus entries in there. Back to the drawing board on that one.. Yep! There are just some things ahead of it on the priority list. I need to get support for regular Lollipop working properly before I start extending out to fancy stuff like Wear. It's been a great week of (overdue) progress though, so we're getting there.. -Mike
  10. No.. the PCI is the only bit of data that is available for neighbor cells, and like Flompholph stated, PCIs are re-used across bands (at least on Sprint). -Mike
  11. It did have me stumped, but a bit more evidence surfaced that got me pointed in the right direction. The biggest drawback to Android development is the variety of devices you have to support.. they all have quirks that don't strictly follow the rules. iOS developers have it easy! -Mike
  12. With the help of @darickster09, I believe I have figured out what is causing this problem. I'm working on a fix that should resolve this. In the meantime, some users (especially those on newer devices / newer software, like a Nexus 6 on Android 5.1) may see an incorrect or missing GCI and/or missing neighbor cells. I will try to get something at least in testing by tomorrow evening. -Mike
  13. Well I don't think it's really a glitch, just the way Samsung chose to program their sites.. based on what they do on the UE end, I'm not surprised they do their own thing the on the network side too! I have resolved the null GCI issue you described in the version I'm testing myself at the moment; it was tricky because I didn't want to kill logging entirely for devices that do not report GCI. So, there will be a new option under Preferences > Logger Settings to allow logging sites without a GCI. By default, it is off. I'll have to play with the BSL issue some more to figure out what is going on with that. I could have a user setting for Samsung market or not, but an overwhelming majority will have no idea what to do with it. Also, if you ever travel between markets it will throw everything off. 03 will not appear as a second carrier in the app until I have some GCI prefixes; there really is no other way to do it. Sorry! Oh I believe you. Between the 3100+ posts here and various other channels of communication, it's amazing that more hasn't fallen through the cracks! -Mike
  14. I wasn't aware of the 09, 0A, 0B second carriers until I saw these posts; I only knew about 03/04/05 in Samsung markets. I will add these new ones to B25 and Clearwire B41. If anyone has anything else, please share so I can add them! -Mike
  15. I would love to have single-site 1X notes myself, but Trip provided a good answer as to why this is challenging (see below, thanks Trip). I can certainly look into moving the note to the bottom of that section and adding an option to hide the BSL if a note is present. That ^ sums it up pretty well. Even if I just wanted to do it for Sprint, not all Sprint sites assign BIDs the same way. I don't really have a method to apply one site note to all sectors of a site if there isn't a consistent method to identify them across the board. In my area, sector BIDs were seemingly random at each site until last year when the "third character rule" kicked in. I haven't seen confirmation that there is a standard BID pattern implemented nationwide yet. 1X 800 is identified by the 22xxx SID. If each SMR SID matched exactly with an associated PCS SID, I might be able to do something about that, but I have no idea if that is the case. Honestly I have gotten very little feedback about the 1X features over the past year or so because of all the focus on LTE, so I haven't done much with it. Waiiiiiit a second did I know about this? I don't have it noted anywhere, so if I did, I'm sorry it fell through the cracks. I will look into this ASAP. As I metioned above, non-LTE feedback has dried up.. and I'm very rarely off LTE myself, so I don't notice those hiccups. I should have explained this caveat a little clearer. I intentionally ignore 03 as a second carrier because non-Samsung markets use 01/02/03 for the first carrier. It's not a problem caused by ALU or Ericsson, it's a problem caused by Samsung. The only way I would be able to circumvent this would be to somehow identify the GCI prefixes for every Samsung market and apply different filters to those sites. If someone wants to take charge and create that list, I'd implement it.. but at the moment I can't commit to digging through the forums and doing that myself. (And please don't pepper the board with a zillion "my market is 0123" messages for everyone else's sake!) Null GCI appearing on the display? Or in the Site Log? I've spent many hours hammering the null/duplicate/invalid entry issues with the Site Logger this week, just haven't had any success yet; my testing last night did not go very well. I pushed out yesterday's update because those particular items were working well. I've been working on it for a few hours today but nothing to share just yet. It's far more of a PITA than I expected! -Mike
  16. So you are not seeing the GCI/PCI/TAC line? In travisc's case, his device was reporting everything as null but somehow LTE Discovery was seeing it, which has me scratching my head. Which device are you on? Do you happen to use LTE Discovery also? Trying to find the common theme.. I haven't tweaked anything with that code recently. -Mike
  17. I initially had the same exact thought. However, I've had an overwhelming number of requests to explicitly indicate B25, so I added it. You still have the option to either show the band (i.e. 25/26/41) or the frequency (1900/800/2500); showing the band is a bit easier to see because I was able to make the font larger. It's tricky because it's a very small area to work with and we all want a ton of information up there. Some users will continue to see just "LTE" throughout SignalCheck; that is because the app is unable to determine exactly which band you are on for one reason or another. For Sprint users, it would be because your device is unable to grab the GCI or you're on a site that is broadcasting an ID that I haven't identified. On other providers, I don't have full information on their network configurations, and with some (notably T-Mobile) there are some overlapping identifiers, so instead of cluttering up the screen or going with a guess that I already know might be wrong, I'm keeping it simple. On another note, I think I solved the blank site note / duplicate log entry issue that's driving many of us nuts! Going to do some more testing on it tonight.. fingers crossed.. -Mike EDIT: I just noticed that you edited your post.. there are already several different options for the status bar icons like you suggested. Check out Preferences > Status Bar Icons and adjust the styles to your liking.
  18. From the looks of the source code for change 52400, here is what is different: Before 5.1, the RSRP thresholds were fixed: -44, -85, -95, -105, -115, -140 In 5.1, the OS can be configured to choose a "strict" or "lenient" thresholds: Strict: -44, -85, -95, -105, -115, -140 (same as before) Lenient: -44, -98, -108, -118, -128, -140 Verizon and Vodafone NL appear to require the "strict" settings, as those PLMNs will default to that. As far as I can tell, devices on other networks will default to the "lenient" settings. -Mike
  19. Most of the lingering issues with Lollipop are related to notifications/alerts. If there is a Lollipop-induced glitch with LTE site identities, it's probably because the OEM messed up their system software. But... I just saw your report; SignalCheck is seeing all of the LTE identity data as null. Off the top of my head, I don't recall others with an M7 to have similar issues. And I believe that LTE Discovery uses the same routines that I do, so that's a head-scratcher. I'll look into some things and may send you a PM later. -Mike
  20. Hmm that's unusual.. are you seeing something that says "invalid" or is it just not on the screen? Are you on the latest update (late December)? Send me a diagnostic report when you are connected to LTE (About > Send Diagnostics); please make sure to include your username on the report. -Mike
  21. Gotcha. From a general perspective, HTC devices have proven to be the "best" for SignalCheck, but my experience is heavily based on feedback from Sprint users. I don't hear much from the Verizon crowd, and I am a Sprint customer myself. Hopefully there is someone else lurking that can answer that better than me. Also, I'm humbled that you find the app so useful that you would buy a phone based on its SignalCheck compatibility.. thanks! Well if you're also asking the SignalCheck developer that question, I can answer it for you. It's also explained in the FAQ link I replied with earlier. Each CDMA 1X site broadcasts a latitude/longitude coordinate pair. If the coordinates appear to be valid, the app takes the pair and queries a geocoding server to translate it into the nearest street address. The geocoding is as accurate as Google Maps is; if the address is wrong, it's because the site is broadcasting offset (or incorrect) coordinates. Sprint has started using an offset in more areas as NV upgrades have progressed. I guess there is a chance it could be some sort of small cell, but it is MUCH more likely that your local site does not broadcast its exact address. If you want, you can send a diagnostic report (About > Send Diagnostics) and I can check exactly what coordinates the app was receiving at the time of your report. Be sure to include your username or email, along with a brief note explaining the reason for the report. -Mike
  22. Ditto. I don't think it's the device as much as it is the network. I went through a few hellish weeks of this last year, suddenly it all went away and B41 started popping up everywhere. Now it's happening again.. I take the positive outlook and assume it's more upgrades, and enjoy the inability to get stuck talking on the phone for hours on end! -Mike
  23. Haha I can't keep moving everything to the top of the list, because then it doesn't mean anything! I'm still working on an overhaul of all the alerts -- my intention is to make them more dynamic. Oh and make them work on Lollipop too.. Ahh ok. Hopefully nobody interprets that as the only compatible devices out there, that's not my intention.. just notes about certain devices and their capabilities. There are too many phones in the world to list them all. It has gotten a bit outdated though, perhaps it's not that useful anymore. -Mike
  24. SignalCheck will show any and all information that the Android OS is receiving.. if a system update causes things to vanish, I can't do anything but wait for the OEM to fix their software. What "list" are you referring to? Everything is software-dependent, so a future update by Samsung/Verizon could have the same impact that you saw on your S5. Of course, a future update could also improve what the app sees also. Several others already chimed in with excellent answers, but I figured this would be another opportunity to point out there is a FAQ linked from within the app that contains some basic answers to questions like yours; it's a work in progress, but covers 90% of what I get asked on a daily basis: http://www.bluelinepc.com/signalcheck/help/#bslwrong Always feel free to ask in here though. There are almost 3100 posts so I don't expect new users to read them all! -Mike
  25. I probably need to word it better on the website; the Known Issues page is for broken stuff that is out of my control, and the To-Do List is for broken stuff I should be able to fix (and new features I want to add). The Lollipop bugs are on the To-Do List. The primary method is TelephonyManager.getNetworkOperator(). If on a newer device and certain conditions are true, it will use CellIdentityLte.getCellIdentity(), but the reliability of that data varies by device and provider. ServiceState.getOperatorNumeric() proved to be the least reliable and is no longer used. However, I can monitor all three methods in realtime on a special diagnostic screen, and from what I have observed, they all change at the exact same instant. If it's delayed (or "early") for one method, it's the same across all of them. I had already done it, but thanks for a great troubleshooting suggestion though! Since this behavior only exists when switching PLMNs, and all (or nearly all) non-Sprint users do not typically see PLMN changes, I've changed my approach and I'm trying to fix it by assuming only Clearwire connections will cause an issue. Hopefully I can make some good progress this weekend. It's driving me nuts, so I know it's driving most of you nuts. -Mike
×
×
  • Create New...