[Gta04-owner] Modem crashing?

Dr. H. Nikolaus Schaller hns at goldelico.com
Sat Feb 18 10:17:06 CET 2012


Am 18.02.2012 um 07:08 schrieb NeilBrown:

> 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 
>  NO CARRIER
> 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.

Indeed surprising! Hm. Can we tap the modem port or is it used (via
the hso driver) for networking? Or is there a bug in the hso driver that
shuts down USB as soon as it finds the NO CARRIER on the modem
port? There must be some automatic since the network setup is
going fully automatic.

> 
> 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 think I remember that there was a note that ATH is not reliable and we
should use AT+CHUP

> 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

There might be seconds of complete silence...

>> - 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

These are unfortunately quite unreliable indicators of a call end.
By moving just some cm the RF link to the base station may become
much better and the modem might reduce transmission power.

But we already have a quite reliable indicator: PCM clock stops at
call end. This has unfortunately the wrong logic to wake up the CPU.

> 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
> though.

This brings me to an idea: is there a gradual suspend? For such
polling of the modem during a voice call we don't need the CPU to run at
800 MHz. I would assume that 1 MHz could be sufficient...

Nikolaus



More information about the Gta04-owner mailing list