Age | Commit message (Collapse) | Author | Files | Lines |
|
Prior to this patch, osmo-trx relied totally on proper VTY configuration
being set in "rssi-offset" together with the RxGain set through TRXC in
order to provide correct Uplink RSSI measurements to bts-trx.
With this patch, RSSI is now by default calculated (in LMS and UHD
backends) based on the currently set RxGain, by providing empirically
discovered values. Still, for backward compatibility, the old
"rssi-offset" command will overwrite completely the per-default
calculated rssi offset.
A new optional parameter "relative" is added at the end of the
"rssi-offset" VTY command to flag the value as relative to the newly
per-default calculated value. This way specific setups (like adding a
LNA / RF fronted) can still be expressed while still keeping the
automatic per-default offset.
Related: OS#4468
Change-Id: I8ef78fd20c22c60d61bfb18d80a4a36df4fd6c20
|
|
Change-Id: Ifb43cb11f3e7a69b0a88f632f0a0c90ada7f939e
|
|
Related: SYS#4920
Change-Id: I39983d026ad54c479aa224968e9491d01f30dc35
|
|
This ones together with rate counters already available in lower layers
allows to understand better the source of the problem with stalled tx
bursts.
Change-Id: Ia34f7e7d780ad1e12f24638a07f05fe91f2afea5
|
|
This allows checking if there's timing issues on the downlink side
between osmo-bts-trx and osmo-trx. This counter is useful to find
information about osmo-bts-trx 'fn-advance' setting, since this counter
basically counts if burstrs from it arrived too late to osmo-trx.
Change-Id: Id6df00da81f6d6884f4dddc5a2c4b354dca3af97
|
|
There is no need to have n threads handle n ctrl sockets, since they all
will immediately respond to commands, so handle them from the existing
main osmo select loop.
Care must be taken to ensure that calls from within the command handler
do not block, or at least don't block too long, which currently is the
case.
Change-Id: I642a34451e1825eafecf71a902df916ccee7944c
|
|
Change-Id: I4ec7accb1912c052b446be7c399bed32a8c62253
|
|
BTS may have any timeslot disabled, or may have not yet sent initial
SETSLOT cmd to properly configure the timeslot.
Change-Id: Icf62e5d1200c7a440f255bb46023cdbf61532b7f
|
|
We don't want to keep osmo-trx running in a started state once the BTS
controlling it becomes unavailable. If a socket towards the BTS fails,
it means the BTS is gone and the best thing to do is to stop the process
(alternatively we could go back to stopped state instead, and wait for
BTS to re-connect, fur so far this action is good enough).
Related: OS#4170
Change-Id: I2ccbe3c17b39fb792ea7810f840235c348054d66
|
|
This code is not needed anymore since we are setting SCHED_RR scheduler
with a real time priority in main thread during startup, so all threads
will inherit same rt priority, which should be enough to keep the
process working reliably even on high system loads (from non rt
processes).
osmo-trx was tested to be reliable during test with stress-ng as
explained in related ticket below.
Related: OS#2344
Change-Id: I3a88946dd71e9aeeaac9d19d396e2236c302b608
|
|
TransceiverChannel naming was misleading there. It's simply a data type
used to pass 2 parameters through the void* of the thread entry
function, so let's clearly specify is a storage for thread params.
Furthermore, we don't need a full C++ class for that, let's simply use a
struct.
Change-Id: I6e3898a8a66520cc5b2a7df9b9ae01b0b272387f
|
|
The setting is negotiatied by osmo-bts-trx on each channel, so let's
keep and use state per channel instead of overwriting the state from
different channels.
Take the chance to change related log lines to also print the channel
number.
Change-Id: If9cf95e89d38d0155ab48b8c0977ca5f381c2aad
|
|
Related: OS#3515
Change-Id: I3719bd8dc015569ecd81928fc079e27593cdca09
|
|
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
|
|
This logic will be used once we support TRXDv1, where idle indications
are sent through the socket.
Related: OS#4006
Change-Id: I46404f6e4055b6d3af3afffb0dfe4a19502917aa
|
|
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
|
|
pullRadioVector()
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
|
|
Change-Id: Id752f6b5ce9a96a67cd1ff835687ce0e03d3a50d
|
|
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
|
|
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
|
|
This patch is a preparation for next patches, which add full VTY cfg
support.
Change-Id: I3d5b0576aa96869756f1629a40306c0043b6304b
|
|
Before this patch, the binding of the listening sockets was hardcoded to
a local IP.
Change-Id: I9ba184a1251c823e413a9230943ed263e52142ec
|
|
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
|
|
Change-Id: Ib3fbe768048b2a34a75ace9688e306720e67019a
|
|
Change-Id: I2cad47160e53f65612bd1da8998c83a0a22bce9b
|
|
Change-Id: I3cbe8e6e4f39dde02c945e6c9086c040e276845c
|
|
Required to move Transceiver::detectBurst to sigProcLib.
Change-Id: I3e0e74a98bbca4d19657f50a5fb447f078663c9b
|
|
The command line EDGE option will enable 8-PSK burst
detection on any slot where a normal burst is expected.
The burst search order is 8-PSK first followed by GMSK.
EDGE will force 4 SPS sampling on Tx and Rx. Along with
twice the search correlation from 8-PSK and GMSK, EDGE
will increase CPU utilization. Whether the increase is
notable or not is dependent on the particular machine.
Signed-off-by: Tom Tsou <tom.tsou@ettus.com>
|
|
Signed-off-by: Tom Tsou <tom.tsou@ettus.com>
|
|
Signed-off-by: Tom Tsou <tom.tsou@ettus.com>
|
|
used.
|
|
|
|
Previously MAXDLY value was applied to Normal Bursts, which was nice
when working with sloppy test equipment like CMD57, but useless for
real world usage. At the same time documentation and de facto usage
of MAXDLY in OsmoBTS and OpenBTS assumed that it actually applies to
Access Bursts (RACH). So this patch changes osmo-rx behavior to apply
MAXDLY to RACH bursts and introduces a new command MAXDLYNB for the
old behavior.
|
|
When EDGE is enabled with the '-e' option, the random burst generator
switches from GMSK normal bursts to 8-PSK EDGE bursts.
$ ./osmo-trx -e -r 7
Signed-off-by: Tom Tsou <tom.tsou@ettus.com>
|
|
Create EDGE slot type in the Transceiver. When EDGE mode is enabled
for a particular slot, blind detection will be performed by
correlating against EDGE followed by normal bursts if no EDGE burst
is found.
Signed-off-by: Tom Tsou <tom.tsou@ettus.com>
|
|
Allow setting the device to non single SPS sample rates - mainly
running at 4 SPS as the signal processing library does not support
other rates. Wider bandwith support is required on the receive path
to avoid 8-PSK bandlimiting distortion for EDGE.
Signed-off-by: Tom Tsou <tom.tsou@ettus.com>
|
|
DFE equalizer is unused and has been experiencing code rot for
multiple years. The effect is a significant amount of baggage being
carried in the Transceiver and interfaces.
Signed-off-by: Tom Tsou <tom.tsou@ettus.com>
|
|
Signed-off-by: Tom Tsou <tom.tsou@ettus.com>
|
|
Signed-off-by: Tom Tsou <tom.tsou@ettus.com>
|
|
Signed-off-by: Tom Tsou <tom.tsou@ettus.com>
|
|
We can't rely on an assumption that if we can't decode a burst - it's noise.
There are many rasons why we can't decode a burst even if it's well above the
noise level. Just one example is a RACH burst which can be overlapped with
another RACH burst up to a level both are completely unrecognizable. Another
example is when a burst is destroyed by bad multi-path.
Signed-off-by: Tom Tsou <tom.tsou@ettus.com>
|
|
There are two primary changes in this commit:
1) Return values of detect functions changed form bool to int to actually pass
the return value from the inner function and notify higher levels about clipping.
Previously the information was lost due to conversion to bool.
2) Clipping level is not the final verdict now. We still try to demod a burst
and mark it as clipped only if the level is above the clipping level AND we can't
demod it. The reasoning for this is that in real life we want to do as much as
possible to demod the burst, because we want to get as much from our dynamic
range as possible. So a little bit of clipping is fine and is expected. We just
don't want too much of it to break our demod.
Signed-off-by: Tom Tsou <tom.tsou@ettus.com>
|
|
Signed-off-by: Tom Tsou <tom.tsou@ettus.com>
|
|
Signed-off-by: Tom Tsou <tom.tsou@ettus.com>
|