[RFC] TODO: Move signal strength property to separate Agent API.
From: Sjur Brændeland sjur.brandel...@stericsson.com --- I think we should consider changing the way we handle signal strength in oFono. In the past I have seen very frequent signal strength reports from the modem under certain network conditions. I think we can improve the power consumption by changing the design here. I know other Radio Interfaces are subscribing to changes in power modes and turns off the signal strength reporting when screen is turned off. An Agent API for for Signal Strength would allow oFono to subscribe to modem signal strength updates only when an Agent is registered, and applications should register on the Agent API only when the signal-strength information is really needed. Regards, Sjur TODO |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/TODO b/TODO index a36e9ed..50561a8 100644 --- a/TODO +++ b/TODO @@ -434,6 +434,14 @@ Miscellaneous Complexity: C1 Owner: Aki Niemi aki.ni...@nokia.com +- Move the Property Strength in NetworkRegistration into an Agent + API in order to avoid frequent wakeup due to signal strength updates + from the modem. With an Agent API the application can register for updates + if the strength bars are visible, and unregister when applicable (before + going into low-power mode). + Priority: Medium + Complexity: C1 + CDMA Voicecall == -- 1.7.0.4 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC] TODO: Move signal strength property to separate Agent API.
Hi Sjur, I think we should consider changing the way we handle signal strength in oFono. In the past I have seen very frequent signal strength reports from the modem under certain network conditions. I think we can improve the power consumption by changing the design here. I know other Radio Interfaces are subscribing to changes in power modes and turns off the signal strength reporting when screen is turned off. An Agent API for for Signal Strength would allow oFono to subscribe to modem signal strength updates only when an Agent is registered, and applications should register on the Agent API only when the signal-strength information is really needed. I don't think is needed. You do not get woken up until you tell D-Bus to wake you up on that PropertyChanged signal. You can even match the first parameter of that signal if you desire. What we might should ensure is that we delay the signal reporting from the modem. In case it wants to play ping-pong between two values. We have done that for ConnMan in the past since WiFi signals are also kinda flaky and made the UI go nuts. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC] TODO: Move signal strength property to separate Agent API.
Hi Marcel, 2011/1/20 Marcel Holtmann mar...@holtmann.org: I don't think is needed. You do not get woken up until you tell D-Bus to wake you up on that PropertyChanged signal. You can even match the first parameter of that signal if you desire. I think this is still a worthy optimization, because this way not even oFono will wake up unnecessarily. What we might should ensure is that we delay the signal reporting from the modem. In case it wants to play ping-pong between two values. We have done that for ConnMan in the past since WiFi signals are also kinda flaky and made the UI go nuts. Personally, I would just move to reporting the strength value in 0...5 bars. Most UIs I've seen report bars in their UIs, and this way these clients will get woken up much more infrequently. In addition if percentage is really required, we could offer that as a separate signal, but to instruct to use with caution. Or put it in a plugin. :) Cheers, Aki Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC] TODO: Move signal strength property to separate Agent API.
Hi Aki, I don't think is needed. You do not get woken up until you tell D-Bus to wake you up on that PropertyChanged signal. You can even match the first parameter of that signal if you desire. I think this is still a worthy optimization, because this way not even oFono will wake up unnecessarily. if you followed the discussion between Kristen and myself on IRC about how stupid some modem are, then I worry seriously how good we can get here. That said, I am open for suggestions here, but they need to be backed up by what certain modems can do for us in this area. And then we have to also look at the screwed up hardware. What we might should ensure is that we delay the signal reporting from the modem. In case it wants to play ping-pong between two values. We have done that for ConnMan in the past since WiFi signals are also kinda flaky and made the UI go nuts. Personally, I would just move to reporting the strength value in 0...5 bars. Most UIs I've seen report bars in their UIs, and this way these clients will get woken up much more infrequently. In addition if percentage is really required, we could offer that as a separate signal, but to instruct to use with caution. Or put it in a plugin. :) To be honest, I have no idea if percentage is the best thing. We just picked it initially to have something. My take here is that you either have no signal, bad signal and a good signal. Everything else is just fake for the human brain that tries to associate anything with the bars it sees. Lets face it unless you deal with dB directly you have no proper relation on what this visual aid means in reality. If we go back in the good old days, then we had 4 bars, then it became 7 in some Nokia phones, now it is 5. What is common, what makes sense? Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
