[Gta04-owner] Modem crashing?

NeilBrown neilb at suse.de
Sat Feb 18 07:08:15 CET 2012

On Sat, 18 Feb 2012 06:14:44 +0100 xdrudis <xdrudis at tinet.cat> wrote:

> On Fri, Feb 17, 2012 at 04:56:03PM +0100, Marcel Holtmann wrote:
> > Hi Butrus,
> > 
> > > > we already fixed this bug with CLCC polling inside oFono. That is not
> > > > the problem.
> > > >
> > > > The one thing that nobody realizes here is that this workaround comes at
> > > > a high price. You have to do constant polling while being in an active
> > > > call.
> > > 
> > > Really _constant_? Would it be enough to wake once in 2 or 5 seconds
> > > (or so)? How much time would one "poll" take? If e.g. it would take
> > > say 100ms and you wake every 5 seconds (for example), the overall
> > > power consumption would be reduced drastically...
> > 
> > we poll every 500ms since that is the expected latency that we can
> > expect from a user. Anything less we result in bad user experience.
> Ok. If I understood correctly we have a GSM chip that isn't able to
> wake up the system when it detects a remote hangup in a voice call. So
> when must keep the cpu and usb path awake too often to poll the GSM
> chip and that drains battery.

I don't think it is quite that simple.
We have a GSM chip for which we do not have complete documentation,
for which the firmware is a little old, and which does not behave exactly the
same as other GSM chips people are familiar with.

If I call my GTA04, answer the call, and then hang up, I do not get 
on the 'Application' port (which is where I get e.g. "RING" indications).
However I *do* get "NO CARRIER" on the Modem port.
A little surprising but possibly quite usable.  There may be other surprises
for those willing to explore.

When I dial out it seems a little different.  I try to hang up with ATH
but "AT+CPAS" indicates I am still on a call.  When the other end hangs up,
then I get NO CARRIER.
I'm not sure if this is always consistent.  More experimentation is needed.

Then there is the question of whether this can wake the phone from a low
power state.  It can certainly wake from idle, but that is still quite some
mW more power than suspend.  I don't know if it will wake from suspend, but
there is still some work to do before suspend is working really reliably.
Maybe it will. (not that that will help me.  The early-adopter boards need to
cpu to copy sound from the GSM to the speakers/microphone.  The more recent
board should be able to do that without CPU being involved.)

The only way to really tell how much any of this will 'drain the battery' is
to measure it.  Until people make real measurements it is all speculation.

> Since we can't get another chip, we can't get 0 polls, but next best
> thing we want is as few polls as possible. But we want to detect end
> of call as close as possible to the real hangup. 
> I wonder if there is any possible "hardware heurism" we can use. Is
> there any possibility, ideally with the current hardware, or maybe
> with simple electronic additions, that we can detect a change in some
> parameter correlated with active voice call ?. For instance do we have
> something that can wake the cpu up (so it can poll once and detect end
> of call or go back to sleep or change the poll interval) when:
> - volume in all of mic, speaker or headphone during last 0.5 s has been
> lower than previous 1.5 s
> - radio emission power has been lower in last 0.5s than was during previous
> 1.5 s (problem, we want to know about reception too, I guess, since it
> may be the other side speaking).
> - total power use (battery drainage) has been lower last 0.5 s than previous
> 1.5 s

Any of these would need substantial interaction with the CPU and so wouldn't
save any power.  The only sane options are:
  1- arrange for the GSM module to tell us (and maybe it does)
  2- poll using a command to the GSM module (e.g. AT+CPAS).

> And another question is about voIP. I've never used it. I guess we
> don't have end of call problems with it. Does it consume more battery
> than GSM voice ? Is it usable only in fewer places (less coverage)?

VoIP requires the CPU to be quite busy particularly handling network
traffic and compressing audio.  I would expect it to use substantially more
power than GSM voice.  This might still be a couple of hours of talk time

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: not available
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20120218/4588c41a/attachment-0001.bin>

More information about the Gta04-owner mailing list