Posted by tsujamin 3 days ago
Signal strength is like the loudness of music being heard. It's possible for music to be quiet but otherwise excellent, or loud but low-quality. However, if it is too quiet, then the "music" becomes almost unintelligible, which the offseted bars should still be able to indicate.
In Wi-Fi, 6GHz and 5GHz are often used instead of 2.4GHz. 2.4GHz would likely win in signal strength. Yet, the others are used anyway, because the others are good for other reasons. However, if range ( ...or compatibility) is critical, then 2.4GHz is used.
Similarly, in cellular, there is a lower frequency e.g. band 8/12/14/17/20/28/71 and a higher frequency e.g. band 1/3/7/30/38/40/41/66/77/78. (Less basically, it can be more granular.)
So this sequence of events is possible: Tower switches the phone to a higher frequency -> speed increases but the signal strength reduces (confusing, but at least doesn't seem bad if there are 3 or 4 bars.) A switch to a lower frequency normally occurs instead if the high frequency signal is weak.
Cellular can be slow due to interference (maybe more common than signal strength issues; the metric to use instead might be SNR/SINR), congestion (maybe more common than signal strength issues; the metric to use instead is confusing, maybe the CFI value (if automatically changed) or RSRQ with a high SNR/SINR might rule it out), the speed of the rest of the network (the metric to use might be RSRQ during a download with a high SNR/SINR), data plan (the metric to use instead might be RSRQ during a download with a high SNR or SINR/QCI (requires interpretation)), and the width of it (the metric to use is BW). So it's confusing, and not exactly that full bars are always better.
For 2G, with each nearby cell (coverage area) basically getting its own channels, signal strength might've been more important, though interference was there somewhat (so there was MAIO planning etc.)
But aside from speed, there's the battery to consider. If the signal strength from the tower to the phone is "satisfactory", it's implied that so is the signal from the phone to the tower, so the phone will have to have an elevated transmit power.
There is a logical and reasonable explanation. These companies are run by a bunch of sociopathic, unethical people who won't hesitate to lie and cheat if it gets them more money. It's as simple as that.
Even if the the company has enough lawyers to win in court, it is still expensive. That's why the lawyers are among the risk aversest. So reporting to a company internal lawyer might already be enough.
Not even phone calls would go through, let alone calls on Whatsapp et al, or loading websites using something heavier than just text.
Have raised a _formal_ complaint (they must report it to Ofcom), and after that it was just a matter of ensuring I lost enough phone calls to demonstrate how many ended up in my answering machine.
The fact that Wifi calling is also super buggy and almost never work, played also a big role.
My problem is, all other mobile providers in my area are even worse, showing LTE or 4G. So I just need to wait for them to strengthen signal, or move!
I'm now on O2 which works kind of normally and also have a silent link esim which is a good backup. They cost like £8, never expire and let you use any UK network you choose if one isn't working. Or almost any network globally for that matter.
And this is on non-provider phone, this is built in in the whatever communication they do with the phone, possibly works with every device.
Man, I love my HSPA+ “4G”!
Really the bigger problem is that there's not enough distinction between SA and NSA
It's handy for locating sweet spots and dead zones in my home.
Is the commit that added it.
I’ve been in bad tower areas where the solution is to drive to the next town or tower along the highway.
Here kitty kitty ...
Until about March this year, it was excellent and I used it as my home broadband. 60MB/s down, 20MB/s up on a good day. Much better than any ADSL I'm able to get.
Since March, from about 10:30am until 5pm some days, and late evening other days, there is no working data, and occasionally no working voice, despite the 5 bars.
It's working fine until then, and then it just stops completely, fading over the course of maybe 10 minutes. This happens all 7 days of the week.
The working theory is congestion at the base station. That's consistent with the occasional 6 minute ping times that I've measured, and more usual 20-30 second ping times, when anything gets through at all.
Still shows 5 bars. Three's coverage map says it's good here. Just can't use it.
$ git log --oneline -SKEY_INFLATE_SIGNAL_STRENGTH_BOOL | tail
gets us the commit [0] from 2020 where config_inflateSignalStrength was renamed to KEY_INFLATE_SIGNAL_STRENGTH_BOOL $ git log --oneline -Sconfig_inflateSignalStrength | tail
gets us this commit [1] from 2017 where it was originally added: 43c14d198479 Add config to artificially inflate number of bars
[0]: https://android.googlesource.com/platform//frameworks/base/+...[1]: https://android.googlesource.com/platform//frameworks/base/+...
private int getNumLevels() {
if (mConfig.inflateSignalStrengths) {
return SignalStrength.NUM_SIGNAL_STRENGTH_BINS + 1;
}
return SignalStrength.NUM_SIGNAL_STRENGTH_BINS;
}
...
} else if (mCurrentState.connected) {
int level = mCurrentState.level;
if (mConfig.inflateSignalStrengths) {
level++;
}
return SignalDrawable.getState(level, getNumLevels(),
mCurrentState.inetCondition == 0);
If the flag is true, bump up BOTH the reported level as well as the total number of bins.If the flag is false, use reported level and default number of bins.
Since both numerator and denominator are bumped up, is it really malicious?
Based on this commit at least, personally, I feel such logic could be due to a decision to shift from levels starting from 0 to levels starting from 1 at the UI level.
Or perhaps to make levels consistent between different operators, some of whom were using 0-based while others used 1-based.
I haven't gone through later commits or latest versions. So my opinion's limited just to this original 2017 change.
2 bins out of 4 suggests 25%-50%
3 bins out of 5 suggests 40%-60%
Hm - what is the word 'INFLATE' doing there?
I would like to believe your opinion but that word INFLATE makes it hard ...
If it is a UI correction, then surely it would have had a different name: ENSURE_SIGNAL_IS_ONE_BASED ... ;)
(but I still would love to know how does one hide from git blame)
(file renaming?)