'Signal' interface

[Dan Williams]

On Fri, 2013-07-19 at 07:40 +0200, Aleksander Morgado wrote:
> >>>  * Currently values are provided as independent properties, e.g.
> >>>> >> > "gsm_rssi", "umts_rssi"... Another option would have been to provide
> >>>> >> > per-technology dictionaries, like a "gsm" property with signature
> >>>> >> > "a{sd}" where the string is the parameter (e.g. "rssi") and the double
> >>>> >> > is the actual value. Don't have a strong feeling about this.
> >> > I think a per-technology/radio dictionary might be a bit cleaner, since
> >> > then you don't need the 'valid' booleans, since the dict would only
> >> > include those items that were valid.  Also, we could potentially include
> >> > statistics on power control, gain control, noise, frame error rate,
> >> > sensitivity, etc, and those are all per-radio too.  I think a non-dict
> >> > interface might be a pain to keep updating if we add further stats in
> >> > the future.
> >> > 
> >> > What do you think?
> > Yeah, let's do that.
> 
> Ok, so now each access tech has a dict property; and the new 'MMSignal'
> helper object in libmm-glib helps to use this new dictionary.
> 
> Available in the 'aleksander/signal-interface' branch, let me know what
> you think.

For QMI, any particular reason to limit this to NAS >= 1.8?  At least on
older devices, NASGetSignalStrength can fill in many of the same values:

Current:
	Network 'lte': '-74 dBm'
Other:
	Network 'cdma-1xevdo': '-125 dBm'
RSSI:
	Network 'lte': '-74 dBm'
	Network 'cdma-1xevdo': '-125 dBm'
RSRQ:
	Network 'lte': '-7 dB'

Which leads me to the next point: we should abstract the
GetSignalStrength/GetSignalInfo logic because we have almost exactly the
same logic for getting signal strength, and there doesn't seem to be a
good reason to duplicate it...

> api,introspection: new 'Signal' interface for extended signal quality

Setup() method - lets specify what units 'rate' is in.

Other than that, looks good to me.

Dan