Also note that we introduced shutdown() method for Transceiver threads which
implement proper shutdown of threads when they are in blocking read state.
This involves using shutdown() on sockets and pushing NULL to queues.
With this change we should be able to start/stop transceiver channels at
arbitrary moments.
This patch aligns the multicarrier (MC) USRP code with
released GSM core changes that accommodate the MC RAD1.
Primary changes are:
1. Runtime setting of number of channelizer paths
2. Matching channelizer path to ARFCN mapping of GSM core
3. Use a single clock update socket on the drive loop
4. Match transceiver data and control socket ports
Setting of channelizer paths (or width) was previously fixed
at compile time. In either case, channelizer width is limited
by the sample rate of the device and channel spacing of the
maximally decimated filterbank. Available settings are 1, 5,
and 10 channels, which accommodate any number of ARFCN's in
between. Also add the frequency offsets to handle the effective
shift in setting RF frequency.
Previous assumption was to place C0 at the center frequency,
but RAD1 assumes C0 at the leftmost carrier, so adjust
accordingly.
The rest is general consolidation to mostly match the RAD1
interaction with GSM core. There is some loss of flexibility to
run, say, multiple independent instances of OpenBTS through a
single bank of channelized transceivers. But, the better
compatibility and reduction in code is the appropriate tradeoff.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
The original split-transceiver abstraction did not maintain
internal instances of the radio interface or drive loop.
The FIFO's were attached through external calls. The control
loop, however, made such an approach overly difficult, so
the transceiver now maintains pointers to the aforementioned
objects. In doing so, we no longer need external attachment
calls to setup the FIFO's.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
This fixes a bug where the energy threshold may reach infinity.
The transceiver energy detection threshold increase is
dependent on elapsed frames and the previous false detection
time. If we assume a (0,0) start time with the actual start
time - randomly determined - it's possible to get very
large elapsed frame counts at start. Once the threshold hits
'inf' further calculations are impossible and transceiver
is locked out from use.
Use the actual start time for initializing variables so
we avoid this scenario.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
Previous approach was to allow stack unwinding to take care
shutdown and thread ending, which was unpredictable and
occasionally segfault. Attempt to shutdown more gracefully.
There are thread cancellation points in the transceiver code
using pthread_testcancel(), but the thread abstraction library
does not allow direct access to the pthread variables. This
prevents thread shutdown through pthread_cancel(). To get
around this, use boolean status values in the receive socket
service loops and main drive loop.
The socket read calls will block indefinitly, so shutdown
may cause the socket implementation to throw a SocketError
exception. Use of timeout values with reads does not seem to
work correctly or reliably, so catch the exception and ignore
if it occurs on shutdown.
The following error may appear as the socket is shutdown while
the Transceiver is blocking on read().
DatagramSocket::read() failed: Bad file descriptor
So be it; the API doesn't allow us to do any more.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
The underlying pthread of the Thread object isn't created until
Thread::start(). If the Thread object is contructed, but not
started, then the destructor will fail with a variety of
unpredictable errors such as the following or double free() in
certain cases.
Program received signal SIGSEGV, Segmentation fault.
__GI___libc_free (mem=0x3811abed3e946178) at malloc.c:2972
2972 if (chunk_is_mmapped(p))
If the Thread object is stack allocated, but start() isn't called,
destructor is guaranteed to run and will fail. The previous
approach was to dynamically allocate threads, but not free them,
thus avoiding memory errors, but creating memory leaks.
To get around this limitation, dynamically allocate Thread objects
and initialize with NULL. Then allocate immediately prior to start
such that pthread allocation is tied to the Thread object
constructor. Deallocation can check that the Thread pointer is
valid through NULL or other tracking methods.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
This patch separates the 'Transceiver' into a multi-channel
I/O component and single channel component. The latter may
may have multiple instances. The receive FIFO is converted to
a thread-safe queue.
The 'TransceiverIO' continuously drives the receive and transmit
loops. In this process, bursts are driven into thread-safe FIFO's
and read from the priority queues. Filler bursts are inserted if
no transmit data is available.
Each 'Transceiver' instance attaches to the I/O object and creates
its own threads and sockets, which include blocking on the receive
FIFO for the attached channel. Each instance also handles its own
control loop and clock indications.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
UHD device type was previously detected, but only categorized in
terms of bus type, USB or Ethernet, and sample rate capability.
With the number of supported device increasing, we can no longer
easily group devices since we need to handle more and more
device-specific peculiarities. Some of these factors are managed
internally by the UHD driver, but other factors (e.g. timing
offsets) are specific to a single device.
Start by maintaining an enumerated list of relevant device types
that we can use for applying device specific operations. Also
rename the USB/Ethernet grouping to transmit window type because
that's what it is.
enum uhd_dev_type {
USRP1,
USRP2,
B100,
NUM_USRP_TYPES,
};
Signed-off-by: Thomas Tsou <tom@tsou.cc>
Although currently unsupported in GSM core, enable TCH/H
support in Transceiver52M for testing and future availability.
Signed-off-by: Thomas Tsou <tom@tsou.cc>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@5169 19bc5d8c-e614-43d4-8b26-e1612bc8e597
The adaptive energy detection threshold does not scale relative
to signal level. In other words, the adjustment factor will be
the same whether the at 40% of signal level or 4%. If the receive
gain is reduced by a large amount, suppose 20 dB, the receiver
may take minutes to adjust to the new level.
When the receive gain is changed, reset the threshold back to
the initial level. This reduces issues of runtime gain adjustment
and prevents blocking bursts while the threhold level slowly
adjusts.
Signed-off-by: Thomas Tsou <tom@tsou.cc>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@4595 19bc5d8c-e614-43d4-8b26-e1612bc8e597
1)I did an experiment and compiled OpenBTS with clang yesterday, which
immediately highlighted two potential bugs in the Transceiver52 code.
I'm not sure they are indeed bugs and not the intended behavior, but
they look very much like that. The first one is below and the second
one is in the following mail.
GSM::Time() arguments are defined like #define USB_LATENCY_INTRVL
(10,0), which means that they are expanded into GSM::Time((10,0)).
This expression is a GSM::Time() with a single parameter where (10,0)
return value of the last argument, 0 in this case. I.e.
GSM::Time((10,0)) is equivalent to GSM::Time(0). I think this was not
the intention.
2) Printing \n after every complex number breaks output when you want to
print it in a single line, e.g. in many debug output.
I do not claim any copyright over this change, as it's very basic.
Looking forward to see it merged into mainline.
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@4515 19bc5d8c-e614-43d4-8b26-e1612bc8e597
Put a floor on the transmit latency of the B100 in order to suppress
underruns in typical conditions. Empirical data from a handful of
relatively recent machines shows that the B100 will underrun when
the transmit threshold is reduced to a time of 6 and a half frames,
so we set a minimum 7 frame threshold.
The overall benefit should be marginal and may increase the
possibility of bursts arriving stale (after the trasmit deadline),
but will reduce the number of alarming UHD related messages that
appear in the log file.
This patch is UHD and B100 specific - USRP1 is unaffected.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@3980 19bc5d8c-e614-43d4-8b26-e1612bc8e597
With the introduction of the B100, there is USB support
using UHD devices. The characteristics of the trasmit
side burst submissions are more reflective of the bus
type than the device or driver.
Use a fixed latency interval for network devices and the
adaptive underrun approach for USB devices - regardless
of driver or device type.
The GPMC based transport on the E100 appears unaffected
by either latency scheme, which defaults to network.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2677 19bc5d8c-e614-43d4-8b26-e1612bc8e597
If no bursts were received over a long enough duration
then the threshold would roll into negative territory.
The energy detection is based on a comparison with the
squared threshold, so all handsets would become
effectively barred after a certain period of
inactivity.
In theory, this bug also exists in the mainline tree,
but there the daughterboard receive gain is fixed at
max, which always allows the ADC to generate sufficient
noise to trigger the energy dectector and keep the
system in a valid steady state.
To fix, simply add a negative value check like those
already in place for other locations.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2655 19bc5d8c-e614-43d4-8b26-e1612bc8e597
UHD will internally accept floats with a range of +/-1.0,
which corresponds to a 16-bit signed integer range of
apporximately +/- 32000. Set the default amplitude to .3,
which is a safe value agaist saturation elsewhere in the
transmit chain.
The non-UHD maximum amplitude is unchanged at 13500.
Remove digital gain control because it's unnecessary and
causes extra load on enbedded systems.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2654 19bc5d8c-e614-43d4-8b26-e1612bc8e597
The output of the modulator or resampler is scaled and
converted from floating point to fixed point. The scaling
factor is the leftover dB in RF attention (relative to max
transmit power), which is handled prior to the integer
conversion. This should work across all daughterboards and
non-UHD installations.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2650 19bc5d8c-e614-43d4-8b26-e1612bc8e597
Similar to the non-52 Mhz case,
589dd9091ef594ef6ef5804fbf6bfa70f3f02858
This drastically reduces underruns on the E100.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2648 19bc5d8c-e614-43d4-8b26-e1612bc8e597
Push the ability to set thread priority out to the 52M
Transceiver interface, because that's where the thread
control exists.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2644 19bc5d8c-e614-43d4-8b26-e1612bc8e597
Alexander Chemeris