Re: [MM RFC] Signal quality and access technology

[Dan Williams <dcbw redhat com>]

On Fri, 2012-09-14 at 08:53 +0200, Aleksander Morgado wrote:
> Hey,
> 
> In the new MM DBus API we allow reporting multiple current access
> technology values, for modems which can connect to more than one network
> at a time (e.g. CDMA1x and EV-DO, or LTE).
> 
> But, we still report only a single signal quality value, while each
> access technology may have its own. Currently the choice of which to
> report is let to the core or plugin implementation; e.g. the base logic
> is to report the maximum value of those gathered (in QMI modems). A
> better approach is probably to give different priority to different
> technologies, e.g. give LTE signal quality value if that is available,
> otherwise give WCDMA signal quality value if that is available,
> otherwise give GPRS/EDGE signal quality value if that is available. Same
> could apply for EV-DO and CDMA1x.
> 
> Anyway, given that we're still changing the DBus API, why not just let
> the users of the interface decide which signal quality value to report?
> Instead of giving a "ub" signal quality ("u" for the value, "b" to
> indicate if the value is taken in the last 60s), we could give it as an
> *array* of "uub" values (being the additional first "u" the access
> technology). This would effectively mean that we're merging the signal
> quality values reported with the access technology report (which is now
> given as a bitmask in a single "u" value).
> 
> Another approach, if we still want to keep the consolidated single
> signal quality value, would be to implement a completely new
> Modem.Signal interface with deeper details of the current radio signal.
> We could give per-access-technology details, including Ec/Io, RSSI, GSM
> timing advance...

The consolidated signal quality thing was mostly a mistake, so no reason
to keep it.  It might be nice to have some indication of tech-specific
details too, like Ec/Io or RSRP/RSRQ; often we'll have multiple
measurements here.  If we do that interface, it'll have to be pretty
extensible, since for example with CDMA/EVDO you actually have "pilot
sets" which are the pilot signals of each sector the modem can see, and
each of those has a few different attributes too.  All this stuff is
typically used for "engineering status" or "field test" apps on phones
or the diagnostics windows of PC connection managers.  Nice to have, but
not critical.

But emitting the "simple" (ie 0 - 100%) signal strength with the access
technology would work fine, I think.

Dan