baseband-devel

baseband-devel@lists.osmocom.org

2022 discussions

[PATCH 1/2] osmocon: array of download-method names
by Christian Vogel 06 Feb '12

06 Feb '12

An array of method names for the parser methods (c123xor, mtk, ...) has been introduced, so that we can easily convert back and forth. --- src/host/osmocon/osmocon.c | 39 ++++++++++++++++++++++++--------------- 1 files changed, 24 insertions(+), 15 deletions(-) diff --git a/src/host/osmocon/osmocon.c b/src/host/osmocon/osmocon.c index fc29506..b3eaedb 100644 --- a/src/host/osmocon/osmocon.c +++ b/src/host/osmocon/osmocon.c @@ -126,6 +126,16 @@ enum dnload_mode { MODE_INVALID, }; +const char * const dnload_mode_str[]={ + [MODE_C123]="c123", + [MODE_C123xor]="c123xor", + [MODE_C140]="c140", + [MODE_C140xor]="c140xor", + [MODE_C155]="c155", + [MODE_ROMLOAD]="romload", + [MODE_MTK]="mtk", +}; + struct dnload { enum dnload_state state; enum romload_state romload_state; @@ -1170,24 +1180,21 @@ static int serial_read(struct osmo_fd *fd, unsigned int flags) static int parse_mode(const char *arg) { - if (!strcasecmp(arg, "c123")) - return MODE_C123; - else if (!strcasecmp(arg, "c123xor")) - return MODE_C123xor; - else if (!strcasecmp(arg, "c140")) - return MODE_C140; - else if (!strcasecmp(arg, "c140xor")) - return MODE_C140xor; - else if (!strcasecmp(arg, "c155")) - return MODE_C155; - else if (!strcasecmp(arg, "romload")) - return MODE_ROMLOAD; - else if (!strcasecmp(arg, "mtk")) - return MODE_MTK; + int i; + for(i=0;i<MODE_INVALID;i++) + if(!strcasecmp(arg,dnload_mode_str[i])) + return i; return MODE_INVALID; } +const char * +dnload_mode_to_str(enum dnload_mode mode){ + if(mode < 0 || mode >= MODE_INVALID) + return "invalid"; + return dnload_mode_str[mode]; +} + #define HELP_TEXT \ "[ -v | -h ] [ -d [t][r] ] [ -p /dev/ttyXXXX ]\n" \ "\t\t [ -s /tmp/osmocom_l2 ]\n" \ @@ -1414,8 +1421,10 @@ int main(int argc, char **argv) break; case 'm': dnload.mode = parse_mode(optarg); - if (dnload.mode == MODE_INVALID) + if (dnload.mode == MODE_INVALID){ + fprintf(stderr,"Invalid download mode!\n"); usage(argv[0]); + } break; case 's': layer2_un_path = optarg; -- 1.7.0.4 --X1bOJ3K7DJ5YkBrT Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0002-osmocon-Option-a-runs-program-script-on-upload.patch"

1 0

Power-savvy GSM network (was: gsm322.c Bug Fix Patch)
by Alexander Chemeris 04 Feb '12

04 Feb '12

Hi Kurtis, (I'm changing subject to the actual topic of this discussion) Yes, I quickly looked through your code. Looks like a big hack right now, but I guess it's meant to be a hack at this point :) So, your idea is to manipulate Tx power of a BTS to cover only actually working handsets, if I understand correctly. It's not possible to do with a normal GSM phone, because phone does not transmit until it sees a beacon. So you want to create a "wake up BTS" channel to get around. Am I following your logic correctly? It does look like an interesting idea if could be done dirt-cheap. But how do you plan to do paging in this system? I see the only way - to use the same "wake up channel", but in other direction. So basically you have a network-specific "default" ARFCN which is used when no active BTS is in range. All communications are first tried on this ARFCN and only then on other ones. Right? On Thu, Feb 2, 2012 at 22:43, Kurtis Heimerl <kheimerl(a)cs.berkeley.edu> wrote: > This is part of my thesis work at Cal, yes. Range is not in any way involved. > > That's roughly the use case, areas where there are too few users to > keep a BTS in constant use. Our designs allow the power usage to scale > with the number of users, rather than sit at a fixed output, as they > do now. The BTS side is simple; the osmocom side is complicated. We > have a handset that can wakeup a sleeping tower, or a "wakeup button" > device which only transmits when a button is pressed. That thing is ~5 > bucks and can probably be attached to the back of a legacy phone in > case we can't convince a large manufacturer to incorporate our changes > into the baseband. > > Anyhow, the code is online if you're interested in looking at our > progress (https://github.com/kheimerl). It's nowhere near ready, but > you're a very knowledgeable guy, and I'd be happy to hear your > opinions on any of our designs. > > On Thu, Feb 2, 2012 at 10:37 AM, Alexander Chemeris > <alexander.chemeris(a)gmail.com> wrote: >> Is it a part of your TIER university work? >> I wonder about use cases for this. >> >> One use case I see is when you have a BTS which is rarely used, like >> in a desert and you don't want it to work all the time. What use cases >> do you plan to use it for? >> >> On Thu, Feb 2, 2012 at 22:03, Kurtis Heimerl <kheimerl(a)cs.berkeley.edu> wrote: >>> >>> Yeah, and we have that working. >>> >>> On Thu, Feb 2, 2012 at 12:56 AM, Alexander Chemeris >>> <alexander.chemeris(a)gmail.com> wrote: >>> > On Thu, Feb 2, 2012 at 12:08, Kurtis Heimerl <kheimerl(a)cs.berkeley.edu> wrote: >>> >> I think I looked at that... I'll give you some context. >>> >> >>> >> We've modified osmocom to "wakeup" a specific tower at a specific >>> >> ARFCN. >>> > >>> > Interesting. Do you mean you send some packet to a "sleeping" BTS to wake it up? >>> > >>> > -- >>> > Regards, >>> > Alexander Chemeris. >> >> >> >> >> -- >> Regards, >> Alexander Chemeris. -- Regards, Alexander Chemeris.

3 3

Re: Operator name in cell_log log file
by Andreas Eversberg 04 Feb '12

04 Feb '12

Dario Lombardo wrote: > Why doesn't cell_log write the operator name in its log file? Is there > any issue related to it? > Attached a patch to log operator name and country. > Dario. hi dario, the reason for that is that cell_log only logs the raw data. later it can be decoded (e.g. by gsmmap tool) with all the info you like. decoding things like "operator" could lead to the following problems when they are stored in the log file: - operator names may change - list of operators may have wrong names or is incomplete - decoding functions may have bugs, so they might output wrong results - decoding several informations would inflate the log file - someone using the log file may not care about operator names in the past we had a bug in the frequency list decoder. after i fixed it, i just parsed my log file again and got the right frequencies. if you need to know what operators you have in your log, i suggest to write a tool that parses the log file and outputs a list of operator infos and other infos you like. look at "gsmmap" to see how it is done. regards, andreas

1 0

develop a software radio front end
by Jerry Giant 04 Feb '12

04 Feb '12

Proposal to develop a software front end Hi, list. --Intro: After watching ccc camp videos, I bought myself a moto c118 and run the Osmocom-bb software on it. It's great fun to get a free software running on proprietary hardware, and so much could be learned from the source code. But what to do when the gray market stock sold out, or some one want to pick up the task of implementing the hardware in a open source fashion? OpenBTS used USRP to implement its radio, but USRP is aged, and it's documentation and price is not so friendly as I see. If further sub projects of osmocom matured, still we have to stick on the hacking hardware would not be so fun. To better the integrity and usefulness of the whole project, we can design and build a software radio front end for osmocom project. Interested? --Background: I am a Chinese electronic engineer working at small company in China, working on machine vision, now our product is building a FPGA/TI DSP based embedded device. I have some free time to learn and very interested in build a software radio front end. --Initial Thought: The goal of build a Osmocom Software Radio Kit, is to build a multipurpose radio front end which compatible to All or Most air interfaces now osmocom is interested. Interfacing an emulated Calypso DSP interface is way to reuse the code, or build another L1 dedicated for OSRK is an option. The hardware spec could be much better than USRP as vendor's products line evolved, but OSRK better to be mobile, has modular RF power amplifier interface, and battery powered. --Hardware Specification: Let get started.

3 2

RSSI firmware
by Dario Lombardo 03 Feb '12

03 Feb '12

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.

5 7

gsm322.c Bug Fix Patch
by Kurtis Heimerl 03 Feb '12

03 Feb '12

Just a quick bug fix to gsm322.c. Basically, there were two commands in an "else" block without brackets, causing the "end = 1023+299" command to execute regardless of the state of index.

4 8

[PATCH 2/2] rearm_timer: update run-time and re-activate
by Christian Vogel 29 Jan '12

29 Jan '12

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

2 1

[PATCH 1/2] printf: Hack to support gcc printf() optimization
by Christian Vogel 29 Jan '12

29 Jan '12

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

1 0

mobile DTMF timing
by mad 28 Jan '12

28 Jan '12

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

2 2

Re: Linux + u-boot port to MT6235
by Victor Rojas 27 Jan '12

27 Jan '12

Nacesito temas y confaguracion

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel