baseband-devel

baseband-devel@lists.osmocom.org

2 participants
2003 discussions

Re: osmocom on windows
by Dieter Spaar 21 Oct '10

21 Oct '10

Hello Peter, On Thu, 7 Oct 2010 11:54:28 +0200, "Peter Stuge" <peter(a)stuge.se> wrote: > > Does e.g. the CodeSourcery toolchain really need Cygwin? That would > suck. I don't know CodeSourcery, I use GNU ARM directly from www.gnuarm.com. According to the CodeSourcery FAQ, they do not require Cygwin. Are there any benefit using CodeSourcery ? I had issues in the past with the firmware using a different GNU ARM version, so I switched back to 4.0.2 which seems to be the same other use on Linux and so far it works OK. You don't seem to like Cygwin, my experience with it is not that bad, OpenBSC (not with GPRS yet due to the need for the TUN device), OsmocomBB, GNUradio and Airprobe run with minor adjustments (just to name GSM related stuff I use under Cygwin). Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

4 4

AW: wrong decoding of bit vectors
by Andreas.Eversberg 21 Oct '10

21 Oct '10

> if (bv->data[bytenum] & (1 << bitnum) == bitval) > return H; i must correct: if ((bv->data[bytenum] & (1 << bitnum)) == bitval) return H;

2 1

wrong decoding of bit vectors
by Andreas.Eversberg 21 Oct '10

21 Oct '10

/* check if the bit is L or H for a given position inside a bitvec */ enum bit_value bitvec_get_bit_pos_high(const struct bitvec *bv, unsigned int bitnr) { unsigned int bytenum = bytenum_from_bitnum(bitnr); unsigned int bitnum = 7 - (bitnr % 8); uint8_t bitval; if (bytenum >= bv->data_len) return -EINVAL; bitval = bitval2mask(H, bitnum); if (bv->data[bytenum] & bitval) return H; return L; } hi, this is part of bitvec.c of libosmocore. it returns if a given bit in the vector is "high" or "low". the bitval that represents "high" depends on the bit position. bitval2mask returns that. so we must check if the bit in the vector equals the returned bitval. i suggest to fix it that way: if (bv->data[bytenum] & (1 << bitnum) == bitval) return H; any complains? without it we cannot check the system information's rest octets. they are essential for any multiband mobile. regards, andreas

1 0

Inquiry on osmocom
by Akilesh Sethu 20 Oct '10

20 Oct '10

Hey, I am working on Android Mobile Operating System. Is it possible for me to port osmocom GSM stack to any of the Android compatible mobiles. Regards, Akilesh Sethu

2 1

Re: osmocom on windows
by Dieter Spaar 16 Oct '10

16 Oct '10

Hello Peter, On Thu, 7 Oct 2010 13:24:50 +0200, "Peter Stuge" <peter(a)stuge.se> wrote: > > In practise it can be negligeable, just another DLL, but it isn't > Windowsy, and for someone who wants Windowsy, Cygwin isn't a really > good answer. (But it can save plenty of time instead!) Exactly, saving time is the point. A software developer, regardless of coming from Windows or Linux should have no problem to understand OpenBSC/OsmocomBB/Airprobe from the OS or C language perspective (I don't talk about GSM specific things, this is something else). I want to use those project and develop for them and not waste my time with things like adopting C language specific issues. > OpenVPN has one, it's signed too. I know, but you have to use the TUN device differently than on Linux, so some adjustments are necessary (besides not knowing if Windows will do proper NAT with the IP traffic from the phone). So I run OpenBSC in a VM if I need GPRS support instead spending time on issues I don't care if I want to use this software or develop for it. > Cool, that's proof that Cygwin is pretty good stuff. It doesn't say > almost anything about how these projects run on Windows though. They work for me, I want to use them and I want to develop for them and so far I could do all I want. Of course this is something else if you for example want to run OpenBSC in a production environment with lots of BTSs. A native Windows port is surely possible, but for me I don't see any benefits besides wasting time. Of course if someone want to sponsor a native port, why not, than at least the time for this effort is paid ;-) > That isn't neccessarily a bad thing at all, evolving the project > internally or the featureset or whatever can be much more important > than adapting the project to work "on" more operating systems. I don't have the impression that more people would work on those GSM related projects if they would directly run on Windows. I think the main obstacle is that you need to know quite a lot of GSM to make use of them. And if you are able to learn and understand the GSM related stuff, using Windows and/or Linux should be no problem at all for you ;-) Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

4 4

Removing the C123 RX filter
by Sylvain Munaut 15 Oct '10

15 Oct '10

Hi, As a prelude to various experimentations, I had to remove the RX filter on some C123. As this can be useful to others, I've done a little summary of how I do it. It's not for the faint of heart tough :) http://www.246tnt.com/gsm/rx_filter.html Comments welcome of course. Cheers, Sylvain Munaut

4 3

AW: Newbie: C123 + layer1.compalram.bin + layer23
by Andreas.Eversberg 14 Oct '10

14 Oct '10

> 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

2 1

PATCH: Framebuffer for C123 and C155
by Christian Vogel 12 Oct '10

12 Oct '10

