/* 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
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
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
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
> 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
{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.jpghttp://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
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.jpghttp://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
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
Hello Marten,
just some basic technical note about what you are planning to do.
The following _could_ work (to be sure if this is really usable
in the planed environment much more research has to be investigated):
- The BTS is based on a modified version of OpenBTS which allows to
send a TCH without the need for signalling to setup the TCH. Similar
everything on the uplink TCH will be played back.
- The phones are based on OsmocomBB and receive the TCH from the BTS
and play it back, they do not send anything on the TCH yet.
- If you make sure that only one phone at once will send, it would
be possible to press a button on the phone which will start
transmitting on the TCH and then talk, similar to simple CB Radio
handsets. On the BTS side you will hear the result.
However all the adjustments to OpenBTS and OsmocomBB, even for a simple
"Proof of concecpt" are not trivial. So you have to understand OpenBTS
and OsmocomBB to make the required changes, you cannot expect that
a short answere here on the list is the solution for the problem.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
