| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
| |
This allows one setter to call a second setter in an atomic way,
without dropping the lock. This is groundwork for incorporating the power
calibraiton manager, which may change the gain setting during the process
of changing the tuned frequency.
|
| | |
|
| |
|
|
| |
This fixes compiler warnings under Clang12.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When calling `get_gpio_srcs()` or `get_gpio_src()` with an invalid bank
parameter, the error text associated with the `uhd::runtime_error` that
is thrown prints the expected bank, not the erroneous bank, e.g.:
>>> my_x310.get_gpio_srcs('BAD_BANK', 0)
[ERROR] [X300::MB_CTRL] Invalid GPIO source bank: BAD_BANK. Only supported
bank is FP0
Traceback (most recent call last):
File "<stdin>", line 2, in <module>
RuntimeError: RuntimeError: Invalid GPIO source bank: FP0
The invalid source bank on the last line should read BAD_BANK, not FP0.
|
| | |
|
| | |
|
| |
|
|
|
| |
FP0 is now listed first. This helps with determining a default GPIO
bank.
|
| |
|
|
|
|
| |
The frontend corrections for N320 (IQ imbalance, DC offset) require the
DB serial. However, there was an error in reading the DB serial in the
code that applies the corrections.
|
| |
|
|
|
| |
The N320 code include some constants that were either unused or
incorrect. This clarifies the lowband frequency.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds support for read only registers in generated interfaces.
For this the default is extended to an option string. The old format
is still supported for backward compability, so if options string is
just a number it will be handled as a writable number.
The option string is a comma separated list with key=value pairs. The
value is optional and treated as None if missing.
common.py now allows to pass in **kwargs to the generate method which
is used by gen_zbx_cpld_regs.py to pass a filter function for registers
used by mpm only.
get_all_addr now has an additional (optional, defaults to false) flag
to indicate whether read only addresses are to be returned or not.
It also supports type generic for the result to align with
get_changed_addr function.
The ZBX CPLD CTRL map is adapted accordingly to reflect read only
registers. The power registers are flagged as MPM scope only (and not
used in ZBX CPLD control of UHD).
Co-authored-by: Martin Braun <martin.braun@ettus.com>
|
| |
|
|
|
|
|
|
| |
If ALL option is specified, set lo source for both lo's. Do not report
an error if user sets LO2 to internal. Enforce single lo target for
queries about lo state.
Signed-off-by: mattprost <matt.prost@ni.com>
|
| |
|
|
|
|
|
| |
This resolves a typo intoduced by
multi_usrp_rfnoc: Add TX buffering using Replay
Signed-off-by: Steven Koo <steven.koo@ni.com>
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Add the Filter API to n3xx specifically for the AD937x device. The TX
filter is limited to 32 taps, and the RX filter is limited to 48 taps.
This feature requires MPM version 4.2 or later on the device.
Co-authored-by: bpadalino <bpadalino@gmail.com>
Signed-off-by: mattprost <matt.prost@ni.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Allow users to control the Mykonos frontend bandwidth settings for
Rx and Tx. Note that this operation requires the daughterboard to
re-initialize, so it may take some time. Values for frontend filter
settings were derived using ADI's AD9371 Filter Wizard.
This feature requires MPM version 4.1 or later on the device.
Co-authored-by: bpadalino <bpadalino@gmail.com>
Signed-off-by: mattprost <matt.prost@ni.com>
|
| |
|
|
|
|
|
|
|
| |
This allows the user to get the current state of the tx atr bits and set
them back to a given state. This is useful for the n310 when resetting
the front end, in order to avoid any tx power out of the frontend when
the init_cals are run.
Signed-off-by: mattprost <matt.prost@ni.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
Enabled with the "tx_replay_buffer" device argument. Buffers TX data in
DRAM using the Replay block (version 1.1 or higher required), allowing
more buffering of data on the device. May reduce underruns for certain
applications. The Replay block is currently limited to 32 play
commands, so fewer calls to send() with larger buffers will perform
better than more calls with smaller buffers.
Signed-off-by: michael-west <michael.west@ettus.com>
|
| |
|
|
|
|
| |
Add support for reading the number of supported SPI slaves from
the device. This has become necessary because we may have bitfiles
with different capabilities and we want to report this back correctly.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
For certain frequencies, the LMX2592 will sporadically fail to lock upon
the very first tune. When this happens, subsequent tunes (even to the same
frequency) do lock. This issue seems to be resolved by programming the FCAL
adjustment register fields (FCAL_LPFD_ADJ/FCAL_HPFD_ADJ) as described in
the LMX2592 datasheet. These fields adjust the FCAL calibration speed to
better accomodate PFD frequencies below 20MHz or above 100MHz.
This patch also fixes a few name typos in the register map that were
directly in the scope of this change.
|
| |
|
|
|
|
| |
This fixes an issue with setting the active channel source in MPM, and
additionally allows opening up the more flexible API in the future without
requiring a filesystem update.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The power that corresponds to a certain gain values depends on the
frequency band we are in. At the edges of these bands discontinuities
can occur (the gain necessary to achieve the same power value changes
non-continuously). The power calibration does a linear interpolation
between two neighbor points in the calibration data set to find at
best fitting value. We therefore have to make sure that this interpolation
does not cross discontinuities.
This is a minimal invasive approach. It adds values at discontinuities
for the lower and the upper band. The power calibration format uses
the frequency for a power to gain mapping as a map key. Therefore two
gain to power mappings cannot be stored for the same frequency as it
would be needed for the discontinuity. Instead the mapping for the
lower band is stored at the discontinuity frequency itself. The mapping
for the upper band is stored at the frequency + 1Hz. The calibration
will therefore still fail to yield proper results within this
sub-Hertz range. The frequency lookup in the power calibration manager
now uses round instead of truncation to find the best mapping frequency
in the calibration table.
With this, searching for neighbor data points now ensures that the data
points used belong to the same band (except for the range of
(f_discontinuity, f_discontinuity + 1Hz) ).
This commit does not solve the issue for calibration data generated
with usrp_power_cal.py because the Python interface has no means to
detect band edges for the USRP it is calibrating.
|
| |
|
|
|
|
|
|
| |
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 fixes the following warnings:
```
/Library/Developer/CommandLineTools/usr/include/c++/v1/memory:2335:5: warning: \
delete called on non-final 'uhd::rfnoc::x400::x400_gpio_port_mapping' that has \
virtual functions but non-virtual destructor [-Wdelete-non-virtual-dtor]
delete __ptr;
^
/Library/Developer/CommandLineTools/usr/include/c++/v1/memory:2648:7: note: in \
instantiation of member function 'std::__1::default_delete<uhd::rfnoc::x400::x4\
00_gpio_port_mapping>::operator()' requested here
__ptr_.second()(__tmp);
^
/Library/Developer/CommandLineTools/usr/include/c++/v1/memory:2602:19: note: in\
instantiation of member function 'std::__1::unique_ptr<uhd::rfnoc::x400::x400_g\
pio_port_mapping, std::__1::default_delete<uhd::rfnoc::x400::x400_gpio_port_map\
ping> >::reset' requested here
~unique_ptr() { reset(); }
^
/Library/Developer/CommandLineTools/usr/include/c++/v1/memory:4063:21: note: in\
instantiation of member function 'std::__1::unique_ptr<uhd::rfnoc::x400::x400_g\
pio_port_mapping, std::__1::default_delete<uhd::rfnoc::x400::x400_gpio_port_map\
ping> >::~unique_ptr' requested here
unique_ptr<_Yp> __hold(__p);
^
/Users/rfmibuild/myagent/_work/76/s/host/lib/usrp/x400/x400_radio_control.cpp:1\
92:33: note: in instantiation of function template specialization 'std::__1::sh\
ared_ptr<uhd::mapper::gpio_port_mapper>::shared_ptr<uhd::rfnoc::x400::x400_gpio\
_port_mapping>' requested here
auto gpio_port_mapper = std::shared_ptr<uhd::mapper::gpio_port_mapper>(
```
and:
```
/Users/rfmibuild/myagent/_work/76/s/host/lib/usrp/x400/x400_gpio_control.cpp:15\
4:75: warning: adding 'const uint32_t' (aka 'const unsigned int') to a string d\
oes not append to the string [-Wstring-plus-int]
"Could not find corresponding GPIO pin number for given SPI pin " + value);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
/Users/rfmibuild/myagent/_work/76/s/host/lib/usrp/x400/x400_gpio_control.cpp:15\
4:75: note: use array indexing to silence this warning
"Could not find corresponding GPIO pin number for given SPI pin " + value);
^
& [ ]
```
|
| |
|
|
|
| |
This allows viewing or, conceivably, customizing the tuning table that
ZBX uses, depending on the particular needs of the end user.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In 716ed77, refactoring was performed to merge `set_tx_subdev_spec()`
and `set_rx_subdev_spec()` via the use of a shared helper function,
`_set_subdev_spec()`, which factors out differences in the two
directions by accepting lambda functions from the caller. However, there
were two bugs introduced in the refactoring:
- The channel map parameter, which is either `_rx_chans` or `_tx_chans`
based on direction, was passed by value and not reference, so changes
made by the function were not persisted in the member variables
maintained in the `multi_usrp_rfnoc` class.
- The connection removal loop checks for the presence of an SEP block on
an edge as its termination condition. In the pre-refactored code, the
direction determined whether the source or destination of the edge was
checked for the SEP. However, in the refactoring, the source of the edge
is checked for both TX and RX. While this works for the
`set_tx_subdev_spec()` call, it breaks the `set_rx_subdev_spec()` call.
This commit fixes the issue by adding another lambda parameter to the
`set_subdev_spec()` function, which puts the onus of the edge check on
the direction-specific code to ensure it is looking at the correct side
of the edge.
|
| |
|
|
|
|
| |
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.
|
| | |
|
