Bug #1024 (oscillating re-camping), the latest news.

Dieter Spaar spaar at openmoko.org
Wed Apr 29 20:19:16 CEST 2009


Hello,

here is the latest news about the investigation of
bug #1024 (oscillating re-camping).

I finally received a GTA02 which exposes the behavior of
bug #1024 and a second one is on the way (Thanks again
to those who send me the phones, you know who you are).

This one GTA02 which I am already playing with for some
time shows re-camping in a very extreme form, if the
phone goes into "Deep Sleep" while receiving the PCH,
the next reception will fail immediately. It does not
care how long this "Deep Sleep" period is, the next PCH
reception will simply fail.

My other GTA02 phones work perfectly in the same
situation (a simulated test cell) and show no problems
at all with "Deep Sleep".

To find out if the 32 kHz oscillator is responsible for
the problem, I connected an external, stable and accurate
clock signal: No difference, still the extreme behavior
in "Deep Sleep".

Finally, after a while I found out that the problem goes
away if I warm up the Calypso chip by a few degrees. The
other chips of the GSM chipset (Digital Baseband and RF
Transceiver) or the 32 kHz and 26 MHz oscillator don't
care about warming, only if I warm up the Calypso,
the problem goes away and this GTA02 behaves as good
in "Deep Sleep" as my other GTA02 do. Additionally
if the Calypso cools down again, it slowly begins to
expose problems in "Deep Sleep" every now and then
until finally the extreme behavior (PCH reception
failure immediately after "Deep Sleep") is back again.

Its still too early to conclude anything from this
observation, its just one GTA02. I am waiting for
the second GTA02 to find out if it behaves the same.

I am also trying to find out if there is a way to
remove this "Deep Sleep" problem with a modification
of the GSM firmware. The transition into "Deep Sleep"
and back again is a rather complex process, there are
all three GSM chips involved, so there is a chance that
things go wrong here at some point. However the big
problem is (again and as usual) that we don't have
the Source Code of this part of the firmware. So
its rather time consuming to find and understand the
responsible parts of firmware, patch them and test
the result.

So this is it for today, just to let you know that
bug #1024 is not forgotten ;-)

Best regards,
  Dieter




More information about the hardware mailing list