Subtracting uint32_t from uin32_t gives you uint32_t. And assigning result to a long doesn't make it a signed value, because on 64-bit Linux long is 64 bits.
(cherry picked from commit 82dd78d698)
* 'master' of git://openbts.git.sourceforge.net/gitroot/openbts/openbts:
gsm: Remove obsolete PCAP stuff from gsmtap.h
gsm: Update and enhance the GSM Tap functionality
gsm: Add same ARFCN()/typeAndOffset() accessors to L1Decoder than L1Encoder
gsm: Save time of received frame for later use in XCCHL1Decoder
gsm: Create more precise TypeAndOffset cste for BCCH/CCCH
transceiver: Fix misusage of ~ in bitfields
misc: Add a proper .gitignore file
build: Fix Transceiver/Makefile.am to use AM_CXXFLAGS instead of CXX_FLAGS
build: Remove all files autogenerated by autoreconf
Fix trivial conflict:
public-trunk/Transceiver/Makefile.am
* switch to the new format
* add uplink frame dump as well
* fill more fields than before (not fully complete yet tough)
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Somehow it seems the author tought using ~ would set that bit to 0. But
it invert all bits and as such set all others to '1'.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Best practice is to not include those in repositories but only
in tar.gz dist tarball.
autoreconf -i will regenerate them
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Fixes the following build error.
UHDDevice.cpp:462: error: ‘EVENT_CODE_SUCCESS’ is not a member of ‘uhd::async_metadata_t’
UHDDevice.cpp:507: error: ‘EVENT_CODE_SUCCESS’ is not a member of ‘uhd::async_metadata_t’
Reported-by: Dirk Kirsten <Dirk.Kirsten@uni-konstanz.de>
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
Fixes the following that occurs with recent uhd changes.
UHDDevice.cpp:260: error: ‘struct uhd::gain_range_t’ has no member named ‘max’
UHDDevice.cpp:260: error: ‘struct uhd::gain_range_t’ has no member named ‘min’
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
The underrun behaviour of the USRP2 is different from the USRP1, and
the adaptive latency mechanism is not directly transferable. Instead,
fix the latency with a higher starting value, which effectively
buffers more samples on the host in front of the Ethernet interface.
An alternative may be to use the adaptive approach with USRP2
specific upper and lower bounds. For now, just use preprocessor
directives until a better solution comes around.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
There should be a better way to do this. Only the USRP1 option
in non-loopback mode needs the swap.
UHD & !SWLOOPBACK: FLIP_IQ = 0
UHD & SWLOOPBACK: FLIP_IQ = 0
USRP1 & !SWLOOPBACK: FLIP_IQ = 1
USRP1 & SWLOOPBACK: FLIP_IQ = 0
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
Transceiver can be built with UHD by specifiying the --with-uhd
option. Fractional sample rates are not supported by the USRP2
so Transceiver52M is not built.
Otherwise, the default GNU Radio USRP1 implementation is used.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
This patch adds USRP2 device support and future support for
other UHD based devices. On receive, a sample buffer class,
which is indexable by timestamps, is used to temporarily
hold data until the requested samples are available.
On transmit, samples are sent immediately unless sample
alignment is known to be off - during startup or after the
occurrence of underruns or other errors. To regain
synchronization at these moments, timestamps are compared
against the current device time and dropped unless there
exists significant delay margin to physically arrive at the
device before deadline.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
Move essential interface components into an abstract Device class
and create a factory method for instantiating compile-time
specified derived types (USRP1 or UHD).
The radioInterface has a device specific type conversion call to
the USRP1 driver, so push that behind the Device interface too.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
Subtracting uint32_t from uin32_t gives you uint32_t. And assigning result to a long doesn't make it a signed value, because on 64-bit Linux long is 64 bits.
Alexander Chemeris
Sylvain Munaut