For the firmware used on RevB the GsmL1_Prim_t was bigger than
the femtobts control structure. Solve it by introducing a macro
that will select the biggest size and use this macro. This is a
follow up fix for 08fce19cfc.
Introduce femtobts_tracef_docs with some more information about
the traceflags, add parameters to the vty_cmd_string_from_valstr
for specifying the separator, the suffix and if the name should
be lowered.
From our header files v2.4 onwards, we include some macros that allow us
to do compile-time checks for the API header version. As older headers
don't have those macros, we have to fall back to assume it will be v2.2
This allows us to do RF measurements (EDGE EVM and the like) even
without having any PCU/RLC/MAC code as of now.
To use it, configure PDCH type timeslots (e.g. TS 7) in the BSC and then
use "trx 0 7 activate 0" to manually activate the PDTCH lchan on top
of that timeslot. The BTS will now happily transmit EDGE/8PSK data.
where previously we would only see
<0006> oml.c:931 (bts=0,trx=0,ts=1,ss=0) MPH-DEACTIVATE.req (FACCH/F)
we now get
<0006> oml.c:931 (bts=0,trx=0,ts=1,ss=0) MPH-DEACTIVATE.req (FACCH/F RxUL)
to notice it is modifying the receive path in the uplink direction.
In L1 RTP mode, the L1 already does all the bit-shifting and re-ordering
required for the RTP formats (which have different bit/nibble order than
the ETSI/3GPP encodings, for some odd reason).
We don't enable it by default yet, as only HR/FR/EFR work with it, but
AMR has some yet to be debugged problem.
Enabling USE_L1_RTP_MODE would save some CPU cycles on the ARM side.
femtobts.c:249:2: warning: excess elements in array initializer [enabled by default]
femtobts.c:249:2: warning: (near initialization for ‘femtobts_clksrc_names’) [enabled by default]
This code re-works osmo-bts to add support for the upcoming sysmocom BTS.
It also tries to add some level of abstraction between the generic
part of a BTS (A-bis, RSL, OML, data structures, paging scheduling,
BCCH/AGCH scheduling, etc.) and the actual hardware-specific bits.
The hardware-specific bits are currently only implemented for the sysmocom
femtobts, but should be (re-)added for osmocom-bb, as well as a virtual
BTS for simulation purpose later.
The sysmocom bts specific parts require hardware-specific header files
which are (at least currently) not publicly distributed.
Harald Welte
Holger Hans Peter Freyther