Jump to content

ingenium

S4GRU Premier Sponsor
  • Posts

    1,717
  • Joined

  • Last visited

  • Days Won

    17

Posts posted by ingenium

  1. I wonder how this would affect, Miami, for example. It's a really mixed market between Clear and Sprint sites.... I've also for a couple Clear 2xCA sites. So it all comes down to ripping wimax fully out? Or???

     

    Sent from my XT1575 using Tapatalk

    Funding mostly. They can add 8T8R to existing Clear sites that are colocated with Sprint sites without tearing out the Clear gear. For standalone Clear sites they'll eventually be replaced with Sprint gear.

     

    Sent from my Nexus 6P

  2.  

     

    That would make Las Vegas one of the 3CA markets because there was no clear conversion. I see more and more former Clear sites in the East Bay being replaced or upgraded, broadcasting as Sprint sites. I hope Sprint will not take too long to finally rip and replace all current Clear equipment after WiMax has been shut down.

    Which ones? They can't tear down the equipment yet because wimax is still running. I know of a couple that got 8T8R added and Clear B41 turned off. The last I'm aware of was maybe 6 months ago?

     

    Sent from my Nexus 6P

  3. In which markets is the 3CA equipment ready to go?

    I believe any market with Sprint B41 as opposed to Clear B41, pending the results of FIT. Once those tests are complete and the configuration is approved, I think it's just a remote software update. Both 8T8R and triband antennas support a 3rd carrier.

     

    Clear equipment in those markets will continue with 1 or 2 carriers, depending on what the equipment is capable of.

     

    Sent from my Nexus 6P

  4. I wish this thread were more active. I'm curious, what are people's experience with Sprint in the South Bay now compared to six months ago? How much time do you spend on LTE? I was in San Jose with my friend last week and his iPhone was on 3G probably around 50% of the time, which is about what it was when I left Sprint at the end of the summer, which seems crazy to me.

    While not the South Bay, in SF and Oakland speeds are good if you're on B41. B25/26 are mostly saturated though and are sub megabit during the day. A lot of our sites have B41 though; 35% confirmed (75% of which have a confirmed 2nd carrier), but that includes the suburbs, the North Bay, and areas that haven't been visited in a while to get recent logs. The immediate bay area is a much much higher percentage, especially when you add in the Clearwire sites.

     

    The only time I drop off LTE is underground on BART and when I'm in the Castro. I had assumed the South Bay would be similar and would have improved due to the Super Bowl.

     

    Sent from my Nexus 6P

    • Like 1
  5. Sorry I should have been more clear I don't have the LTE roaming line. Why would the 5x and not the 6p?

    The 6P also doesn't have the CA line and lacks a useful/functional LTE engineering screen. Different people writing this part of the software is my guess (ie different manufacturers)

     

    Sent from my Nexus 6P

    • Like 1
  6. While I appreciate the sentiment and effort, as a security conscious consumer I don't install unknown APKs on my device. Although this one is signed with something called "Sprint Android Production Key" since I can't validate that certificate and I assume Sprint won't publish their known signing cert public key somewhere for validation, I'll just have to go without.

    There are other copies of the apk floating around. You could download them and see if the serial number and SHA1/SHA256 signature on the signing certificate match. Or pull a copy off someone else's Sprint device.

     

    Sent from my Nexus 6P

  7. For me there is a guy on reddit.com/r/sprint who works in engineering who looked it up for me. He said the only way to get the site upgraded to LTE was to submit a report through Sprint zone app, except I don't have that on my N5 so can't do it. Anyway there's no way they don't know that a site along the 380 corridor isn't running LTE, tens of thousands of commuters drive that route every day and hand off to this site. During rush hour the EVDO is so overloaded that I can't even get a speed test to complete and I get the bang "!" next to 3G... off times I can get tolerable service from the site.

     

    Even more frustrating is that there's even an extra unused basket at the top of the site from the old Nextel equipment, it makes no sense why it hasn't been upgraded. Site photo: http://imgur.com/cijthLK

     

     

    I sent you a PM with the BID of the site that is killing the 380 corridor for Sprint.

    You can install the Sprint Zone app and it'll still let you submit reports. You can't view any account info or other things in the app, but report submission works. Here's the current version: https://drive.google.com/open?id=0B0VwIsKe5ermNXpqZ3FRcE52Vmc

     

    It'll say "updating" and "content is updating. Try again later" the first few times you open the app (at least it did for me on my Nexus 6P). But eventually it'll start working and let you submit them.

     

    Now, as to whether the reports are "valid" (since I'm guessing some fields like PRL, device ID, etc are missing) is another story... I would hope Sprint would investigate them anyway, but no way to know for sure.

     

    Sent from my Nexus 6P

  8.  

     

    Awesome, I'm on the nexus 6p, bootloader unlocked with tether working and Android pay is the only reason I'm not rooting.

     

    I don't feel like keep fighting Google blocking the pay exploit bc I use pay a lot.

     

    Sent from my Nexus 6P using Tapatalk

    Yeah, Pay is unfortunately a bit of a cat and mouse game. It currently works with the right work around (I used it a couple days ago at Trader Joe's). Worst case though is they block it and you just full unroot from the SuperSU app and you're back in business with using Pay in a few minutes, albeit giving up root features.

     

    Sent from my Nexus 6P

    • Like 1
  9. On my N6

     

    crw-rw---- 1 system    system       230,   0 1970-03-21 05:14 /dev/smd0
    crw------- 1 root      root         230,   1 1970-03-21 05:14 /dev/smd1
    crw------- 1 root      root         230,  11 1970-03-21 05:14 /dev/smd11
    crw------- 1 root      root         230,   2 1970-03-21 05:14 /dev/smd2
    crw------- 1 root      root         230,  21 1970-03-21 05:14 /dev/smd21
    crw------- 1 root      root         229,  11 1970-03-21 05:14 /dev/smd22
    crw------- 1 root      root         230,  27 1970-03-21 05:14 /dev/smd27
    crw------- 1 root      root         230,   3 1970-03-21 05:14 /dev/smd3
    crw------- 1 root      root         230,  36 1970-03-21 05:14 /dev/smd36
    crw-rw---- 1 system    system       230,   4 1970-03-21 05:14 /dev/smd4
    crw-rw---- 1 system    system       230,   5 1970-03-21 05:14 /dev/smd5
    crw-rw---- 1 system    system       230,   6 1970-03-21 05:14 /dev/smd6
    crw-rw---- 1 bluetooth net_bt_stack 230,   7 1970-03-21 05:14 /dev/smd7
    crw------- 1 root      root         230,   8 1970-03-21 05:14 /dev/smd8
    

    Hmm, that's interesting. The files are exactly the same as on my Nexus 6P (including /dev/smd7 being owned by bluetooth), with the exception of the major number being offset by 6 (230 vs 224, and 229 vs 223), and the ownership of /dev/smd11 (system vs radio).

    root@angler:/ # ls -l /dev/smd*                                                
    crw-rw---- system   system   224,   0 1970-04-04 19:18 smd0
    crw------- root     root     224,   1 1970-04-04 19:18 smd1
    crw-rw---- radio    radio    224,  11 2016-02-18 20:33 smd11
    crw------- root     root     224,   2 1970-04-04 19:18 smd2
    crw------- root     root     224,  21 1970-04-04 19:18 smd21
    crw------- root     root     223,  11 1970-04-04 19:18 smd22
    crw------- root     root     224,  27 1970-04-04 19:18 smd27
    crw------- root     root     224,   3 1970-04-04 19:18 smd3
    crw------- root     root     224,  36 1970-04-04 19:18 smd36
    crw-rw---- system   system   224,   4 1970-04-04 19:18 smd4
    crw-rw---- system   system   224,   5 1970-04-04 19:18 smd5
    crw-rw---- system   system   224,   6 1970-04-04 19:18 smd6
    crw-rw---- bluetooth bluetooth 224,   7 1970-04-04 19:18 smd7
    crw------- root     root     224,   8 1970-04-04 19:18 smd8
     

    If you do ls -l /dev/smd* are there any files that are owned by radio? I find it odd that Qualcomm appears to have removed this functionality from their driver for 1-2 generations before adding it back in. 

     

    It looks like it's trying to use /dev/smd11, just like the on Nexus 6P, but for some reason the modem is responding with an error. So either the /dev file is different on the 5X, or the driver for the Qualcomm 808 doesn't support issuing modem commands for some reason. Can you, or anyone else with a rooted 5X, run ls -l /dev/smd* in a root shell and see if any of them are owned by radio?

  10. i cant seem to get it to work on my nexus 5x but i could be doing it wrong i suppose.

    Can you enable full logging in SuperSU, try it again, and then look at the 2 recent log entries in SuperSU and see if one of them lists an error? 

     

    Or, preferably, open a root adb shell and type: 

    ls -l /dev/smd*

    and post the output? It's possible CellMapper is just using the wrong file by default on the 5X, which you can change in the CellMapper settings. The above output will tell us which file it should be using.

  11. From the list of devices on this post (https://plus.google.com/+IvanZupan/posts/3aXM3Y6QCC2), it appears to work on the Snapdragon 801, 810, and 410. Reported not working with the Nexus 6 (Snapdragon 805) and Nexus 5 (Snapdragon 800). I find it odd that it works with the 801 but not the 800 or 805. I'm going to have a friend with my old Nexus 6 double check for me and will report back. 

     

    Mike, the comments on that post give some more information about the different smd devices used on various phones and might help you out. I particularly found the comment about mknod interesting (learned something new about Linux there!). For what it's worth, on my Nexus 6P /dev/smd11 has major number 224 and minor number 11. Not sure where he came up with major number 245 to test for the Nexus 5... We might have to try to comb through the Android source code for device specific information. The major number should correspond to the kernel driver being used.

     

    I did notice though that after running "ls -l /dev/smd*" that /dev/smd11 is the only smd## style file owned by "radio". That might be a good way to determine which file to use on a given device, ie:

    ls -l /dev/smd[0-9] /dev/smd[0-9][0-9] | grep radio | grep -oE '[^ ]+$'

    Btw, ls -l also shows the major and minor numbers for each file in /dev.

  12. I'm still sitting on LTE as my preferred network type. Also why would we need Global set?

    It doesn't need to be set, but it's the default option. I'm just saying one of the last 2 forced profile updates reverted mine back to the default setting. I would assume they do this when they make a more substantial change to the network settings, but maybe not.

     

    Sent from my Nexus 6P

  13. My hero! I would have killed to have read your posts about 8 hours ago.. I've been working on implementing this all day. I have tackled a majority of the issues, but it literally took all morning. Figuring out the exact modem command had me hung up for a bit (escape characters tripped me up but I figured it out after I finished my Cheerios) and I was struggling to figure out the best way to read the response from the appropriate device without choking the phone. Your code takes a slightly different approach than my implementation, but I think there's enough there to get me over the hump. Shame on me for not looking at S4GRU earlier.. I would be done by now. THANK YOU!

     

    -Mike

    You're definitely welcome! I initially tried using read commands and doing it all with 1 root shell session, but it kept choking and getting out of sync. The only way I could reliably get it to work was using 2 root sessions, one reading the output of cat line by line looking for one that has the info we want, and the other using echo to issue the commands. If you use cat, remember to call kill() on destruction rather than close(), otherwise it will hang waiting for the shell to be idle which it never will unless you figured out how to terminate the cat command :-) I kept wondering why it would hang then crash any time I tried to disable the feature from the app preferences

     

    Sent from my Nexus 6P

  14. That is huge! I'm struggling to find time to dig into app-related things lately (life is good, that's all!), but I'll look into it. I would LOVE to get something like this implemented, even if it's only for a limited subset of devices.

     

     

    Not necessarily true. SignalCheck users tend to be on the nerdier side, and many of us just happen to be rooted as well. I don't mind implementing features that require root because it's better than not implementing them at all (i.e. the "Reset" feature and a few other goodies, like direct PRL Updates for some Nexus users).

     

     

    I've been testing out some options to turn on location/logging when plugged in, so this is along the same lines. There are a lot of half-working features like this I'm testing on my own devices. Progress is slow because I'm learning how to code as I go! ;)

     

    -Mike

    Just saw this post after I replied to your post in the LTE Discovery thread. I'd be happy to help you implement the feature if you want. As I said in that post, feel free to take the code I submitted on github to Signal Detector. It's hopefully commented well enough that you'll be able to follow it. I just threw out the earfcn data for neighbor cells in that implementation because it was more a proof of concept and a little tricky to match up to the PCIs from the Android API (ie B25 and B26 show the same PCI, so you have to guess based on reported signal strength which one to assign the earfcn to)

     

    Sent from my Nexus 6P

    • Like 3
  15. Is it actually displaying the true EARFCN for you? On my Nexus devices, I just see a generic range that corresponds to the current LTE band. If so, that is awesome and they definitely have a leg up on my developer skills!

     

    -Mike

    Yes, it's the true EARFCN. The code I submitted to Signal Detector hardcodes /dev/smd11, but it seems on other devices they may use /dev/smd0. /dev/smd3 or smd7 may also be valid. My device (Nexus 6P) has the other files, and I believe they all respond to the inquiry, but I haven't tested to verify. I'm not sure what the difference is between them, if any.

     

    I would probably recode it to first check which smd files exist (using ls /dev/smd* ), then of the ones that are there, try each until one works (maybe in a certain priority?). And if none work or the ls command returns exit code 1 (file not found), then gracefully fail and don't display the EARFCN. I think LTE Discovery does it that way, and always attempts to get the true EARFCN, and if it can't it just displays the range.

     

    Feel free to take the code I linked to in my earlier post if you want to add it to SCP. I'd go ahead and make the change for the filename mentioned above as well, but I'm waiting on the pull request to be accepted first. I'm happy to help you implement this feature in any way that I can, if you're interested.

     

    Sent from my Nexus 6P

    • Like 3
  16. How?

     

    With LTE Discovery it seems the feature is automatically enabled if you have root (and grant it root permission when it asks). I took this screenshot earlier on my Nexus 6P

     

    QIJsHEXl.png

     

    I also submitted a pull request adding the feature to Signal Detector: https://github.com/lordsutch/Signal-Strength-Detector/pull/1/files I can send you the APK if you don't want to wait for lordsutch to accept the patch.

     

    vuwF9jKl.png

     

    The interface that's used to fetch it also returns the EARFCN for the neighbor cells. So it's possible to display that as well. The only app currently doing this is CellMapper: https://play.google.com/store/apps/details?id=cellmapper.net.cellmapper&hl=en

  17. Im not sure if you need to purchase the app or not, I do see in-app purchase in the store info. Its been soo long since ive had this application im not sure. Another option would be to look at someone else's device.

     

     

    Damn you N6P!! Damn you to hell! :wall:

    You need root. With root it will work.

     

    Sent from my Nexus 6P

  18. There is a confident requirement for the site info. We could not have them crowd sourced. But it would be great to allow them to be loaded to be displayed along with the GCI and on local maps.

     

    Sent from my LGLS991 using Tapatalk

    I assumed the crowdsource feature simply sends the current data that's being received from the device, and wouldn't send user notes or imported/past data. But you're right, we wouldn't want the imported data to be uploaded for crowdsourcing.

     

    Sent from my Nexus 6P

×
×
  • Create New...