Welcome - You're looking at mwester's Openmoko repository

The Bouncy Rubber Calypso

Update October 4, 2008: problem is tracked down to Deep Sleep mode -- see the bug report (link below)

Overview

A number of users have reported a debilitating problem -- the GSM modem constantly drops off the GSM network and then immediately registers again.

This problem is widespread, and a quick review of the information on the bug tracker bug 1024 shows that it's not related to any one type of device, nor to a single carrier.

One vital thing that we don't know is what the real problem might be. Specifically, is the issue that the calypso is inappropriately deregistering and reregistering constantly? Or might it be that the real bug is that the calypso is behaving normally given some external factor, and that the problem is that it inappropriately signals this normal behavior as if it were a problem?

The fact that once a call is established the calypso holds the call without any registration issues at all is interesting.

"Spackling over" the problem

We all know about the concept of "wallpapering" over a problem -- the art of fixing a problem by supressing the symptoms rather than fixing the root cause. This problem is too big for wallpaper to work; we need at least a giant bucket of spackle to do the job.

We need data. Specifically, we need to know how useful the calypso is if we suppress the symptoms of this problem. And the only way to really find out is to create a hacked-up Qtopia image.

The Qtopia test image (* NOW OBSOLETE*)

NOTE: This test image is now OBSOLETE! Do not use this patch any longer!

This patch was very useful in gathering data on the problem, which was of course its primary purpose. We now know that the problem is related to the calypso's Deep Sleep mode, and both the Qt Extended (aka Qtopia 4.4.x) and the FSO teams are addressing this problem and should have fixes out shortly.
If you absolutely cannot wait, a quickfix patch is available, below.

This test image is based on the released Qtopia sources: qtopia-opensource-src-4.3.2-snapshot-20080917

(Note for those who have installed the Qtopia 4.3.3 image: this may regress a few fixes -- but Trolltech/Nokia have not made the 4.3.3 source code available yet, so there's nothing I can do about that. Sorry.)

Recommended Prerequisites

Install, configure, and test Qtopia. See the documentation on the Openmoko Wiki.

You might also consider the Qtopia suspend/resume updates on the Qtopia page.

Install the Update

Download the update: q-brc-spackle-1-4.3.2-snapshot-20080917.tgz.

Extract the contents using "tar", and execute the install script (or read the install script and perform the steps manually).

(Note that the installation procedure is the same as the update procedure provided by Qtopia for those updating (not reflashing) from 4.3.2 to 4.3.3.)

Restart the device.

Enable Logging

Once the device boots, enable logging:
Main Menu
Settings
  Logging
   Options
    Categories
    check "Modem AT communication"
    check "Modem Other"

Restart the device to make the changes take effect.

Verify that your logging is working by logging in via ssh after the device reboots, and execting the logread command. If all is well, you'll see lots of output including the "AT" commands to and from the GSM.

Your Obligations

Yes, you have obligations too!

This test isn't particularly worthwhile if nobody provides feedback.

So, please send an email to the "devel" list outlining your experience with this -- does it prevent your device from constantly losing registration? Does your device appear to work correctly, or does it miss calls, or display other bad behavior?

And, of course, we need the statistics from the log files -- please use the "logread" command to dump the logs out, and provide that information (after you edit the results to remove your PIN and any other personal data). If you can provide nothing else, the "LoR" lines from the log file are very important.

Reading the Log Data

There are a few new log entries. Here's a snippet, and a short description:





Sep 21 15:07:20 om-gta01 user.notice Qtopia: AtChat :  percentCSQ event, rssi:  18

Sep 21 15:07:20 om-gta01 user.notice Qtopia: AtChat :  N : "%CSQ:  18, 99, 2"

Sep 21 15:07:20 om-gta01 user.notice Qtopia: AtChat :  N : "+CIEV: 1, 3"

A normal sequence, the lines above show an incoming signal quality report, 18/31 for the signal strength/quality. The CIEV message is not useful with Qtopia and the calypso GSM; hence the proprietary CSQ message is used instead.





Sep 21 15:07:52 om-gta01 user.notice Qtopia: AtChat :  percentCSQ event, rssi:  99

Sep 21 15:07:52 om-gta01 user.notice Qtopia: AtChat :  N : "%CSQ:  99, 99, 0"

Sep 21 15:07:52 om-gta01 user.notice Qtopia: AtChat :  N : "+CIEV: 1, 0"

The next three line sequence looks similar -- but instead it reports "99" for the signal strength. This special value indicates that the signal is invalid, most probably because we lost registration with any cell site.





Sep 21 15:07:52 om-gta01 user.notice Qtopia: Modem :  LoR -> Timer started.

Sep 21 15:07:52 om-gta01 user.notice Qtopia: AtChat :  N : "+CREG: 0"

And as we expected, the preceding two log lines show the loss-of-registration from the GSM. The "Timer started" message is part of the "spackle" patch.





Sep 21 15:07:54 om-gta01 user.notice Qtopia: Modem :  LoR -> Timer cancelled.

Sep 21 15:07:54 om-gta01 user.notice Qtopia: Modem :  LoR -> lost: 0  queries: 274

Sep 21 15:07:54 om-gta01 user.notice Qtopia: Modem :  LoR -> unsticks: 1843  ms=( 18735 / 24103 / 77940 )

Sep 21 15:07:54 om-gta01 user.notice Qtopia: Modem :  LoR -> bounces: 1843  ms=( 820 / 2696 / 3999 )

Sep 21 15:07:54 om-gta01 user.notice Qtopia: AtChat :  N : "+CREG: 1,"52DA","14A2""

The last line above is the text from the GSM - it immediately has registered again with the GSM network. The preceding messages are part of the "spackle" patch. The first ("Timer cancelled") indicates that this re-registration event happened before the timer set previously expired -- and therefore this event was not reported to upper layers. The next LoR lines provide some cumulative statistics: since boot, we have zero real loss-of-registration events. We've switched towers or cells 274 times, out of 1843 total registration events. There were a total of 1843 of the registration "bounces" detected. Each bounce is a loss-of-registration followed by an immediate re-register; the "ms=" line tells us that the average time from loss to re-aquire is 2.696 seconds, the shortest was 820 milliseconds, and out of all 1843 events, the longest gap was less than 4 seconds. Similar timing information is provided for the "unstick" events -- for this example, this one indicates that on average we hold registration for only about 24 seconds, and that the longest time we have remained registered is a paltry 78 seconds!





Sep 21 15:07:58 om-gta01 user.notice Qtopia: AtChat :  percentCSQ event, rssi:  17

Sep 21 15:07:58 om-gta01 user.notice Qtopia: AtChat :  N : "%CSQ:  17, 99, 1"

Sep 21 15:07:58 om-gta01 user.notice Qtopia: AtChat :  N : "+CIEV: 1, 2"

And finally, we see the sequence begin all over again.

Source Code

The patch itself: brc_spackle_v1.patch

Qt Extended Quick Fix Patch

NOTE: Use at your own risk!

This patch is a quick fix for the problem; it basically disables the Deep Sleep mode if it detects that the calypso has begun the bouncing behavior.

This patch is based on the Qt Extended 4.4.1 source code. Apply, and then build and install per the Qt Extended instructions. If you find yourself unable to do that, you would be best served to wait for the next release, which will certainly incorporate a fix of some sort as well. (I do not at this time have plans to release binaries for this.)

The quick fix patch is here: brc_qt_extended_quickfix_v1.patch.

FSO Patches

The code in FSO that manages the GSM is written in python, which makes it practical to distribute changes in patch form.

(Patches will be provided shortly - stay tuned.)