| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
The FPGA GPIO registers don't exactly match the pin numbering on the
front panel and in the docs. This commit changes the algorithm so that
the API presented to the user matches the front panel.
|
| |
|
|
|
|
|
|
|
|
| |
This commit disables x4xx_radio_block_test on macOS
because the platform has stricter casting and symbol
export rules, which causes this test to fail.
Signed-off-by: Steven Koo <steven.koo@ni.com>
|
|
|
|
|
| |
Add SPI Core host implementation for x410 and a discoverable
feature to make it accessible.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Throughout UHD, we are using a random mix of __FUNCTION__, __func__,
__PRETTY_FUNCTION__, and BOOST_CURRENT_FUNCTION. Note that the first two
macros are non-standard (although many compilers understand them), and
the last requires Boost. __func__ is available since C++11, but is not
the best choice because the C++ standard doesn't require it to be of any
specific value.
We thus define UHD_FUNCTION and UHD_PRETTY_FUNCTION as portable macros.
The former simply contains the undecorated function name, the latter the
expanded function with full signature.
As it happens, our currently supported compilers didn't have any issues
using non-standard macros, so the main fix here is the removal of the
Boost macros and the harmonization of the other macros.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem was that TwinRX has a special LED configuration (unlike most
other daughterboards): Since it has two channels, it is possible to
stream RX from both SMA ports. In that case, we would light up both LEDs
in green (which was not happening, only one LED would light up,
depending on which antenna was set last).
This fixes the problem and turns on both LEDs when both channels are
used, and both SMA ports are selected.
Note that the reason for this issue was an incorrect porting of this
code from UHD 3. There, we had separate LED ATR objects per channel.
|
| |
|
|
|
|
|
|
|
| |
The E3xx devices have one LO per TX/RX, respectively. That means when
changing the frequency on channel 0, the frequency on channel 1 also
gets changed. The code didn't track this change properly: When setting
channel 1, channel 0's frequency didn't match.
|
|
|
|
|
|
|
|
|
|
| |
The host code was calculating and programming a 32-bit value for the DSP
frequency, but the DDS modules in the FPGA only use the upper 24-bits.
This led to inaccurate frequency values being returned. This change
corrects the resolution of the value on the host side so an accurate
value is returned.
Signed-off-by: michael-west <michael.west@ettus.com>
|
|
|
|
|
| |
This change simply refactors these methods so that the core of the algorithm
is no longer duplicated between them.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have noticed that on 1 GbE connections, MTU discovery can become
unreliable. Since we now use the MTU directly for deriving spp and other
values, a correct MTU is important.
Because we don't have a way of knowing if MTU discovery worked or not,
we add some heuristics in form of a plausibility check. For now, the
only rule in this check is if that the detected MTU is a bit larger than
1472 bytes, we coerce down to 1472, because this is such a standard
value (most 1 GbE interfaces default to an IPv4 MTU of 1500 bytes).
For the cases where the interface MTU is set to be between 1500 and 1528
bytes, this would cause a very minor performance loss. We accept this
performance loss as it is small, and those cases are very rare. MTUs are
usually 1500 bytes, or >= 8000 bytes for high-speed links using jumbo
frames.
|
|
|
|
|
|
|
| |
This constant was generally harmful, since it was only correct under
certain circumstances (64 bit CHDR with timestamps). The X3x0 code was
the last place it was being used, and we remove it without substitute
because it was not doing anything useful here.
|
|
|
|
|
|
|
| |
Getting the time from the mb_controller is slow, so try to get the time
from the Radio on the fast path first.
Signed-off-by: michael-west <michael.west@ettus.com>
|
|
|
|
|
|
|
|
|
|
| |
The times on the device can glitch if either the tick rate changes or
the number of active chains changes. This throws off the time if the
user gets streamers, changes the sample rate, or changes the tick rate
after synchronizing the time. This change re-synchronizes the times
automatically in those cases.
Signed-off-by: michael-west <michael.west@ettus.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
This gets closer to what our hardware can actually support. See the
comments for further explanations.
This has the side-effect of patching an issue on X410 (using 200 MHz
images) where garbage samples would get injected (one per packet). It
is not, however, the final fix for that problem.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements the GPIO API for X410 through get_gpio_attr and
set_gpio_attr. In ATR mode, which channel's ATR state is chosen by the
set_gpio_src call, setting e.g. DB0_RF0 for channel 0 or DB0_RF1 for
channel 1. In manual mode, all 24 bits (for both ports) are set in
a single register write.
Although the front panel of the device has two ports, labelled GPIO0 and
GPIO1, this API exposes them as though they were a single 24-bit GPIO
port.
|
|
|
|
|
|
|
| |
Refactors register addresses into a gpio_atr_offsets structure which
contains the various register addresses. This allows creating other
devices with different GPIO register layouts with greater ease, and
eliminates the use of macros (yay!)
|
|
|
|
| |
Thanks to Mait for pointing these out!
|
|
|
|
|
|
|
|
|
| |
In multiple places in the UHD code, we were doing the same calculation
for a wrapped frequency (wrap it into the first Nyquist zone). This math
was using boost::math, too. Instead of editing every instance, we create
a new function, uhd::math::wrap_frequency(), and replace all of its
separate implementations with this function. The new function also no
longer relies on boost::math::sign.
|
|
|
|
| |
Replaced by std::numeric_limits<>.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a very mechanical task that could almost have been done with
sed. Boost versions of mutexes and locks were removed, and replaced with
std:: versions. The replacement tables are as follows:
== Mutexes ==
- boost::mutex -> std::mutex
- boost::recursive_mutex -> std::recursive_mutex
Mutexes behave identically between Boost and std:: and have the same
API.
== Locks ==
C++11 has only two types of lock that we use/need in UHD:
- std::lock_guard: Identical to boost::lock_guard
- std::unique_lock: Identical to boost::unique_lock
Boost also has boost::mutex::scoped_lock, which is a typedef for
boost::unique_lock<>. However, we often have used scoped_lock where we
meant to use lock_guard<>. The name is a bit misleading, "scoped lock"
sounding a bit like an RAII mechanism. Therefore, some previous
boost::mutex::scoped_lock are now std::lock_guard<>.
std::unique_lock is required when doing more than RAII locking (i.e.,
unlocking, relocking, usage with condition variables, etc.).
== Condition Variables ==
Condition variables were out of the scope of this lock/mutex change, but
in UHD, we inconsistently use boost::condition vs.
boost::condition_variable. The former is a templated version of the
latter, and thus works fine with std::mutex'es. Therefore, some
boost::condition_variable where changed to boost::condition.
All locks and mutexes use `#include <mutex>`. The corresponding Boost
includes were removed. In some cases, this exposed issues with implicit
Boost includes elsewhere. The missing explicit includes were added.
|
|
|
|
|
|
|
|
|
|
| |
As GitHub user marcosino points out, we're running the AD9361 in
overclocked mode. This is because the driver was written with no longer
valid recommendations.
We add a comment and some debug messages to clarify this. Should there
be RF impairments (signal integrity or other) because of overclocking,
users would be able to check DEBUG log statements to correlate with
overclocked configurations.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous behaviour of UHD for setting gain was:
1. Set "Mask Clr Atten Update". This will avoid "Immediately Update TPC
Atten" to be cleared.
2. Then, assert "Immediately Update TPC Atten".
3. Poke the LSBs of the attenuation value.
4. Poke the MSB of the attenuation value.
This order of operations has the downside of causing large Tx power
spikes when setting the attenuation, because you need both registers to
properly set the attenuation, but we are updating the gain immediately,
even between the two attenuation register's update.
Moreover, the upstream Linux driver for AD9361 by ADI also does not
do this. We therefore change the procedure to match the kernel driver
behaviour, which is:
0. [During initialization: Clear "Mask Clr Atten Update"
1. Poke the attenuation registers
2. Then, assert "Immediately Update TPC Atten".
This avoids Tx power spikes. It also reduces the Tx-gain procedure to
3 pokes instead of 4.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So, both the set_tx_antenna_switches and set_rx_antenna_switches functions
configure the TX0_ANT_11 register (which controls the final switch before
the TX/RX port, switching it between the three TX paths and the RX path).
The RX antenna configuration code will, if the RX antenna is set to TX/RX,
configure that switch to the TX/RX->RX path when the ATR is set to RX.
However, the TX antenna config code will always configure that switch to
the "bypass" path, for both the 0X and RX ATR modes, regardless of whether
the RX side actually needs that path.
Ergo, this change makes set_tx_antenna_switches only configure that
switch when it is configuring the XX or TX modes.
|
|
|
|
|
| |
Error message was not adapted when support for 11.52 MHz and 23.04 MHz
references was added. Fixing this.
|
| |
|
|
|
|
|
| |
This allows UHD clients to determine, for example, whether the currently
loaded filesystem is up-to-date.
|
|
|
|
|
| |
Fix function definition set_rx_iq_balance so that Python can reach the
overloaded C++ function. There was a copy & paste error in there.
|
|
|
|
|
| |
This modifies some log messages or exception strings when using
auto-correction APIs that are not supported by the underlying device.
|
|
|
|
|
|
|
|
| |
N320 doesn't have an automatic RX IQ balance correction, so that API is
removed.
The auto-DC offset correction was calling into the manual DC offset
correction code, which means auto-DC offset correction was never enabled
for N320.
|
|
|
|
| |
It held the same value as MAX_RATE_10GIGE due to a typo.
|
| |
|
|
|
|
|
|
|
| |
In x300_eth_mgr.cpp the variable init is created but not initialized.
Only some of the variables within the struct are then set before init
is assigned to a different variable. Initialize the variable to
prevent unexpected values.
|
|
|
|
|
|
|
| |
- Use FPGA images with fixed sc12 converter.
- Properly flush channels and restart streaming in the case of an overrun.
Signed-off-by: michael-west <michael.west@ettus.com>
|
|
|
|
|
|
|
|
|
| |
In days of yore, before we had evolved RFNoC to the UHD 4.0 state, only
one radio on N310 was able to drive the front-panel GPIOs. With the
introduction of the UHD 4.0 GPIO API, we have fine-grained control for
every pin who may drive it. This makes this constant obsolete, and we
remove it to avoid confusion. Besides, these two `constexpr` values
where being used nowhere.
|
|
|
|
|
|
|
|
|
| |
`std::abs` is only a templated function, when dealing with complex
numbers. For real values, it is an overload. There is no
documented standard way to use `std::abs<double>()` for real-valued
arguments. We therefore remove all usages of `std::abs<>()` and
replace them with `std::abs()` where they were taking a real-valued
argument.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This serves two purposes:
- This file no longer goes into the compiled DLL if B200 is disabled
- Discourage use of this file for new devices, making it clear that this
architecture is no longer used
The file itself is left untouched, only the class is renamed from
radio_ctrl_core_3000 to b200_radio_ctrl_core.
Note: In UHD 3, this file was also used by N230.
|
|
|
|
|
|
| |
In 26cc208, we accidentally added an `auto` into a loop, making the loop
variable's scope local. However, this variable lives outside this for
loop.
|
|
|
|
|
|
|
| |
meta_range_t(0,0) actually calls the iterator-based constructor for
meta_range_t, which is almost certainly not the intended constructor
for that call syntax. Therefore, we add a static_assert to prevent
such usage, and fix all failing instances.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
YA Boost removal!!!
Justification
---
const int if_freq_sign = boost::math::sign(fe_conn.get_if_freq());
_dsp_freq_offset = if_freq * (-if_freq_sign);
// boost::math::sign : 1 if x > 0, -1 if x < 0, and 0 if x is zero.
// ==> if if_freq_sign > 0 then * by -1 else +1 (effectively)
// std::signbit : true if arg is negative, false otherwise
// ==> need 'not' of input argument to invert for same result as prior algorithm
double fe_if_freq = fe_conn.get_if_freq();
if (!std::signbit(fe_if_freq)) {
if_freq *= -1.0;
}
---
The above should result in the same algorithm except possibly
if fe_if_freq is exactly 0.0 in which case the results might be
off by the sign (+0.0 versus -0.0).
|
| |
|
| |
|