tranceiver support for osmo-bts

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.

Andreas Eversberg andreas at eversberg.eu
Fri Jan 18 17:52:21 UTC 2013


Sylvain Munaut wrote:
>    - the sysmobts one which basically includes all the specific stuff
> to convert the 'generic' primitves into the specific call to the DSP.
hi sylvain,

your mail inspired me, so i looked deeper at the l1_if.c of sysmobts code.

there is one major function (that calls several other functions): 
l1if_handle_ind(). it handles data (ph-data-ind, ph-rach-ind) received 
from dsp and triggers (ph-readytosend-ind) generation and transmission 
of data (ph-data-request) sent to dsp.

the primitives have a layer-1 header that is specific for the dsp of 
sysmobts. since the coding of data between l1 and the bts code is not 
defined in the gsm specs, i think this header is something that sould be 
used for a split between common and l1 specific part. i would suggest to 
move the handling and generation of primitives from l1_if.c of sysmobts 
code to the common part of osmo-bts and only keep the handling of dsp 
itself.

it would be nice to put femtobts/gsml1prim.h (currently a seperate git) 
to be part of the common include files. i don't know if the license of 
that header file allows that.

another thing i need to deeper look at is the oml.c of sysmobts specific 
code. many stuff could be moved to common part of osmo-bts also, if the 
layer 1 primitives are used to split between common part and l1 specific 
part.

the current osmo-bts-bb code would become (already became) obsolete and 
should be removed.

regards,

andreas





More information about the baseband-devel mailing list