Hi Dieter,
Hi everyone,
(cc'd the list, for the record and if other people are interested in
the inner workings :)
I'm pretty satisfied with the current state of the TCH primitive (as
it is in my testing branch now). But there is still two things I'm
stumbling upon:
* When to put / read data for FACCH.
Getting downlink FACCH blocks looks quite logic: just check the
B_BLUD bit on the TCH response of the last burst of the block.
So with rx_time being the time at which the burst was received
(i.e., one frame before the response is executed)
- For TCH/F: (rx_time.fn % 13) % 4 == 3
- For TCH/H: (rx_time.t2 - subchannel) in {6,15,23}
But for when to load the next FACCH block, it seems weird. From
what I understand of what you did and what the TSM30 does, you need to
load the data on the TCH cmd corresponding to the bursts _before_ the
first burst.
So with tx_time being the time at which the burst will transmitted
(i.e., one frame after the command is executed = l1s.next_time)
- For TCH/F (tx_time.fn % 13) % 4 == 3
- For TCH/H (tx_time.t2 - subchannel) in {6,15,23} (2 TDMA before
the first burst because on TCH/H, we're executed one once every two
frame)
Why the need to load it one burst in advance ? (while on the RX
side, which seems more complex to do, data is available directly after
the last burst is received).
* TCH/H support: AFAIK, I did everything that should be required for
it to work:
- set fn_report properly for TCH/H
- set chan_type to TCH_H in dsp_load_tch_parameters
- Use a different condition for when to put/read FACCH bursts
(according to 05.02)
- Schedule the TCH task appropriately ...
But still can't get it to work (testing with the racal). SACCH seems
to work fine (I see the SI messages), but I don't see a single FACCH
message (and eventually the racal says T3107 expired, assignement to
TCH failed).
Do you see anything else that would be required ?
Cheers,
Sylvain
Hello Deiter ,Sylvian
As u advised I completed reading GSM standard, and dig down source code
AFAIK , i have recognized the files and parameters where i need to
change values to tune for particular TCH, and also understood that
how important signaling is to be involved .
I just want to know one thing that is , during the channel request MS
send burst on RACH with RA ref number, where this RAF or RA reference
number stored on MS side , because when Immediate assignment send
from the network it must be match before tuning to particular SDCCH, i
want to apply a trick here i will copy the RA reference from the
immediate assignment message and will replace with original one stored
in MS, hence MS will think this channel is for me and tune to the
SDCCH accordingly, further it will keep on listening all process like
authentication, location updating , again the TCH channel information
is send SDCCH without encryption
as only authentication procedure needs Kc Ki and SRES, SDCCH is not
encrypted and all MS hosting on that SDCCH can decode TCH parameter
like FN , TS, ARFCN hopping sequence.
but again i need to clarify how L1ctl.c and L23_api.c fetch the decoded data,
from immediate assinment masseg.
as it is written printf..........%u . From where this will scan or fetch.
if i will be able to know, where MS kept stored the input values
advised in signaling messages by BTS on PCH, or AGCH. so i can
manipulate them and land on CCCH,
and then SDCCH then TCH.
kindly tell me if it is feasible , or there is more i need to think.
Kind Regards,
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
/* 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
