Trip

I found this link this morning: 

- Trip

2 hours ago, Paynefanbro said:

I can't speak to the quality of Dish's network because I haven't tested it for myself but here in NYC they have a relatively mature buildout. I've seen their sites in every borough and it seems like they didn't cheap out and only collocate on sites that other carriers are already on, they are increasingly doing new builds in areas where even the Big 3 have weaker service.

Glad to hear they're doing it somewhere.  Because it's not in the DC area.  Very, very cheap build-out from what I can tell.  Around here it looks like they went with whatever dedicated antenna structures (monopoles, lattice towers, etc.) they could find that were covered by their master agreements with American/SBA/Crown Castle, and then filled in with a handful of building mounts where no such structures were available.  Service is very uneven.

- Trip

13 hours ago, red_dog007 said:

Faster they can pass out rainbow sims, faster they can at least start saving money.

The problem is that as of right now, they can't hand them out because the network isn't ready.  I've done a bunch of driving around over the past week and a half, since I got my Rainbow SIM, and it's kind of impressive how sparse it is.  In the city of Alexandria, I'm aware of 9 permitted sites.  Of those, only 5 are actually operating today.  The site that would be my home site only got antennas put up last week, even though the permits have been around for about a year.  Meanwhile, T-Mobile has 37 sites, by my count.  While some of those are obviously for capacity, there are plenty of places where the coverage itself is an issue, independent of capacity.  

It's not ready for showtime yet.  I'm not sure it would be ready even if all 9 were operating. 

(And in Fairfax County, one site I went by specifically to check on Saturday that's had Dish antennas for months is not yet operating.  Don't know what's going on there.)

- Trip

1 hour ago, schmidtj said:

Can’t say I’ve ever heard of any of these cities.

T-Mobile - T-Mobile Expands 5G Network Coverage in Utah, Delivering Supercharged Speeds Across the State

The list is counties, not cities.

- Trip

Got Dish Wireless activated, and it looks like SCP does not handle site notes properly with Dish Wireless.  Bug submitted in the tracker:

https://github.com/bluelinepc/signalcheck/issues/48

- Trip

On 10/23/2023 at 3:44 PM, Trip said:

Utter.  Fiasco.

So, I made it to the store today.

As expected, they were unable to do it on a plan lower than the $40/mo plan, despite my best efforts.  He even went so far as to show me on the system that it wouldn't allow him (not at my insistence, but he was going to put me on a non-Dish SIM and I was insistent).  Oh, and since in-store activation has a $35 fee, they basically won't let you connect to Dish without paying the activation fee since you can't do it online.  But, the guy was very nice, and I now have an activated phone on Dish Wireless. 

https://imgur.com/a/j3BPgrx

Now to file another bug report on SCP since it doesn't handle Dish Wireless sectors properly.  (I'm not connected to Edison HS.)

- Trip

Mike,

I've added another enhancement request based on my experience with the Rainbow SIM over the past 24 hours.

https://github.com/bluelinepc/signalcheck/issues/47

- Trip

Utter.  Fiasco.

So I now have another new Moto G 2023 which did successfully bootloader unlock and is now rooted.  I wanted to activate a SIM on the $100/year plan if at all possible, and it's online-only, so I decided to call up my nearest Boost store and see if they had the Rainbow SIM.  I tried twice; both times it went to Cox voicemail after 5 rings, and asked me to input my number, as if I was logging in to retrieve messages.  Weird.  So then I tried the next nearest store, and that one it would hang up as soon as the call connected.  Tried several times.  Finally, third store was the charm, that one I got an answer right away, and they had the Rainbow SIM.  Ran over to the store and picked up two of them, $10/ea.

Got home, tried to activate online.  Nope, ICCID is given as invalid.  Tried to talk with chat, and chat told me I had to call.  Called, and the call dropped the first time.  Called back, spent a whole hour on the phone with the second guy, and after a lot of talking back and forth, picking the $168/year plan, we got to the part where I needed to give my credit card, and three different cards were rejected.  He said it was probably a system issue, and that I should go into a store.  Guy was very nice and helpful, but he ultimately couldn't get me started.

