[Gta04-owner] Modem crashing?

Dr. H. Nikolaus Schaller hns at goldelico.com
Fri Feb 17 11:11:10 CET 2012

Hi Marcel,

Am 17.02.2012 um 10:46 schrieb Marcel Holtmann:

> Hi Nikolaus,
>>>>>> Why should they implement and certify voice commands, PCM audio
>>>>>> interface and so on if it were a data call only modem?
>>>>> either they have a call state notification command and never told you
>>>>> about it or this modem has never been used for voice calls.
>>>>> If anybody would have been serious about using this in a phone type
>>>>> device with voice calls, then a call state notification would exist. The
>>>>> polling is expensive and will drain your battery. In addition doing that
>>>>> on USB is not really battery friendly either.
>>>> Btw you can detect that the call ended with arecord - the umts soundcard stops 
>>>> sending data...
>>> this is all kinda nice stuff, but fundamentally we need an unsolicited
>>> notification that informs us about call state changes. Everything else
>>> is just wasted time.
>> Unfortunately no. We are not in a position (regarding number of units)
>> to define what the modem manufacturer should do for us.
>> And, we are not in a position to swap the modem on the fly. It is
>> tightly integrated into the space and signals that are available.
>> In the meantime, I got an answer from OPTION. They do not know about our bug
>> but asked which firmware version we have. It turned out that we don't have
>> modules with the latest one. Which comes from the fact that we
>> got them from a distributor and they ship by FIFO principle. I.e. we got
>> modules with a production date several months ago. And nobody upgrades
>> already produced modules. So this does not come unexpected.
>> The only way to change this is that we reduce the stock roundtrip time
>> by getting more users and buyers. Then, we get less aged devices.
>> While we can suspect that it could be possible to upgrade firmware, this is beyond
>> our current capabilities. First of all, we don't know how a firmware upgrade
>> can be done and if it is succesful and/or introduces other bugs that we
>> find out only after we have done the upgrade. Then we may have to repeat.
>> And our users will have different firmware versions installed and the middleware
>> has to cope with that situation as well. So it introduces complexity.
>> Not to forget the logicstics of collecting the devices and somehow applying
>> patches (I have not enough information how complex this is and what
>> it means and how much time it would consume).
>> Therefore, it is IMHO wasted time to think about such changes or upgrades.
>> It is much easier to see that we have a bug (and everyone has the same one.
>> Which simplifies our life) and find a workaround in our software.
>> And again, we are not yet in the role of an important customer of OPTION
>> so that we can demand anything from them (or any other modem manufacturer).
>> To change this, please help to make the Group tour a success! Which
>> also means that we should focus on a workaround first.
>>> Yesterday I realized that even Sierra has included such a command in
>>> their modems.
>> Yes, they may be better from a programmer's point of view, but as said
>> above, we have to live with the GTM601W for a while.
>> And, we have to separate a real bug (module does not behave as
>> specified) and a missing feature (we would like to see a feature that
>> simplifies our software but is not defined in the hard/firmware).
>> Radek's approaches are all addressing the bug, while Marcel votes for
>> new features. This does not have much to do with each other.
> 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

all known alternatives also have a high price.

> call. That will reduce your battery life significant. And because the
> modem is on USB and can't do auto-suspend it will be even worse.

I think Radek's approach to monitor the PCM clock - which is only active
during a (single) voice call - can address this. It may of course miss
some signalling with a second call coming in during a first one
(GSM conference calls).

> Let me tell you from experience that we already had this problem with a
> modem from Huawei that insisted on sending notifications during an
> active data connection even if no packets were transmitted. Our USB
> controller was never able to sleep and essentially drained the battery
> very quickly.
> Doing voice data processing in the host by just forwarding is a nice
> feature for research purposes, but it can also decrease your battery
> life significantly. So essentially you really wanna do that directly via
> modem to codec connection. Once you do that, you can not even use such a
> method for detecting a call ending.
> Meaning you are back to CLCC polling. I am curious how long of a phone
> call you can make with a fully charged battery and CLCC polling.

Yes, I agree that it would be a technically much better solution and improves
user's experience to some degree. That is what we all are working for.
But it is like wanting to have Linux 4.0 on a OMAP5 which would be a
really great step :) The project is simply not yet strong enough to get it done
as easily as we would like to see it. So we have to live with some issues
but as long as the total experience is good, I think it is still ok.


More information about the Gta04-owner mailing list