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

Dieter Spaar spaar at
Wed Jan 7 16:45:42 CET 2009

Hello Dima,

First of all, thank you very much for spending the time looking at the 
problem and
reporting the results, I really appreciate it.

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

If its not too much effort for you, it would be great if you can replace 
resistor with 100k and see if this influences #1024. This way we would
be sure that this resistor is not causing the problems.

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

This is an interesting observation, in the traces I have I did not see
it yet.

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

"EXT: I" is just an indication that some extended AT commands are
executed. There is currently no way to find out if "Deep Sleep" is on.
The only thing which gives some sort of indication is that the first
typed character in the terminal got lost because it is needed to
wakeup the chip.

> The mickeyterm logs from
> my sessions that demonstrate the described behaviour are at
> I can easily reproduce 1024 most of the time, so I can do experiments
> if needed.
> Dima

Best regards,

More information about the hardware mailing list