796334 - Gaia system app: don't short-sell the signal strength when computing bars

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia, defect, P1)

Description

[GH to BZ]

[GitHub issue by geoelectric on 2012-03-28T06:47:17Z, https://github.com/mozilla-b2g/gaia/issues/1065]
This isn't properly a gaia bug. I'm reporting here so that it'll show up on @cleemoz's and @elancaster's trackers, but if not fixed/invalidated, we should move to the appropriate bug system.

I've heard two separate people comment on particularly poor reception since trying out the recent RIL fix. John, in particular, was moving his SIM between a known-good phone and a test phone and mentioned a clear performance difference in finding and holding a signal.

I have no idea if this is hardware, software, or coincidence, but we should probably take a closer look at it.

Comment 1

[GH to BZ]

[GitHub comment by tonychung on 2012-03-28T06:54:21Z]
My experience. upon first flash of the modem firmware, @fabricedesre and I put an AT&T Sim card into the Nexus S and saw it show 1 signal bar.   granted, we were able to send and receive a phone call.   But the carrier signal strength shown on the phone was at 1 bar.

Comment 2

[GH to BZ]

[GitHub comment by cleemoz on 2012-03-28T07:05:11Z]
Thanks guys. 

@cjones: worth taking a look at tomorrow to understand what impact (if any) this has on consistently making calls/SMS.

Comment 3

[GH to BZ]

[GitHub comment by jammink on 2012-03-28T08:47:57Z]
My signal strength was between 1 and 0 bars during most of the trials.  I was able to call out once on the phone.

Comment 4

[GH to BZ]

[GitHub comment by tonychung on 2012-03-28T15:23:09Z]
i wonder if this is a signal strength perception issue?   i walked over to 10 FWD, and the bar fluctuates between 0-2 bars, but mainly averages at 1.   alternately, i have my iphone next to me, and it shows 4-5 bars.     While different numbers, both of these are AT&T Sim cards.

perhaps a bug similar idea to what Apple had with their Signal Strength display issue on the original Iphone 4?

Comment 5

[GH to BZ]

[GitHub comment by philikon on 2012-03-28T16:29:47Z]
The signal strength on the Nexus S is computed according to our own algorithm (on the SGS2 the phone provides us with "bars" already.) The algorithm is almost certainly completely wrong and needs to be revised. I don't believe this is an M2.5 blocker, but please correct me if I'm wrong. (We can easily fix this in a Gecko update.)

Comment 6

[GH to BZ]

[GitHub comment by philikon on 2012-03-28T16:33:55Z]
Also, when you compare general reception ("I can't make a call from this room, but my iPhone can!"), PLEASE don't compare B2G to an iPhone or any other device. Compare the same radios, IOW a B2G Nexus S with an Android Nexus S. (They'll still show different bars for signal strength because our algorithm is probably wrong, but in terms of actual reception it should be the same.)

Comment 7

[GH to BZ]

[GitHub comment by philikon on 2012-03-28T18:58:45Z]
Also, I just found out that the UCKE baseband (used in candidate 5) and AT&T is an unfortunate combination. If I use T-Mobile, it works fine. I get what I would consider a fairly normal signal strength reading and I can make calls, SMS, etc. Not so on AT&T.

Comment 8

[GH to BZ]

[GitHub comment by cleemoz on 2012-03-28T20:10:50Z]
How's signal strength for T-Mobile SIM card?

Comment 9

[GH to BZ]

[GitHub comment by philikon on 2012-03-28T20:11:35Z]
T-Mobile signal strength actually seems ok, but this needs more investigation.

Comment 10

[GH to BZ]

[GitHub comment by vingtetun on 2012-07-14T21:40:34Z]
Does this bug affects the Otoro? Otherwise I'm going to remove it of the P1 list.

Comment 11

[GH to BZ]

[GitHub comment by philikon on 2012-07-17T00:10:31Z]
We don't do anything special for the Otoro, compared to the Nexus S. So I imagine whatever bug people are seeing, it's still there.

Comment 12

[GH to BZ]

[GitHub comment by autonome on 2012-07-19T15:31:33Z]
Needs QA confirmation on Otoro. Nominated for blocking.

Comment 13

[GH to BZ]

[GitHub comment by timdream on 2012-07-24T15:51:12Z]
Note that the current status bar renders API value 0-1 to 0 to 5 bars.

https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/statusbar.js#L185

Comment 14

[GH to BZ]

[GitHub comment by autonome on 2012-07-24T15:51:31Z]
John will survey a few phones while in Brazil, to see signal strength.

Comment 15

[GH to BZ]

[GitHub comment by jammink on 2012-08-01T03:35:38Z]
I brought 3 (B2G Otoro) phones;   and went to two locations:  Porto Alegre (South Brazil) and Recife (Equatorial Brazil).

All three phones had V, D, T simcards.  Two were regular subscriptions, a third was prepaid.  So pretty good test set.

Two out of three B2G Otoros showed 2 bars of coverage in PoA; a third (not the prepaid one) showed 3 bars.  Same thing in Recife.

