Change History

mickey@andromeda:/local/pkg/openmoko/src/target/OM-2007.2$ libgsmd-tool -m atcmd
libgsm-tool - (C) 2006-2007 by Harald Welte and OpenMoko?, Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY

Hi Mickey,
we have a similar problem and reported by Michael in San Francisco. It's
difficult to camp to the network with AT&T SIM card there and it registers with
a roaming network, not home network. Could you please help us to run a basic
script and check the gsm network in your local network? Thanks a lot!!!

Status update:
TI@tw finish the analysis of the trace, they didn't see something abnormal in
protocol layer.They think the problem could be in L1 layer or our hw. TI will do
more testing with neo device, and compared to their EVB.

After checked the trace, TI said it is similar to one issue happened on their
another platform. They already had a patch for that, TI is waiting for the
testing result of the patch.
If the patch is the solution for this, there'll be a new gsm firmware in the future.

Ok, I'm now more convinced that it's an actual hardware problem than ever. I
have swapped things among four devices, firmware, and SIM cards whatsoever and
the only constant is that of all my devices, I have only one that does not emit
this bug.

All my options of doing any research on this are now exhausted. Last night, I
used GTA02 #60 to do some modem-stress-tests -- hammering it with commands on
multiple virtual channels while being registered to the network -- and guess
what... over 12 hours there has not been a _single_ +CREG: 0.

And yes, this is the same phone, same SIM card, same location, same
initsequence, same cell tower, same everything.

Now we can only pray that it does not occur too often in the field.

The only remaining scientific attempt to find out what is going on would be
someone scrutinizing this by using the GSM low-level debug and GNU radio.

I can trigger this under FSO. Every time a GPRS connection is closed down, or an attempt failed quite late (after ppp0 is setup I guess), I get unregistered signals on the system dbus. ​http://lists.openmoko.org/pipermail/community/2008-August/026026.html
I estimate that it takes some 15+ seconds after the connection is shut down until I get the dbus signal.
This also happens without me doing anything to the phone, but I haven't logged that or looked into it - I've just noticed at work, looking at the screen from time to time, that the signal strength bar goes from 80-85% to 0 and stays there for quite some time. I've also been forced to reboot to get a signal back. (Don't know what to try else but /etc/init.d/frameworkd restart).

Added an oscillating GTA02 to ​http://wiki.openmoko.org/wiki/GSM_network_registration#Results_table.
The unregistered reports do not always start at turn on, but once started they don't seem to stop.
I sent a mail to support "Debian GTA02 How to get python logs, messages etc?" and a samp le to Mickey L. Today I just turned it on and let it run for 10 hours. It unregistered about every 2 minutes..Running Debian.
Attachment:source:mdbus-s-l-080824-0333utc.gz
Sorry I don't follow how to make it pick up that file,
clare johnstone

same problem for me with all kinds of software (2007.2, 2008.8 and now Debian)
I tried 4 different 3G sim cards with the same result. (I seem to be unable to get any 2G cards) Here is an example session from mickeyterm:

my freerunner is gta02v6 (with gps capacitor already in place at sd socket when I got it) and still needs more than 10 minutes to get First Fix. (mine looks like ​http://wiki.openmoko.org/images/d/dd/Gta02_gps_10pf_rework_sop.pdf) -- I know this is GPS and not GMS, but I wonder if there is any relation between stuff like that just because the accepted solution does not seem to work for me.

IMO this is the most recent U-Boot version that should know about my Freerunner's version, right?

I noticed a better reconnect to gsm behavior on OM2007.2 right after installing and using gsm0710muxd. Before at some point (about after 10-15 minutes) phone never really registered again.

When calling the FR the line drops immediately -- the second time works most of the time (ie: wait until after registration of FR completes, call FR, FR will immediately get "CREG: 0" instead of the call, FR reconnects, call FR again -> bell rings...)

After having a connection (no matter if in- or outbound) it is stable most of the time. Just roaming between cells does not work reliably due to this issue.

I will gladly help by providing any information necessary for further debugging and can even offer root shell to the device if anyone is interested?! Will gladly try alpha & beta GSM firmware! :-) [sadly right now the phone is unusable for me... :-/]