So I'm sitting here and after all of that, I have nothing to show for it.  Not really an auspicious start.

- Trip

36 minutes ago, mikejeep said:

I sent you an e-mail a few weeks ago about this.. did you get it?

Mike,

I'll create issues in the tracker.  I have terrible memory as well, so I definitely get it.

Regarding your e-mail, I just dug it out of my junk.  D'oh!  I'll answer there.

Thanks, as always!

31 minutes ago, dkyeager said:

My only concern is maybe the US Cellular pattern is regional like Sprint.

Possible, of course.  I've only checked sites in Virginia, West Virginia, and Maryland as those are the only places I've been lately where US Cellular can be found.

- Trip

Mike,

Sorry to be chewing up your whole thread here, but I did some prodding at US Cellular and I think I've found a pattern.  It's using three bytes for sector ID, like T-Mobile, but there also appears to be a pattern lining up the NR NCI with the LTE GCI on the same tower.  I've checked four sites in random locations and they all seem to agree, so if this is not an accurate pattern, then it's one heck of a coincidence.

As an example, I was looking at the Open Cell ID data and found 0x9C41BDxxx, which appeared to be the Falling Water site on the south side of Appomattox.  Converted to decimal, that's 10240445.

Now that site has two LTE GCIs, 0x7C90E and 0x7D0DE, or in decimal, 510222 and 512222.

It looks like the way it works is that to convert LTE to NR, you double the first two digits, which are the FIPS state code (so 51 --> 102), then stick a 4 in, and then double the last three digits, being sure add leading 0s to make it 4 digits, and then add 1.  That gets you 10240445.

Same story for Evans Hill in West Virginia.  0x83DC9xx --> 540105.  54 --> 108, stick a 4 in, 0105 --> 0210, add 1, NR is 10840211 (0xA56893).  Which is what I observed.

- Trip

T-Mobile had far better site density than the other carriers even before the Sprint conversions.  Otherwise, this aligns with my perception.

- Trip

5 hours ago, schmidtj said:

T-Mobile’s 5G Network Now Covers 97% of Virginia

Interesting.  While they talk about all of Virginia (which their coverage of which still has pretty significant holes), I'm betting the talk of "new towers" is largely talking about conversions in the Shentel region.  In Buckingham County (my favorite example case) they went from 2 sites to 17 sites by converting the existing Shentel sites.  I can easily see how they got to 900 new sites if you start counting all of those.

Still plenty of work left to do.  No sites in Lunenburg County, for example.  No service in Chase City.  The Shentel site at Gordonsville had to be turned off and the replacement isn't scheduled to go live until next year.  Plenty of gaps along highways in places where Shentel stopped building new sites mid-stream pending the merger.

- Trip

51 minutes ago, floorguy said:

This is actually a REALLY good point.  I don't think enough people have thought about it this way.

I got 10 days to decide....I need to call (I wish the store knew better for biz lines how things work)  And play with the numbers for which way to go.

I have. 

I have a $160/mo bill, due on the 10th of the month.  What I did was I opened a T-Mobile Money account, stuck $180 in it to have a $20 cushion.  Set up auto-pay from that account.  After the first payment was taken from it, I set up a recurring transfer with my credit union for each month on the 5th for $160.  So in theory, the T-Mobile Money account just receives the money--my actual checking account info is not set up within the T-Mobile Money account--and then almost immediately has the money taken back out to pay the T-Mobile bill.

Not the most elegant system, but it works for me thus far, and should theoretically keep my actual account information safe.  I shouldn't be able to lose more than $180 if a T-Mobile breach causes me a loss, and for most of any given month, it shouldn't be more than $20.

- Trip

Mike,

I sent you a diagnostic immediately following an SCP crash on my Verizon phone yesterday.  Not sure if you got it or if it contains anything of particular interest.  I was just rolling down the highway (US-17 maybe?) and it exited.

