SignalCheck - Android app to monitor your Wi-Fi/2G/3G/4G LTE/5G-NR signal strengths

[david279]

What's the PCI under LTE?

 

Sent from my One using Tapatalk 4

 

 

[digiblur]

What's the PCI under LTE?

 

Sent from my One using Tapatalk 4

 

Interesting!  That's the 3 digit style serving cell.  Very nice!  GCI is the Global LTE serving cell and the PCI is the Physical Serving Cell.  Up until now only the iPhone5 on Sprint could show both of those values.  What version of OS are you using?  CM?

 

Look at the NOLA Map or Spreadsheet and you'll see the site: Hayne & Bullard confirmed with the following 85, 254, 423 and 05A12Axx.

[david279]

Well I built cm 10.2 for the one using this patch for LTE CID info using 4.3 radio blob. http://review.cyanogenmod.org/#/c/48930/

 

And now that info is available. It should be merged soon.

 

Sent from my One using Tapatalk 4

 

 

[david279]

So I can see the sector value now. Cool.

 

Sent from my One using Tapatalk 4

 

[david279]

I believe this is @lordsutch patch.

 

Sent from my One using Tapatalk 4

 

 

[digiblur]

So I can see the sector value now. Cool. Sent from my One using Tapatalk 4

 

So go get the ones for I-10 & Read (Avalon Hotel Roof) - 05A094xx now  

 

And just a quick reference for others as I know many of us have called these serving cells everything from SIDS, to SCIDs, to HEX serving cells, to whatever.  The proper names are GCI and PCI.  I see mikejeep has the name correct for the PCI, maybe he can change the CID to GCI now as well. 

 

GCI = Global Cell Identity and PCI = Physical Cell Identity. 

 

The GCI is a unique value assigned to the basestation across the entire network.  In Sprint's world they use the last two digits to identify the sector.  It is usually 01, 02, and 03.  I've seen in some markets where 00, 01, 02 is used instead.  The iPhone5 shows this identifier in decimal format that is easily converted to hex.

 

The PCI is a smaller identifier for each LTE sector.  There are only 504 numbers in the spec and the sector numbers have to get reused.  Most people refer to these as 3 digit style serving cells shown on Samsung, LG, etc devices.  In Ericsson markets (and maybe Alcatel-Lucent markets) the serving cells are offset by 169 for each sector.  Example: 0, 169, and 338 would all be the same site. 

[david279]

 

Here you go

 

Sent from my One using Tapatalk 4

 

 

[digiblur]

 

Here you go

 

Sent from my One using Tapatalk 4

 

Oh wow...you're quick. 

[david279]

Yea just went outside and picked it up.

 

Sent from my One using Tapatalk 4

 

 

[mikejeep]

Oh wow...you're quick.

That's what she said!

 

-Mike

[mikejeep]

And just a quick reference for others as I know many of us have called these serving cells everything from SIDS, to SCIDs, to HEX serving cells, to whatever. The proper names are GCI and PCI. I see mikejeep has the name correct for the PCI, maybe he can change the CID to GCI now as well.

 

GCI = Global Cell Identity and PCI = Physical Cell Identity.

I have them labeled as Serving Cell, CID, and PCI because the Android routines I am using say that's what they are. But, to me, digiblur > Google, so expect this to change very soon

 

-Mike

[digiblur]

I have them labeled as Serving Cell, CID, and PCI because the Android routines I am using say that's what they are. But, to me, digiblur > Google, so expect this to change very soon

 

-Mike

 

Uhhh...put it all on my shoulders eh?  

 

For some SignalCheck trivia....  http://s4gru.com/index.php?/topic/579-network-vision-site-map-new-orleans-memphis-gulf-coast-east-texas-mississippi-and-louisiana-markets/?p=198579&do=findComment&comment=198579

[lordsutch]

Well I built cm 10.2 for the one using this patch for LTE CID info using 4.3 radio blob. http://review.cyanogenmod.org/#/c/48930/

 

And now that info is available. It should be merged soon.

 

Hopefully this one is small and unintrusive enough that it'll go in in the next day or two. Now to figure out why deck can get a GPS lock on jewel (Evo) but I can't with these blobs...

 

By the way, this patch doesn't fix everything; for some reason I won't have time to delve into for a day or so, apps that listen for CELL_INFO events don't get the updates in the callback even though apps that request an update with getAllCellInfo() do.  My cheesy app did the former until today, while both Sensorly and SignalCheck do the latter.  I'm not sure it's worth fixing, or even if it can be fixed without deep magic that will get rejected by CM.

[david279]

You have

LPP_Control_Plane

LPP_PROFILE = 1

 

In the gps.conf. On the m7spr we can't get a gps lock without it on 4g. It's a shot.

 

 

Sent from my One using Tapatalk 4

 

[lordsutch]

You have LPP_Control_Plane LPP_PROFILE = 1 In the gps.conf. On the m7spr we can't get a gps lock without it on 4g. It's a shot. Sent from my One using Tapatalk 4

 

I'll try that in my next build. Thanks!

[lordsutch]

Another interesting discovery with the 4.3 HTC RIL: if you dump out all the CellInfoLte records, you'll see the PCI, RSSP, and RSSQ for other sites the phone can also see. The site the phone is connected to will be the one with isRegistered()=true and usually will have the GCI and TAC reported as well. I may see about adding that info to my app mostly for my own amusement, but others might find it interesting too. For example:

