Ticket #1024 (in_testing defect)

Opened 7 years ago

Last modified 5 years ago

gsm modem oscillating between registrated / not-registrated

Reported by: mickey@… Owned by: sean_chiang
Priority: high Milestone:
Component: GSM Modem Version: unspecified
Severity: normal Keywords:
Cc: buglog@…, tick@…, erin_yueh@…, sean_chiang@…, fredrik@…, john_lee@… Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: no PatchReviewResult:
Reproducible:

Description

This is without me sending any commands nor moving the station. This wasn't a
problem when I worked with gsmd some months ago.

Sun Nov 25 16:56:21 2007 <1> gsmd.c:144:gsmd_test_atcb() AT%CPI=3' returned OK'
Sun Nov 25 16:56:21 2007 <1> atcmd.c:233:atcmd_done() Clearing mlbuf
Sun Nov 25 16:56:23 2007 <1> atcmd.c:260:ml_parse() buf=`%CSQ: 12, 99, 1'(16)
Sun Nov 25 16:56:23 2007 <1> atcmd.c:329:ml_parse() extd reply `%CSQ: 12, 99,
1' to cmd `NONE', must be unsolicited
Sun Nov 25 16:56:23 2007 <1> vendor_ti.c:48:csq_parse() entering csq_parse
param=` 12, 99, 1'
Sun Nov 25 16:56:23 2007 <1> unsolicited.c:69:usock_evt_send() entering evt=6
Sun Nov 25 16:57:11 2007 <1> atcmd.c:260:ml_parse() buf=`+CREG: 0'(8)
Sun Nov 25 16:57:11 2007 <1> atcmd.c:329:ml_parse() extd reply `+CREG: 0' to cmd
`NONE', must be unsolicited
Sun Nov 25 16:57:11 2007 <1> unsolicited.c:69:usock_evt_send() entering evt=5
Sun Nov 25 16:57:11 2007 <1> atcmd.c:260:ml_parse() buf=`%CSQ: 99, 99, 0'(16)
Sun Nov 25 16:57:11 2007 <1> atcmd.c:329:ml_parse() extd reply `%CSQ: 99, 99,
0' to cmd `NONE', must be unsolicited
Sun Nov 25 16:57:11 2007 <1> vendor_ti.c:48:csq_parse() entering csq_parse
param=` 99, 99, 0'
Sun Nov 25 16:57:11 2007 <1> unsolicited.c:69:usock_evt_send() entering evt=6
Sun Nov 25 16:57:11 2007 <1> atcmd.c:260:ml_parse() buf=`+CREG: 1,"000F","0343"'(22)
Sun Nov 25 16:57:11 2007 <1> atcmd.c:329:ml_parse() extd reply `+CREG:
1,"000F","0343"' to cmd `NONE', must be unsolicited
Sun Nov 25 16:57:11 2007 <1> unsolicited.c:69:usock_evt_send() entering evt=5
Sun Nov 25 16:57:14 2007 <1> atcmd.c:260:ml_parse() buf=`%CSQ: 15, 99, 1'(16)
Sun Nov 25 16:57:14 2007 <1> atcmd.c:329:ml_parse() extd reply `%CSQ: 15, 99,
1' to cmd `NONE', must be unsolicited
Sun Nov 25 16:57:14 2007 <1> vendor_ti.c:48:csq_parse() entering csq_parse
param=` 15, 99, 1'
Sun Nov 25 16:57:14 2007 <1> unsolicited.c:69:usock_evt_send() entering evt=6
Sun Nov 25 16:57:44 2007 <1> atcmd.c:260:ml_parse() buf=`%CSQ: 99, 99, 0'(16)
Sun Nov 25 16:57:44 2007 <1> atcmd.c:329:ml_parse() extd reply `%CSQ: 99, 99,
0' to cmd `NONE', must be unsolicited
Sun Nov 25 16:57:44 2007 <1> vendor_ti.c:48:csq_parse() entering csq_parse
param=` 99, 99, 0'
Sun Nov 25 16:57:44 2007 <1> unsolicited.c:69:usock_evt_send() entering evt=6
Sun Nov 25 16:57:44 2007 <1> atcmd.c:260:ml_parse() buf=`+CREG: 0'(8)
Sun Nov 25 16:57:44 2007 <1> atcmd.c:329:ml_parse() extd reply `+CREG: 0' to cmd
`NONE', must be unsolicited
Sun Nov 25 16:57:44 2007 <1> unsolicited.c:69:usock_evt_send() entering evt=5
Sun Nov 25 16:57:46 2007 <1> atcmd.c:260:ml_parse() buf=`+CREG: 1,"000F","0343"'(22)
Sun Nov 25 16:57:46 2007 <1> atcmd.c:329:ml_parse() extd reply `+CREG:
1,"000F","0343"' to cmd `NONE', must be unsolicited
Sun Nov 25 16:57:46 2007 <1> unsolicited.c:69:usock_evt_send() entering evt=5
Sun Nov 25 16:57:48 2007 <1> atcmd.c:260:ml_parse() buf=`%CSQ: 15, 99, 1'(16)
Sun Nov 25 16:57:48 2007 <1> atcmd.c:329:ml_parse() extd reply `%CSQ: 15, 99,
1' to cmd `NONE', must be unsolicited
Sun Nov 25 16:57:48 2007 <1> vendor_ti.c:48:csq_parse() entering csq_parse
param=` 15, 99, 1'
Sun Nov 25 16:57:48 2007 <1> unsolicited.c:69:usock_evt_send() entering evt=6
Sun Nov 25 16:58:25 2007 <1> atcmd.c:260:ml_parse() buf=`%CSQ: 99, 99, 0'(16)
Sun Nov 25 16:58:25 2007 <1> atcmd.c:329:ml_parse() extd reply `%CSQ: 99, 99,
0' to cmd `NONE', must be unsolicited
Sun Nov 25 16:58:25 2007 <1> vendor_ti.c:48:csq_parse() entering csq_parse
param=` 99, 99, 0'
Sun Nov 25 16:58:25 2007 <1> unsolicited.c:69:usock_evt_send() entering evt=6
Sun Nov 25 16:58:25 2007 <1> atcmd.c:260:ml_parse() buf=`+CREG: 0'(8)
Sun Nov 25 16:58:25 2007 <1> atcmd.c:329:ml_parse() extd reply `+CREG: 0' to cmd
`NONE', must be unsolicited
Sun Nov 25 16:58:25 2007 <1> unsolicited.c:69:usock_evt_send() entering evt=5
Sun Nov 25 16:58:28 2007 <1> atcmd.c:260:ml_parse() buf=`+CREG: 1,"000F","0343"'(22)
Sun Nov 25 16:58:28 2007 <1> atcmd.c:329:ml_parse() extd reply `+CREG:
1,"000F","0343"' to cmd `NONE', must be unsolicited
Sun Nov 25 16:58:28 2007 <1> unsolicited.c:69:usock_evt_send() entering evt=5

