RyanThaDude

That's awesome! Thanks @mikejeep!

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!

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

I have the hardest time finding anything I need on the FCC website.  I guess I just don't know exactly what to look up or where.  Thanks for the advice. 

Try this: http://specmap.sequence-omega.net/

Sent from my Pixel 2 XL using Tapatalk

Just now, danlodish345 said:

What's q beta?

Sent from my SM-G973U using Tapatalk
 

Android Q, the beta of the newest Android OS. It was released today for Pixel devices. https://www.google.com/android/beta

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. 

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

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

1 hour ago, mikejeep said:

I have B5 as 17/27/37/47/57/67 (dec) from @Trip but that's the only confirmed B5 data I have received. The 15.. 16.. 18.. 19.. examples do not conflict with anything else I have noted, so all of those might be accurate. Have you definitively confirmed each of those? I can't wait for the day when every device reports EARFCNs.. @david279 mentioned above that Samsungs are reporting on the Oreo 8.1 preview which is huge.

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.

1 hour ago, mikejeep said:

Keep me updated.. I just have to be careful to assume that something deployed in one market is going to hold true elsewhere (i.e. T-Mobile's mess).

Done & done! Definitely understandable. I'll be doing some more digging around and let you know what I find.

1 hour ago, mikejeep said:

NSG is not a good comparison, because they do not use native Android API methods, they communicate directly with the modem using routines not available to anyone else. It results in great data, but for now it's not the type of information within my reach. But I should be able to do anything CellMapper is showing -- could you give more details? SCP should show the same data.

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.

1 hour ago, mikejeep said:

Sure, so GCI like FAxxxxxx / FBxxxxxx? Can you confirm any other details? PLMN 311480 I assume? Nobody has mentioned them.

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!

@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?

GS8+ Oreo beta shows everything now

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

This may have been asked before. I have a new phone and wonder if I can retrieve my site notes to import into the app in the new phone.

 

TIA,

David

 

Sent from my 2PZC5 using Tapatalk

Back up your database on the old phone, import said database on new.

 

Sent from my SM-G935V using Tapatalk

No luck sending you diagnostics. Tried on LTE & WiFi. Got a screenshot of the error I got while sending:

 

I am using an unrooted S7 on Sprint, running the U firmware (Unlocked) 7.0

Same error on my S7 Edge VZW.

 

Sent from my SM-G935V using Tapatalk

Ahh. If you enable full logging for SuperSU for CellMapper (while it's closed), then run CellMapper for a minute and exit, then go to SuperSU, it should have logs. Look for the lines saying "cat /dev/______". Whatever that _____ is is the appropriate device name to give SCP.

 

Sent from my Pixel XL

Doesn't work that way unfortunately on my N6 with Nougat.

 

Sent from my SM-G935V using Tapatalk

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

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.

 

 

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 4²: 0D,17,21

Band 13: 01,02,03

Band 2 available in your area? When i had tmo, it identified it no problem.

 

Sent from my SM-G928P using Tapatalk

I never had a problem, either. SCP would identify bands 2, 4, and 12 no problem.

 

Sent from my Nexus 6 using Tapatalk

Since I started testing my fix for this "bug" it's certainly seeming more and more like this is not a bug at all, but intentional behavior by Android 5.0+ devices, most often when connected to a weak LTE signal. The only "bug" is that the current release of SignalCheck does not display the GCI (which, in turn, causes other issues, like band identification and site note entry/display). But my fix does appear to be solid and ready for release. The only thing holding up an update is the new EARFCN features, which I'm close to finishing.

 

-Mike

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

Do you have the 4.2 API enabled? 

 

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

Why is it that sometimes the app doesn't report which band you're on??

My device is a Nexus 5x

 

 

Sent from my Nexus 5X using Tapatalk

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

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

This happens to my laptop a lot and there is a nice video on YouTube that I use to fix it. Just look up burn in fix and leave the video running for a bit.

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

So today while my phone was sitting on a white screen loading an app, I noticed that the SignalCheck Pro logo and text has burned into the top left corner of my Galaxy S5's screen. I didn't think burn-in was a problem on modern screens.

 

But I think it speaks to the amount of time SCP runs on my phone.

 

- Trip

Same here on my S5. Didn't notice it on my Nexus 6 yet.

 

Sent from my Nexus 6 using Tapatalk