Commit 90f7a01d lost "return" statement. We also should account the fact that
offset can be negative.
We should return the tuning request immediately after
Signed-off-by: Tom Tsou <tom.tsou@ettus.com>
Rounding error introduced oscilating timing advance error by regularly
overwriting one bit and then skipping one bit.
This commit also adds an error message to show up in logs if this ever
happens again.
Signed-off-by: Tom Tsou <tom.tsou@ettus.com>
Previous behaviour used UHD command line args string for device search,
but did not apply the values to the device constructor. Now use the user
passed args string for both find and device construction.
Signed-off-by: Tom Tsou <tom.tsou@ettus.com>
New UHD versions support split configuration of Tx gain stages.
We utilize this to set the gain configuration, optimal for
the Tx signal quality. From our measurements, VGA1 must be
18dB plus-minus one and VGA2 is the best when 23dB or lower.
Signed-off-by: Tom Tsou <tom.tsou@ettus.com>
Frequency tuning is a multi-step process with RF and DDC/DUC protoimns
that can be corrupted if both channels attempt to tune at the same time.
Signed-off-by: Tom Tsou <tom@tsou.cc>
Treat X300 similar to N200 and resample with 100 MHz base clocking,
which provides some amount of oversampling for reduced phase error
compared to the 1 sample per symbol receiver. Treat E310 similar to 13
MHz rate devices for the lowest computational use.
Signed-off-by: Tom Tsou <tom@tsou.cc>
Add stop and restart capability through the POWEROFF and POWERON
commands. Calling stop causes receive streaming to cease, and I/O
threads to shutdown leaving only the control handling thread running.
Upon receiving a POWERON command, I/O threads and device streaming are
restarted.
Proper shutdown of the transceiver is now initiated by the destructor,
which calls the stop command internally to wind down and deallocate
threads.
Signed-off-by: Tom Tsou <tom@tsou.cc>
Existing implementation outputs sample buffer parameters, but it is
helpful to know the submitted timestamp that led to the errant
condition.
Signed-off-by: Tom Tsou <tom@tsou.cc>
Device specific timing settings for the E100 and E110 were missing from
the Tx/Rx offset table. Add E1XX identifier and offsets to the device
list and offset table respectively.
Signed-off-by: Thomas Tsou <tom@tsou.cc>
UHD requires a small amount of time to align multiple streams at
startup. Delay the startup by 100 ms relative to the queried device time
(actual delay inclusive of control latencies will be less).
The following error is only relevant to dual-channel UHD devices (e.g.
Fairwaves UmTRX and Ettus B210).
UHD Error:
The receive packet handler failed to time-align packets.
1002 received packets were processed by the handler.
However, a timestamp match could not be determined.
Signed-off-by: Thomas Tsou <tom@tsou.cc>
Recent versions of UHD require setting the sample rate before creating
streamers otherwise the following exception occurs.
Boost_105300; UHD_003.007.000-0-g7fef199d
terminate called after throwing an instance of
'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::math::rounding_error> >'
what(): Error in function boost::math::round<d>(d): Value -nan can not be represented in the target integer type.
Signed-off-by: Thomas Tsou <tom@tsou.cc>
Allow command line setting of the DSP frequency in UHD. All channels
will be tuned with the same offset. Dual-channel tuning with the B210,
which uses a single LO, will override the command line offset value
and set the DSP frequency automatically.
Signed-off-by: Thomas Tsou <tom@tsou.cc>
The main difference between existing UmTRX dual channel is the
single LO on B210 transmit and receive front-ends vs. independent
tuning paths. In order to support dual-ARFCN frequencies, baseband
offset conversion must be applied by tuning the FPGA CORDIC for
each channel. For B210, the following tuning order is applied.
1. If the new frequency of channel A is within the baseband range
of channel B, then retune both channels with the RF centered
and equal valued positive and negative baseband shifts.
2. If the new frequency of channel A is not with the baseband range
of channel B, then retune channel A directly (without manual
applied offset). Channel B will no longer be tuned to the
previous frequency.
Signed-off-by: Thomas Tsou <tom@tsou.cc>
With dual-channels on B210, we lose the ability to reset both
channels to a synchronized state. Instead, let the timestamp
clock start with an arbitary value, which is the first
timestamp received from the device, instead of a near-zero
value. This approach also makes integration for device, in
general, with free-running timestamp clocks.
Signed-off-by: Thomas Tsou <tom@tsou.cc>
Change from the original USRP1 rate of 52 MHz. On B2XX we can use
26 MHz, which is closer to the default 32 MHz of the device.
Signed-off-by: Thomas Tsou <tom@tsou.cc>
On startup errors we get a segfault if we stop and shutdown. This
is because we try to send a stop stream command to the device before
it has been created. Setup a check for running status before
attempting to stop the physical device.
Signed-off-by: Thomas Tsou <tom@tsou.cc>
This patch add support for dual channel diversity on the receive
path. This allows two antennas two shared antennas to be used for
each ARFCN handling channel in the receiver. This configuration
may improvde performance in multi-path fading environments,
however, noise andpotential interference levels are increased due
to the higher bandwidth used.
The receive path is oversampled by a factor of four for a rate
of 1.083333 Msps. If the receive paths are tuned within a
maximum channel spacing (currently set at 600 kHz), then both
ARFCN frequencies are processed by each channel of the receiver.
Otherwise, the frequency shifted diversity path is disabled and
standard non-diversity operation takes place.
Diversity processing is handled by selecting the path with the
higheset energy level and discarding the burst on the second
path. Selection occurs on a burst-by-burst basis.
Signed-off-by: Thomas Tsou <tom@tsou.cc>
As we add more channel combintions including but not limited to
new devices, signal processing schemes, and diversity, we'll
need to handle more special cases. Add string descriptions for
just a bit more sanity.
Signed-off-by: Thomas Tsou <tom@tsou.cc>
With testing on current UHD releases, currently 003.005.xxx series,
timeout errors on both receive and transmit are recoverable on network
and USB based devices. Remove the fatal error conditions.
Signed-off-by: Thomas Tsou <tom@tsou.cc>
B2xx is a USB based device so use the USRP1 based adaptive flow
control window for transmit bursts. This adds additional stability
primarily on ARM platforms.
Signed-off-by: Thomas Tsou <tom@tsou.cc>
This patch primarily addresses devices with multiple RF front end
support. Currently device support is limited to UmTRX.
Vectorize transceiver variables to allow multiple asynchronous
threads on the upper layer with single downlink and uplink threads
driving the UHD I/O interface synchronously.
Signed-off-by: Thomas Tsou <tom@tsou.cc>
Underruns are only explicitly set on the downlink side. Overruns
are logged but unused. In either case, reset indicators to false
to avoid sending false state information.
Signed-off-by: Thomas Tsou <tom@tsou.cc>
Enabling the external reference on UHD devices through the configure
time switch is awkward. Use a database variable "TRX.Reference" with
'0' or '1' value for internal and external references respectively.
Use internal reference is no entry is defined.
Signed-off-by: Thomas Tsou <tom@tsou.cc>
We want to push UHD logs to the OpenBTS logging system, but most
device errors occur at startup, so keep the output on stdout until
after device initialization. That way obvious errors are easily
viewable before seeing the useless TRX timeout message.
Signed-off-by: Thomas Tsou <tom@tsou.cc>
Move B100 to the resampling interface with default
clocking. This temporarily resolves undetermined
FPGA clocking issues. This also provides extensible
support for multiple clocking rates and resampling
ratios.
Signed-off-by: Thomas Tsou <tom@tsou.cc>
This patch applies oversampling, when selected with 4 sps,
to the downlink only, while running the receiver with
minimal sampling at 1 sps. These split sample rates allow
us to run a highly accurate downlink signal with minimal
distortion, while keeping receive path channel filtering
on the FPGA.
Without this patch, we oversample the receive path and
require a steep receive filter to get similar adjacent
channel suppression as the FPGA halfband / CIC filter
combination, which comes with a high computational cost.
Signed-off-by: Thomas Tsou <tom@tsou.cc>
Set master clock rate to 52 MHz for B200. Also, we want to avoid
floating point comparison errors on clock rate settings, but we
expect to be able really set the rates we specify. Set the
offset limit to 1 Hz. If we can't set our rates with that level
of precision, then something is wrong.
Signed-off-by: Thomas Tsou <tom@tsou.cc>
Provides substantially improved transmit phase error
performance when enabled. Requires use of 4 samples
per symbol, and is enabled by default when set.
Signed-off-by: Thomas Tsou <tom@tsou.cc>
If there is an error in the sample rate determination, noted
by a negative return sample rate value, error directly and
don't try to set the device rate.
Signed-off-by: Thomas Tsou <tom@tsou.cc>
Replace the polyphase filter and resampler with a separate
implementation using SSE enabled convolution. The USRP2 (including
derived devices N200, N210) are the only supported devices that
require sample rate conversion, so set the default resampling
parameters for the 100 MHz FPGA clock. This changes the previous
resampling ratios.
270.833 kHz -> 400 kHz (65 / 96)
270.833 kHz -> 390.625 kHz (52 / 75)
The new resampling factor uses a USRP resampling factor of 256
instead of 250. On the device, this allows two halfband filters to
be used rather than one. The end result is reduced distortial and
aliasing effecits from CIC filter rolloff.
B100 and USRP1 will no be supported at 400 ksps with these changes.
Signed-off-by: Thomas Tsou <tom@tsou.cc>
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>
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.
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>
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>
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>
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>
This patch is long overdue and can now be merged after better understanding
of timestamp stability issues. UHD tick / timespec conversions were
generally used with the streamer interface, though these calls are actually
independent change sets. The combination would lead to internal rounding
errors and a timing drift most notably on B100 running at GSM symbol
rate multiples. There are no known issues, however, with the streamer code
itself.
The aforementioned issue was discovered in test code only, which was never
merged to mainline.
Signed-off-by: Thomas Tsou <tom@tsou.cc>
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
UHD accepts optional 'args' that can be used for device descriptions
such as IP address, device type, etc. Allow these to be passed in on
the transceiver command line as the third argument (number of supported
carriers is the second argument). This option benefits those who may
have multiple UHD devices attached to a single system.
This option is not yet supported by GSM core and requires starting the
transceiver independently on the command line. This option has no
effect when USRP1 is used.
Signed-off-by: Thomas Tsou <tom@tsou.cc>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@4315 19bc5d8c-e614-43d4-8b26-e1612bc8e597
Alexander Chemeris