Trip

Wasn't sure where to post this.  This thread seems as good as any.

Went out and about last night and spotted this:

http://imgur.com/Y1FdQb4

Do you see it?  If not, here's a zoomed picture.

http://imgur.com/vqbms0A

That's a Verizon small cell.  I knew it was there because of the -50 dBm AWS signal on my Verizon phone, but it took me a while to find it.  When I got home, I found the building permit for it; it was apparently filed 12/15/16, issued 3/1/17, and passed inspection on 6/5/17.  ( https://apps.alexandriava.gov/permittracker/CaseDetails.aspx?casenum=BLD2016-02856 ) 

I wish Sprint could move so fast...

- Trip

I don't get the anti-trust argument against cable companies merging. They dont compete directly. Cable companies are local monopolies who compete with sat. And telephone companies to deliver content.

 

Sent from my LG-LS993 using Tapatalk

Verizon and AT&T compete directly with the local cable company in many cases.  In my area, I have Verizon FiOS, and Cox is also available (but significantly more expensive for whatever reason).

- Trip

I would like to make the diagnostics more robust, right now it just crudely tries to send it once and bails if it doesn't work. I was mostly concerned with better handling of short-term network interruptions, and hadn't considered that some devices might only be able to send data on Wi-Fi. Definitely something I could improve.

 

-Mike

Three of my phone have SIMs and connect to the network, but have no service associated (two T-Mo, one Verizon).  So it's definitely something I've encountered.

- Trip

For a future build, it would be worth making it possible to dump the disgnostics into a file for later submission.  I have several phones with no service that I am basically unable to send diagnostics as a result.  By the time I'm home on Wifi on those devices, it's too late and I've lost whatever I wanted to show you.

- Trip

Now that Android 7 includes EARFCN data in the API, what's the cheapest phone to get the most information out of each network? I'd like to get one phone each for Verizon, AT&T, T-Mobile and US Cellular and then get the cheapest SIM card I can for them.

I haven't updated this thread in quite a while.  Here's what I'm using now.  All rooted devices have Network Signal Guru for band locking and, with the exception of the AT&T phone which is now on Android 7 and uses the API method, for EARFCN retrieval in SignalCheck Pro.

Verizon - I have a rooted Moto G4 Play, which is expecting an update to Android 7 any day now.  Every 90 days, I swap out the SIM, and though it has no service, it does connect to LTE and provide information on the network.

AT&T - I have a rooted HTC One M9, which is running Android 7.  I recently replaced H2O Wireless with the new FreedomPop LTE-only SIM, which has a free 200MB monthly.  The LTE seems more reliable on FreedomPop too.  I replaced my Nexus 5 with the M9 since my sister on Project Fi needed a loaner phone when her 5X started to boot loop and I wanted a replacement phone with Band 30.  (I've now gotten the Nexus 5 back, but it doesn't support the root method of EARFCN retrieval, it won't get an Android 7 update, and I don't know what to do with it.)

US Cellular - I have a rooted Moto G4 Play, which is expecting an update to Android 7 any day now.  I can put 30 days of service on it for $10, and it won't connect to LTE without service (US Cellular appears to be SRLTE only, so without service, it only connects to 1X). 

T-Mobile - I have a rooted Moto G3, which will not be updated to Android 7 from what I understand.  The T-Mobile SIM has no service on it, but connects to LTE anyway.  The phone does not support Band 12.

T-Mobile - I have a non-rooted BLU R1 HD, which will not be updated to Android 7 from what I understand.  It has a MetroPCS SIM in it, but connects to LTE anyway.  It has a utility on it which allows band locking, but no ability to get EARFCN, so the phone is perpetually locked on Band 12 only.  No need for EARFCN when you always know what it's going to be!

I suspect there are now cheaper phones that would work, but I'm happy with what I have for the moment--for the most part.  I'm keeping an eye open for something that's Band 66 capable with the idea of using it to replace either my Verizon or US Cellular phone (and using the G4 Play it replaces with T-Mobile and using the G3 for something else), but I haven't seen anything inexpensive in that category yet.

- Trip

I think I might have accidentally figured this out. Simple math:

 

NSG EARFCN (66486) - SCP EARFCN (950) = 65536

 

65536 is 2¹⁶, aka the max 16-bit integer. The API specifies it is a 18-bit integer, but I'm guessing something buried inside the OS got messed up along the way.

 

Not sure if it's an HTC glitch or an Android glitch, but I found a similar report discussing issues with EARFCNs above 47000, so I added to it. If anyone wants to 'star' this on the Android Issue Tracker, it might help get the Android developer team's attention.

 

-Mike

I suspect you're right.  AT&T PCS in this area has an EARFCN of 850, not 950. 

I starred it as well.  That's... really unhelpful if true. 

