Jump to content

mikejeep

Honored Premier Sponsor
  • Posts

    3,269
  • Joined

  • Last visited

  • Days Won

    188

Everything posted by mikejeep

  1. Hmm.. I hope there's a chance you dropped the B41 connection between the engineering screenshot and the SignalCheck one, because SignalCheck is showing the wrong MCC-MNC. The S4T has this problem; it always reports the "home" ID, not the currently connected one. I would like to ask a favor of the G2 users out there with the Spark update who are connecting to band 41 and use SignalCheck: Could you let me know if the LTE MCC-MNC is showing correctly in the app (should be 311490 or 311870 -- not 310120)? If not, can you hit About > Send Diagnostics next time you think you are on band 41? Just note that's why you're sending it in the comments. EDIT: Thanks to lilotimz, I see what is going on behind the scenes prior to the Spark update; I'd still like confirmation from someone using the newer 2.0.20018 baseband from the latest update as well. Thanks, -Mike
  2. Oh I knew you were joking, but I would love to somehow get it on hotspots too. But I doubt they are running Android under the hood, there is no need for a full OS. Now you're making me hungry and I suddenly want to go cook up the infinite amount of beans the rest of the world assumes we keep in our cabinets.. -Mike
  3. Ah. Must just be a matter of display then, since with 0, 1, or 2 leading zeroes it's still the same decimal value. Band 25 in the Boston market only has 6 characters, so theoretically the Zing would only pad one zero onto it. I'd make a version for hotspots, but the Android version keeps me busy enough! Plus, I don't really know how that would work.. you can't load apps or additional modules to those, can you? -Mike
  4. Surprisingly, "enginerring" reports the proper current MCC-MNC on its native screen, but it doesn't report it to the Android telephony functions. Android provides access to 4 different MCC-MNC functions; I agree with you, it looks like the S4T reports the native one from the SIM to all of them. -Mike
  5. It's not really more/less characters.. you're just dropping a leading zero. B7E702 == 0B7E702 == 00B7E702. SignalCheck should automatically pad GCIs to 8 characters, so if you're seeing one missing in the app, please let me know. They are likely very different because the B41 sites that are live were Clearwire sites, while the B25 sites have been Sprint's from day one. EDIT: ALU PCI's in the Boston area appear to be arbitrary also; no 169-spacing that I have seen. -Mike
  6. No.. that message has been going out to people all over the country in the past week. Some people are in areas that have a long way to go before NV could be considered "largely complete". It has been mentioned in a few threads. That being said, we are spoiled around here when you look at the progress in some other areas, except for Chicago and Atlanta. -Mike
  7. Interesting! By any chance, have you ever happened to notice if SignalCheck shows anything? I'm guessing if you have bars, it should.. I haven't tried grabbing a VZW SIM because I figured it wouldn't work at all, but maybe I should find one. -Mike
  8. Yes. Read back in the thread, several people got it OTA. Polite request to all: You don't need to share with us that you don't have the update yet. Those posts just fill up the thread and generate more questions from people who don't want to dig through all the "me too" posts. -Mike
  9. It's just new versions of the LTE and 3G icons that were previously on the phone. The icon does not indicate LTE band; it's the same one for any LTE connections. -Mike
  10. It is too early to tell, but it's something to keep an eye on. The MCC-MNC is a better indicator of band 41; it should be 311490 or 311870. I'm a bit concerned that it says 311870 on the engineering screen but 310120 in SignalCheck, which would indicate band 25 or 26. Perhaps it flipped back to band 25 before he caught that screenshot. Otherwise, the G2 is suffering from the same issue the new Samsung S4T has, it's not reporting the correct MCC-MNC to Android. Those GCIs you mention appear to be decimal format, GCI is typically expressed in hexadecimal. From an iPhone user I'm guessing? In any case, they do not appear to translate into valid GCIs, unless I am interpreting them wrong. I believe that 8.22E+03 is 8220 (hex 201C) and 8.22E+05 is 822000 (hex C8AF0). As I noted in the other thread I just replied to you about, Sprint GCI and PCI values from the same site do not appear to have a recognizable correlation. -Mike
  11. You realize that the Nexus 5 doesn't have its Spark update either, right? -Mike
  12. Why doesn't it make sense? The G2 and the G Flex are two completely different devices. The "update" on the Flex is likely not the same code that the G2 requires. Not to mention that Sprint hinted the G2 update would be out by the end of the month, and we still have a week to go. And do we have any proof that the Flex will be Spark-enabled at launch? It's not entirely clear in the press release, and I have yet to see a hands-on review confirming it. You are basically complaining that the Flex should not be released until the G2 and Nexus 5 both have the Spark update. To use your line, "That dont make any sense at all." -Mike
  13. Relax. It's not a letter of what's "right", it's a matter of not releasing an update until it is ready. I'm sure that Sprint and LG would have shipped the phone bug-free and Spark-ready from day one if they could have. You're talking about technology that hadn't ever been deployed on Sprint's network until a couple of months ago, and a large majority of the country still doesn't have access to it. Go outside and enjoy the weather. If the G2 update is the biggest drama in your life, you're doing ok. -Mike
  14. HTC has a great page showing a diagram of the update process. It helps explain why a Nexus (or an iPhone, if you think of it) gets updates immediately, but it takes months for a new Android version to make its way to provider-specific devices: http://www.htc.com/us/go/htc-software-updates/ The process for non-OS updates is similar. LG posting source code may or may not be a sign that a public update is imminent. Sprint has to test and certify it before that happens. I don't see why LG would publicly post code from an update that has not been certified yet (and therefore might not be released), but who knows. -Mike
  15. Booooo, you already used that one, get some new material, amateur... ( throwing tomatoes ) -Mike
  16. Got it.. are you able to see anything popping up in logcat when it happens? You can try going back into the app and sending me a diagnostic report right after, but it might clear out the log on a restart. -Mike
  17. I hadn't heard of that specific issue, but the freezing/crashing reports have been wildly inconsistent so it is probably all related. Did you have any alerts enabled? That seems to be the biggest culprit, but I'm not convinced it's the only one. The version I have been testing the past couple of days suddenly seems stable.. not sure if it was something I did or something Google quietly fixed in the background, but it seems much better. Fingers crossed.. been spending hours and hours on this with little to show for it. -Mike
  18. Heh.. yeah I see the mobile one is still way off, but someone over there must be paying attention. Just doing my little part to save the world from misinformation, one small article at a time.. -Mike
  19. Haha, I just read it a few minutes ago and thought the same thing! Even decided to comment on it to gently point out that it's the same phone.. -Mike
  20. Interesting, never realized that! Edited my original post, thanks for the info. -Mike
  21. A few of you have reported this to me.. JossMan's issue appears to be yet another Samsung enginerring screen bug. It appears to be showing the home/default MCC-MNC for the device in that field, instead of the one it is actually connected to. Especially in JossMan's case, where he's using a Sprint device but is a Virgin Mobile customer, and 311-490 is VM's ID. There are various functions that Android reports the MCC-MNC through. SignalCheck displays the one that has proven to be the most reliable no matter what the connection status is, but the diagnostic reports that can be sent from the app include them all. The evidence I have seen indicates that SignalCheck is correct. In the case of the S4T, the issue is reversed -- the enginerring screen shows the correct ID, but the phone always reports the home/default MCC-MNC. I have been in touch with Samsung, but of course I was left hanging with the dreaded "we will pass it on to the appropriate people". EDIT: To add to this topic overall, I'll toss in this note that I posted in the SignalCheck thread: I was able to confirm with Sprint that Band 25 and 26 are only using PLMN (MCC-MNC) 310-120. Band 41 is only on 311-490 or 311-870. All of this is subject to change in the future if they decide to consolidate IDs. However, I also know that Virgin Mobile users see Band 25 on 311-490. -Mike
  22. OTAs for all Android devices (except HTC - see here) are completely random, no matter what wireless provider is involved. It is done that way to keep the load balanced on their servers. If you can't wait for your turn, it will probably be available for download from sites like XDA shortly after the rollout begins. -Mike
  23. (You need to edit your post and remove the specific site references and statuses -- this is not a sponsor area.) It could be related to work on band 41 (or 26) sites in the area, but that's really just a guess on my part. If you had a tri-band device, I would speculate that was the issue; others have indicated that tri-band phones without the Spark update have trouble connecting to any LTE when the new bands are live in the area. But, with the original S4, that specific issue shouldn't affect you. They could be very close to 'flipping the switch' on LTE for those other sites; considering how much progress has been made around the area, the remaining sites are probably more complicated to access or just haven't received their backhaul yet. It has been noted that the weather isn't slowing down crews elsewhere, and I would expect those working around here to throw on an extra pair of socks and keep working also. Contractors who don't work don't get paid. 800 LTE acceptances are still few and far between around here, so it's probably a bit early to suspect that. They might have adjusted the strength/downtilt at the site you were connecting to last year, resulting in it having worse performance at your specific location. You could always inquire directly with Sprint; you will typically get generic answers from them, but you never know. If Customer Care doesn't seem to dig into the issue as much as you would like, you can always try the dan@sprint e-mail team. -Mike
  24. A CDMA 800 upgrade on a site isn't the primary reason that you no longer connect to LTE there. Is that closer site LTE-accepted on the maps here? Are you certain you were connecting to the site you think you were? Your phone has most of the control over which site you are connecting to; it doesn't care which site is closer or farther away, it tries to stay with the strongest available signal. -Mike
×
×
  • Create New...