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

Wed Jan 7 16:13:04 CET 2009

Oh, yeah, I may have forgotten to send this to list, but this post
reminds me. I have also experienced #1024 when deep_sleep = never. It
seems that it auto-recovers pretty quickly though. It also happens for
2-3 minutes, (at a cycle between 15-30 seconds). After a few minutes,
the modem goes back to normal like nothing ever happened.

On Wed, Jan 7, 2009 at 6:05 AM, Dima Kogan <dkogan at cds.caltech.edu> wrote:
> My phone readily exhibits #1024, so I just spent a bit of time looking
> into the stability of the 32KHz oscillator at R1050. I scoped across
> C1050, and looked for instabilities in the clock waveform as the phone
> repeatedly lost and regained registration. I found none. The waveform
> seemed stable at 32.786KHz. I looked at the waveform on a very slow
> timescale, looking for dropouts, and on a faster time scale with a long
> trigger delay, looking for phase drift. I didn't find any instability
> with either method. It's still possible that a very quick instability
> got by the scope, and I missed it, but if it's there, it's subtle. I
> did not replace the resistor, but I can if you think it would be
> useful.
>
> While playing with this, I discovered that issuing AT%SLEEP=2 does not
> completely eliminate recamping for me. If the registration was stable,
> and I issued AT%SLEEP=2, no recamping would occur. However, if the
> phone was very recently recamping, recamping would continue
> even after I issued AT%SLEEP=2. In the new setting it would still
> recamp a few times, and then settle and become stable. It feels like in
> sleep=4, the phone goes in and out of an unstable state, and that
> issuing AT%SLEEP=2 doesn't kick the phone out of this unstable state,
> but rather doesn't let this it ENTER the unstable state.
>
> Another thing I noticed is that when I issue AT%SLEEP=4, the calypso
> responds with "EXT: I" and "OK". If registration is stable and I issue
> AT%SLEEP=2, I also get "EXT: I" and "OK", and most of the time no
> recamping happens (but not always). If recamping was recently
> happening, AT%SLEEP=2 only says OK, no "EXT: I". If I issue the command
> a second time, I get "EXT: I" also. In this situation, the calypso
> seems to always recamp at least once. This is all based on one night's
> worth of experimenting, so it's not conclusive, obviously. It may still
> be interesting to understand what EXT: I is. It probably doesn't mean
> we're currently not in Deep Sleep because that would imply that we're
> often NOT in Deep Sleep when the phone is sitting on my desk, doing
> nothing (if we're in sleep=4, but registration is stable). Is there a
> way to tell if we're CURRENTLY in Deep Sleep? The mickeyterm logs from
> my sessions that demonstrate the described behaviour are at
>
> http://secretsauce.net:5050/recamping.log
>
> I can easily reproduce 1024 most of the time, so I can do experiments
> if needed.
>
> Dima
>
> On Mon, 22 Dec 2008 13:06:27 +0100
> 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
>
> _______________________________________________
> hardware mailing list
> hardware at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/hardware
>