Attachments

testGSM (15 bytes) - added by erin_yueh@… 7 years ago.
test gsm network registration
gsm.log (283.2 KB) - added by marcus.bauer@… 7 years ago.
gsm.log from a constantly re-registering phone as to Erin's mail
gsm.2.log (153.1 KB) - added by ahvenas@… 7 years ago.
GSM log - Henrik Pihl
gsm.3.log (125.8 KB) - added by d.wollersheim@… 7 years ago.
gsm log file - Dennis Wollersheim
logread.txt (63.9 KB) - added by Yorick 6 years ago.
logread 2007.2
brc_qtopia_quickfix.patch (2.3 KB) - added by mwester@… 6 years ago.
Additional code to actually issue the AT%SLEEP=2 command to GSM
libgsmd-tool.output (869 bytes) - added by pb0 6 years ago.
at_commands.output (608 bytes) - added by pb0 6 years ago.

Change History

comment:1 Changed 7 years ago by mickey@…

Corresponding libgsmd-log:

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

AT+COPS
STR=`AT+COPS'
RSTR=`'
EVENT: Netreg registered (home network) LocationAreaCode? = 0x000F CellID = 0x0343
RSTR=`OK'
EVENT: Signal Quality: 99
EVENT: Netreg not searching for network
EVENT: Netreg registered (home network) LocationAreaCode? = 0x000F CellID = 0x0343
EVENT: Signal Quality: 16
EVENT: Signal Quality: 99
EVENT: Netreg not searching for network
EVENT: Netreg registered (home network) LocationAreaCode? = 0x000F CellID = 0x0343
EVENT: Signal Quality: 16

comment:2 Changed 7 years ago by mickey@…

Another Neo at the same place with a different SIM shows:

EVENT: Netreg searching for network
EVENT: Netreg registered (home network) LocationAreaCode? = 0x000F CellID = 0x0343
EVENT: Signal Quality: 11
EVENT: Signal Quality: 6
EVENT: Signal Quality: 12
EVENT: Signal Quality: 9
EVENT: Signal Quality: 13
EVENT: Netreg registered (home network) LocationAreaCode? = 0x000F CellID = 0x5B4F
EVENT: Signal Quality: 6
EVENT: Netreg registered (home network) LocationAreaCode? = 0x000F CellID = 0x0343
EVENT: Signal Quality: 14
EVENT: Signal Quality: 8
EVENT: Signal Quality: 11
EVENT: Netreg registered (home network) LocationAreaCode? = 0x000F CellID = 0x237D
EVENT: Signal Quality: 3
EVENT: Netreg registered (home network) LocationAreaCode? = 0x000F CellID = 0x032F
EVENT: Signal Quality: 12
EVENT: Netreg registered (home network) LocationAreaCode? = 0x000F CellID = 0x0343

comment:3 Changed 7 years ago by tick@…

  • Cc tick@… added

comment:4 Changed 7 years ago by tick@…

  • Owner changed from laforge@… to tick@…

comment:5 Changed 7 years ago by tick@…

  • Status changed from new to assigned

comment:6 Changed 7 years ago by tick@…

  • Cc sean_chiang@… added

comment:7 Changed 7 years ago by tick@…

  • Status changed from assigned to closed
  • Resolution set to later

This shall be a firmware issue.
Leave this later.
Reopen it when we are ready to solve this one.

comment:8 Changed 7 years ago by mickey@…

  • Status changed from closed to reopened
  • Resolution later deleted
  • Severity changed from normal to blocker

Reopening this now and bumping priority -- before selling FreeRunner? devices we
need to find the root of this problem.

comment:9 Changed 7 years ago by sean_chiang@…

  • Owner changed from tick@… to sean_chiang@…
  • Status changed from reopened to new
  • Cc erin_yueh@… added

comment:10 Changed 7 years ago by sean_chiang@…

  • Status changed from new to assigned

Changed 7 years ago by erin_yueh@…

test gsm network registration

comment:11 Changed 7 years ago by erin_yueh@…

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

  1. confirm the gsm firmware version: AT+CGMR

root@fic-gta01:/$ libgsmd-tool -m atcmd

  1. use an attachment file 'testGSM' command list to verify GSMD

root@fic-gta01:/$ libgsmd-tool -m shell < testGSM

  1. send us your gsm log , the file is located at '/tmp/gsm.log' in NEO

comment:12 Changed 7 years ago by alphaone@…

I don't see this oscillating behaviour with my simyo card.

root@fic-gta02:~# 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

EVENT: Netreg registered (home network) LocationAreaCode? = 0x0020 CellID = 0xDACC
EVENT: Netreg registered (home network) LocationAreaCode? = 0x0020 CellID = 0x00CA
EVENT: Signal Quality: 27
EVENT: Netreg registered (home network) LocationAreaCode? = 0x0020 CellID = 0xDACC
EVENT: Signal Quality: 24
EVENT: Netreg registered (home network) LocationAreaCode? = 0x0020 CellID = 0xDAB8
EVENT: Signal Quality: 26
EVENT: Signal Quality: 22
EVENT: Netreg registered (home network) LocationAreaCode? = 0x0020 CellID = 0xDACC
EVENT: Signal Quality: 17
EVENT: Netreg registered (home network) LocationAreaCode? = 0x0020 CellID = 0xDAB8
EVENT: Signal Quality: 9
EVENT: Netreg registered (home network) LocationAreaCode? = 0x0020 CellID = 0x00CA
EVENT: Signal Quality: 28

comment:13 Changed 7 years ago by graeme@…

I think this is the bug I am seeing t-mobile UK

comment:14 Changed 7 years ago by graeme@…

Latest news,

Sean Chiang upgraded my firmware to moko7 and set the IMEI to one borrowed from
an old broken Nokia I own. Phone still oscillated between Registering and on the
network.

Same SIM in a GTA01 phone does not demonstrate this behaviour.

comment:15 Changed 7 years ago by graeme@…

I have tried a different t-mobile UK SIM and it doesn't suffer the problem. The
metal work on the SIM is a different shape which normally denotes a different
manufacturer.

I shall bring both to Taiwan with me as well as phone.

comment:16 Changed 7 years ago by graeme@…

No I was wrong in last comment, it has just started oscillating after 10 minutes.

comment:17 Changed 7 years ago by erin_yueh@…

so you have two T-Mobile SIM cards and have the same network registration
problem in UK, right?! Looking forward to seeing you in Taipei soon! -- erin

Changed 7 years ago by marcus.bauer@…

gsm.log from a constantly re-registering phone as to Erin's mail

comment:18 Changed 7 years ago by marcus.bauer@…

I'll add some lines form libgsmd output here, showing the events before, during
and after reregistering.

EVENT: Netreg registered (home network) LocationAreaCode? = 0x7204 CellID = 0xA113
EVENT: Signal Quality: 20
EVENT: Netreg registered (home network) LocationAreaCode? = 0x7204 CellID = 0x3B49
EVENT: Netreg registered (home network) LocationAreaCode? = 0x7204 CellID = 0xEEF4
EVENT: Signal Quality: 99
EVENT: Netreg not searching for network
EVENT: Netreg searching for network
EVENT: Netreg registered (home network) LocationAreaCode? = 0x7204 CellID = 0xBD26
EVENT: Signal Quality: 15
EVENT: Netreg registered (home network) LocationAreaCode? = 0x7204 CellID = 0xEEF4
EVENT: Signal Quality: 22
cme error: 22
EVENT: Signal Quality: 99
EVENT: Netreg not searching for network
EVENT: Netreg searching for network
EVENT: Netreg registered (home network) LocationAreaCode? = 0x7204 CellID = 0xBD26
EVENT: Signal Quality: 15
EVENT: Netreg registered (home network) LocationAreaCode? = 0x7204 CellID = 0xEEF4
EVENT: Signal Quality: 22

Changed 7 years ago by ahvenas@…

GSM log - Henrik Pihl

Changed 7 years ago by d.wollersheim@…

gsm log file - Dennis Wollersheim

comment:19 Changed 7 years ago by mickey@…

I don't want to annoy, but do we have a status update here?

comment:20 Changed 7 years ago by sean_chiang@…

My observation for this so far:
graeme's neo + T-mobile pre-paid sim --> 18 times re-camping to network in 10
minutes
my neo's + T-mobile pre-paid sim --> 17 times re-camping to network in 15 hours

These two neos have the same kernel, uboot, rootfs, gsm firmware, IMEI, and
tested at the same place(Taipei).

comment:21 Changed 7 years ago by zecke@…

I have gta02 #48 and it loses registration more than once a minute:

Using minicom:
AT+CPIN="MYPIN"
AT+CFUN=1
AT+CREG=2
AT+COPS=0

=>
+CREG: 1,"011B","5477"

%CSQ: 18, 99, 2

%CSQ: 99, 99, 0

+CREG: 0

+CREG: 1,"011B","5477"
...

comment:22 Changed 7 years ago by zecke@…

I have tested this with the newly arrived #73. And in contrast to #48 I have not
lost the registration yet.

I think both devices have moko7 as GSM firmware.

comment:23 Changed 7 years ago by sean_chiang@…

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.

comment:24 Changed 7 years ago by sean_chiang@…

TI@tw also said, the cell reselection is OK and only "searching for network" is
abnormal.

comment:25 Changed 7 years ago by mickey@…

Thanks for the update.

Yes, I would expect the device to frequently reselect based on cell tower signal
strength. Automatically dropping registration every couple of seconds is what
worries me.

comment:26 Changed 7 years ago by sean_chiang@…

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.

comment:27 Changed 6 years ago by mickey@…

gsm_ac_gp_fd_pu_em_cph_ds_vc_cal35_ri_36_amd8_ts0-moko9-beta1 is _not_ fixing
the recamping issue for me. Still forced unregistering (+CREG:0) and
reregistering every 5 seconds on E-Plus (DCS 1800).

comment:28 Changed 6 years ago by mickey@…

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.

The ones that do emit the bug are:

GTA01v4 (taipei)
GTA02v5, #30 (taipei)
GTA01v5, #60 (taipei)

The one that does not emit the bug is:

GTA01v4 (suzhou, production model)

comment:29 Changed 6 years ago by mickey@…

Guys, this is a Heisenbug (http://en.wikipedia.org/wiki/Heisenbug).

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.

Until then this is my last comment on this bug.

comment:30 Changed 6 years ago by shoragan

I've received mickey's GTA02v5 (#30) which showed this problem with my simyo (E-Plus) card (+CREG: 0 about every minute).
Updating the GSM firmware from moko6 to moko9-beta1 made no difference.

comment:31 Changed 6 years ago by roh

  • Owner changed from sean_chiang@… to sean_chiang

comment:32 Changed 6 years ago by fwendt

  • Cc fredrik@… added

comment:33 Changed 6 years ago by fwendt

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

comment:34 Changed 6 years ago by claregj

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

comment:35 Changed 6 years ago by Yorick

My 2007.2 is fully upgraded and my gsm re-registers ever few minutes
attached is my logread.

Changed 6 years ago by Yorick

logread 2007.2

comment:36 follow-up: ↓ 37 Changed 6 years ago by akriegisch

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:

AT+CFUN=1
AT+CREG=2
AT+COPS=0
OK
=> (removed empty lines)
+CREG: 2
+CREG: 1,"00B5","4B72"
+CREG: 0
+CREG: 1,"00B5","7320"
+CREG: 0
+CREG: 1,"00B5","4B72"
+CREG: 0
+CREG: 1,"00B5","4B72"
+CREG: 0

have about 0.5 to 2 "CREG: 0" per minute ad infinitum)

several other strange things I noticed:

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

*

 AT+CGMR
 +CGMR: "HW: GTA02BV5, GSM: gsm_ac_gp_fd_pu_em_cph_ds_vc_cal35_ri_36_amd8_ts0-Moko8"

list my FR as GTA02BV5 whereas /proc/cpuinfo gives:

  Hardware        : GTA02
  Revision        : 0360

and using boot prompt on serial console says GAT02v6:

    Connected.
    In:    usbtty
    Out:   usbtty
    Err:   usbtty
    Unrecognized hardware revision 0x305. Defaulting to GTA02v6.
    PCB rev: 0x305
    Power: 0mA
    GTA02v6 # version

    U-Boot 1.3.2+gitr650149a53dbdd48bf6dfef90930c8ab182adb512 (Sep  3 2008 - 10:20:46)

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... :-/]

comment:37 in reply to: ↑ 36 ; follow-up: ↓ 39 Changed 6 years ago by erin_yueh

Replying to akriegisch:

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:

AT+CFUN=1
AT+CREG=2
AT+COPS=0
OK
=> (removed empty lines)
+CREG: 2
+CREG: 1,"00B5","4B72"
+CREG: 0
+CREG: 1,"00B5","7320"
+CREG: 0
+CREG: 1,"00B5","4B72"
+CREG: 0
+CREG: 1,"00B5","4B72"
+CREG: 0

have about 0.5 to 2 "CREG: 0" per minute ad infinitum)

several other strange things I noticed:

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.

*

 AT+CGMR
 +CGMR: "HW: GTA02BV5, GSM: gsm_ac_gp_fd_pu_em_cph_ds_vc_cal35_ri_36_amd8_ts0-Moko8"

list my FR as GTA02BV5 whereas /proc/cpuinfo gives:

  Hardware        : GTA02
  Revision        : 0360

and using boot prompt on serial console says GAT02v6:

    Connected.
    In:    usbtty
    Out:   usbtty
    Err:   usbtty
    Unrecognized hardware revision 0x305. Defaulting to GTA02v6.
    PCB rev: 0x305
    Power: 0mA
    GTA02v6 # version

    U-Boot 1.3.2+gitr650149a53dbdd48bf6dfef90930c8ab182adb512 (Sep  3 2008 - 10:20:46)

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... :-/]

comment:38 Changed 6 years ago by martintsw

I'm also getting this symptom with various distributions and SIMs... and would be happy to provide any traces/debug info as required. regards, Martin

comment:39 in reply to: ↑ 37 ; follow-up: ↓ 40 Changed 6 years ago by akriegisch

Replying to erin_yueh:

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

[SNIP]
and using boot prompt on serial console says GAT02v6:

    Connected.
    In:    usbtty
    Out:   usbtty
    Err:   usbtty
    Unrecognized hardware revision 0x305. Defaulting to GTA02v6.
    PCB rev: 0x305
    Power: 0mA
    GTA02v6 # version

    U-Boot 1.3.2+gitr650149a53dbdd48bf6dfef90930c8ab182adb512 (Sep  3 2008 - 10:20:46)

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.

Then I wonder why it says

  Unrecognized hardware revision 0x305. Defaulting to GTA02v6.

I thought there might be something wrong with my Freerunner just because I got the latest Firmware for Freerunners and it says "Unrecognized hardware"...

Thanks alot for your help!

comment:40 in reply to: ↑ 39 Changed 6 years ago by erin_yueh

Replying to akriegisch:

Replying to erin_yueh:

[...]

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

[SNIP]
and using boot prompt on serial console says GAT02v6:

    Connected.
    In:    usbtty
    Out:   usbtty
    Err:   usbtty
    Unrecognized hardware revision 0x305. Defaulting to GTA02v6.
    PCB rev: 0x305
    Power: 0mA
    GTA02v6 # version

    U-Boot 1.3.2+gitr650149a53dbdd48bf6dfef90930c8ab182adb512 (Sep  3 2008 - 10:20:46)

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.

Then I wonder why it says

  Unrecognized hardware revision 0x305. Defaulting to GTA02v6.

I thought there might be something wrong with my Freerunner just because I got the latest Firmware for Freerunners and it says "Unrecognized hardware"...

Thanks alot for your help!

sorry! i don't know either.... below texts are from my FR:
Connected.
In: usbtty
Out: usbtty
Err: usbtty
PCB rev: 0x000
Power: 0mA
GTA02v5 # version
U-Boot 1.3.2-moko12 (Aug 26 2008 - 08:24:58)

perhaps you can post your question to community or support mailing list?

comment:41 Changed 6 years ago by fwendt

I tried to attach logs but they are too huge (more than 262144 bytes).

< mwester> ceda: it's definitely the same problem

I did two runs with different carriers. The signal strengths are different although I'm at the same location which could mean that the two runs uses two different antenna towers.

Logs are at http://wendt.se/software/openmoko/ticket-1024/frameworkd-080921.log and http://wendt.se/software/openmoko/ticket-1024/frameworkd-080921-second-carrier-telia.log

comment:42 Changed 6 years ago by Treviño

Could the mwesters brc fix solve (workaround) the issue also in om2008?
I guess that the code is quite the same...

comment:43 follow-up: ↓ 44 Changed 6 years ago by mwester@…

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

comment:44 in reply to: ↑ 43 Changed 6 years ago by Treviño

Replying to mwester@dls.net:

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

comment:45 Changed 6 years ago by mickey

Amazing find, mwester! What makes me really sad is that the %SLEEP is not only not present in AT+CLAC but also hidden from the AT interpreter source code that Openmoko got from TI. http://git.freesmartphone.org/?p=framework.git;a=commitdiff;h=cb428650f456160992f9a0e8d57bf5d93dcdba55 is an attempt to take your findings into account. While this increases power consumption, it will make a significant difference to all people who want to use their Neo as a day-to-day phone. Thanks a million!

Changed 6 years ago by mwester@…

Additional code to actually issue the AT%SLEEP=2 command to GSM

comment:47 in reply to: ↑ 46 ; follow-up: ↓ 48 Changed 6 years ago by mwester@…

Replying to erin_yueh:

patch is committed to qtopia image
http://git.openmoko.org/?p=qtopia.git;a=commitdiff;h=115a733771d257565c0ec03b485d3ba63c2cec61;hp=22c3c1f28631c1091a83fb72bf0a9c9f4b008246
thanks a lot!

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.

comment:48 in reply to: ↑ 47 Changed 6 years ago by erin_yueh

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.

comment:49 Changed 6 years ago by mickey

Did some tests with moko8 and an MP device here. Had no problems using %SLEEP=2, it stopped the recamping and it also woke up fine from suspend.

"there is a report that Moko8 will not wake from GSM activity if the %SLEEP is issued".

Can you give more details on that? Can you reproduce that? (Note that we had some resume problems in the stable kernel for a while)

comment:51 Changed 6 years ago by john_lee

  • Status changed from assigned to in_testing
  • HasPatchForReview unset

Should be in testing repo now.

comment:52 Changed 6 years ago by john_lee

  • Cc john_lee@… added

comment:53 Changed 6 years ago by think-free

I have already this bug using frameworkd on debian :
Gsm unregister from network very often ...

frameworkd logs :

2008.12.29 17:55:29 ogsmd.objects INFO org.freesmartphone.GSM.Network.SignalStrength?: 0
2008.12.29 17:55:32 ogsmd INFO This TI Calypso device suffers from the recamping bug. Turning off sleep mode to recover.
2008.12.29 17:55:32 ogsmd WARNING Recamping bug occured, but TI Calypso is still out of deep sleep mode.
2008.12.29 17:55:35 ogsmd.objects INFO org.freesmartphone.GSM.Network.SignalStrength?: 86
2008.12.29 17:56:00 ogsmd INFO <UnsolicitedResponseChannel? via /dev/pts/6>: unhandled unsolicited data incoming: '+CGEV: NW DETACH'
2008.12.29 17:56:00 ogsmd INFO <UnsolicitedResponseChannel? via /dev/pts/6>: unhandled unsolicited data incoming: '%CGEV: NW DETACH'
2008.12.29 17:56:01 ogsmd.objects INFO org.freesmartphone.GSM.Network.SignalStrength?: 0

Changed 6 years ago by pb0

Changed 6 years ago by pb0

comment:54 Changed 6 years ago by pb0

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?

comment:55 Changed 6 years ago by mickey

  • Component changed from gsmd to GSM Modem
  • Severity changed from blocker to normal

#1024 will not be fixed by a hardware exchange. All current distributions have a satisfying workaround, the real issue is still undergoing research wrt. GSM firmware.

comment:56 Changed 5 years ago by PaulFertser

Dieter Spaar finally found a way to fix recamping.

It's a hardware mod, basically increasing capacitance of C1009 (either
by soldering another one in parallel or desoldering C1009 and putting
a shiny new 22uF 0805 low-ESR cap on its place).

Great thanks to everybody who worked hard to make this happen and who
verified the solution!

Details can be found at
http://lists.openmoko.org/pipermail/hardware/2009-May/001192.html ,
results of suspend time (143hrs) at
http://totalueberwachung.de/blog/2009/06/03/freerunner-deep-sleep-standby-time .

Note: See TracTickets for help on using tickets.