Jump to content

mikejeep

Honored Premier Sponsor
 View Profile  See their activity

  • Posts

    3,284

  • Joined

  • Last visited

  • Days Won

    197

 Content Type 

Everything posted by mikejeep

  1. mikejeep
    Haha.. at the airport? Hmm.. I like Potbelly, we don't really have those near me and it's always good. I'm not one to usually eat a big meal while traveling. If you're looking for food in the city, go to Slows BarBq down by the old train station and the Tiger Stadium site. Great food. -Mike
  2. mikejeep
    I fly in and out of DTW often.. service is fine. I believe they have free Wi-Fi in the terminal as well that was decent. -Mike
  3. mikejeep
    ^ This; it's all GCI-based. AT&T is very clean with its GCI patterns. I have a very reliable source who provides me with nearly all of my AT&T info. If anyone on AT&T sees a GCI but doesn't see a band indicator, grab a screenshot and let me know; I believe the app has that network 100% covered at the moment. -Mike
  4. mikejeep
    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
  5. mikejeep
    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
  6. mikejeep
    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? I saw your post the other day and have been looking into it -- I found the issue and it will be corrected in the next update. It's an issue with the B30 icons.. it won't impact anything else in the app, you'll just be stuck seeing the tower icon. I'm hoping to get a minor bugfix update pushed out in the next week or so. You see distance/direction but no note when a site has been recorded with the Site Logger but you didn't enter a Site Note for it. Distance/direction is missing on sites that the app hasn't seen before because it has no idea where they are. -Mike
  7. mikejeep
    I put a lot of weight on your opinions and understand your reasoning. I know someone could see the current SignalCheck labeling as "squared" instead of "second". But I don't necessarily see it as a cause the misunderstandings that have popped up on here lately. It just seems that not everyone is aware that additional carriers aren't an automatic indicator of carrier aggregation. With the hopes that some method to identify when CA is live is eventually discovered, I have been giving a lot of thought to how that information could best be displayed in the app. Perhaps that would in fact be best expressed as an exponent. It's one of several things I've been playing around with. I have always argued in favor of continuity, but not if it handicaps capability. -Mike
  8. mikejeep
    You were on my list of people to follow-up with today to check on the status of your bug. I don't think I knew you were on Boost, that makes a big difference! I will have to look into that. -Mike
  9. mikejeep
    Here is a detailed change log for SignalCheck Pro 4.31, as promised! Those of you who have not updated should take a moment to do so, there are some bug fixes that impact a lot of users. Option to display LTE EARFCN and frequency data from the onboard modem if rooted. This is the most significant improvement to SignalCheck since neighbor cells were added, but I wish root access wasn't required. Using a different approach that was recently discovered, the app can attempt to directly query your device's modem to get LTE EARFCN data. This allows the app to display the actual frequency of your connection, eliminating the need to rely on previously-identified GCI patterns for band identification. For now, EARFCN data is simply displayed and not used to set any band indicators, and neighbor cells do not display any EARFCN information. However, this is only the first release, and I intend to expand upon this. The only drawback is you need to determine the path of your device's modem in order for the app to communicate with it. The default is "smd11" which works on several devices; if you discover your device uses a different path, please let me know. I would like to have the app auto-configure itself based on what device is in use, but I need to know what each device actually uses to do this. Resolved issue with missing LTE data and neighbor cells on some newer devices. Many newer devices failed to show all available LTE data when simultaneous 1X+LTE connections were present. Other devices failed to show neighbor cells, or in some cases, any LTE data at all. Happy to finally have these issues resolved! Additional indicators for nTelos LTE band 41 and T-Mobile LTE band 4; Added site note pairing for nTelos LTE bands 25 and 41. These band indicators existed in the app previously, but new patterns have been identified so users should see better results. nTelos users will now enjoy synced B25/B41 site notes as native Sprint users do. New indicators for AT&T LTE band 4 second carriers and band 30; Sprint LTE band 41 third carriers; Verizon LTE band 4 second carriers; nTelos LTE band 41 second carriers. Lots of new data thanks to user reports, mostly from S4GRU! Implemented Material design theme; Added option to allow users to set text color on main screen. The ugliest app on Google Play now uses Material instead of Holo. Also, a new user option to set the color of the text on the main screen has been implemented. If there's a color you would like to see that is not there, let me know. My design skills are terrible, but this is a small step in the right direction! New options to automatically enable/disable Location Service and/or Site Logger upon charging, unplugging, or low battery. This is fairly self-explanatory; I have already received a few reports of some quirks with these features, so they will be further tweaked in upcoming releases. There are no major bugs, they just need a little more polish. Added initial support for Wi-Fi Calling network type. Some devices have been reporting a new network type related to Wi-Fi Calling; the app will now display this instead of "Unknown." Added broadcast intents to toggle Background Service, Location Service, and Site Logger through third-party apps (i.e. Tasker). This is an advanced feature that still needs some more work, but the basic functionality has been implemented. Using Tasker or similar methods, users can now send intents to SignalCheck to toggle the three main processes that can run behind-the-scenes. Using a broadcast intent, you can toggle these by using the intent "com.blueline.signalcheck.SetServices" along with the following Extras: LocationService:true (enables Location Service) LocationService:false (disables Location Service) SiteLogger:true (enables Site Logger) SiteLogger:false (disables Site Logger) BackgroundService:true (enables Location Service) BackgroundService:false (disables Location Service; see note below) As of right now, there are some quirks that I intend to change. Most notably, *all* intents a user wishes to enable must be sent together; the app will disable any intents that are omitted. Also, the Background Service cannot be killed off automatically; the option will be disabled, but the Background Service will not actually terminate until the next time the app is opened and then sent to the background. Resolved issue with notification icon(s) occasionally appearing as a blank square on Android 5+. Android recently changed the way notification icons are displayed, eliminating all color; the default icon was incompatible with this, and would sometimes show a white square or nothing at all depending on the circumstances. Now you should see a monochrome version of the standard "tower" icon when no signal data is being received. SignalCheck Lite will be updated with the pertinent changes as time allows. Thanks for all of your support, and keep the feedback coming! I sincerely appreciate it. -Mike
  10. mikejeep
    This is on my priority list, it's just quite an involved implementation so I haven't had time to finish it yet. (Check the website for a full "wish list" of things I'm working on or plan to implement.) I am overhauling the overall way the Alerts work behind the scenes to make them more dynamic. In general, I try to balance new features with bugfixes based on the limited amount of time I have to work on the app. I wish I could devote 40+ hours a week to it, and I wish I was a programmer by trade (I'm self-teaching as I go), but unfortunately life gets in the way sometimes! -Mike
  11. mikejeep
    Hmm.. I was going to reach out to you in the hopes that it was resolved. Send me a diagnostic report next time you know you have a connection but the app says otherwise (About > Send Diagnostics). Include your username and a brief note about the issue so I don't forget what I'm looking for. Not yet.. but that's in progress! Try getting a new SIM before ditching the phone. It can't hurt. -Mike
  12. mikejeep
    The latest SignalCheck Pro update includes Sprint third carrier indicators (B41³) as seen above.
  13. 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
  14. mikejeep
    I have an Android and basically couldn't connect at all. Sprint never hinted that it was limited to iOS devices. It was limited to a particular area of the country. -Mike
  15. mikejeep
    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
  16. mikejeep
    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
  17. mikejeep
    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 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
  18. mikejeep
    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
  19. mikejeep
    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
  20. mikejeep
    Soon™ -- aka however fast Google Play decides to publish what I uploaded a few minutes ago... -Mike
  21. mikejeep
    All I saw were a couple of generic tweets from Sprint saying it's been resolved and that it was a network issue. They aren't elaborating publicly. Would love to know what happened, just for geeky curiosity sake. -Mike
  22. mikejeep
    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
  23. mikejeep
    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
  24. mikejeep
    Hmm. It might be resolved in the next update I'm preparing to release, it resolves several issues where LTE information is missing in certain specific scenarios. Send me a Diagnostic Report (About > Send Diagnostics) and include your username and a brief note about the issue. Any idea if other similar apps (Signal Detector, LTE Discovery, etc) show your connection properly? -Mike
  25. mikejeep
    Thank you for confirmation. That will be fixed in the next update. Administrative privileges can only do a small number of special tasks -- remotely wipe a phone, force password strength requirements, control lock screens, etc. AFAIK, there isn't anything that is related to the radio. 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. 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. Yes, it will be in the next update. I had recently received this and a few other updates from our old friend digiblur. -Mike
×
×
  • Create New...