- baseband-devel - lists.osmocom.org

[PATCH] Updated GPS code so that it is compatible with new gpsd version.
by Konstantin Weitz 28 Jun '11

28 Jun '11

--- src/host/layer23/src/common/gps.c | 11 ++++++++--- 1 files changed, 8 insertions(+), 3 deletions(-) diff --git a/src/host/layer23/src/common/gps.c $REPLACE$ index 38aae2c..ffdaa1a 100644 --- a/src/host/layer23/src/common/gps.c +++ b/src/host/layer23/src/common/gps.c @@ -70,11 +70,14 @@ int osmo_gpsd_cb(struct osmo_fd *bfd, unsigned int what) goto gps_not_ready; /* gps has no data */ - if (gps_waiting(gdata)) + + // 10 seconds timeout, only place where + // logic was changed to upgrade to new gpsd + if (gps_waiting(gdata,10000000)) goto gps_not_ready; /* polling returned an error */ - if (gps_poll(gdata)) + if (gps_read(gdata)) goto gps_not_ready; /* data are valid */ @@ -111,7 +114,9 @@ int osmo_gpsd_open(void) gps_bfd.when = BSC_FD_READ; gps_bfd.cb = osmo_gpsd_cb; - gdata = gps_open(g.gpsd_host, g.gpsd_port); + gdata = malloc(sizeof(struct gps_data_t)); + + gps_open(g.gpsd_host, g.gpsd_port, gdata); if (gdata == NULL) { LOGP(DGPS, LOGL_ERROR, "Can't connect to gpsd\n"); return -1; -- 1.7.5.2

1 0

libosmocore / logging from within libraries
by Harald Welte 27 Jun '11

27 Jun '11

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)

2 2

help me i have motorola c123
by adel 26 Jun '11

26 Jun '11

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.

2 1

1 of 4 phones not loading
by Job 26 Jun '11

26 Jun '11

Hi, I've got 4 C115 phones (all same firmware). One is not loading and reporting the ftmtool error. The others are loading fine. Could this be caused by a blown RX input on the chip? Or could there other reasons why it does not work. I tried both an FTDI cable and a buspirate. Best regards, Job output: ./osmocon -p /dev/ttyUSB0 -m c123xor ../../target/firmware/board/compal_e88/loader.compalram.bin got 2 bytes from modem, data looks like: 04 01 .. 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/loader.compalram.bin): file_size=17132, hdr_len=4, dnload_len=17139 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

1 0

Re: Cygwin Windows --> Accessing serial port.
by Dieter Spaar 25 Jun '11

25 Jun '11

On Sat, 25 Jun 2011 23:13:10 +0530, "R M" <rm.engineer84(a)gmail.com> wrote: > > Can you please provide me the patch for the present version of > osmocon.c as you mentioned in the mail as I am unable to apply the > patch manually. I don't have a patch for the current version as I currently don't work with OsmocomBB. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

Re: Cygwin Windows --> Accessing serial port.
by Dieter Spaar 25 Jun '11

25 Jun '11

Hello Harald, On Sat, 4 Jun 2011 08:46:50 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote: > > i have never heard of somebody doing this on windows 7. Almost everyone > here uses Linux or MacOS. And the only prominent Windows user involved > in the project is working with Windows XP. At least on my Cygwin installation under Windows XP the serial port is accessible as "/dev/ttySx" (x is "0" for COM1, "1" for COM2 and so on). All the USB to serial converters I am aware of are virtual COM ports on Windows which means that they are accessible the same way, e.g. if the virtual COM port is "COM7" it can be be accessed as "/dev/ttyS6", Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

6 8

Layer3 interaction
by Paul Lambert 25 Jun '11

25 Jun '11

Hello, since I am new to this list, I want to take the opportunity to thank your for your efforts. It is just awesome that one can do phonecalls with an open-source baseband stack. I'm new to the project and I'm searching a method to send prepared packets (Layer 3) to my basestation in my lab. I'm searching now for the best way to do so, is there already a script allowing me to perform that task? I couldn't find one when I searched. If there is none available I would try to build one using code located in layer23. I would be glad if you could point me to the method if there is already something available. With best regards

3 2

Progress with NuttX
by l--putt 24 Jun '11

24 Jun '11

Hi list, with a bit of help from Harald, I finally managed to push my commits. Hence, we have: - platform support for Calypso (timers, irq, ...) - char device driver for keypad (/dev/keypad) - some hacks reusing old drivers for SPI/poweroff and sercomm The console currently outputs in osmocon while you have to write to the loader interface with a python script. Flushing is kind of a problem too. Haven't checked how to fix those two, so any volunteers? Bye, Stefan

1 0

Sending and receiving TCH frames with 'mobile'
by Michael 23 Jun '11

23 Jun '11

Hello List, as part of my research, I'm trying to use the 'mobile' app to send and receive data on traffic channels. That is, I want to replace the audio stream from the phone's microphone/speaker by something else supplied by the computer attached to the phone. I realize this feature isn't fully implemented in osmocom-BB currently, and I'm willing to write some code to make it work (and share my results with this list if there's any interest). Here's what I've done so far: - merged the sylvain/traffic and jolly/voice branches - added some code to mobile that writes the payload of downlink frames to a user-specified file once a call has been established As far as the receiving end goes, this seems to work. I'm still unclear as to where I should start on the sending side -- I do expect it to be somewhat more complex. Any pointers -- or a rough outline of what is left to be done to make this work -- would be much appreciated. Kind regards, Michael Voelske

1 0

the need all people to make
by 麦田守望 22 Jun '11

22 Jun '11

i find a way maybe the phone(motorola) it can to make usrp

1 0