The time at which the phone is allowed to transmit a burst of
traffic within a timeslot must be adjusted accordingly to prevent
collisions with adjacent users. Timing Advance (TA) is the
variable controlling this adjustment. The TA value is normally
between 0 and 63, with each step representing an advance of
one bit period (approximately 3.69 microseconds).
As trxcon doesn't perform actual burst transmission, this value
needs to be forwarded to the transceiver, which will take care
about the timings.
Change-Id: Ia8c0848827ab2b4cd7cf1efe128b28d5c06ec84e
The 'SETMAXDLY' command is used on the BTS side to limit maximal
Time of Arrival for access bursts. As we don't receive RACH
bursts on the MS side, the command is useless.
The 'SETRXGAIN' command is used on the BTS side to set initial
receive gain value for TRX. On the MS side it's possible to set
that parameter via command-line options of TRX.
Change-Id: I3e61b4b48193004cdcb241cefabb44c12db93120
In order to get the transceiver more time to process bursts,
the L1 scheduler should process the frames and send the bursts
in advance (a few frames before), like OsmoBTS does. By default,
the advance value is 20 frames, but this can be adjusted using a
new command line option of trxcon '-f'.
Change-Id: Ic258a169f3554f931d6277e18ca060d029b77f32
This change introduces a new tool for sending existing bursts from
file or standard input either to L1 (OsmoBTS or OsmocomBB) or to
TRX (OsmoTRX and GR-GSM TRX).
Change-Id: I2c542583252d31daac466e6c7837317fda8a7020
Sometimes it's important to use different CTRL port, for example
when OsmoTRX is running at the same time. This change adds the
corresponding command line options and help message.
Change-Id: Ic6eeb69d9a1fc151eab2e63f3708e3d70e2e558b
Since 8c4f5457 in libosmocore there are some limitations on FSM
and FSM instance names. This change adjusts the names of both
l1ctl_fsm and trx_fsm instances.
Change-Id: Icaaac3f51bdcfe4f7723060179b8730c3a06529b
There is no (performance) reason to use fprintf instead of LOGP.
Second one provides more useful information, such as a file name
and a line number.
Change-Id: I86dda5b3d746c7802442e4226578a06c04941721
For some reasons, the function, which is used to flush a queue of
transmit primitives, was intended to flush a list of msgb instances
instead of trx_ts_prim, so memory was being cleaned incorrectly.
Moreover, the items weren't actually removed from queue.
Change-Id: Ia84b57350a5c2eee0afebc65f62e30eaddb141d4
The training sequences, data / traffic indication and confirmation
helpers are used by several lchan handlers, like xCCC and TCH. It
would be better to have them all declared within a shared header.
Change-Id: I71980f09a0c0e023370e1a651afc24fff2491552
The l1ctl_info_dl header is expected to be a part of a
L1CTL_DATA_CONF message, but was missing previously.
Change-Id: Ia8dfaed924fd84395ba9ae539164eaa94f52d30b
This change introduces shared primitive management functions,
exposed from the l1ctl_rx_data_req() implementation:
- sched_trx_init_prim() - allocates memory for a new primitive
and its payload. Initializes primitive's header, setting
the logical channel type and the payload length. After
initialization, the talloc context of a primitive is
a trx instance, which passed as the first argument.
- sched_trx_push_prim() - decodes the timeslot index from
chan_nr and pushes a primitive to its transimt queue.
The talloc context of primitive is changed to the
parent trx_ts instance after queuing.
Both functions will be used for handling both L1CTL_TRAFFIC_REQ
and L1CTL_RACH_REQ.
Change-Id: I8169a1ef4ef54d91b50f3e213e4842f54af8b499
L1 Data is quite verbose, while Control is typically limited.
And if you would need to debug some Control message handling,
the Data messages wont overflow your terminal anymore. This
change introduces a new logging category named 'DL1D'.
Change-Id: Id830c8bf913f7a8ddc87c47f70a337ee4623abd8
When the L1CTL_CCCH_MODE_REQ is received, we don't need to
reconfigure anything if the current mode matches requested.
Change-Id: Ib8a511e4edd7210b1806f47e83f316be00a8cbb1
The training sequences array is currently used by xCCH handlers,
but will be also used for handling both TCH/F and TCH/H bursts.
Moreover the code that forwards decoded L2 payloads to L1CTL
protocol handlers was separated into a new shared function.
Change-Id: I34c3de351362ebd9a070f49bb78d7bd976784b04
It's better to pass a trx_lchan_state instance directly from
caller to lchan handler instead of passing trx_lchan_type. This
way a handler wouldn't need to find lchan itself.
Change-Id: I47a40542b03ab31da12b0abb1c263c83662ff018
Previously, the chan_nr, received from L2, was parsed in a wrong
way, so in some cases only one logical channel was activated or
some messages (such as Measurement Requests) were sent on
incorrect channel (e.g. on SDCCH instead of SACCH).
This change reimplements the sched_trx_chan_nr2lchan_type(), and
introduces a new function sched_trx_set_lchans(), whics will
parse chan_nr and (de)activate required channels.
Change-Id: I480311c65ef93bbc1644ec708dd2a68fd33091e0
To be able to decode one xCCH message, it's required to have
all set of bursts collected (4/4). Otherwise we should not
even try to decode an incomplete set.
Change-Id: Iaa63462efe19b8e96102fc8c8d8c968a2df2c70e
We should make sure that required timeslot is not only allocated,
but also configured, i.e. has a correct multiframe layout.
Change-Id: I1d0b870c389802b51c709d089b80ac3fb3565fa8
As we know the count of timeslots per GSM TDMA frame, it would
be better to have an array of pointers to trx_ts instances instead
of linux list, which is more usable for lists with unknown length.
Change-Id: I9510a5cddde22950ceb8422e0990d59f05ed4d60
This change introduces a new tool named 'burst_gen.py'. One can
be used for sending GSM bursts either to L1 (OsmoBTS or OsmocomBB)
or to TRX (OsmoTRX and GR-GSM TRX). Currently it is only possible
to send random bursts of different types: NB, FB, SB, AB.
Change-Id: Ie14281222d29536b8690517e57af2a1007fcbc91
Both SCH_EVENT_CLCK_IND and SCH_EVENT_CLCK_LOSS were not handled,
moreover there is no purpose to keep them.
Change-Id: I8efac459a40f4287e3325890809991d5ef46e9b1
Vadim Yanitskiy