An iPhone in Recife showed nearly full coverage; and a Samsung SGS2 showed 4-5 bars coverage; both of these could call out normally.

However, calling on the B2G phones has been a completely different story.  As it turns out, I could only call out from two of my three phones (each with with generally two bars, as opposed to three).  One of the working phones was a prepaid, another was subscribed.  The third subscriber phone had three bars and could  not make outgoing calls.    This makes absolutely no sense.

It's hard to say what the specific problem was - to make matters even more confusing I was stuck with https://github.com/mozilla-b2g/gaia/issues/3001 (Dialer can't hang up a call) which made it necessary to pull the battery after every trial!

Comment 16

[GH to BZ]

[GitHub comment by jammink on 2012-08-21T20:15:20Z]
@autonome - see my comment above.   What next steps should be taken here?

Comment 17

[GH to BZ]

[GitHub comment by nhirata on 2012-08-22T21:10:01Z]
removing qa-wanted based on the testing above.

Comment 18

[GH to BZ]

[GitHub comment by autonome on 2012-09-11T21:10:53Z]
Sounds like we need some help from vivo here.

Comment 19

[GH to BZ]

[GitHub comment by zacc on 2012-09-20T15:49:04Z]
I am experiencing this too, never more than 2 bars although generally call performance is fine.

Is it possible to debug and get the raw values from Android / B2G so we can deduce whether it is an antenna/provider issue or algorithm?

Comment 20

[Dietrich Ayala (:dietrich)]

Philikon, this sounds like RIL work, not just Gaia.

Comment 21

[Philipp von Weitershausen [:philikon]]

(In reply to Dietrich Ayala (:dietrich) from comment #20)
> Philikon, this sounds like RIL work, not just Gaia.

This is likely entirely the RIL's fault. Some context here: we get raw dBm values from the modem. We have to compute the bars. Actually, for the sake of the API, we compute a relative signal strength as a percentage. Way back when I just made shit up and divided the dBm range between 0..100% linearly, knowing that this was probably not going to be the final solution. (Note that I'm pretty sure everybody else also just makes shit up. Apparently this particular solution is known as the "AT&T method".) Anyway, this is why it's not totally unexpected for B2G to report "weird" bars. I've said that before in some Gaia issue, but maybe not everybody here has that context. I just thought this had been resolved by now; sorry if this isn't the case.

I've also said before in response to jammink that comparing the, say, Otoro running B2G to Android on an SGS2 is pretty useless. We need to compare the *same* device with Android and B2G if we want meaningful numbers. My Nexus S, for instance, has a much worse antenna/modem than my SGS2. At least in the same spot on the same network it tends to report less bars. So comparing two operating systems by using two different phone models doesn't help us much.

zacc's comment 19 hits the nail on the head:

(In reply to GH to BZ from comment #19)
> Is it possible to debug and get the raw values from Android / B2G so we can
> deduce whether it is an antenna/provider issue or algorithm?

Yes, we expose the raw dBm values through the API. It is trivial to make Gaia report them in the status bar. I'm sure there's a way on Android, too. Why yes, there seems to be plethora of signal strength apps in the Google Play store. So we could take a B2G and an Android otoro side by side and compare how they do on bars given *equal* dBm values. *If* we think Android is our yard stick. Either way, we eventually make up an equation that we think represents signal strength best.

Comment 22

[Philipp von Weitershausen [:philikon]]

To elaborate, from the modem we get an integer 0..31 which corresponds to -113..-51 dBm. So our "algorithm" to compute dBm and a relative percentage is as follows [1]:

  if (obj.gsmSignalStrength >= 0 && obj.gsmSignalStrength <= 31) {
    obj.gsmDBM = -113 + obj.gsmSignalStrength * 2;
    obj.gsmRelative = Math.floor(obj.gsmSignalStrength * 100 / 31);
  }

I don't necessarily think there's anything wrong with it, though I'm not ruling out there might be a "better", non-linear function that converts dBm to a relative percentage. I think the problem is how we turn this percentage into bars by the Gaia system app [2]:

  icon.dataset.level = Math.floor(voice.relSignalStrength / 20); // 0-5

The flooring means we essentially short-sell the relative signal strength. In fact, just changing the Math.floor to Math.ceil means we're almost spot on with what I've seen described as the "AT&T method" out there.

Going to write a patch to do that. Moving bug back to Gecko.

[1] https://mxr.mozilla.org/mozilla-central/source/dom/system/gonk/ril_worker.js#4209
[2] https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/statusbar.js#L329

Comment 23

[Philipp von Weitershausen [:philikon]]

PR submitted at https://github.com/mozilla-b2g/gaia/pull/5887

Comment 24

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Philipp von Weitershausen [:philikon] from comment #23)
> PR submitted at https://github.com/mozilla-b2g/gaia/pull/5887

r=me. Thanks.

Comment 25

[sarsenyev]

Verified it's fixed on "Unagi"
Build ID:20130113070202

The signal bar shows a strong signal