same problem for me with all kinds of software (2007.2, 2008.8 and now Debian)
I tried 4 different 3G sim cards with the same result. (I seem to be unable to get any 2G cards) Here is an example session from mickeyterm:

about these error numbers, they define in some 3GPP spec. CMS is related to SMS error and CME error is related to general modem error. you can find their meanings from 3GPP website.
3GPP TS 27.007
9.2 Mobile Termination error result code +CME ERROR
3GPP TS 27.005
3.2.5 Message Service Failure Result Code +CMS ERROR

also, as i remembered in gsmd part for 2007.02, i get this error code, coz i have no voice mail number in my SIM card.

my freerunner is gta02v6 (with gps capacitor already in place at sd socket when I got it) and still needs more than 10 minutes to get First Fix. (mine looks like ​http://wiki.openmoko.org/images/d/dd/Gta02_gps_10pf_rework_sop.pdf) -- I know this is GPS and not GMS, but I wonder if there is any relation between stuff like that just because the accepted solution does not seem to work for me.

IMO this is the most recent U-Boot version that should know about my Freerunner's version, right?

Yes, you are using the latest GSM firmware and U-Boot version.

I noticed a better reconnect to gsm behavior on OM2007.2 right after installing and using gsm0710muxd. Before at some point (about after 10-15 minutes) phone never really registered again.

When calling the FR the line drops immediately -- the second time works most of the time (ie: wait until after registration of FR completes, call FR, FR will immediately get "CREG: 0" instead of the call, FR reconnects, call FR again -> bell rings...)

After having a connection (no matter if in- or outbound) it is stable most of the time. Just roaming between cells does not work reliably due to this issue.

I will gladly help by providing any information necessary for further debugging and can even offer root shell to the device if anyone is interested?! Will gladly try alpha & beta GSM firmware! :-) [sadly right now the phone is unusable for me... :-/]

about these error numbers, they define in some 3GPP spec. CMS is related to SMS error and CME error is related to general modem error. you can find their meanings from 3GPP website.
3GPP TS 27.007
9.2 Mobile Termination error result code +CME ERROR
3GPP TS 27.005
3.2.5 Message Service Failure Result Code +CMS ERROR

also, as i remembered in gsmd part for 2007.02, i get this error code, coz i have no voice mail number in my SIM card.

Thanx alot for clarifying this -- so this error message is completely irrelevant to this issue.

my freerunner is gta02v6 (with gps capacitor already in place at sd socket

Disabling the GSM from entering "deep sleep" will stop this oscillation:

AT%SLEEP=2

The problem is related to the GSM's deep sleep mode. It seems that in certain circumstances (I'm guessing on that, for me it is *all* circumstances), the GSM experiences some sort of trouble when it is permitted to enter deep sleep (which is the default mode, at least for any recent GSM firmwares). Whatever trouble it encounters results in it losing registration, regaining registration, entering this bad state after a time. This is consistent with the data gathered by myself and several other volunteers (thanks for your logs to those who helped!) -- the frequency of the oscillation or bouncing is very consistent and usually at a frequency of between 2 and 3 oscillations per minute.

The calypso is remarkably similar, at least from an AT command set point of view, to a device called the "Enabler II" by Enfora. Documentation for the latter is available on the Internet, unlike the calypso. The Enabler supports sleep modes, and while the calypso does not list the AT%SLEEP command, nor respond to query attempts using the AT%SLEEP? or AT%SLEEP=? commands, it turns out that it does honor the actual setting of sleep modes. See the Enfora document for details, and remember that we (the community) do not know how closely this really maps to the calypso.

Using the AT%SLEEP=n command, when n=3 or n=4 the calypso bounces.
When n=0, n=1, or n=2, the bouncing ceases. Changing the sleep value will result in immediate cessation or resumption of the bouncing behavior.