- Trip

B66 superset with Mfbi B4 for non B66 capable devices?

 

Sent from my Pixel using Tapatalk

That would explain the output of NSG, but not what's going on in SCP.

hey Trip. I locked my phone to band 66. Look at this screenshot. Same pci

Interesting.  What does SCP show?

And, of course, send a diagnostic to Mike, if you haven't already.

- Trip

Not sure if this is intentional or not but band 66 is showing up as band 4.

Those two pictures appear to be different cells.  What's really weird is that the EARFCN being shown in the picture on the right is PCS, but the GCI sector ID matches AWS.  And in the picture on the left, the frequency shown is within the AWS-1 band.

- Trip

 

1) The app tries two different methods to get GSM-based neighbor cells.. one returns a PLMN+LAC+CID, and the other returns only a PSC. PSC is not logged or labeled because no PLMN is returned with that method, so there's no way to narrow it down enough.

I don't understand why that means the PSC isn't logged for the connected cell though.  Seems like useful information.  And I actually have the PLMN matching turned off on the LTE side anyway.

- Trip

I ended up getting home much later than I expected, but I was still hoping to crank them all out tonight. Unfortunately, the site I used to make all of the icons is apparently gone (yeldnats.com/fonticons) and I have not been able to find any other similar resources. Band-aid it is.. I promised an update today, so the people will get an update today!

 

If anyone is good with graphics or knows of a similar tool, please let me know..

 

-Mike

Mike,

Two things.

1) In the other thread, you mentioned neighbor cells for the GSM-based technologies.  I want to point out that those appear to use PSC, a value that is not currently logged, to identify the neighbor cells.  Since the value is not logged, there are never any labels attached to neighbor cells in that mode.

2) With respect to this, you may want to look into ImageMagick.  It's open-souce software that can be used to write images from a command line.  Theoretically, you could script the creation of images, thus automating the process for yourself.  I'm afraid I don't use it enough to be a resource on how to use it.

- Trip

Oh no.. I just realized what is going on here. I need to make icons for every possible LTE band/frequency, not just the ones the app has identified to this point.. this is not going to be fun!

 

-Mike

 

**Mods can you please move these two posts to the Beta thread?

Done.

Could you just point all unknown bands to the generic "LTE" icons that used to be used for that sort of thing?  It's a band-aid, I know, but it would save you some work right now.

- Trip

Now that I can see neighbor EARFCNs on the fly, I noticed that I never see a PCI or EARFCN for a neighbor cell unless it's on the same channel as my current connection. That explains all of the "Unknown" cells that only report signal strength. Anyone on other devices seeing better results? Curious if it's an Android OS bug or a Pixel radio bug.

 

-Mike

My LG G5 does the same thing.  I think it started with the upgrade to Android 7; I recall older versions showing me other bands, which was easy to spot on my Sprint phone because the B41 PCI is different from the B25/B26 PCI on a given sector.

- Trip

Hmmm I will have to check, but I bet it checks for PCI >0, not >=0; I'll double check that and adjust accordingly, thanks! I will make a note to add an option to hide 1X on the main screen, but that might not be until the next release cycle.

 

-Mike

I actually thought it was intentional, for devices that didn't report PCI.  But I'd prefer it show 0 PCIs since most current devices do report the PCI.

- Trip

Nothing against this site's name, but wouldn't it be conflicting after a merger if the new company is called T-Mobile?

Any more than "CTIA - The Wireless Association" or "NTCA - The Rural Broadband Association"?

- Trip

I'm curious what the new name of the site would be if T-Mobile took over Sprint.

My guess?  S4GRU.

- Trip

 

I just checked out your report, thanks. If you could share the math that correlates the LTE and GSM data (I didn't look at it too closely), I can look into it.

 

I will think about the best way to approach your single band idea. I decided to have the app only use educated guesses on T-Mobile in Nokia markets, because the Ericsson sites have proven to be wildly inconsistent. Hopefully as Android 7 becomes adapted more widely, it becomes a moot point.

 

-Mike

Mike,

I'm currently connected to 00DFE217 (weird that it's following the Nokia pattern; it's a new site I've yet to track down), with a TAC of 20234.  The GSM data has 20234 as the LAC and the CID is 57879, which is 0xE217, matching the last four digits of the LTE GCI. 

The LTE ASU is always 99 on this phone, but on GSM it changes, so I'm not sure if the ASU is being reported correctly for the GSM entry and not for LTE.  I'm suspicious of some of the other numbers as well.

My big problem is that it logs this faulty data to the GSM log, which then requires periodic cleaning. 

