Only old v0 is supported so far. TRXD protocol related data/logic is
moved to its own file out of Transceiver class. Code is refactored so it
can be re-used later by TRXDv1.
Related: OS#4006
Change-Id: I5786dd44b076202c6f1a6e82405670e8605797ed
Currently we have 2 out parameters, but in forthcoming commits will add
a third one. All those functions already have too many parameters, so
let's put together all the output params in a struct to pass them easily
and make it easier to understand they are the estimated output values.
Related: OS#4006
Change-Id: I05cfa0ceaa2e633a5e6e404e2eae497ff4442dea
This logic will be used once we support TRXDv1, where idle indications
are sent through the socket.
Related: OS#4006
Change-Id: I46404f6e4055b6d3af3afffb0dfe4a19502917aa
This will be needed upon forthcoming refactor to support idle frames,
which will add a goto return. Otherwise compiler complains:
error: jump to label ret_idle [-fpermissive]
note: crosses initialization of unsigned int max_toa
Change-Id: Icd2793adc7b73a795184639b95fb5da336909b59
Makes code easier to follow and will help in forthcoming refactoring
once idle frames are supported.
Change-Id: I56c84e9684ca460efd6c983d7e95d8e455bcac69
We have a good socket API in libosmocore, let's drop osmo-trx socket API
and use libosmocore's one instead of maintaining the two of them.
Change-Id: Ib19856a3e0a7607f63436c4a80b1381a3f318764
Make the interface using trx_ul_burst_ind more implementation agnostic
as well as easier to use. For instance, we don't care about SoftVector
size one returned from pullRadioVector(); we want to use nbits instead.
As a result, we no longer spend time normalizing guard periods. While at
it, change vectorSLicer to return void since it always returns true.
Change-Id: I726e5a98a43367a22c9a4ca5cbd9eb87e6765c7a
Use of that class is really not needed since we don't need to do any
calculation with those values, so we can simply store the final values
in the struct.
Related: OS#4006
Change-Id: Iadf2683d7f52138a2248598641f3b702252f325d
That's where all the filling logic happens, while in driveReceiveFIFO we
mostly want to take the burst, generate a message and sent it over the
socket.
Related: OS#4006
Change-Id: Ibfb48877af4ff5ef0f56390901669c8353beaf48
That's where all the filling logic happens, while in driveReceiveFIFO we
mostly want to take the burst, generate a message and sent it over the
socket.
In pullRadioVector this way we always provide normalized values based on
user configuration (VTY rssi-offset).
Related: OS#4006
Change-Id: I1ee28daf21dc287bec564d45d58086d63655c0f6
That's where all the filling logic happens, while in driveReceiveFIFO we
mostly want to take the burst, generate a message and sent it over the
socket.
Related: OS#4006
Change-Id: Ib1df10c40d737954904290f57d58b1c77d65f82e
That field is actually never used. Furthermore, if pullRadioVector()
returns false, then the caller should consider the 'trx_ul_burst_ind'
structure as uninitialized. Moreover, RSSI is mandatory - we cannot send
burst indications without it.
Related: OS#4006
Change-Id: Ia109298aebe8ba4750a39338ba7962555903cd82
A new struct trx_ul_burst_ind is introduced, which will handle
information filled by lower layers upon decoding of uplink bursts.
Methods pullRadioVector() and logRxBurst() are adapted to use that
struct. This way it's easier to understand in/out parameters and it's
also easier to add further parameters to be filled in in the future.
Related: OS#4006
Change-Id: I7e590fb1c0901de627e782f183251c20f4f68d48
The callback actually belongs there, since it's the code/thread in main the one
actually in charge of stopping everything. It simplifies current code,
and more important, allows for new clients of this signal to use it.
This callback will also be used in forthcoming commits by code
controlling rate_ctr thresholds to stop the process if the VTY
configured threshold is used.
Change-Id: Id4159e64225c6606fef34a74b24f37c3a071aceb
Since I838c21db29c54f1924dd478c2b34b46b70aab2cd we have both TS1
and TS2 synch. sequences, in addition to "default" TS0. Let's
finally introduce the VTY configuration parameter, that can
be used to toggle optional detection of both TS1 and TS2.
Note: we keep this optional because of potentially bad impact on
performance. There's no point in paying the performance penalty
unless upper levels (BTS, PCU) actually make use of it.
Change-Id: I1aee998d83b06692d76a83f79748f9129a2547e8
Related: OS#3054
This log category is applied to messages related to TRX CTRL socket
interface, and it's printed in yellow, same color used in osmo-bts-trx
for TRX category (so same messages are printed with same color in both
sides).
Change-Id: I98ec5e416272783ad3fbadf70478a4e48ae64983
osmo-trx can start a considerable amount of threads that can make
debugging it challenging at least. By using phtread_setname_np, the
system sets a meaningful name to the thread which can be seen while
debugging with gdb or by printing /proc/$pid/task/$tid/comm.
Now we also log system TID when setting the name so we can identify
different tasks in /proc even if pthread_setname_np fails.
Change-Id: I84711739c3e224cb383fd12b6db933785b28209e
Transceiver::stop() can only be called from either CTRL iface thread or
from main thread (running osmocom loop). That's because stop attempts to
cancel and then join all the other threads, which would then lock if
attempting to stop from some of them.
As a result, the best option is to indicate to the user of the
transceiver option (osmo-trx.cpp) to stop it in a correct fashion by
destroying the object from the main thread.
Change-Id: Iac1d2dbe2328e735db2d4b933cb67b1af1babca1
There was no a simple range check for both (NO)HANDOVER commands,
so an out-of-range access was possible. For example, a command:
CMD HANDOVER 0 -3
might enable EDGE at run-time, because:
a[i] == *(a + i)
Let's fix this.
Change-Id: I24a5f70e8e8097f218d7cbdef8cb10df2c35416f
It looks like the author of control command parsing code was not
familar with simple pointer arithmetics, so excessive amount of
memory and useless memcopying was used to parse a single command.
Let's introduce two pointers, one of which will point to the
beginning of a command, another to the beginning of its arguments.
Also, let's simplify the command matching by using a separate
function called 'MATCH_CMD'.
Change-Id: I226ca0771e63228cf5e04ef9766057d4107fdd11
Previously it was assumed that a sender should zero-terminate
each command being sent. Otherwise, this could cause to printing
garbage. Let's do this manually, using the length of received
data as a position for '\0'.
Change-Id: I69f413f33156c38a853efc5a8cdc66fbfb0ca6af
Stop calling writeClockInterface() when receiving commands in Transceiver::driveControl,
otherwise it fools osmo-bts-trx clock skew check because it is always sending a clock
indication with the same fn when it issues any commands during the time in between
CMD POWEROFF and RSP POWERON, because fn is not increased during that period.
Also use mForceClockInterface flag to delay delivery of first IND CLOCK until we start
serving frames, otherwise the first one is sent and only after a long period of time
the next clock indications are sent, when the radio starts to process bursts. That makes
osmo-bts-trx unhappy because it expects to receive an IND CLOCK aprox at least every
400 frames. This way also we send the first IND CLOCK after the RSP POWERON 0 response.
Change-Id: I91b81a4d7627cec39c1814a39ed4be306681b874
Upon issuing POWEROFF command to a running transceiver, UHD
interfacing thread state may become undefined if the device
is stopped with I/O threads still active. Bad behavior is
device dependent with only network based USRP devices
affected. USB based device thread behavior stops and shutdowns
as expected. Tested with N200, X300, and B210.
Tested solutions include the following:
1. Set pthread_setcanceltype() with PTHREAD_CANCEL_ASYNCHRONOUS
2. Add sleep delay to allow I/O threads to timeout before
stopping the device
3. Wait for I/O threads to join after cancellation before stopping
the device
This patch resolves the issue by with the third approach. Number 1
is not guaranteed to always work with UHD internals as driver code
may explicitly set thread parameters. Using sleep calls to fix
order-of-operation issues is almost never a good idea.
Change-Id: Ib72ab98a27a02084b040319046c92d1c4157ae4c
vectorSlicer() converts soft-bits from -1..+1 to 0..1 while we want
to keep SoftVector in -1..+1 mode until the last minute, because at some
point we'll want to transmit -1..+1 to osmo-bts instead of converting it
from 0..1 back to -1..+1 on the osmo-bts side.
Plus it removes code duplication - we call it once instead of twice.
Change-Id: Idd6ddd7ac219afb0df055a692632678b66373764
Place conditional brackets on handover table reset. Reset table
only on successful start or restart.
Change-Id: I74032b49785bd68835a0a68cb0f14cdaab4fcd26
Vadim Yanitskiy
Pau Espin
Eric Wild
Harald Welte