[Gta04-owner] Modem reenummerating (was: Re: Crowdfunding an Ubuntu smartphone)

[Dr. H. Nikolaus Schaller]

Hi Radek,

Am 31.08.2013 um 12:32 schrieb Dr. H. Nikolaus Schaller:

> 
> Am 30.08.2013 um 08:07 schrieb Radek Polak:
> 
>> On Thursday, August 29, 2013 01:00:54 PM Dr. H. Nikolaus Schaller wrote:
>>> Am 29.08.2013 um 12:56 schrieb Radek Polak:
>>>> On Thursday, August 29, 2013 11:50:26 AM Dr. H. Nikolaus Schaller wrote:
>>>>> Am 29.08.2013 um 10:50 schrieb Radek Polak:
>>>>> 
>>>>> Looks like becoming a Heisenberg-Bug. The closer you look the less you
>>>>> can grab it...
>>>> 
>>>> unfortunately yes...
>>>> 
>>>>>> I think that it has lost it after playing with AT_OPSYS. My GTA04 is
>>>>>> brand new and i havent used AT_OPSYS command until yesterday.
>>>>> 
>>>>> Unfortunately I don't know what the factory setting is.
>>>> 
>>>> You can use AT_OPSYS? to find out on brand new GTA04 board if such board
>>>> exists.
>>> 
>>> Hm. I don't think so :( All of them have been tested including some modem
>>> commands... So unless we produce more, there is no really virgin GTA04
>>> board :(
>> 
>> I think "some AT commands" dont matter unless you did AT_OPSYS.
>> 
>> Btw mine phone is now very stable. 315 calls and 0 reenumerates.
> 
> If I get it right, this is with OPSYS=0,2.
> 
> Hm. What I still don't get into a clear hypothesis is that it depends on
> 2G vs. 3G AND suspend vs. no suspend.
> 
> If it would show up only when using suspend I would conjecture that
> the EHCI/USB interface does not handle CPU suspends correctly. Maybe
> irritating the modem which might not be prepared that the host is suspending
> or getting into a bad state [1]
> 
> But the dependence on 2G vs. 3G does not fit into this picture.
> 
> BTW: in my setup I still have to try to find out why my GTA04 used for testing
> only sees 2G (AT_ONCI?) - even if I issue OPSYS=3,2. Maybe I have played
> with some other (persistent) settings of the modem. So at the moment I can't
> try to reproduce 3G reenumerations.
> 
> -- hns

I have now a better setup to test this issue.

The major problem was that the antenna connection in the GTA04 was broken
and therefore the signal strength wasn't good enough for 3G and the modem
simply refused to switch to 3G mode even with OPSYS=3,2 because it did not
even see a 3G base station.

But after replacing the antenna, I could now see reenumeration in ~10% of the
incoming (and aborted) 3G calls.

To me it looks as if the first RING signal is not even being printed, but once I
had a RING + some other unsolicted message. The caller is redirected to
the mailbox quite immediately.

And, it is not only the modem reenumerating, but it also appears to be
sort of resetting.

I conjecture that from the fact that parameters like AT+CRC=1 and AT+CLIP=1
are reset when I reopen /dev/ttyHS_Application.

Hm. We may have some resonance of the 2.1 GHz UMTS signals with
the ON_KEY transistor...

But I don't have the impression that the modem is switched off and on, because I
don't have to wake it up again. I.e. the USB connection is reenumerated
automatically. If we would have RF disturbances there would be some chance
that the modem stays turned off after the transmission stops.

I have not enabled PIN checks on this SIM card for easier testing, so I can't see
if the modem was really powered off, because then it would ask for the PIN
again.

I use the latest 3.11 kernel and I don't think the kernel did go to suspend at all.

So it is still not really clear what is going on and why it depends so much on 2G vs. 3G.

The next step I want to try is to use the HSO driver with debugging enabled. Currently
dmesg only shows

[ 2803.900421] usb 1-2: USB disconnect, device number 5
[ 2807.770477] usb 1-2: new high-speed USB device number 6 using ehci-omap
[ 2807.942260] usb 1-2: New USB device found, idVendor=0af0, idProduct=8800
[ 2807.949310] usb 1-2: New USB device strings: Mfr=3, Product=2, SerialNumber=0
[ 2807.970397] usb 1-2: Product: Globetrotter HSUPA Modem
[ 2807.975799] usb 1-2: Manufacturer: Option N.V.
[ 2807.998809] reg-virt-consumer reg-virt-consumer.2: Failed to obtain supply 'vaux2': -517
[ 2808.090637] platform reg-virt-consumer.2: Driver reg-virt-consumer requests probe deferral
[ 2808.099548] reg-virt-consumer reg-virt-consumer.3: Failed to obtain supply 'vaux3': -517
[ 2808.300628] platform reg-virt-consumer.3: Driver reg-virt-consumer requests probe deferral

I have included the reg-virt-consumer messages as well as they always occur after the
reenumeration. This indicates a different problem that may just be retriggered.

BR,
Nikolaus