Separately, I have a feature request that may or may not be worth the effort.  On my Verizon phone, I've recently been noticing Verizon B48 LTE in the neighbor cells.  If I lock the phone to B48, it won't connect, so I'm guessing it's being used as supplemental downlink or something, but that also means the only way to identify sites with B48 is to screenshot SCP showing B48 in the neighbor cells and then review the screenshots later.  Since Verizon uses consistent PCIs across bands, I can do that with a high degree of certainty.  The same is true for identifying 5G-NR NSA.

Would you consider adding a separate trail logger table and an optional function to record info on neighbor cells in LTE?  Record the lat/lon, timestamp, PCI, EARFCN/band, and signal level?  And maybe also the GCI/PCI it's connected to when the neighbor cell is being recorded?  (Recording the GCI it's been matched up to in showing the site note could be useful too, I suppose, but probably less so.)  Could this also be used to record 5G-NR NSA data when connected to LTE, since it's more like a neighbor cell than anything else?  Particularly on Verizon, I could see this being useful to identify what's going on with bands that can't be directly observed or bands that are less frequently connected to.  (AWS-3 regularly appears in neighbor cells but doesn't often connect directly, for example.)

While theoretically also useful for NR, in practice it appears that only MediaTek phones support NR neighbor cells at this time, and since only T-Mobile has NR SA on a widespread basis and the PCIs are inconsistent across bands, this isn't something that would be useful to me specifically except in corner cases.  Maybe it would be more so when Dish becomes more widely available if their PCIs are consistent.  Regarding T-Mobile, in areas where n41 SA is not running, with my Edge 2022 I can see n41 neighbor cells, but as they're just PCIs without any indicator of what the NCI is, that's really not terribly helpful.

Supposedly, Cell Mapper can record neighbor cells in this way, but I've yet to figure out how to get a CSV file out of Cell Mapper.  I've tried steps I've found online without success, and gave up pretty quickly because Cell Mapper just isn't that friendly.

If it's too much work, then no worries.  I know this would probably be a VERY niche feature.  But can't hurt to ask!

- Trip

On 9/29/2023 at 6:27 PM, mikejeep said:

I changed the behavior for the next app update, which is going to roll out shortly.. it will revert to displaying the -44 cells, but now it will skip logging them.

Okay, so I eyeballed it today, and it appears that even when the signal levels are invalid, the Timing Advance, GCI, PCI, and TAC values all appear correct.  So that information is valid, even though the RSRP/RSRQ are not.

- Trip

11 hours ago, mikejeep said:

I changed the behavior for the next app update, which is going to roll out shortly.. it will revert to displaying the -44 cells, but now it will skip logging them.

Thanks.  I'll eyeball it at the next opportunity, which should be this coming week (the FCC found some money to stay open a while after a shutdown starts) and I will see if the data looks valid or not.  If it doesn't, then I'd definitely say that the prior behavior was more correct.  If it does, then a judgment can be made on how to handle going forward.

I got my Moto G 5G 2023 and like it so far.  To my moderate surprise, it too has a built-in band locking screen, which I had thought could have been limited to the MediaTek chipsets.  The problem is that, like the Edge 2022, it requires disabling/enabling one band at a time as best I can tell.  (Going to experiment with that at some point.)  It requires the various adjustments to the TA value to get accurate reporting, so clearly the MediaTek chipset is the difference between TA values that require tweaks and don't require tweaks.

Separately, I tested it yesterday locked first to B71 LTE and then B12 LTE and had no issues with it resetting like the Edge 2022 did, though it will need more testing to verify that all is well on that front.  I've been unable to get the bootloader unlocked so far, but can actually survive without it, though obviously if it proves unable to be unlocked then I won't standardize on it because I prefer phones where I can do the root-required in-app Airplane Mode toggle and I prefer using third-party apps to enable and disable bands rather than doing it one at a time through the built-in one that requires the dialer on each use.  And, of course, there's still no telling what an Android 14 update would look like with respect to NR TA and the built-in band locking menu.

- Trip

2 hours ago, dkyeager said:

To what firmware version did you lock your s21FE?

I've locked all my Samsung devices to the last firmware before access to the Band Selection tool was cut off.

- Trip

Oh, by the way, I have a Moto G 5G (2023) on its way to me.  USPS tracking says it's coming by 9/28.  That one has a Qualcomm chip in it, so we'll see how that one is.

