Jump to content

RyanThaDude

S4GRU Member
  • Posts

    49
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by RyanThaDude

  1. For months I've been complaining on CellMapper about DISH Wireless's (313340) current method of obtaining its gNB is incorrect, where sites are split between gNBs, mismatch sectors, and other general errors. Today I mapped several of DISH's sites on SCP and it also seems to be using the same method as CM. Without having to re-type everything out again, here's the post on Reddit I made on r/CellMapper: I'm not proposing this is official by any means, but it does make much better sense than what is being used right now. Thanks!
  2. I had this issue when importing prior to the GSM PSC logging. I had to export a blank database then use a sqlite db editor (I used Sqlite Studio for Windows) to copy the old database to the new empty one. Sent from my Pixel 2 XL using Tapatalk
  3. Android Q, the beta of the newest Android OS. It was released today for Pixel devices. https://www.google.com/android/beta
  4. Just a heads up, I updated to the Q Beta on my Pixel 2 XL and it broke SCP. It no longer shows the connected cell.
  5. Just FYI it seems Verizon is changing their cells. Band IDs are now assigned to B2 (OC, 16, 20) instead of B4 AWS. No change to B13. No signs of B4, B5, or any others as of yet. Sent from my Pixel 2 XL using Tapatalk
  6. SCP has been reopening on me as well on occasion. I've had it happen on all of my devices including my unrooted stock Pixel 2XL and Nexus 6P running LineageOS 15.1. It usually happens when I access SCP through the notification. Sent from my Pixel 2 XL using Tapatalk
  7. Yes, it's been confirmed. These are the cells I found a few days ago, which are on CellMapper. Thankfully my N6P got the EARFCNs since the S7E didn't. I saw that post and gave a slight glimmer of hope for Samsung but considering I'm on VZW I'm sure they'll neuter it because, well, that's what they do best. Done & done! Definitely understandable. I'll be doing some more digging around and let you know what I find. Fair enough about NSG, but CellMapper will mostly show the same info as well. Here are a few screenshots of my N6P showing the cell data from my network extender in NSG, CM, SCP, and Android's phone info screen. While the device is rooted, CM isn't using it so I can only assume that's it's getting the data via the API. Again, this was just a thought since it would allow capture of data without or with a bad SIM. I have an extender (311480, yes) that's currently using the first three hex of 0FB, and a few in the area as well (same ID, different sector), but it was once assigned 0FA a few months ago. By default they use B13, but they can be configured by Big Red to use B4. Sadly, since my S7E doesn't capture EARFCNs, I'm unable to determine if there's a difference in B13 and B4 IDs. Only a select few were able to get captured by the N6P and they were all B13. Cheers!
  8. @mikejeep, a few things: I'm starting to notice in my area (Chicago/NW Indiana) that Verizon is deploying Band 5, but SCP doesn't display it as such, but without anything other than LTE. The ones in my area are using 16, 26, & 36 (decimal) and was confirmed on my Nexus 6P with NSG and matched up with my Galaxy S7 Edge (no EARFCN ). However, I've noticed elsewhere while browsing CellMapper that B5 has several other sectors such as (15, 25, 35), (18, 28, 38), and (19, 29, 39). Unlike B4 (and maybe B2?) where there are second carriers, these appear not to be as such as I haven't seen any sites with two different B5 sectors. So far I haven't noticed any correlation on the assignments but as soon as I find more data, I'll hopefully see it. I've also noticed while browsing that there are sectors assigned (72, 82, 92 - B4) and (74, 84, 94 - B2) along with the normal macro-style numbering in the San Francisco area, which appear to be a small cells. To what I've notice so far a site can have three different eNB numbers, but are seem to be treated as sectors. For example, I've found 3 cells with different eNBs but the same PCI (38032, 338032, 638032). The only difference is the starting number (0, 3, 6). Along with the B5 issue, I'll be doing some research on this as well. Last thing, would it be possible to be able to get the cell data in SCP without being actually connected to the network, much like NSG or CellMapper does? I'm using a Nexus 6P that has a SIM issue and in those apps I can still see cell data, although from different carriers. I use it frequently along with NSG to lock bands to determine which carrier(s) are at a site, although it can be unpredictable. Adding the ability to have SCP do this as well would be extremely useful. Maybe, have it be an option to turn this feature on/off. Thanks as always, Mike! EDIT: I also forgot to mention that there's also something that could be added is Verizon's Network Extenders (femtocells). So far the ones I've found all start with the hex FA and FB. Many units share the same eNB but have different sectors. Could those be added as well?
  9. Nice. Makes me wonder if the S7E will be the same, if we get Oreo at all. Then again I'm on the Verizon variant. Sent from my SM-G935V using Tapatalk
  10. Back up your database on the old phone, import said database on new. Sent from my SM-G935V using Tapatalk
  11. Never mind my issue. It's my phone as every other app doing the same thing. I think it may be time to move on from my N6 as I've had nothing but problems with the radio. Complete loss of signal, LTE quits, constantly having to cycle airplane mode to even get it to connect, and now this. Sent from my Nexus 6 using Tapatalk
  12. I'm having a strange issue and I'm pretty sure this existed prior to the latest upgrade. The data on the SCP screen doesn't update. This is on my Nexus 6 running stock systemless rooted Marshmallow w/ March Update. I even uninstalled and reinstalled the app, along with restarting the phone and clearing cache.
  13. Out of curiosity will the newer versions have Verizon's LTE Band 4 identification, in what I can only assume it's second carrier? I'm noticing quite a few sites in certain markets in my region are using them. They are just identifying as "Verizon" w/o a band. So far everything else is identifying perfectly, including Verizon's LTE Band 2. Band 2: 0E,18,22 Band 4: 0C,16,20 Band 42: 0D,17,21 Band 13: 01,02,03
  14. I never had a problem, either. SCP would identify bands 2, 4, and 12 no problem. Sent from my Nexus 6 using Tapatalk
  15. If it means anything when I disable VoLTE or when in an area where it's not supported on my Nexus 6 on VZW the "bug" appears. I found this out a few months ago when I was in an area where US Cellular owns the CDMA market and VZW was deploying new LTE sites. AFAIK Sprint doesn't use VoLTE, so not sure there. Sent from my Nexus 6 using Tapatalk
  16. 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 crw-r----- 1 radio radio 229, 25 1970-03-21 05:14 /dev/smd_cxm_qmi crw------- 1 root root 229, 28 1970-03-21 05:14 /dev/smd_data_0 crw------- 1 root root 229, 27 1970-03-21 05:14 /dev/smd_logging_0 crw------- 1 root root 229, 30 1970-03-21 05:14 /dev/smd_pkt_loopback crw------- 1 root root 229, 24 1970-03-21 05:14 /dev/smd_sns_adsp crw------- 1 root root 229, 21 1970-03-21 05:14 /dev/smd_sns_dsps crw------- 1 root root 229, 26 1970-03-21 05:14 /dev/smd_test_framework crw------- 1 root root 229, 12 1970-03-21 05:14 /dev/smdcnt_rev0 crw------- 1 root root 229, 13 1970-03-21 05:14 /dev/smdcnt_rev1 crw------- 1 root root 229, 14 1970-03-21 05:14 /dev/smdcnt_rev2 crw------- 1 root root 229, 15 1970-03-21 05:14 /dev/smdcnt_rev3 crw------- 1 root root 229, 16 1970-03-21 05:14 /dev/smdcnt_rev4 crw------- 1 root root 229, 17 1970-03-21 05:14 /dev/smdcnt_rev5 crw------- 1 root root 229, 18 1970-03-21 05:14 /dev/smdcnt_rev6 crw------- 1 root root 229, 19 1970-03-21 05:14 /dev/smdcnt_rev7 crw------- 1 root root 229, 20 1970-03-21 05:14 /dev/smdcnt_rev8 crw-r----- 1 radio radio 229, 0 1970-03-21 05:14 /dev/smdcntl0 crw-r----- 1 radio radio 229, 1 1970-03-21 05:14 /dev/smdcntl1 crw------- 1 root root 229, 9 1970-03-21 05:14 /dev/smdcntl10 crw------- 1 root root 229, 10 1970-03-21 05:14 /dev/smdcntl11 crw-r----- 1 radio radio 229, 2 1970-03-21 05:14 /dev/smdcntl2 crw-r----- 1 radio radio 229, 3 1970-03-21 05:14 /dev/smdcntl3 crw-r----- 1 radio radio 229, 4 1970-03-21 05:14 /dev/smdcntl4 crw-r----- 1 radio radio 229, 5 1970-03-21 05:14 /dev/smdcntl5 crw-r----- 1 radio radio 229, 6 1970-03-21 05:14 /dev/smdcntl6 crw-r----- 1 radio radio 229, 7 1970-03-21 05:14 /dev/smdcntl7 crw------- 1 root root 229, 23 1970-03-21 05:14 /dev/smdcntl8 crw------- 1 root root 229, 8 1970-03-21 05:14 /dev/smdcntl9
  17. I know there's a lot to see in this thread but it's been discussed quite a bit. I can only guess it's a bug, but I think it can also happen when VoLTE isn't supported or working at the site. I'm on VZW so YMMV. Sent from my Nexus 6 using Tapatalk
  18. 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
  19. I'm going to assume that video is for a stuck pixel on an LCD screen. We're referring to screen burn on OLED screens, which can be similar to screen burn on old CRT (tube) screens. Sent from my Nexus 6 using Tapatalk
×
×
  • Create New...