| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
Make sure no active components are connected to the TX frontend during
next boot. This avoids configurations that could generate unwanted tones
during operations such as the Mykonos init cals.
Signed-off-by: mattprost <matt.prost@ni.com>
|
| |
|
|
|
|
|
|
|
| |
The FSRU (aka EISCAT) was never supported in UHD 4.0. The FPGA
repository never had the relevant files, and the block controller also
never existed. This removes all the corresponding files from MPM, as
well as some references from makefiles.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Throughout UHD, we often do floating-point comparisons for frequency
ranges that require resilience to floating point rounding errors. Most
of the time the checks look like this:
```cpp
if (fp_compare_epsilon<double>(freq) > boundary) {
// ...
}
```
The exception is the N320 daughterboard control, which uses a custom
epsilon:
```cpp
if (fp_compare_epsilon<double>(freq,
RHODIUM_FREQ_COMPARE_EPSILON) > boundary) {
// ...
}
```
This was, for the most part, not by design, but because authors simply
didn't think about which epsilon value was appropriate for the frequency
comparison. This was complicated by the fact that fp_compare_epsilon
previously had some issues.
This patch introduces FREQ_COMPARE_EPSILON, which is a sensible default
value for fp_compare_epsilon when doing frequency comparisons (note that
fp_compare_delta already had such a value).
Also, it introduces freq_compare_epsilon(x), which is a shorthand for
fp_compare_epsilon<double>(x, FREQ_COMPARE_EPSILON).
We then replace all occurrences of fp_compare_epsilon<double> which are
specific to frequency checks with freq_compare_epsilon.
|
|
|
|
|
| |
This allows viewing or, conceivably, customizing the tuning table that
ZBX uses, depending on the particular needs of the end user.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
| |
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!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
This Boost header is included in some places, despite not being used.
|
|
|
|
|
|
|
| |
Its behaviour is almost identical to std::lround, which we use instead.
The only downside of std::lround is that it always returns a long, which
we don't always need. We thus add some casts for those cases to make the
compiler happy.
|
|
|
|
|
| |
The TRACE message is repeated in the zbx_lo_ctrl object and is thus not
worth carrying the _chan and _trx attributes.
|
|
|
|
|
|
|
|
| |
- Missing override
- Superfluous 'this' lambda capture
- Register state in zbx_cpld_ctrl was being initialized too late (this
is actually a bug depending on compiler version)
- Remove lots of unused fields from experts
|
|
|
|
|
|
| |
The ostream<< overloads where in the wrong namespace to be found by the
expert framework. Other compilers are more forgiving; not so clang 10.
This enables compilation on that compiler.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Co-authored-by: Lars Amsel <lars.amsel@ni.com>
Co-authored-by: Michael Auchter <michael.auchter@ni.com>
Co-authored-by: Martin Braun <martin.braun@ettus.com>
Co-authored-by: Paul Butler <paul.butler@ni.com>
Co-authored-by: Cristina Fuentes <cristina.fuentes-curiel@ni.com>
Co-authored-by: Humberto Jimenez <humberto.jimenez@ni.com>
Co-authored-by: Virendra Kakade <virendra.kakade@ni.com>
Co-authored-by: Lane Kolbly <lane.kolbly@ni.com>
Co-authored-by: Max Köhler <max.koehler@ni.com>
Co-authored-by: Andrew Lynch <andrew.lynch@ni.com>
Co-authored-by: Grant Meyerhoff <grant.meyerhoff@ni.com>
Co-authored-by: Ciro Nishiguchi <ciro.nishiguchi@ni.com>
Co-authored-by: Thomas Vogel <thomas.vogel@ni.com>
|
|
|
|
|
|
|
|
|
|
| |
The N320, like the X310, has some frontend corrections (IQ balance, DC
offset) which can be controlled from software. The property tree entries
exist for these, but the radio_control APIs do not (which also disables
the multi_usrp APIs).
This makes it harder to disable DC offset or IQ balance corrections from
software, and disables our calibration utilities.
|
|
|
|
| |
Adds a missing <thread>, <algorithm>, and <chrono>.
|
|
|
|
|
|
|
| |
Add extra precision to if frequency in the low band rx path in order to
avoid hitting the edges of a filter.
Signed-off-by: mattprost <matt.prost@ni.com>
|
|
|
|
|
|
|
|
| |
This reverts commit 969e426f2ef57f8d6fd3099870955ba2083abf9c.
Revert "fixup! N310: Low band IF adjustments"
This reverts commit 71137999430afaca18bfff179e6a3c4b0276d54c.
|
|
|
|
|
|
|
|
| |
Changed register offset from 4 bytes to 8 bytes. The registers in the
frontend were not being properly addressed, so calibration, IQ mapping,
and frontend corrections were not working properly.
Signed-off-by: michael-west <michael.west@ettus.com>
|
|
|
|
|
|
| |
Available antennas for TX and RX were swapped.
Signed-off-by: michael-west <michael.west@ettus.com>
|
|
|
|
|
|
|
| |
A typo was causing an issue with order of precedence in the calculation
of the LO frequency when using an external LO for RX on the N310.
Signed-off-by: michael-west <michael.west@ettus.com>
|
|
|
|
| |
The RX FE core was using the address for the TX FE core.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The const-ness of some radio_control differed between base class and
implementation. This fixes the consistency, but also makes sure these
methods follow the rules for when to make methods 'const'.
The following rules apply:
- Methods that query static capabilities are const. Here, we made
get_tx_lo_sources() const (the RX version was already const).
- Getters that may have to interact with the device (e.g., peek
a register) are not const, because the act of peeking is usually also
non-const. Here, we changed get_rx_lo_export_enabled() to non-const.
- All base classes are fixed such that the derived classes and the base
classes have the same const-ness. Clang was warning about differences.
This can cause very tricky bugs, where the radio_control_impl version
can get called instead of the intended child class.
|
|
|
|
|
|
|
|
|
|
|
|
| |
The checks from the new clang-tidy file are applied to the source tree
using:
$ find . -name "*.cpp" | sort -u | xargs \
--max-procs 8 --max-args 1 clang-tidy --format-style=file \
--fix -p /path/to/compile_commands.json
Note: This is the same procedure as 107a49c0, but applied to all the new
code since then.
|
| |
|
|
|
|
|
|
| |
This is potentially a performance issue, even though it doesn't have
a big impact in this context. Clang will warn about it, and this fixes
the compiler warning.
|
|
|
|
|
|
|
| |
twinrx_gain_config_t defined an assignment operator, but not a default
copy ctor. This is not allowed in modern C++, although compilers let it
slide and provide their own defaults. Clang, however, throws a warning
so let's fix it.
|
| |
|
|
|
|
| |
This fixes a clang warning.
|
|
|
|
| |
This fixes a clang warning.
|
|
|
|
| |
This fixes a clang warning.
|
|
|
|
| |
This fixes a clang compiler warning.
|
|
|
|
|
|
|
|
|
| |
The checks from the new clang-tidy file are applied to the source tree
using:
$ find . -name "*.cpp" | sort -u | xargs \
--max-procs 8 --max-args 1 clang-tidy --format-style=file \
--fix -p /path/to/compile_commands.json
|
|
|
|
|
|
|
|
|
| |
The freq_resolution parameter to the set_frequency() method was
confusing. Changing it to the mod2 value clarifies the intention and
makes the math to reduce the FRAC2 and MOD2 values much easier to read
and maintain.
Signed-off-by: michael-west <michael.west@ettus.com>
|
|
|
|
|
|
|
|
|
|
| |
- Reduce FRAC2 and MOD2 values on ADF5356
- Add write to register 10 and delay during retune on ADF5356
- Make negative bleed conditional on integer or fractional N mode for
ADF5356
- Tune unused LOs out of band to remove interference
Signed-off-by: michael-west <michael.west@ettus.com>
|
|
|
|
|
|
| |
These rf_control interfaces allow easier implementation of
radio controls as well as allowing easier sharing of code
for implementing e.g. gain_profile.
|
| |
|
|
|
|
|
|
|
| |
- Put ADF4351 at fixed integer-n mode IF freq
- Set ADF4351 in low noise mode
Signed-off-by: michael-west <michael.west@ettus.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The N310 had a different behaviour from other devices, where setting
a gain out of range would cause an assertion error. This is problematic
for two reasons:
1) Assertion errors should not be triggered by public APIs (if we throw
public APIs, we should give a clear error message), and
2) Setting gain and frequency has a coercing behaviour on all other
devices.
This changeset clips the gain before calling into the gain table lookup.
|
|
|
|
|
|
|
|
|
| |
The loopback test sometimes fails. It was found that it would pass on a
retry. The root cause of the failure is unknown at this time, but the
retry allows the test to pass. This is intended as a temporary patch
until the root cause of the failure can be identified.
Signed-off-by: michael-west <michael.west@ettus.com>
|
|
|
|
|
| |
twinrx_gain_tables takes long time to build with optimizations on
macOS / Clang. Turn them off for this platform.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This sets the reference clock for X300 daughterboards (other than UBX)
to 100 MHz by default to improve RF performance.
Note: The UBX daughterboard requires a clock rate of no more than the
max pfd frequency (50 or 25 MHz depending on the hardware rev) in
order to maintain phase synchronization. If a UBX daughterboard is
present on the X300, the clock rate for all daughterboards will be set
to the pfd frequency by default. This is because of the limitation on
X300 that requires the daughterboards to use the same clock rate.
Signed-off-by: mattprost <matt.prost@ni.com>
|