EDIT:  If interested, I put together a little page about the phones currently in use in my phone collection.  https://www.rabbitears.info/kb/phones

- Trip

4 minutes ago, mikejeep said:

I know you have to monitor it a bit to be sure, but based on your understanding of the glitch right now, what do you think would be the best solution? Even if it's just temporary.. or is leaving it as-is best for now so it's clear when you need to check the diagnostic screen? Can you split-screen it with SCP?

For right now, I think the best bet would be to revert it.  The suddenly-full signal bar draws the eye.  I'll assume that phone's data to be a loss if it's in LTE mode and not use it, but I generally use it as my n41 phone when out and about, so that's not a huge deal.  I'm not planning to go too far out of the area again for a few weeks.

4 minutes ago, mikejeep said:

Don't think I was aware of this one, unless I missed a message somewhere. Let me know what I can do to improve things for you! I haven't had much NR sector feedback lately.

The SignalCheck map is correct, so RAvirani, at least, is aware of it.  I only figured it out this morning, having spotted the pattern while looking at my otherwise-unlabeled AT&T NR rows.  (I've now labeled them all.)

https://imgur.com/a/xRxfIDW

- Trip

19 hours ago, mikejeep said:

I configured -44/-3 scenarios on an Edge 2022 to be an invalid connection, so yes, it would show no service.. I didn't realize it was a frequent issue though. How certain are you about the other values? Perhaps they are just unchanged from the previous array of signal information that was reported? If that is the case, I can try to have the app discard -44/-3 datapoints and leave the screen unchanged. I worry about the slippery slope of having it display as -140, because that leads users to believe there is a -140 signal present, when in reality we don't know what the actual reading is.

Fair.  I mean, most of my other phones show garbage data between sites, just not in this exact way.  Usually, the TAC is missing so I know it's invalid and I have SCP set to not log when the TAC is missing. 

I'll have to try to study the diagnostic screen when it's doing that.  Not 100% sure when that will be.  Can't really do that while barreling down the highway, and if the government shuts down next week, I won't be on the train again until it's reopened...

EDIT:  Separately, you may already know, but I've seen some invalid AT&T n2 entries on my T-Mobile phone.  Did some poking this morning and it looks like AT&T is using the final 10 bits for the sector ID.  Definitely a headache on the "picking through the database manually" side of things, but if you didn't already know, would allow you to set all associated rows when editing in the app.

- Trip

Following up, I've gone into the office in person today and took my Edge with me. It looks like it now shows "No service" instead of the -44/-3 value.  I saw a lot of "no service" because it apparently does it a lot.  I'll check again on the train ride home later.

Assuming I'm correct, is it possible to have some kind of middle ground on this?  I think it was showing other legitimate values, like the TA, even when it was showing -44/-3.  I'd prefer it show the data it has but at -140 dBm in those cases.  I recognize this could be a pain to implement, and if it is, then no worries, mostly curious.

EDIT:  But now I'm sitting here thinking "what if the PCI is bad and I don't know it?"  But that can just as easily be the case on other phones that aren't caught.  I do regularly see bad PCI entries on my other devices, so maybe this isn't the best option.  Bleh, I wish this stuff just worked properly!

- Trip

6 minutes ago, mikejeep said:

You did not have to do that, but I sincerely appreciate it, thank you! Beta update is rolling out now, let me know how it goes.

Just installed the update, and it's good!  As you recommended, I turned off both TA adjustments, and turned on displaying it when it's zero.  The value is basically spot-on.  It's bouncing between 18 and 19 for the Cameron Valley site, and it is in fact between 0.87 and 0.92 miles, as displayed in the app.  This is probably a better estimate of the TA values than any other device I own provides.

As far as the -44 goes, I'll have to take it out and verify that it no longer records those cases.

If this device didn't have that annoying reset problem, and got the Android 14 update (and in so doing supported TA on NR and continued to allow band locking), it would easily be the best device I own.  Easily.  And would be the device I standardize on for the 5G era.  I'll probably have to wait for a future device to come out with Android 14 and then see what happens.

And I know I didn't have to, but I love SCP.  It is my primary tool for tracking the goings-on of the various networks and is very easy to use and work with across my 10 phones.  I am very happy to send a token of my appreciation your way now and then.  Thanks again!

- Trip

4 minutes ago, mikejeep said:

I received the reports, thanks! You didn't catch it happening (it captures the diagnostics as soon as you hit send or long-click the connection banner on the main screen), and I had sent you an e-mail to clarify which value was -3.. but your screenshots confirmed my hunch that you meant RSRQ!

 

I know exactly what is happening here. Somewhere along the way, I learned that TD-LTE bands (33-53) needed a TA correction of -19 applied, and I confirmed it on several devices. Perhaps that is no longer universally true.. but what you're seeing SCP display matches that correction. Below 19 you see nothing, at 19 you see 0, and above that you see TA-19. The upper limit is 1282, which is why you see 1263. Your phone must report 1282 when the TA is unknown, which is not technically safe but I can work around that.

Funny enough, I had a change to TA coming in the next update that had nothing to do with your issues.. TA:0 will be hidden moving forward, since several devices report 0 when it cannot be identified.

I'll have an app update out shortly that addresses all of this, let me know how it works for you and thanks for the detailed feedback!

In order:

This is very helpful to know.  Thanks.

That makes a lot of sense, though it's showing me zero rather than nothing; it looks like if it's calculating a negative number, I'm seeing zero instead.  It makes me wonder how many devices you've tested against which use the MediaTek chipset.  This is only the second one I've used, and the first one was very, very old (didn't have B41), so it's possible that the MediaTek chip doesn't need the correction while others do.  Separately, I doubt that a real world case will ever see 1282, so I imagine any value above 1281 could be ignored.

I would ask you to please not hide TA values of 0, or if you hide them by default, add an option to not hide them.  I am aware that, for example, the S22 doesn't report a valid TA value and always reports zero, but zero is a legitimate value and is useful to know when trying to identify sites.

I'll look forward to your impending update, and I'm going to send along another donation if I can find the link.  Thanks so much, as always! 

- Trip

Mike,

We ended up going out this morning to do errands in spite of the tropical storm.  I locked the phone on LTE B41, turned off the TA correction checkbox, and watched it carefully while out and about.  I have four screenshots for you.

https://imgur.com/a/kCPTCnB

First, I happened to get a screenshot of it doing the -44 dBm thing.  I also tried to send you at least one set of diagnostics showing the -44 dBm but I don't know where precisely in the process it collects the diagnostics.  Hopefully there's something useful in them.

The rest of the screenshots are far more interesting.  All three were taken within seconds of each other in the CVS parking lot.  The phone's diagnostic screen shows a TA of 17, and oddly, the SCP diagnostics screenshot also appears to show a TA of 17.  But SCP's normal display is showing 0.  Not entirely sure what to make of that.  It looks like SCP won't show me a value other than 0 until I hit about 19 according to the phone diagnostic screen.

It also appears that when SCP is showing a TA of 1263, that's the equivalent of a null value for the TA--no TA is calculated.  The phone diagnostic screen appears to show just "12" when that's happening; the SCP diagnostic screen shows 1282 in the TA section when that happens, a difference of 19, which is highly convenient given what I noted above about the TA value.  (I can't test that the phone diagnostic screen is limited to two characters and is thus truncating 1282 to just "12" as I suspect given where I am right now.  Had I known to be looking for it, I'd have tested in the middle of nowhere yesterday.)

Anything catch your eye?  Anything I can do to help more? 

- Trip

13 minutes ago, mikejeep said:

Yuck! Obviously there's a bug with the phone itself, but I'll get on a workaround. Hopefully you can repair some of your bogus data.. that is annoying. If you haven't already, can you send a diagnostic from that phone with a reference to the bug? Doesn't have to be when it's happening, I just want to capture the device info.

 

Let me know what you find, happy to help however I can.

Done.  I'll send you another later when it's actually connected.  Bonus points if I can catch it at -44.

And regarding the TA value, I will.  Not sure I'll be able to investigate more before Monday, but as soon as I can I'll try to get you some data.

- Trip