baseband-devel January 2012

baseband-devel@lists.osmocom.org

38 participants
55 discussions

by Paul Lambert

Hello, I have a ursp1 working fine and I want to use my c123 to conenct to it with osmocombb. Now I face some problems. First of all I have no sim, so I do: sim testcard 1 001 01 The usrp runs a testnetwork (001 01) I don't know how I can associate with the usrp. I tried: network search (lot of output and also my testnet) network show (nothing happens) network select 1 001 01: Network not in list! Any idea what I'm doing wrong? Would be really Cool if i could use opensource only. With best regards, Paul

13 years, 4 months

RSSI firmware

by Dario Lombardo

Hello everybody I'm trying to use the RSSI firmware on a c118 and c115. Both of them give me this error host/osmocon/osmocon -p /dev/ttyUSB0 -m c123xor target/firmware/board/compal_e88/rssi.compalram.bin got 1 bytes from modem, data looks like: 04 . got 1 bytes from modem, data looks like: 81 . 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 The maximum file size is 64kBytes (65535 bytes) read_file(target/firmware/board/compal_e88/rssi.compalram.bin) failed with -27 Do I need to do something different to load this FW or simply my phones have no enough room for it? Thanks for your help. Dario.

13 years, 5 months

[PATCH 2/2] rearm_timer: update run-time and re-activate

by Christian Vogel

