Hi,
I could not resist buying a C116 for 15 euro, so I compiled osmocombb
and connected a 3.3V serial cable.
Of course the C116 was not in the supported list, but I was hoping it
would work as it seems that it is very similar to the C115.
Here is my load attempt: (used -m c123 ) but there's no loading of the image.
I am not using TX mode, also I don't have a SIM installed.
Anything I can try to get it working?
./osmocon -p /dev/ttyS0 -m c123xor
../../target/firmware/board/compal_e88/loader.compalram.bin
got 1 bytes from modem, data looks like: 00 .
got 2 bytes from modem, data looks like: 00 81 ..
got 4 bytes from modem, data looks like: 1b f6 02 00 ....
got 1 bytes from modem, data looks like: 41 A
got 1 bytes from modem, data looks like: 01 .
got 1 bytes from modem, data looks like: 40 @
Received PROMPT1 from phone, responding with CMD
read_file(../../target/firmware/board/compal_e88/loader.compalram.bin):
file_size=16788, hdr_len=4, dnload_le n=16795
got 1 bytes from modem, data looks like: 66 f
got 1 bytes from modem, data looks like: 74 t
got 1 bytes from modem, data looks like: 6d m
got 1 bytes from modem, data looks like: 74 t
got 1 bytes from modem, data looks like: 6f o
got 1 bytes from modem, data looks like: 6f o
got 1 bytes from modem, data looks like: 6c l
Received FTMTOOL from phone, ramloader has aborted
got 1 bytes from modem, data looks like: 65 e
got 1 bytes from modem, data looks like: 72 r
got 1 bytes from modem, data looks like: 72 r
got 1 bytes from modem, data looks like: 6f o
got 1 bytes from modem, data looks like: 72 r
got 1 bytes from modem, data looks like: 00 .
got 1 bytes from modem, data looks like: 1b .
got 1 bytes from modem, data looks like: 66 f
got 1 bytes from modem, data looks like: 6d m
got 1 bytes from modem, data looks like: 74 t
got 1 bytes from modem, data looks like: 6f o
Regards,
Henk
Hello
I'm having a problem in the start mobile application
~/osmocom-bb$ cd src/host/layer23/src/mobile
~/osmocom-bb/src/host/layer23/src/mobile$ ./mobile
Copyright (C) 2008-2010 ...
Contributions by ...
License GPLv2+: GNU GPL version 2 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Failed to parse the config file: '/etc/osmocom/osmocom.cfg'
Please check or create config file using: 'touch /etc/osmocom/osmocom.cfg'
~/osmocom-bb/src/host/layer23/src/mobile$
Please help me as soon as
--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Help-me-I-have-a-difficult-probl…
Sent from the baseband-devel mailing list archive at Nabble.com.
Hi Folks, just wanted to know if anyone actually tried the Motorola C115
with OsmocomBB ?
It appears to be difficult to source compatible phones in the UK but I did
manage to get this C115 Model and wanted confirmation before hacking away at
it only to find it is not going to play.
The wiki states :
Motorola C115/C117
It seems to be 99.9% identical with the
MotorolaC123<http://bb.osmocom.org/trac/wiki/MotorolaC123>/C121/C122
series.
So far, all our software (written for the
MotorolaC123<http://bb.osmocom.org/trac/wiki/MotorolaC123>)
is working on the C115/C117, too.
The PCB is marked E87, i.e. one number less than the
MotorolaC123<http://bb.osmocom.org/trac/wiki/MotorolaC123>(E88).
Any feedback would be very appreciated from anyone who has had success with
this particular phone from the Users side.
Thanks
Raz
I've been going over Sylvain's report on removing the RX filters,
http://www.246tnt.com/gsm/rx_filter.html, and I had some slight
differences on the c139 that I'm hoping someone can help me with.
Similar to Sylvain's experience, the schematic doesn't match reality.
Just as Sylvain describes, the signal from the balanced output appears
to be going through inductors rather than capacitors and there isn't a
bridging inductor.
However on my c139, the unbalanced input is missing the inductor to
ground on the EGSM path and is missing the capacitor to ground on the
DCS path. (Sylvain had a capacitor to ground on DCS where the schematic
has an inductor to ground.)
You can find a picture of what I'm looking at here:
http://thre.at/c139/c139rxfilters.jpg . I've placed the c139 schematics
in that directory as well, http://thre.at/c139 .
My guess is that the filters in the schematics had a different
unbalanced impedance than the ones they ended up placing on the c139.
But I'm not an EE, and that is just a guess.
I can't read the markings on the filters I have, so I can't check the
unbalanced input from a data sheet. I also don't have a way to measure
the components that are there now so I can't try and compute the value.
My question is, does this matter? That is, should I use the same balun
that Sylvain chose or should I find one with a different unbalanced
impedance? Alternatively, should I use the same baluns and just install
an inductor (or capacitor on DCS) to ground so that it matches Sylvain's
c123?
Any ideas?
(As an aside, the baluns that Sylvain chose aren't perfect for the US
frequency range, but they should work okay.)
Hello,
I'd like to propose a 3-way link swap with your website http://bb.osmocom.org, where you receive 2 links in exchange
for one of yours.
3-way linking is a very effective link building strategy. Since you're getting the links from third party websites, they appear
totally natural to search engine algorithms. Such inbound links help your website rank higher in Google and other search
engines.
Our partner sites that link to your site are at least 3 years old with a minimum pagerank of PR3.
Visit http://twinlinks.net to submit your website.
Thanks,
Rebecca Wilson
Founder & CEO, TwinLinks
Dear folks,
I recently played with osmocomBB and wanted to try out the
cell_log and gsmmap feature.
Therefore I tried to rebuild osmocomBB (sylvains testing tree) with gpsd
2.96 installed on archlinux kernel 2.6.38.
If there is more information needed, just tell me!
Error while "$make":
Making all in src
make[2]: Entering directory
`/home/temal/dev/pkg/osmotemp/osmocom-bb/src/host/layer23/src'
Making all in common
make[3]: Entering directory
`/home/temal/dev/pkg/osmotemp/osmocom-bb/src/host/layer23/src/common'
CC l1ctl.o
CC l1l2_interface.o
CC sap_interface.o
CC lapdm.o
CC logging.o
CC networks.o
CC sim.o
sim.c: In function ‘gsm_sim_reply’:
sim.c:146:11: warning: variable ‘payload’ set but not used
[-Wunused-but-set-variable]
CC sysinfo.o
CC gps.o
gps.c: In function ‘osmo_gpsd_cb’:
gps.c:73:2: error: too few arguments to function ‘gps_waiting’
/usr/include/gps.h:1435:13: note: declared here
gps.c:77:2: warning: implicit declaration of function ‘gps_poll’
[-Wimplicit-function-declaration]
gps.c: In function ‘osmo_gpsd_open’:
gps.c:114:2: error: too few arguments to function ‘gps_open’
/usr/include/gps.h:1430:12: note: declared here
make[3]: *** [gps.o] Error 1
make[3]: Leaving directory
`/home/temal/dev/pkg/osmotemp/osmocom-bb/src/host/layer23/src/common'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/home/temal/dev/pkg/osmotemp/osmocom-bb/src/host/layer23/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/home/temal/dev/pkg/osmotemp/osmocom-bb/src/host/layer23'
make: *** [host/layer23/layer23] Error 2
Hi!
As more and more code is moving into libraries (like I just did with the
LAPDm code, and like pablo is working on with libosmo-abis), we needed a
solution how to allocate and use the LOGP subsystem constants like DRSL,
DRR, ... from within libraries.
The existing logging code wasn't really prepared for that. I've now
come um with a hack to extend it while preserving compatibility to
applications:
* we use negative numbers starting from -1 for library-internal
subsystems
* those numbers get converted to a positive index into the various
arrays at run-time. So -1 ends up one entry higher in the array
than the last application-providede log category/subsystem.
As part of this change, the array allocations are now dynamic, i.e there
is no maximum limit for the number of log categories that an application
can register with the core.
Only for libraries (even outside libosmocore), we have compile-time
registration, i.e. the 'struct log_info_cat' and the D* constant need to
be defined inside libosmocore. I think this is an acceptable
compromise.
Furthermore, if LOGP()/DEBUGP() ever see a subsystem number that it
doesn't know, it will assign it to the new 'DLGLOBAL' (Debug Library
GLOBAL) category, i.e. there cna be no array overflows.
This ensures that even an external library using a 'newer' D* constant
will not crash or otherwise fail, it will simply log in a slightly
different way.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
hello
i have Motorola c123 The following are my steps:
1-
$ cd osmocom-bb
$ git checkout -b testing remotes/origin/sylvain/testing
fatal: git checkout: branch testing already exists
2-
~/osmocom-bb/src/host/osmocon$ ./osmocon -p /dev/ttyUSB0 -m c123xor
../../target/firmware/board/compal_e88/layer1.compalram.bin
got 2 bytes from modem, data looks like: 2f 00 /.
got 5 bytes from modem, data looks like: 1b f6 02 00 41 ....A
got 1 bytes from modem, data looks like: 01 .
got 1 bytes from modem, data looks like: 40 @
Received PROMPT1 from phone, responding with CMD
read_file(../../target/firmware/board/compal_e88/layer1.compalram.bin):
file_size=51320, hdr_len=4, dnload_len=51327
got 1 bytes from modem, data looks like: 1b .
got 1 bytes from modem, data looks like: f6 .
got 1 bytes from modem, data looks like: 02 .
got 1 bytes from modem, data looks like: 00 .
got 1 bytes from modem, data looks like: 41 A
got 1 bytes from modem, data looks like: 02 .
got 1 bytes from modem, data looks like: 43 C
Received PROMPT2 from phone, starting download
handle_write(): 4096 bytes (4096/51327)
handle_write(): 4096 bytes (8192/51327)
handle_write(): 4096 bytes (12288/51327)
handle_write(): 4096 bytes (16384/51327)
handle_write(): 4096 bytes (20480/51327)
handle_write(): 4096 bytes (24576/51327)
handle_write(): 4096 bytes (28672/51327)
handle_write(): 4096 bytes (32768/51327)
handle_write(): 4096 bytes (36864/51327)
handle_write(): 4096 bytes (40960/51327)
handle_write(): 4096 bytes (45056/51327)
handle_write(): 4096 bytes (49152/51327)
handle_write(): 2175 bytes (51327/51327)
handle_write(): finished
got 1 bytes from modem, data looks like: 1b .
got 1 bytes from modem, data looks like: f6 .
got 1 bytes from modem, data looks like: 02 .
got 1 bytes from modem, data looks like: 00 .
got 1 bytes from modem, data looks like: 41 A
got 1 bytes from modem, data looks like: 03 .
got 1 bytes from modem, data looks like: 42 B
Received DOWNLOAD ACK from phone, your code is running now!
OSMOCOM Layer 1 (revision osmocon_v0.0.0-786-g937023b)
======================================================================
Device ID code: 0xb4fb
Device Version code: 0x0000
ARM ID code: 0xfff3
cDSP ID code: 0x0128
Die ID code: df0d1621a400d808
======================================================================
REG_DPLL=0x2413
CNTL_ARM_CLK=0xf0a1
CNTL_CLK=0xff91
CNTL_RST=0xfff3
CNTL_ARM_DIV=0xfff9
======================================================================
THIS FIRMWARE WAS COMPILED WITHOUT TX SUPPORT!!!
Assert DSP into Reset
Releasing DSP from Reset
Setting some dsp_api.ndb values
Setting API NDB parameters
DSP Download Status: 0x0001
DSP API Version: 0x0000 0x0000
Finishing download phase
DSP Download Status: 0x0002
DSP API Version: 0x3606 0x0000
LOST 1968!
3-
~/osmocom-bb/src/host/layer23/src/mobile$ ./mobile
Copyright (C) 2008-2010 ...
Contributions by ...
License GPLv2+: GNU GPL version 2 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
<000e> sim.c:1206 init SIM client
<0005> gsm48_cc.c:61 init Call Control
<0001> gsm48_rr.c:4944 init Radio Ressource process
<0004> gsm48_mm.c:1220 init Mobility Management process
<0004> gsm48_mm.c:971 Selecting PLMN SEARCH state, because no SIM.
<0002> gsm322.c:3472 init PLMN process
<0003> gsm322.c:3473 init Cell Selection process
Mobile '1' initialized, please start phone now!
VTY available on port 4247.
<0004> subscriber.c:556 Requesting SIM file 0x2fe2
<000e> sim.c:209 got new job: SIM_JOB_READ_BINARY (handle=00000004)
<000e> sim.c:697 go MF
<000e> sim.c:241 SELECT (file=0x3f00)
<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4)
I wait and wait and nothing happens to keep as is?
What is the solution to this problem?
I hope someone can help me as soon as
--
View this message in context: http://baseband-devel.722152.n3.nabble.com/help-me-i-have-motorola-c123-tp3…
Sent from the baseband-devel mailing list archive at Nabble.com.