Status of bug #1024 (periodic signal lost and re-registration)

[Sargun Dhillon]

I understand the difficult in reproducing #1024. I can reproduce it
very easily (San Jose, CA, USA, Pleasanton, CA, USA: (Providers:
T-mobile, AT&T)) . How much would an RF dump help? I mean, I can give
you SSH access to Freerunner, if you'd like. What can the community do
to help you?

For possible cheap ways to gather more data:
-If you have a firmware that can save out the RF. We could deploy it
on our Freerunners that are exhibiting the problem, and send up the rf
save out. This might be very naive, as I don't really understand how
the Calypso chip works. These guys seem to be working on something
similar: http://wiki.thc.org/gsm/opentsm


-Get a USRP(2), and the proper transceiver boards. We can do the
captures. Obviously there would be a lot of noise, so we'd have to
figure out a way to get this out. These devices are expensive, so I'm
not volunteering to purchase one, but I would split the cost with a
few other Freerunner owners, and give OM access to the USRP, and a
Freerunner in its proximity remotely.

Dieter, I may be babbling, feel free to call me out if I am, but will
any of this help?

On Mon, Dec 22, 2008 at 4:06 AM, Dieter Spaar <spaar at openmoko.org> wrote:
> Hello,
>
>
> here is an update about the status of bug #1024.
>
> First some background information why it is so hard for us to
> solve this bug:
>
>
>  - we (or better, those who work on the GSM stuff) cannot reproduce
>    this bug.
>
>
>  - OM does only have a small part of the GSM firmware as source code.
>    Basically its the AT command interface and some drivers. The rest
>    is delivered by TI as binary libraries only, especially the GSM
>    protocol stack and Layer 1. So we cannot just have a look at the
>    source code and search for errors.
>
>
>  - To get an impression of what we talk about, here are some C metric
>    numbers from a comparable GSM firmware:
>
>     GSM Protocol stack:  700 files  400.000 lines   127.000 statements
>     Layer 1:             130 file   130.000 lines    31.000 statements
>
>
>  - the actual low-level RF work of decoding the GSM frames is done
>    by the DSP in the Calypso (there is an ARM and a DSP core inside).
>    The DSP has its code in ROM and OM has no documentation about it.
>
>
>  - The Calypso chipset is already "end of life" for quite some time,
>    there is not much support from TI for it any more.
>
>
> The above should be no excuse, it should show why it is rather difficult
> for us to fix this problem.
>
> What we know so far about #1024:
>
>  - We have some PCO2 traces (PCO2 is an internal TI tool) which show
>    that in Idle Mode (the phone is registered to the cell but there is
>    no voice or data traffic) the periodic reading of the BCCH (Broadcast
>    Control Channel) of the serving cell at some point fails. We don't
>    know yet what exactly fails, just that an error flag set. When this
>    happens, the error does no longer go away and most certainly after
>    some timeout causes the "signal lost" indication and finally the
>    re-registering in the cell.
>
>
>  - In traces where bug #1024 does not occur, this error flag is only
>    set very rarely. And if it is set, it usually goes away within the
>    next few readings. This is similar if the "AT%SLEEP" workaround is
>    applied, the error flag is nearly never set.
>
>
>  - This periodic reading of the BCCH occur about every two seconds,
>    there is no difference with or without #1024 occurring.
>
>
>  - This periodic reading basically works like that: A special
>    timer ("special" because it is designed to support the
>    GSM frame timing very well) is programmed to wake up the
>    chip at the correct time so that the GSM frame of interest
>    can be received. Then the chip starts to sleep and waits
>    for the interrupt of the timer. There are two different
>    sleep modes, "Big Sleep" and "Deep Sleep".
>
>
>  - #1024 only occurs if "Deep Sleep" mode is active (this is the
>    standard behaviour, AT%SLEEP=2 disables it and only "Big Sleep"
>    is used). The special thing about "Deep Sleep" mode is that the
>    fast oscillator of the Calypso is turned off and it relies on the
>    32kHz oscillator only.
>
>
>  - "Big Sleep" draws less current than "Deep Sleep" so its not a
>    perfect workaround to disable "Deep Sleep" completely. We have not
>    yet measured how exact the standby time of the phone is influenced
>    if "Deep Sleep" is turned off. I assume that it has an influence
>    which should not be neglected.
>
>
> There are several open questions:
>
>
>  - The problem could come from "drifting away" in "Deep Sleep" mode from
>    the right point of time to receive the frame. The firmware does some
>    adjusting of the 32kHz oscillator, but there are several things which
>    could go wrong (software and/or hardware issue).
>
>
>  - We should check the 32kHz oscillator, especially have a look at
>    the 220k resistor R1050. In one of the Calypso docs and in the TI
>    reference implementation this resistor is 100k. TI is very picky
>    about the 32KHz resonator, they mention quite a lot of things about
>    what to take care. Is there a reason why we choose 220k ?
>
>
>  - Is there a regular pattern when bug #1024 occurs ? For example
>    does it depend on temperature ? Or does it depend on the charging
>    level of the battery ?
>
>
>  - Is there a way to reproduce #1024 ? Does it only occur with certain
>    phones ? Or does it depend on the cell where the phone is registered ?
>
>
> Please feel free to add your comments and thoughts, we are really trying
> to fix this problem but we need your help by reporting as much details
> as possible about the circumstances for bug #1024. Thank you very much.
>
> Best regards,
>  Dieter
>
> _______________________________________________
> hardware mailing list
> hardware at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/hardware
>