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
    Frequency class is gone for now. I think the band identifier is a bit more useful anyway, since it would show additional carriers, small cells, etc.. FYI beta discussion moved to a new thread: http://s4gru.com/index.php?/topic/7720-signalcheck-beta-crew-forum/ -Mike
  2. mikejeep
    Found your reports.. ironically it's the crash monitoring library that's crashing, not the app itself. What exact version of Android are you running on that? Google reported "2.3.3 - 2.3.7". -Mike
  3. mikejeep
    Yep, that was a bug I discovered last night. One of the primary reasons I pushed out a new update early this morning.. glad to see your later post showing it was resolved! Doh! Let me know. I will try to do some testing also. If others could keep an eye on this, I'd appreciate it. My hope is that this can be the final release for pre-4.1 devices; there are many small bugfixes and a lot of nice changes, nothing that should preclude those devices from working. Where did you send a report? I don't see anything in my e-mail, diagnostics inbox, or Google reports. -Mike
  4. mikejeep
    This new thread has been spun off for beta-related discussions. It is open to all, even if they are not on the Beta Crew. Thank you to lilotimz for moving the related posts over and Joski1624 for the suggestion! -Mike
  5. mikejeep
    It took awhile, but I think I was able to fix this. You will still have to manually edit the database if you want any sector(s) to have unique site notes, but if you do that, it should pull the correct one now. However, if you edit the note for any sectors via the app, it will overwrite all of the sectors. I would have to make significant changes to permit editing site notes on a per-sector basis through the app, but I don't think it is going to be a common issue. I also don't think Mini-Macros will be an issue as I initially thought, but we'll see. -Mike
  6. mikejeep
    That is not possible right now. But eventually I will be overhauling the alerts and icons, theoretically you could have as many icons as you want. Not happening in the near term though, sorry. -Mike
  7. mikejeep
    Aha, now I understand.. and I know what it is happening. This is going to be a potential issue for Sprint mini-macro sites as well. When pulling site notes, the app just checks the database for the first match of the first 6 GCI characters. Until now, that has never been a problem; it was intentional. All of the major providers had been using the same 6 characters (or a consistent offset) to identify cells at one site. So if you were hitting a site you've connected to before, but on a new band, the site note would cross over automatically. These new configurations don't follow this pattern. I'm going to have to gut those routines and come up with another method. Site notes are no good if they aren't reading from (or writing to) the correct site. I'd thank you for discovering this, but now I have a lot more work to do! -Mike
  8. mikejeep
    Ahh ok, I did not realize the 10x10 was a second carrier. I'll change that. Are the non-Samsung 10x10 sectors second carriers as well? I sometimes get lost when we get too deep into these discussions.. -Mike
  9. mikejeep
    Thank you for sharing that! Based on the feedback I've received, I'm going to change it to "MM". Spelling it out, even shortened, is ugly. I'd like to limit the toggles, because (selfishly) that creates more headaches than you can imagine on my end. And screen real estate is tighter than you might think; I need to design with the HTC EVO in mind, not a Galaxy Note. The signal bar is quite tight against the text when displaying "LTE 2500" on some devices. At some point I intend to finish my tabbed UI I started 2 years ago, and also have a few different "themes".. so your display could show every metric possible (hardcore users), just the basics in large print (perhaps while driving), or somewhere in between (as it is now). But I have enough on my plate at the moment. Maybe tomorrow.. -Mike
  10. mikejeep
    By invite only, or if you make Honored Premier Sponsor. I have plenty of Sprint testers on the beta crew right now, but be patient.. public updates aren't usually too far behind betas. -Mike
  11. mikejeep
    I am willing to display the Mini Macro sites however everyone feels is most appropriate, those are good suggestions. I always have concerns about screen clutter, but I also don't want to need people to download a reference guide to identify every two-character acronym I come up with. It's technically 3 more characters (need a space if I'm spelling it out!) but I think that might be the best approach. Is there a second carrier pattern that isn't displaying properly, or are you saying it would be nice if we knew what it was? -Mike
  12. mikejeep
    No, I don't have any of the new API functions working yet, still working on them. Integrating that is a priority and I have every intention to have that (or the root EARFCN method) determine the LTE band once it's working, but I wanted to get an update pushed out while the code was at a point of stability. See below about T-Mobile. See above about the new API functions like EARFCN goodies. I finally got some solid information from a reputable source regarding T-Mobile's network configuration. They are using two vendors for LTE deployment. One vendor has their sites configured in a manner that I can definitively identify the bands, while the other vendor does it differently and (even worse) inconsistently. That vendor "usually" does things a certain way in some markets, but not always. For other markets, it's up in the air right now. Thankfully I am able to identify which vendor handled each site, so the appropriate routines are implemented. Some of it matched what I already had in previous versions of the app, but a lot of it was wrong for most of the country. I am still gathering information, but in beta testing, I have it set to display a question mark if it's one of those "usually" sites, and no band information if it's completely up in the air. If there is no question mark, the band indicator should be accurate. The "B4" part is what's triggering the LTE AWS display; perhaps that needs a question mark too. See above regarding native EARFCN routines. For Verizon band 5, I have your Savannah sectors noted, but I've seen evidence of other sector patterns online. I've recruited a few Verizon testers this week so hopefully I can get that improved. Someone else pointed out the notification pulldown bug this morning, I know what I broke there and it is an easy fix. My bad! Can you share (PM or email is fine if that's easier) more information on what you mean about and issue with different labels different sectors? -Mike
  13. mikejeep
    Beta crew.. assemble! A new update is finally published.. if you're special -Mike
  14. mikejeep
    You sent me quite a bit! I've filled in a lot of blanks today from numerous sources, S4GRU and otherwise. AT&T is fully handled as of now. Got some solid T-Mobile info through an old friend that will help clean things up significantly. caspar347 hooked me up with fantastic Verizon info, but I'm still trying to figure out more. I have conflicting information on their Band 5 sectors, and I'm lacking information on DAS or other non-macro sites if you or anyone else have anything to share..? -Mike
  15. mikejeep
    Hmm, that doesn't sound right.. it doesn't "do" all that much in the background, as all of the functions simply "listen" for signal changes when the device provides them. Is it any better/worse with the app's Logger and/or Location Service disabled? When it is running, do signals typically update rapidly or does it seem to be more normal? -Mike
  16. mikejeep
    Soon™! -Mike
  17. mikejeep
    Maybe B25 was so reliable because everyone else's device was on B26 or B41 also! Did things ever improve for you? It sounds like something wasn't working the way it should be. -Mike
  18. mikejeep
    Got most of the new band identifiers implemented over the past few days, but I also broke some stuff in the process.. 2 steps forward, 1 step back. Getting there, though. I sincerely appreciate all the kind words and support for the app I've received privately and on this thread! I do see every message, even if I don't get back to you right away. -Mike
  19. mikejeep
    I don't think that is an issue.. you can't directly read any other app's databases (Android security won't let you), but if it's saved in an non-protected folder (like the /sdcard/SignalCheck folder) it's fine. Once you export the data, it's available for anything. I don't think Google Play would block it, and there are certainly no issues on my end. I encourage people to use the data for anything they want. If you created an import function for your own app I think it would be cool. I have plans for a mapping component in SCP but it's far from ready. -Mike
  20. mikejeep
    The map around Lake Winnipesaukee (central NH) seems to show mostly "LTE Roaming" on Sprint's map, with some "Off-Network Roaming" -- what is the difference between these two? Do both count against your roaming cap? I'm guessing it's USCC around there. -Mike
  21. mikejeep
    AGREED!! Howdy all. Checking in again. Yep, same excuse, crazy busy, blah blah blah.. but I have been working on it, slowly. Due to my lack of progress, I've decided to take a new approach to the Android permissions nightmare that is really holding everything up. Everyone is antsy for new features and the new API stuff -- and that includes me. The big holdup is how the app reacts when someone revokes a permission while it is running; right now it's pretty catastrophic. As in, worst case scenario is the device is frozen until the battery dies (!). Denying a permission doesn't go so well either. Android guidelines (and my conscience) require that the app handle these scenarios properly. However, because SignalCheck is really just displaying a lot of data it's getting from the phone itself, this is more complicated than one would expect. I'm changing directions and going to leave crude protections in place for those who don't grant permissions, and instead going to focus on adding other new goodies. I can't release it publicly like that, but at least it will hopefully give me a chance to implement some of this new stuff and let others play with it. I also want to change who has access to beta versions since it's been so long since anyone has gotten an update, but I need to figure out the logistics of that. Seriously, thanks for your patience. I realize it's been a year, and a lot has changed since then. New band identifiers and new API features will be the first priorities. -Mike
  22. mikejeep
    Good luck! This crowd will start throwing tomatoes at you before you know it (just kidding!!) Google has simplified the beta testing features recently but I haven't tried them out yet. Let me know if there's something you think I might be able to help you with on that end. I'm a terrible programmer though so I wouldn't recommend asking me those kinds of questions. (Now I gotta go hide before anyone realizes I'm lurking around here..) -Mike
  23. mikejeep
    Hi all! Wanted to pass along another progress report. I am still fighting with the new Android API to get permissions properly recognized.. it's a difficult task because of the way the app is designed. As you have likely noticed in other apps by now, users have to physically accept a menu prompt to grant apps certain "sensitive" permissions. SignalCheck has a lot going on in the background, much of which requires permissions of this nature (specifically, the Phone and Location permissions, for obvious reasons). I am spending many many hours on this, so just keep trying to be patient! I need to get this finished before I can move onto the more fun things like native band identification (and fixing the LTE30 and 10x10 bugs -- I hear ya!) I promise, my alpha version doesn't have any secret new features you're all missing out on.. at least not yet.. -Mike P.S. #Brady #Belichick #GOAT :)
  24. mikejeep
    Yep, everyone that was there is still good to go. I don't expect to change that anytime soon. Quick update on recent progress to reassure everyone.. I have spent many hours over the past few weeks trying to bring SignalCheck up to date by switching to the new Android Studio development environment as well as implementing the new Android permissions model required if you compile for Android 6.0 or higher. I had been skirting both of these mandates by using older software and compiling it for Android 5.0, but obviously there are many new features (yes, I have seen all of your e-messages!) that would be great to add into the app. It has been a far more cumbersome process than I anticipated, and I'm not very comfortable with the new IDE yet. But I'm putting the work in, so stay tuned! -Mike
  25. mikejeep
    Hello strangers!!! SURPRISE! I'm not done.. I am *way* behind on my e-mail and S4GRU threads, and have not had much time to work on the app over the past several months. But I'm lurking. And have been (slowly) working on an update to include the new API features. As I've privately told a few of you, I'm just crazy busy with other things in life and at work. Everything is great, just not enough time in the day. Looking forward to being as active as I used to be. Sincere apologies for giving anyone the impression that the app was dead and I appreciate your patience. SignalCheck had hit a point of stability where I felt like I could let it simmer for a bit without a huge impact to users. Not because I don't enjoy working on it, just because I was burning the candle at both ends and real life takes priority sometimes. Maintaining the app could probably be a (terrible-paying) full-time job but it's still a fun hobby to me. I'm slowly but surely working through all the e-mails and posts. It's all good! -Mike
×
×
  • Create New...