Jump to content

mikejeep

Honored Premier Sponsor
 View Profile  See their activity

  • Posts

    3,271

  • Joined

  • Last visited

  • Days Won

    189

 Content Type 

Everything posted by mikejeep

  1. mikejeep
    Think about how many other users are in the area, and many are probably traveling in a moving vehicle.. so they are connecting to the most appropriate sector for their location at that moment, then eventually their location changes enough to identify a different optimal sector, thereby opening up another "space" in the previous sector for someone to park in. Just because you are sitting still doesn't mean a few hundred others aren't hopping on and off the site I clearly notice this in my area, where at least 2 of the 3 sectors of my "home" site that I can see out my dining room window serve a major interstate highway. I'm constantly getting bounced off that site during the day to other nearby sites. I'm not far from any of them, and I don't suffer any signal issues as a result, but watching SignalCheck flip-flop between 3-4 sectors is kind of fun. If I watch it around 3am, it camps on the sector out my window and never changes. Not a lot of traffic on the highway at that hour, therefore not a lot of load on that site.. seems to verify my theory. -Mike
  2. mikejeep
    The -70 dB site might have a stronger signal, but it could have more load than the -95 dB site, so the network is bouncing you as a method of load balancing. If that is true, you would probably actually get better service from that -95 dB site. The strongest signal is useless if the site is overloaded. -Mike
  3. mikejeep
    Those are consistent with results from other markets as well; I'm now satisfied that there is plenty of evidence to support the GCI sector patterns recognized by S4GRU members are intentional. Thank you for keeping tabs on this for me, and thank you Sprint for keeping it simple! Have you noticed if B25/B26 PCI's for the same site are identical? I know it has proven true in some areas, but I'm not yet sure if that's a coincidence or part of the plan, and I know you've been keeping a close eye on this stuff. SignalCheck has the capability, and Android 4.2+ has the structure in place; it's just a matter of the phone itself reporting the information or not. Sprint Samsungs do not have a good track record with this. Someone with a newer device will have to give you a definitive answer on this; as far as I can remember, I haven't heard of any stock Samsung devices reporting any LTE info except for on the engineering screens. The S4T doesn't even report the correct PLMN, and that radio should be Sprint-specific! I have expressed my opinion on this to Samsung numerous times, but it's not like I'm put in direct contact with the developers or "enginerrs" -- no matter how many e-mails, tweets, or phone calls I am forwarded to, it always ends in "we'll pass it along to the appropriate people". I have no idea why they neglect to report this data on Sprint phones; I know it's reported on at least some other provider's devices, such as AT&T. Interesting -- could you get me a screen shot of that and/or hit About > Send Diagnostics from within SignalCheck while on an HD Voice call? Maybe there's something I can hook onto. What do you mean by "results"? CDMA 800 or LTE 800? SignalCheck reports everything the radio is reporting to it; if the app is open, it's listening for data. The only exception is that while a phone call is active, the app stops showing some cell site ID data, because Android does not update it while the phone is off-hook. The signal levels will continue to update, but SID/NID/BID does not. -Mike
  4. mikejeep
    Agreed.. that's the one scenario I was trying to indicate would be a valid reason to generate "disappointment". I didn't mean to infer that a fringe 1900 signal should be considered reliable. I'm not often in an area where my N5 has a weak 1X 1900 signal, other than going deep into some buildings. It does seem to switch when the PCS signal is lost, but you're absolutely right, it should transition to SMR before it gets to that point. It's like they need to adjust the threshold to connect to 800 a bit sooner.. if there is such an adjustment. I can't imagine the 1900 signal needs to be completely dropped before this could happen. -Mike
  5. mikejeep
    I have always dropped the call when handed off between 1X 800 and 1X 1900 and assumed it was not possible, but others (I know nexgencpu already replied) pointed out they had no issues with it. Perhaps it's a market/vendor thing for now. It hasn't happened to me as often with my Nexus 5, but that's because it practically laughs at the notion of losing 1X 1900 anywhere. It was more prevalent with my EVO LTE that was often hopping between PCS and SMR. I was usually using a sponsor PRL that prioritized 800 and camped on it; I would lose any call that moved out of range of live 800 sites, despite the fact that I would watch the phone immediately connect to 1900. -Mike
  6. mikejeep
    Guess I'll repeat this again. If you have a reliable 1X connection on 1900 MHz, your phone has no reason to switch to 800. It could be live in your area, but you just don't need it. It's not like EV-DO vs. LTE; 800 is not "better" than 1900. It will not switch when it discovers 800. In fact, the latest stock PRLs won't even look for 1X 800 if it connects to 1900. If you're losing a 1X 1900 signal when walking into a building, with no sign of any transition to 1X 800, then perhaps it's not live in your area. You shouldn't necessarily be "disappointed" unless you're having trouble holding a 1X connection. The speed is the same and the voice quality is the same. The difference is 800 has increased signal coverage over 1900, which comes in most handy in buildings and previous dead spots. If you're maintaining a reliable PCS signal, you don't need it. -Mike
  7. mikejeep
    You mean a SignalCheck crash? If so, ART/dalvik doesn't matter.. I have tried both and it has no impact. The cause seems to be related to specific signal updates from the device's radio, typically when connecting/disconnecting from LTE or re-connecting after completely losing all signal. I can't identify why it does, but whatever it is, SignalCheck can't handle it and basically chokes until you kill it. I'm fairly confident that it has been resolved in the next update, but there are now other bugs that I'm ironing out before pushing out a public release. No sense in releasing something that fixes one bug, only to cause another. The new bugs are fairly minor and will hopefully be quick fixes. They are just enough for me to not feel comfortable enough for a public update yet. -Mike
  8. mikejeep
    "Early 2014" and "soon" have been the consistent statements from Sprint.. so inferring 1Q2014 is reasonable. The G2 had the same promise, and received its update several weeks ago. I really wish that the reason for the wait would leak out, just to satisfy our curiosity at this point! -Mike
  9. mikejeep
    I noticed that too, including some of Google's own apps. I only specifically mentioned SignalCheck because that's what this thread is for, and a LOT of users have been contacting me about it. Interestingly, this is at least the second time this specific bug has popped up in Google Maps. Sometime last year a Maps update caused the same exact problem.. it wouldn't actually execute a search or plot coordinates that were passed into Maps unless it was still running in the background. Hopefully they don't let it happen again. -Mike
  10. mikejeep
    Looks like the new Google Maps update (7.7.0 on my N5) fixes the problem of the first click on the BSL not mapping the site! I've been out of town for over a week, but I received everyone's testing feedback and I'm trying to get another beta update out soon. Not enough time in the day.. -Mike
  11. mikejeep
    I can explore that possibility, but it's a long shot. The problem is the engineering screen apps would be the only way to "back-door" the system to get the data, and they are all locked down with special permissions that cannot be granted to third-party apps. Even when I was able to get certain pieces around those security mechanisms, the system-specific engineering apps that are already embedded on the device were blocking access. By design, Android security permissions are a difficult thing to bypass.. which is a good thing of course. -Mike
  12. mikejeep
    I agree, that would be cool! But unfortunately, this falls in the same category as the band/frequency/channel/EARFCN data.. it's not accessible by third-party apps. Android does not have any functions to grab this type of information, and there are security features built into the OS that block any workarounds that might be able to obtain the data directly. It's frustrating, but out of my hands unless something significant changes in a future Android version. Sorry! -Mike
  13. mikejeep
    No.. my Nexus 5 is on 55018. -Mike
  14. mikejeep
    My N5 updated on its own right on time; I was in the car and noticed it moments after 2am. My 6:30am phone alarm went off as scheduled. I was not on Wi-Fi at 2am, but was when the alarm went off. Both settings to let the network set the clock and time zone on the N5 are enabled. My wife was with me; I don't know exactly when the clock on her iPhone 5s updated, but it was correct in the morning. But, she swore her 6:00am alarm didn't go off. Good thing I had mine set, although she lost 30 minutes of time in front of the mirror doing whatever ladies do whenever they go somewhere! We both figured she must have shut it off and fell back asleep, even though she never does that and it typically wakes me up too. Now I wonder if it was a DST issue and would've buzzed at 7am if she left it enabled. We both have Sprint. Kind of cool side note.. we were actually on a long overnight drive, using Google Maps on my N5 for navigation at the time. It showed the correct 4am ETA when we started the 4-hour trip at 11pm. I was impressed that it knew to factor in the time change.. in the fall I'm going to plot a short trip just before 2am to see if it will let me travel back in time.. -Mike
  15. mikejeep
    Not trying to pick a fight, but buying a new phone and switching wireless providers seems like a bit of an overreaction to simply questioning whether or not CDMA 800 is available on a Sprint-owned network..! -Mike
  16. mikejeep
    I just started taking advantage of cloud-based storage and I'm liking it far more than I expected. Seems like it can replace whatever you would store on an SD card. My 2 laptops, N5, and wife's iPhone 5s all sync to the same account. The phones use Titanium Backup and auto-upload once a week in the middle of the night, and the laptops are able to access the same documents and app source code (with the bonus of them now being backed up) without any effort on my part. I went with box.com because I took advantage of a 50GB free for life promo, but Dropbox and others probably offer similar functionality. Various promos seem to pop up often. -Mike
  17. mikejeep
    Cool kids = my beta crew. The most recent SignalCheck Pro update (4.22) was released on January 3, and the corresponding Lite version was released on January 11. Since then, a few beta updates have been released, but only the beta testers see those. Betas are hidden from the public. And thank you everyone for your support.. I'm cracking up at the peer pressure (and blushing from the compliments) on here. I do have plans to improve the Wi-Fi features in the app.. a few have asked for a notification icon, and as I mentioned before, I'm looking into real-time updates (right now it only refreshes Wi-Fi data when the cellular signal changes). I want to evaluate the battery impact on adding new routines like this before including them. And as much as I (and Google) would love to prey on you signal junkies, I'm not adding another version into the mix. Maintaining two code branches is too much as it is! Yes I was referring to the beta version, but I'm not sure why you got an update notice; like I mentioned above, Lite hasn't been touched since January 11. Looks like there are still some issues with the latest beta, so I still have some work to do, but it's getting closer.. -Mike
  18. mikejeep
    I heard the Verizon SIM story as well, in fact I feel like I might have relayed it somewhere in this thread myself. In any case, that specific update, whether it went to all Nexus 7's or not, only contained updates that pertained to the Verizon network. So the precedent is there for Google to push out an OTA to everyone that only includes adjustments for the Sprint network. -Mike
  19. mikejeep
    Well when I fix bugs, they don't magically teleport to your phone, you have to update the app. And by looking at that screenshot, I know you haven't updated to version 4.23 yet; that's where it's fixed. Guess I should also mention that only the cool kids have that version at the moment anyway.. -Mike
  20. mikejeep
    SignalCheck can't determine your eHRPD provider on non-HTC phones, so I'm guessing you mean your 1X connection switched to Cricket. In any case, it could have been anything, probably something site-related. Hopefully after-hours NV work! -Mike
  21. mikejeep
    In addition to this not being correct (HD Voice can be deployed on 1900), Sprint has recently done just the opposite with the recent updates, which keeps users on 1900 whenever possible. -Mike
  22. mikejeep
    They could be working on that Sprint site near you, which could certainly provent you (or anyone else) from connecting to it for a period of time. How do you know you were on Cricket eHRPD? -Mike
  23. mikejeep
    The Wi-Fi speeds reported by Android each correlate to a unique 802.11 spec/bandwidth. In the few cases where it might be one of two versions of the protocol, SignalCheck shows both. If it's not sure of the protocol or bandwidth, it hides any possibly incorrect information. The only caveat is that 802.11ac will not be identified as such unless the speed exceeds 150 Mbps. Slower speeds will be likely identified as 802.11n. The threshold is actually -40 dB.. but who says that's a bug? -Mike
  24. mikejeep
    I've been doing digging into the technicalities of 1X Advanced, and you are right, it's either "1X Advanced" or "1xRTT". It's also quite an upgrade from regular 1X, there are some very nice improvements if the Qualcomm marketing materials are to be believed. BID patterns must be market-specific, because around here the post-NV BIDs did not change, and they were already a random mix of 3 and 4 digits. With a lack of an identifiable pattern, and no capability within Android to distinguish between flavors of 1X, the app has no idea if it's 1xA or not. So plain old "1X" will probably be what I go with as a base label, since that is never technically incorrect. As far as Sprint's rollout of 1xA goes, everything I've read on here is vague, and others who have asked couldn't find a source with a clear answer. People speak of 1xA a lot, but I have never identified a way to see if I device is connected to it (none of the engineering screens I have seen reflect anything useful).. Sprint could say it's there, but I don't know how one could confirm that. I already have the next app update overloaded with changes, so I'm not going to add anything else.. as soon as I iron out the bugs that have been popping up in testing, it's getting released. But I appreciate everyone's input and will be considering tweaking some labels in the near future. I have no plans to reduce functionality in the app or on the status bar icons. -Mike
  25. mikejeep
    I wasn't trying to say that a profile update wouldn't do a band rescan, but just that both a PRL and subsequent profile update were not necessary, as they would both trigger what you are ultimately trying to do; there is no need to do it twice. In my experience, doing a profile update alters your LTE band priorities as well, which is why I would avoid it for "Spark hopping" purposes. If airplane toggling worked, a band rescan wasn't necessary in your situation. That action does not do any sort of frequency scanning.. it just turns the radio off and then on again. That's typically enough to force an immediate switch to LTE on the same frequency the phone was previously on (i.e. EV-DO 1900 to LTE 1900), but that alone will not force a switch in bands (i.e. CDMA 1X 1900 to CDMA 1X 800). I'm interested what Global vs. LTE mode actually does, but when I was investigating it a couple of months ago, the only effect while on the Sprint network seemed to be switching the equivalent options in the Radio Info screen from "LTE/CDMA auto (PRL)" to "LTE/GSM/CDMA auto (PRL)". The 1X option correlates to "CDMA only" and the 3G option is "CDMA auto (PRL)". I don't have any LTE band 26 or 41 in my area to test yet, but I have yet to see any changing of these options force a move from CDMA 1900 to 800. I mess around with it quite often while testing my app. -Mike
×
×
  • Create New...