Transceiver52M: Add UHD device type checking

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>
Transceiver52M: Add device offset correction table

Previously, two timing correction values were used for UHD devices
depending on the sample rate of 270.833e3 or 400e3 for native GSM or
resampled device rate respectively. The correction values compensate
for residual timing effects due to analog component delays, filters
lag times, and general fudge factors. These values are device
specific and over-generalized by the two value configuration.

This patch adds the following struct to store these correction
values by device type and sample rate - through samples-per-symbol.

struct uhd_dev_offset {
        enum uhd_dev_type type;
        int sps;
        double offset;
};

Signed-off-by: Thomas Tsou <tom@tsou.cc>
Transceiver52M: Remove periodic alignment update from UHD build

Periodic timing alignment should never be required for UHD devices,
though the mechanism was used as a fallback mechanism should UHD
not properly recover after an underrun - as may occur in old
003.003.000 based revisions. This issue is not a concern in more
recent UHD releases and deprecates this code for legacy USRP1
use only.

Signed-off-by: Thomas Tsou <tom@tsou.cc>
Transceiver52M: Remove and rename oversampling variables

The transceiver only uses a single integer oversampling value,
which is more simply referred to as samples-per-symbol.

mRadioOversampling --> mSPS
mTransceiverOversampling (removed)

Signed-off-by: Thomas Tsou <tom@tsou.cc>
Transceiver52M: Set sample rate from within the radio device

The GSM transceiver only operates at a whole number multiple of
the GSM rate and doesn't care about the actual device rate and
if resampling is used. Therefore GSM specific portion of the
transceiver should only need to submit the samples-per-symbol
value to the device interface.

Then, the device should be able to determine the appropriate
sample rate (400 ksps or 270.833 ksps) and if resampling is
appropriate.

Signed-off-by: Thomas Tsou <tom@tsou.cc>
Transceiver52M: Set resampling option automatically based on device

Remove the built time resampling selection and link both options.
Move the normal push/pullBuffer() calls back to the base class and
overload them in the inherited resampling class.

USRP2/N2xx devices are the only devices that require resampling so
return that resampling is necessary on the device open(), which is
the point at which the device type will be known.

Signed-off-by: Thomas Tsou <tom@tsou.cc>
Transceiver52M: Allow tolerance in UHD sample rate selection

We're performance floating point comparisons so allow a
10 Hz offset when UHD does not return an exact sample rate;

Signed-off-by: Thomas Tsou <tom@tsou.cc>
Transceiver52M: Use exception blocks for rate changes

UHD will throw if something goes awry in these sensitive sections,
so we should catch and shutdown gracefully. There is no recovery
if we can't set rates.

Signed-off-by: Thomas Tsou <tom@tsou.cc>
Transceiver52M: Explicitly check for USRP2 device type

Before, we assumed that non-B100 device was implicitly a USRP2
(inclusive of N200/N210). Make the check explicit so that any
unknown device will causes an error and exit.

Signed-off-by: Thomas Tsou <tom@tsou.cc>
Transceiver52M: Add UmTRX support
multi-arfcn, trx: add header wrappers for radio interface

Signed-off-by: Thomas Tsou <ttsou@vt.edu>
multi-arfcn, trx: modify radio interface for multi-channel use

The radio interface needs to feed the device I/O buffers
synchronously in order to drive the channelizer. Asynchronous
channel access occurs opposite the radio interface through
a bank of thread-safe FIFO's or priority queue's on receive
and transmit sides respectively.

Setup 'M' channels and allow only a subset to be active at a
given time. When a channel is unused, there is no need to
feed the particular receive FIFO or pull data from the
channel priority queue.

Signed-off-by: Thomas Tsou <ttsou@vt.edu>
multi-arfcn, trx: split transceiver to handle multiple channels

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>
multi-arfcn, trx: add and modify transceiver main for new interfaces

Add a transceiver main() for multi-arfcn use and modify single
channel transceiver for use with updated interfaces.

Setup multiTRX with 3 channels for default case.

Signed-off-by: Thomas Tsou <ttsou@vt.edu>
transceiver: define virtual destructor for base device

Lack of an explicitly defined virtual destructor was
causing the empty default interface destructor to be
called, which created a memory leak at shutdown.

Signed-off-by: Thomas Tsou <ttsou@vt.edu>
multi-arfcn, trx: only deallocate radio resouces if started

Certain notable variables - sample buffers - are not
allocated until start(), which causes a segfault if the
transceiver is shutdown without the radio starting. Check
that the radio is 'started' before releasing in the
destructor.

Signed-off-by: Thomas Tsou <ttsou@vt.edu>
multi-arfcn, trx: remove unused attach call()

At one point an attach() call was used to connect
multiple transceivers to the radio interface. The
current approach is to pass the radio interface to
the transceiver instances through the constructor.
Remove the unused and deprecated call.

Signed-off-by: Thomas Tsou <ttsou@vt.edu>
multi-arfcn, trx: remove unused reset() call in drive loop

This call is a remnant of the Transceiver / DriveLoop split. The
empty call is never used.

Signed-off-by: Thomas Tsou <ttsou@vt.edu>
multi-arfcn, trx: allocate threads on heap and fix thread release

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>
multi-arfcn, trx: handle thread exiting on shutdown

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>