Instead of calling schedule_timer() inside the callback (which causes list-reshuffling) just call rearm_timer(self,milliseconds) to have it re-execute after the specified time. --- src/target/firmware/comm/timer.c | 6 ++++++ src/target/firmware/include/comm/timer.h | 1 + 2 files changed, 7 insertions(+), 0 deletions(-) diff --git a/src/target/firmware/comm/timer.c b/src/target/firmware/comm/timer.c index 6a649ae..d135e24 100644 --- a/src/target/firmware/comm/timer.c +++ b/src/target/firmware/comm/timer.c @@ -63,6 +63,12 @@ void schedule_timer(struct osmo_timer_list *timer, int milliseconds) add_timer(timer); } +void rearm_timer(struct osmo_timer_list *timer, int milliseconds) +{ + timer->expires = jiffies + ((milliseconds * TIMER_HZ) / 1000); + timer->active = 1; +} + void del_timer(struct osmo_timer_list *timer) { if (timer->in_list) { diff --git a/src/target/firmware/include/comm/timer.h b/src/target/firmware/include/comm/timer.h index db7d1a5..6ca51b5 100644 --- a/src/target/firmware/include/comm/timer.h +++ b/src/target/firmware/include/comm/timer.h @@ -60,6 +60,7 @@ extern unsigned long volatile jiffies; */ void add_timer(struct osmo_timer_list *timer); void schedule_timer(struct osmo_timer_list *timer, int miliseconds); +void rearm_timer(struct osmo_timer_list *timer, int milliseconds); void del_timer(struct osmo_timer_list *timer); int timer_pending(struct osmo_timer_list *timer); -- 1.7.0.4

13 years, 5 months

[PATCH 1/2] printf: Hack to support gcc printf() optimization

by Christian Vogel

gcc optimizes printf("x") to putchar('x'), but we #define putchar to be something else. Now lib/printf.c defines a putchar() function that always prints on the sercomm port, it will break uart consoles. --- src/target/firmware/lib/printf.c | 16 ++++++++++++++++ 1 files changed, 16 insertions(+), 0 deletions(-) diff --git a/src/target/firmware/lib/printf.c b/src/target/firmware/lib/printf.c index a4fc687..887b5b4 100644 --- a/src/target/firmware/lib/printf.c +++ b/src/target/firmware/lib/printf.c @@ -17,3 +17,19 @@ int printf(const char *fmt, ...) return r; } + +/* HACK: we define putchar to be sercomm_putchar, + * but gcc optimizes printf("x") to putchar('x') + * so it will generate a call to the function putchar(). + * + * Note: This will break non-sercomm consoles! + */ + +#ifdef putchar +#undef putchar + +int putchar(char c){ + return sercomm_putchar(c); +} + +#endif -- 1.7.0.4

13 years, 5 months

mobile DTMF timing

by mad

Hi list, hi Jolly, I just tested the DTMF support on a real network and discovered that the timeout of 70ms for receiving the Start DTMF ACK is too short. The consequences are many repeated Start DTMF messages, never received ACKs and no tone is played. Using a timer value of 170ms in mnccms.c:759 fixes this for that network. Unfortunately I didn't found - or overlooked - a mandatory timeout value for Ta in TS 23.014 which the MSC has to meet. Is that undefined in the standard and where came the 70ms from? Regards, Mad

13 years, 5 months

Re: Linux + u-boot port to MT6235

by Victor Rojas

Nacesito temas y confaguracion

13 years, 5 months

Creating unique features for a real OsmocomBB phone

by alphaflux

A novel feature would be direct connections to other OsmocomBB handsets that are in range. So not only handsets communicate with towers but a handset also listens to announcements of compatible handsets within range. Reason is to have free communication between different buildings, floors, rooms.

13 years, 5 months

Re: Creating unique features for a real OsmocomBB phone

by Dave Schmidt

> why should two phones use uplink frequency to communicate directly > together? why not using downlink frequency? Because in most if not all counties transmission on downlink frequency requires a license? (Sorry and please correct me if this is some obvious nonsense... to me, the original proposal was looking quite nonsensial because of this, but I'd love to learn if I'm wrong...) Dave.

13 years, 5 months

Asterisk GSM channel driver?

by Tim Ehlers

Hi, I have seen, that there are channel driver for the DECT project, where you can connect your DECT handset to the Asterisk PBX. There is also somehow a possibility to connect a mobile GSM phone via openBSC and asterisk. But has somebody thought about just connecting the osmocombb mobile phone (which is connected to a public mobile network [or openBSC]) to asterisk? I would think of making a call through a channel driver, osmocombb is doing a call like "call ms number", but instead of using mike and speaker asterisk would send the already in GSM-codec modulated voice data through the serial port (maybe it would needed to use the non-standard USB-TTL version to handle full duplex GSM speech). And layer1 of osmocombb could send that nearly untouched on the air. For incoming calls this could be similar + signalling the call through the channel driver. Has somebody already thought of that? Would that be a achieveable task or is it technically impossible? Thanks Tim

13 years, 5 months

read Kc with osmocombb

by Tim Ehlers

Hi, today I seached for a possibility to read the temporary session key "Kc" from my phone in osmocombb. I did not find a function. So I used the function, which writes SMS into sms.txt to write the Kc. Since I never used the Kc to decode something I would like to ask if I did it correct this way: --- old/host/layer23/src/mobile/subscriber.c 2012-01-10 17:06:40.000000000 +0100 +++ new/host/layer23/src/mobile/subscriber.c 2012-01-19 23:52:36.000000000 +0100 @@ -60,6 +60,39 @@ return NULL; } +static int gsm_kc(struct osmocom_ms *ms, uint8_t *kc) +{ + const char osmocomkc[] = ".osmocom/bb/kc.txt"; + int len; + const char *home; + char *kc_file; + FILE *fp; + + home = getenv("HOME"); + if (!home) { +fail: + fprintf(stderr, "Can't deliver SMS, be sure to create '%s' in " + "your home directory.\n", osmocomkc); + return NULL; + } + len = strlen(home) + 1 + sizeof(osmocomkc); + kc_file = talloc_size(l23_ctx, len); + if (!kc_file) + goto fail; + snprintf(kc_file, len, "%s/%s", home, osmocomkc); + + fp = fopen(kc_file, "a"); + if (!fp) + goto fail; + fprintf(fp, "%s %02X%02X%02X%02X%02X%02X%02X%02X\n", ms->name, kc[0], kc[1], kc[2], kc[3], kc[4], kc[5], kc[6], kc[7], kc[8]); + fclose(fp); + + talloc_free(kc_file); + + return 0; +} + + static char *sim_decode_bcd(uint8_t *data, uint8_t length) { int i, j = 0; @@ -377,6 +410,7 @@ subscr->key_seq = data[8] & 0x07; LOGP(DMM, LOGL_INFO, "received KEY from SIM\n"); + gsm_kc(subscr->ms, subscr->key); return 0; } Maybe it would be a better way to implement a function in VTY. BTW, am I wrong or why did nobody do that until present? Thanks Tim

13 years, 5 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel January 2012