I agree that it will hopefully become a moot point, I'd just prefer not to have to replace my devices any sooner than necessary.  Despite the promise of Android 7 when I bought it, it no longer looks like the R1 HD will get it, but it's otherwise still a very useful device because I can lock it to a band without root.  (It has a MediaTek chip so I can't use the root method to get EARFCN anyway.)  It's the only device I have that can't get the EARFCN at all; my G4 Play phones have the root method now and should have Android 7 soon, and my G3 has the root method.

- Trip

Mike,

I attempted to send diagnostics from my BLU R1 HD this morning; hopefully you got them.  For as long as I've had it, it's listed both GSM and LTE at the same time.  With a little bit of math, it quickly becomes obvious that the LTE data is being duplicated as GSM data for some reason.  I assume the API is providing bad data, but is there any way to work around this issue, even if it means having a software setting for it somewhere? 

Additionally, I always lock this phone to Band 12, but with the new version, it now only reports "LTE" and never "LTE 700".  How would you feel about adding a means of telling SCP that the phone only connects to a single band so all logs can be identified as that band (if EARFCN is unavailable)?

- Trip

Failing to load on my rooted LG G2s.  Sent a report from each one.

Are any other users here running rooted devices?  Your report makes me wonder if our crashes are related--the app attempting to use the root method to read the neighbor EARFCN or something before permission is granted, or something along those lines.

- Trip

Mike,

New version crashes on start-up on my Moto G3 and Moto G4 devices, all of which are rooted.  It gets as far as asking for root permissions, then crashes before I can grant them.  I used the "Report" button to send a report from one of each device.

Works on my HTC M9 and my LG G5, both of which are on Nougat.  Didn't have a chance to test my BLU R1 this morning.

- Trip

I'm going to argue the opposite; I prefer LTE 800.  It allows at-a-glance differentiation between B5 (LTE 850) and B26 (LTE 800).

Thanks for the update!  I've downloaded it now, and can't wait to try it out, probably tomorrow on my way to/from work.

- Trip

I like your fallback idea, it just might take some time to implement. I am hesitant to rely on pulling band info out of the database because if a site's configuration is changed for whatever reason, that could throw things off. SCP minimizes the number of reads and writes to the database so a little more complicated than one might expect.

Mike,

First of all, I upgraded my HTC M9 to the latest build this morning and now have EARFCN via the API on it.  Looking good!

Second, I wanted to follow up on this comment briefly.  I'm trying to prevent an unnecessary write to the database with my suggestion.  What I'm suggesting is that when you read the site note, if the EARFCN isn't available, pull the previous value until the first update occurs. 

For example, suppose we're talking about my T-Mobile phone.  I connect to 00B4A004 from another cell.  When it first connects, the EARFCN is not yet available, but the database says the EARFCN was 2300, which you read out at the same time you're reading the site note for display.  You use the 2300 value to say that the provider is "T-Mobile B4" rather than "T-Mobile B12?" which the sector method would give you for that first instance.  To the extent that keeps the "T-Mobile B4" provider already in the database in place, that saves a write.  Then, on the next refresh, the root method should have returned the EARFCN by then.  It returns 2300, thus everything is the same, saving you a second write.  If it's now different, replace it and write once.  It prevents an unnecessary write and rewrite while also preventing it from flipping back and forth on-screen as it switches one way when the EARFCN is absent and then back when it becomes available.  (Also, note that I'm not saying to display the database EARFCN value on-screen at any time, only that you use it for band ID purposes.)

If I'm misunderstanding something, let me know.  It also may be too much work.  In any case, it's just a suggestion.

Finally, here's a perfect example of why I'm glad the EARFCN method is coming:  http://imgur.com/WgG4g2b

- Trip

Me too. But I upgraded, and it's working for me on my Nexus 6. All screens. Including the Band selection. No extortion requests, so far. I haven't upgraded on any of my other devices, yet. It's only on N6 that I was getting the outdated message.

 

Using Tapatalk on Note 8.0

So it does.  I didn't realize they'd backed down.

- Trip

FYI, for people like me who had stuck with version 1.2.3 of Network Signal Guru, I'm now getting a message that it's outdated and requires an update.  Looks like the end of the line.

- Trip

Mike,

Thinking about this Samsung thing, perhaps you could assume that any Band 1 EARFCN with an MCC beginning with 3 is invalid.  Won't help outside of North America, but I don't know how much of your audience is international.

- Trip

Some USC download EARFCNs:

2425, 2585 - Band 5 (850)

5090 - Band 12 (700)

I think DL EARFCN corresponds directly to band across a range of values, so it's a matter of simply checking where in the range the EARFCN falls and mapping that to a band number.  (For example, Band 1 is 0-599, then Band 2 is 600-1199, etc.)  It shouldn't need individual EARFCN values mapped to numbers like that.

Where it gets trickier is using it to try to identify bandwidths.  For that we'll probably need to work out manual mappings.

- Trip