{Resent, it didn't appear on the list after 20 minutes.} Hi, I had some spare time the last days and put together a first attempt at a framebuffer for the OSMOCOM mobiles. It currently supports the C123 and the C155, the only two phones I own. > On Sat, 10 Apr 2010 10:26:05 +0300, Harald Welte > >1) we need a way to select between individual fonts ... > > Something like display_select_font(FONT_5x8) to be called > > before a display_puts() sounds like a reasonable API for this. the current API looks like this: fb_clear(); fb_setfg(FB_COLOR_GREEN); fb_setbg(FB_COLOR_WHITE); fb_setfont(FB_FONT_HELVB14); fb_gotoxy(2,20); fb_putstr("Hello World!",framebuffer->width-4); fb_setfg(FB_COLOR_RED); fb_setbg(FB_COLOR_BLUE); fb_gotoxy(2,25); fb_boxto(framebuffer->width-3,38); fb_setfg(FB_COLOR_WHITE); fb_setfont(FB_FONT_5X8); fb_gotoxy(8,33); fb_putstr("osmocom-bb",framebuffer->width-4); fb_flush(); Which results in an output such as: http://vogel.cx/git/20101011_hello_world_c123.jpg http://vogel.cx/git/20101011_hello_world_c155.jpg > - If we want to support arbitrary sized fonts, we either should buffer > the display in RAM (might be wasteful on high res color displays?) ... This patch keeps a image of the LCD in a RAM and only copies "dirty" parts upon changes. > >2) Removing all the special characters might not be the best idea to do. > > If at all, it should be a compile time option whether or not to drop > > the special characters. > > Also, the check for replacing a character with '?' needs to be > > a font-specific and not a global decision. This patch currently encodes only #32..#127 to conserve space, but it supports leaving out arbitrary characters. When the data is actually put into ROM we can spare additional space on more glyphs and/or fonts. I currently don't have commit access to the git-repo, so I couldn't upload my vogelchr/framebuffer branch. Please have a look at the patch you can download from http://vogel.cx/git/20101011_framebuffer.diff It removes the old display code completely and replaces it with the framebuffer, but currently only "hello world" makes use of it by creating the image in the photographs linked above. It should apply cleanly to today's master (11.Oct.2010) as it doesn't touch anything where currently work is being done. Please send me your comments on that patch. Greetings from the Dillberg, Chris

1 1

PATCH: Framebuffer for C123 and C155
by Christian Vogel 11 Oct '10

11 Oct '10

Hi, I had some spare time the last days and put together a first attempt at a framebuffer for the OSMOCOM mobiles. It currently supports the C123 and the C155, the only two phones I own. > On Sat, 10 Apr 2010 10:26:05 +0300, Harald Welte > >1) we need a way to select between individual fonts ... > > Something like display_select_font(FONT_5x8) to be called > > before a display_puts() sounds like a reasonable API for this. the current API looks like this: fb_clear(); fb_setfg(FB_COLOR_GREEN); fb_setbg(FB_COLOR_WHITE); fb_setfont(FB_FONT_HELVB14); fb_gotoxy(2,20); fb_putstr("Hello World!",framebuffer->width-4); fb_setfg(FB_COLOR_RED); fb_setbg(FB_COLOR_BLUE); fb_gotoxy(2,25); fb_boxto(framebuffer->width-3,38); fb_setfg(FB_COLOR_WHITE); fb_setfont(FB_FONT_5X8); fb_gotoxy(8,33); fb_putstr("osmocom-bb",framebuffer->width-4); fb_flush(); Which results in an output such as: http://vogel.cx/git/20101011_hello_world_c123.jpg http://vogel.cx/git/20101011_hello_world_c155.jpg > - If we want to support arbitrary sized fonts, we either should buffer > the display in RAM (might be wasteful on high res color displays?) ... This patch keeps a image of the LCD in a RAM and only copies "dirty" parts upon changes. > >2) Removing all the special characters might not be the best idea to do. > > If at all, it should be a compile time option whether or not to drop > > the special characters. > > Also, the check for replacing a character with '?' needs to be > > a font-specific and not a global decision. This patch currently encodes only #32..#127 to conserve space, but it supports leaving out arbitrary characters. When the data is actually put into ROM we can spare additional space on more glyphs and/or fonts. I currently don't have commit access to the git-repo, so I couldn't upload my vogelchr/framebuffer branch. Please have a look at the patch you can download from http://vogel.cx/git/20101011_framebuffer.diff It removes the old display code completely and replaces it with the framebuffer, but currently only "hello world" makes use of it by creating the image in the photographs linked above. It should apply cleanly to today's master (11.Oct.2010) as it doesn't touch anything where currently work is being done. Please send me your comments on that patch. Greetings from the Dillberg, Chris

1 1

Re: osmocom on windows
by Dieter Spaar 07 Oct '10

07 Oct '10

Hello Mihai, On Thu, 7 Oct 2010 05:25:27 -0700 (PDT), "eisencah eisenach" <wbg_1000(a)yahoo.com> wrote: > > PS. The thing is I've done windows programming up until now, but maybe I > should adapt instead of trying to the sw :) I am mainly doing Windows software development, but I don't see any benefits from spending lots of time to adopt C language specific things in the source code so that it compiles with the MS compiler (be it either gcc specific language features or missing language features in the MS compiler). So I use Cygwin which also emulates at least those Unix specific features used in OpenBSC/OsmocomBB/Airprobe. And the C standard libraries are not that different that you won't understand what is going on. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel