Jump to content

SignalCheck Beta Crew Forum


mikejeep

Recommended Posts

2 hours ago, Trip said:

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.

Sorry, I misread your message -- yes, the app would show 0 if an invalid value was being reported. I don't think I had any MediaTek devices myself, but the beta testers have had a decent variety of devices over the years.

 

2 hours ago, Trip said:

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.

Sorry, I didn't word that very well in my last post -- I added an option to control display of LTE TA when it is 0. By default it will now be hidden (sadly a lot of devices do not show it) but anyone who wants to display it can adjust accordingly. There will be 3 user-selectable options related to LTE TA now -- the existing correction option, correction on LTE-TDD (which is independent/in addition to the existing correction option), and TA:0 display. In your case, I'd disable the TDD option and enable the TA:0 option; the defaults will be the opposite of what I think you need.

 

2 hours ago, Trip said:

I'll look forward to your impending update, and I'm going to send along another donation if I can find the link.

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.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

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

  • Like 3
  • Love 1
Link to comment
Share on other sites

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

Edited by Trip
Link to comment
Share on other sites

3 hours ago, Trip said:

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.

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.

 

3 hours ago, Trip said:

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!

Haha me and you both wish this!!!

  • Like 1
Link to comment
Share on other sites

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

Edited by Trip
Link to comment
Share on other sites

1 hour ago, Trip said:

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

 

1 hour ago, Trip said:

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.

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

  • Thanks 1
Link to comment
Share on other sites

17 hours ago, Trip said:

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

To what firmware version did you lock your s21FE?

Link to comment
Share on other sites

On 9/26/2023 at 10:37 AM, Trip said:

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.

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.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

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

  • Like 2
Link to comment
Share on other sites

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

  • Thanks 1
Link to comment
Share on other sites

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

  • Like 2
Link to comment
Share on other sites

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

  • Thanks 1
Link to comment
Share on other sites

On 10/8/2023 at 6:48 PM, Trip said:

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.)

Sorry for the delay in replying.. I'm always willing to consider new things when someone would find them useful! So I don't lose track of this, could you please open up a request on the issue tracker here with these details?

 

1 hour ago, Trip said:

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.

Nice job!! I wish every provider had a method to their madness like that, it would be so much more convenient.. could you add a separate request on issue tracker for this too? These threads are so big I sometimes lose track of where things were mentioned.. and I have a terrible memory..

 

On 9/26/2023 at 8:13 AM, Trip said:

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.

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

  • Like 1
Link to comment
Share on other sites

4 minutes ago, mikejeep said:

Sorry for the delay in replying.. I'm always willing to consider new things when someone would find them useful! So I don't lose track of this, could you please open up a request on the issue tracker here with these details?

 

Nice job!! I wish every provider had a method to their madness like that, it would be so much more convenient.. could you add a separate request on issue tracker for this too? These threads are so big I sometimes lose track of where things were mentioned.. and I have a terrible memory..

 

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

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

Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

On 10/16/2023 at 7:22 PM, Trip said:

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!

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

Hopefully this is more of a call to arms for those in Oregon and Iowa to look for this pattern or variation of it.

Link to comment
Share on other sites

Not sure if this has already been discussed, but I have a Pixel 8 and it seems band info is slow to refresh. On my commute, the time, date and GPS will refresh every 4 seconds. Band info below it takes between 1 and 10 minutes to refresh and just seems to be stuck even though I've traveled miles and passed multiple towers. I owned a Pixel 7 previously that had the same issue, and my S22 seems fine.

When I'm stationary, the issue does not seem to exist. 

Edited by jasonsteele
New observation
  • Confused 1
Link to comment
Share on other sites

  • 2 weeks later...
On 10/27/2023 at 12:13 PM, jasonsteele said:

Not sure if this has already been discussed, but I have a Pixel 8 and it seems band info is slow to refresh. On my commute, the time, date and GPS will refresh every 4 seconds. Band info below it takes between 1 and 10 minutes to refresh and just seems to be stuck even though I've traveled miles and passed multiple towers. I owned a Pixel 7 previously that had the same issue, and my S22 seems fine.

When I'm stationary, the issue does not seem to exist. 

Hmm.. my primary daily device is a Pixel 8 (and was a Pixel 7 for the year prior) and I have not seen this. Do you have any sort of memory optimization app running? Do you have timestamps enabled for the individual network types (not at the very top of the screen, but within each "block" of signal information) and are they updating at all?

Link to comment
Share on other sites

On 10/26/2023 at 1:56 PM, Trip said:

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

Thank you for the detailed info on this! A fresh beta update is rolling out now that temporarily changes how site notes are saved on Dish Wireless 5G-NR connections. Dish site notes will now only be updated on the specific NCI you are connected to, so other sectors at the same site will need to be saved independently -- but at least that stops further bad data collecting in your logs. I will work on restoring normal site note functionality using the formula you shared, just going to take some time.

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

3 hours ago, mikejeep said:

Hmm.. my primary daily device is a Pixel 8 (and was a Pixel 7 for the year prior) and I have not seen this. Do you have any sort of memory optimization app running? Do you have timestamps enabled for the individual network types (not at the very top of the screen, but within each "block" of signal information) and are they updating at all?

Timestamps for individual network types are frozen for anywhere from five to fifteen minutes, timestamps at top refresh every four seconds when I'm moving and every ten seconds when I'm stationary. I have no memory optimization used. I went through and changed a few settings: battery usage to "unrestricted", toggled modify system settings to "allowed", toggled unrestricted data usage to "on". I also just turned off adaptive connectivity. All permissions are allowed. Will test on my next drive.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • large.unreadcontent.png.6ef00db54e758d06

  • gallery_1_23_9202.png

  • Similar Content

  • Posts

    • I've now seen how things work in Kobe, Hiroshima, and Osaka, as well as some areas south of Osaka (e.g. Wakayama, Kinokawa), and tried three more SIMs. The two physical SIMs (different branding for each) both use IIJ, which provides a Japanese IP address/routing on NTT, aleit LTE-only, so latency is ~45ms to Tokyo. The catch with NTT is that it uses two frequency bands (B42/3500 MHz LTE, n79/4900 MHz NR) that you're not going to get on an Android sold in the US, and I'm guessing that B42 would be helpful speed-wise on that network, as it doesn't have B41. I also found one place that doesn't have cell service: a vending machine in the back of the Osaka Castle tower. Or, rather, the B8/18/19 signal is weak enough there to be unusable. Going back to 5G for a moment, I saw a fair amount of Softbank n257 in Hiroshima, as well as in some train stations between Osaka and Kobe. 4x100 MHz bandwidth, anchored by B1/3/8, with speeds sometimes exceeding 400 Mbps on the US Mobile roaming eSIM. Not quite the speeds I've seen on mmW in the States, but I've probably been on mmW for more time over the past few days than I have in the US over the past year, so I'll take it. My fastest speed test was actually on SoftBank n77 though, with 100 MHz of that plus 10x10 B8 hitting ~700 Mbps down and ~80 Mbps up with ~100ms latency...on the roaming eSIM...on the 4th floor of the hotel near Shin-Kobe station. Guessing B8 was a DAS or small cell based on signal levels, and the n77 might have been (or was just a less-used sector of the site serving the train station). I'm now 99% sure that all three providers are running DSS on band 28, and I've seen 10x10 on similar frequencies from both NTT and SoftBank IIRC, on both LTE and 5G. I also picked up one more eSIM: my1010, which is different from 1010/csl used by US Mobile's eSIM unfortunately, as it's LTE-only. On the bright side, it's cheap (10GB/7 days is like $11, and 20GB for the same period would be around $15), and can use both KDDI and SoftBank LTE. It also egresses from Taiwan (Chunghwa Telecom), though latency isn't really any better than the Singapore based eSIMs. Tomorrow will include the most rural part of our journey, so we'll see how networks hold up there, and from tomorrow night on we'll be in Tokyo, so any further reports after that will be Tokyo-centric.
    • I think the push for them is adding US Mobile as a MVNO with a priority data plan.  Ultimately, making people more aware of priority would allow them (and other carriers) to differentiate themselves from MVNOs like Consumer Cellular that advertise the same coverage. n77 has dramatically reduced the need for priority service at Verizon where the mere functioning of your phone was in jeopardy a couple of years ago if you had a low priority plan like Red Pocket. Only have heard of problems with T-Mobile in parts of Los Angeles. AT&T fell in between. All had issues at large concerts and festivals, or sporting events if your carrier has no on-site rights. Edit: Dishes native 5g network has different issues: not enough sites, limited bandwidth. Higher priority would help a few. Truth is they can push phones to AT&T or T-Mobile.
    • Tracfone AT&T sims went from QCI 8 to 9 as well a couple years ago. I'm pretty neutral towards AT&T's turbo feature here, the only bad taste left was for those who had unadvertised QCI 7 a couple months ago moved down to 8. In my eyes it would have been a lot better for AT&T to include turbo in those Premium/Elite plans for free to keep them at QCI 7, while also introducing this turbo add on option for any other plans or devices. As it stands now only a handful of plans can add it, and only if you're using a device on a random list of devices AT&T considers to be 5G smartphones.
    • My Red Pocket AT&T GSMA account was dropped to QCI 9 about a year ago.  Most recently 8 for the last few years prior.  Voice remains at 5.
  • Recently Browsing

    • No registered users viewing this page.
×
×
  • Create New...