For currently unknown reasons not reproducible by hand, the Qtopia 4.3.2 firmware image (on a Neo with Moko 5 GSM firmware) displays this bouncing behavior until a call is either placed or received. At that point, the device behaves exactly as expected, until the GSM is reset. Exactly why this is the case is not known; either something "fixes" whatever is broken and allows the device to enter deep sleep, or something about this sequence disables deep sleep. If we can figure out which of the two it is, perhaps that might help in tracking the firmware issue down further.

As for what to do about this -- perhaps someone at Om can take a look at the firmware and see what affects the deep sleep modes.

In the meantime, I'm working on a patch for Qt Extended (aka Qtopia 4.4.1) that will detect the bouncing behavior and automatically change the sleep mode when necessary. This will permit those who can actually enter deep sleep to use that mode, while those who cannot will be no worse off in terms of power consumption (the bouncing calypso isn't in any kind of sleep mode) and will be better off in that they can at least use the GSM. Other solutions or workarounds are welcome! Patches and other information are on ​http://moko.mwester.net/brc.html

In the meantime, I'm working on a patch for Qt Extended (aka Qtopia 4.4.1) that will detect the bouncing behavior and automatically change the sleep mode when necessary. This will permit those who can actually enter deep sleep to use that mode, while those who cannot will be no worse off in terms of power consumption (the bouncing calypso isn't in any kind of sleep mode) and will be better off in that they can at least use the GSM. Other solutions or workarounds are welcome! Patches and other information are on ​http://moko.mwester.net/brc.html

That brc patches are also working in the Om2008 isn't it?
I've not tested them yet but the code should be very similar (if not the same).

I took a quick look at the commit -- please apply the "brc_qtopia_quickfix.patch" as well.

The problem is that I updated the Qt Extended (4.4.1) patch to include the %SLEEP fix, but I overlooked updating the patch for Qtopia 4.3 on the website. The code as committed only detects and logs when the oscillation begins. The extra patch adds the logic to disable "deep sleep" if we detect 3 "bounces" in succession.

Note that there are TODO items in the code; this needs to be revisited once we understand more about the problem. Areas that could use improvement would be adding logic to attempt to re-enable deep sleep at various times -- right now, a restart is required to do this. If we can identify some events that would be worth trying to re-enter deep sleep without disruption to the user, that would be good. Also, we may need to do this conditionally - I know that Moko7 firmware works well with this parameter but there is a report that Moko8 will not wake from GSM activity if the %SLEEP is issued. Perhaps Openmoko can help out by publishing a change log for the firmware releases, or by testing these changes on the various GSM firmwares for the community.

Note that there are TODO items in the code; this needs to be revisited once we understand more about the problem. Areas that could use improvement would be adding logic to attempt to re-enable deep sleep at various times -- right now, a restart is required to do this. If we can identify some events that would be worth trying to re-enter deep sleep without disruption to the user, that would be good. Also, we may need to do this conditionally - I know that Moko7 firmware works well with this parameter but there is a report that Moko8 will not wake from GSM activity if the %SLEEP is issued. Perhaps Openmoko can help out by publishing a change log for the firmware releases, or by testing these changes on the various GSM firmwares for the community.

Thank you! I will apply this patch soon. But for me, i can hardly verify this problem, coz i cannot reproduce it in Taiwan. I would ask Mickey's help for the GSM network provider.

It looks like I have the same problem even with the newest QT extended (4.4.2) and the latest om image 2008.12. I upgrade firmware from Moko8 to Moko10. Neo keeps registration only for several seconds. Due this the outgoing call is impossible and incoming ring only once (or ever). Then phone is unregistered and registered again. Tested with 4 T-mobile SIMs and with one brand new O2 SIM with the same behaviour. I tested it with libgsmd-tool and directly with AT commnads (output is attached).
Should be the problem caused by something else then deep sleep?
Can I run any other command to be the problem allocated?
Anyway it looks like the problem is HW related. The phone should be replaced with other one by local reseller, shouldn't?