D/CdmaSST (  930): [CdmaLteSST] SST.getAllCellInfo(): X size=4 list=[CellInfoLte:{mRegistered=YES mTimeStampType=oem_ril mTimeStamp=6598001508117ns CellIdentityLte:{ mMcc=310 mMnc=120 mCi=61107458 mPci=318 mTac=7466} CellSignalStrengthLte: ss=16 rsrp=-1023 rsrq=-66 rssnr=2147483647 cqi=2147483647 ta=2147483647}, CellInfoLte:{mRegistered=NO mTimeStampType=oem_ril mTimeStamp=6598001508117ns CellIdentityLte:{ mMcc=2147483647 mMnc=2147483647 mCi=2147483647 mPci=487 mTac=2147483647} CellSignalStrengthLte: ss=13 rsrp=-1108 rsrq=-148 rssnr=2147483647 cqi=2147483647 ta=0}, CellInfoLte:{mRegistered=NO mTimeStampType=oem_ril mTimeStamp=6598001508117ns CellIdentityLte:{ mMcc=2147483647 mMnc=2147483647 mCi=2147483647 mPci=460 mTac=2147483647} CellSignalStrengthLte: ss=7 rsrp=-1259 rsrq=-160 rssnr=2147483647 cqi=2147483647 ta=0}, CellInfoLte:{mRegistered=NO mTimeStampType=oem_ril mTimeStamp=6598001508117ns CellIdentityLte:{ mMcc=2147483647 mMnc=2147483647 mCi=2147483647 mPci=39 mTac=2147483647} CellSignalStrengthLte: ss=13 rsrp=-1796 rsrq=-800 rssnr=2147483647 cqi=2147483647 ta=0}]

Here we can see my connected GCI (3A46D02) and its PCI (318) first, followed by 3 other sites my phone is thinking of handing off to: PCIs 487, 460, and 39. 487 is presumably another sector of 3A46D (I think it's 3A46D03) by the Ericsson offset-of-169 rule, while 460 and 39 are PCIs from distinct sites that are clearly further away (-125.9 dBm and -179.6 dBm, respectively) that I haven't definitely identified yet. Someone really clever could probably do LTE geolocation based on having info on the signal strength of 3-4 sites.

[digiblur]

That's pretty cool! Wish we had a Samsung geek around in the CM side of things but I have heard way too much of that story.

[lordsutch]

You have LPP_Control_Plane LPP_PROFILE = 1 In the gps.conf. On the m7spr we can't get a gps lock without it on 4g. It's a shot. Sent from my One using Tapatalk 4

 

Alas, that doesn't seem to solve the problem on my device. I must have a blob missing or something...

[david279]

:/

 

Sent from my One using Tapatalk 4

 

 

[COZisBack]

Is it possible to not cache locations? I've cleared data twice but the same sites are getting linked wrong.

 

Today's post has been brought to you by Sprint, the letters GN and the number 2.

 

 

[mikejeep]

Is it possible to not cache locations? I've cleared data twice but the same sites are getting linked wrong.

 

It's not possible, but I am aware of the cache bug and it's actively being worked on and tested.. the issue appears to be when the BSL changes before a pending address response is received from the geocoding server.  The address is getting linked to the coordinates that are active at the time the response is received, not the coordinates that were used to get the address.

 

As soon as the fix is stable and running smoothly, I will release an update.. want to make sure it's perfect so I don't need to release several updates in a short period of time.

 

-Mike

[COZisBack]

It's not possible, but I am aware of the cache bug and it's actively being worked on and tested.. the issue appears to be when the BSL changes before a pending address response is received from the geocoding server. The address is getting linked to the coordinates that are active at the time the response is received, not the coordinates that were used to get the address.

 

-Mike

Agreed. Thanks Mike.

 

Today's post has been brought to you by Sprint, the letters GN and the number 2.

 

 

[mikejeep]

SignalCheck Pro has been updated to version 4.13 on Google Play.. it should be available within the hour.  The changes are below; big thanks to 4ginnc for his help in troubleshooting the cache bug!

 

Resolved issue with incorrect BSL address cache entries. (Pro)

This is the most significant reason for this release.  Those of you who follow this thread are aware that a bug was discovered in the BSL address cache introduced in the last version of the app.  If a BSL address response came after your device had switched 1X sites, the wrong coordinates were being attached to the address in the cache.  This has been fixed; upon installing this version for the first time, your cache will be wiped clean to eliminate any possible entries that were saved incorrectly.

 

Added hex value of BID on main display.

Users asked for it, so here it is!

 

Corrected LTE sector ID fields to display as “GCI” (Global Cell Identity) instead of “Serving Cell” or “CID”.

The technologically correct term is GCI, so that's what it's labeled as in the app now.

 

Resolved crashes on GSM devices when the MCC/MNC was invalid.

Some crashes were reported by GSM users starting with the last version; these should now be fixed.

 

Updated numerous entries in the CDMA and EV-DO carrier databases.

Revol Wireless should now display properly; there were a few other minor updates as well.

 

Thanks for all of your support!  SignalCheck Lite will be updated to 4.13 sometime next week.

 

-Mike

[mikejeep]

Uhhh...put it all on my shoulders eh?  

 

For some SignalCheck trivia....  http://s4gru.com/index.php?/topic/579-network-vision-site-map-new-orleans-memphis-gulf-coast-east-texas-mississippi-and-louisiana-markets/?p=198579&do=findComment&comment=198579

 

I was too slow in checking the trivia post to give an answer that didn't look like cheating, but I did notice it too! Relieved to see that it's just a testing thing, I was going to get mad if Sprint was going to start using PCS SIDs for SMR..

 

-Mike

[azoclark]

Added hex value of BID on main display.

Users asked for it, so here it is!

 

I am probably being way over the line, but any chance to change the format of this to be 0xHHH where zero x is the standard notation of signifying hex values?  My reasoning is that as I look at my phones running 4.13 one (on sprint) lists a BID of 385 (181) and the other (on verizon) lists a BID of 1585 (631).  It is little hard to tell the second value in parentheses is hex.