But I'm not sure it really works: the firmware seems to freeze (not responding to the power button anymore) and the last output of
'mobile'
is:
<0003> gsm322.c:257 Sync to ARFCN=104 rxlev=-65 (No sysinfo yet, ccch
mode NONE)
hi nicolas,
be sure to use the branch of sylvain: sylvain/testing (i think you did)
the process freezes after many sync requests due to a memory leak that has not been fixed. without the fix, the full network search process should run several times without freeze. but in your case it looks like freezing every first sync request.
can you watch the display of your c123? see if it gets a little darker at the point it freezes (when trying to sync).
regards,
andreas
Good morning,
First, thanks to both of you for your replies!
Sylvain Munaut 246tnt@gmail.com writes:
-65 dBm is a pretty strong signal actually :)
Ooops :)
Try to force the ARFCN to a known good cell (that you get from a phone with netmonitor) using the stick option.
That's the hard part, I don't have such feature on any phones I own :-( I thought I could find one at work today but... no.
"Andreas.Eversberg" Andreas.Eversberg@versatel.de writes:
<0003> gsm322.c:257 Sync to ARFCN=104 rxlev=-65 (No sysinfo yet, ccch mode NONE)
be sure to use the branch of sylvain: sylvain/testing (i think you did)
I was using master, I changed that now. I'm currently at 7e25c8bd
the process freezes after many sync requests due to a memory leak that has not been fixed. without the fix, the full network search process should run several times without freeze. but in your case it looks like freezing every first sync request.
In fact, the whole problem disappeared when I compiled the project with the gnuarm.com toolchain instead of mine (built with crosstool-ng[1]).
So now, 'mobile' application seems to work but I still have an issue with layer23: after a few seconds, it keeps dropping frames (like 90% of packet loss):
,---- | % host/layer23/src/misc/layer23 -a 544 -i 1.2.3.4 | .. | <000a> lapdm.c:1529 fmt=B | <000a> lapdm.c:843 UI received | <000a> lapdm.c:875 length=0 (discarding) | <000b> l1ctl.c:155 SDCCH/8(0) on TS0 (0064/20/32) -102 dBm: 00 01 03 03 2d 06 1e e0 4c 02 f8 10 65 00 54 ff 2b 2b 2b 2b 2b 2b 2b | <000a> lapdm.c:1520 fmt=B4 | <000a> lapdm.c:843 UI received | <0000> rslms.c:66 RSLms UNIT DATA IND chan_nr=0x40 link_id=0x40 | <000b> l1ctl.c:155 SDCCH/8(0) on TS0 (0064/13/00) -105 dBm: 03 42 9d 3a 17 8e ba 17 fd a5 a3 87 35 56 2b 0f 09 a4 a3 c7 87 fc 98 | <000b> l1ctl.c:210 Dropping frame with 86 bit errors | <000b> l1ctl.c:155 SDCCH/8(0) on TS0 (0064/12/00) -101 dBm: e6 2c f6 80 de 37 0c f9 29 10 7f e3 ed df 86 e5 2d 58 63 85 d7 5f 5c | <000b> l1ctl.c:210 Dropping frame with 104 bit errors | <000b> l1ctl.c:155 SDCCH/8(0) on TS0 (0064/18/32) -98 dBm: 1b 6e 07 1c 36 18 e1 40 c7 b6 49 d3 4a ea 58 63 6a 02 34 fd 0a 87 4f | <000b> l1ctl.c:210 Dropping frame with 77 bit errors | <000b> l1ctl.c:155 SDCCH/8(0) on TS0 (0064/11/00) -95 dBm: 96 85 20 62 92 7e 4a e4 47 ec 17 f7 bb 82 0d 78 10 a9 90 81 db f0 aa | <000b> l1ctl.c:210 Dropping frame with 63 bit errors `----
Full layer23 dump available at http://pastebin.org/167286 The osmocom dump is available at http://pastebin.org/167278
Could it be a bad serial cable?
Is there anything I can do to debug further?
Thanks,
Footnotes: [1] http://ymorin.is-a-geek.org/projects/crosstool
baseband-devel@lists.osmocom.org