| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit reverts the changes made in commit 81a9cc1f8 to reduce the
time for the LMK PLL to report lock status. The decision to revert the
change comes after an investigation found that reducing the overall time
to detect lock correlates with an increase in an error reported by the
TDC ('[ERROR] TDC measurements show a wide range of values! Check your
clock rates for incompatibilities. ... Uncaught exception in method
set_clock_source: TDC measurement out of expected range!'). Despite the
LMK PLL reporting lock status, our investigation revealed that it takes
additional time for the PLL to align the daughterboards' clocks closely
enough to pass the TDC measurement's range limit (i.e., no samples
exceeding the measurement mean +/- 500 ps). Reverting the change
increases the amount of time between achieving lock status and taking
the TDC measurements, thus greatly reducing the likelihood of the
reported error.
|
|
|
|
|
| |
Change the filename expected by x4xx_update_cpld to match the name used
by package_images and downloaded by uhd_images_downloader.
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
| |
- Update dependencies
- Add python3-uhd package
- Add uhd-doc package
In part, this changeset is to further align with the official Debian
upstream at https://salsa.debian.org/bottoms/pkg-uhd.git, which is
maintained by Maitland Bottoms.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
When running MPM as a simulator, none of the board-specific tools like
the BISTs, or usrp_update_fs need be installed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In f73e327, we modified PeriphManagerBase to explicitly list all
required methods as per the MPM/UHD API. This had an unintended side
effect: Because the clocking methods on x4xx are imported from
X4xxClockMgr, and not defined on x4xx itself, the method used to import
methods from X4xxClockMgr onto x4xx would refuse to re-define API calls
such as set_clock_source(), get_clock_source(), and so on.
The solution is to allow _add_public_methods() to overwrite existing
methods, which means we can overwrite abstract methods from
PeriphManagerBase in this fashion.
Without this patch, UHD sessions could fail in the following manner:
>>> import uhd
>>> U = uhd.usrp.MultiUSRP("type=x4xx")
>>> U.get_clock_source(0)
Traceback (most recent call last):
File "<input>", line 1, in <module>
U.get_clock_source(0)
RuntimeError: RuntimeError: Error during RPC call to `get_clock_source'.
Error message: get_clock_source() not available on this device!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
get_sync_sources() was not implemented for E31x and E320. Because UHD
assumes this exists, calling this would cause an error like this:
>>> import uhd
>>> U = uhd.usrp.MultiUSRP("type=e3xx")
>>> U.get_sync_sources(0)
Traceback (most recent call last):
File "<input>", line 1, in <module>
U.get_sync_sources(0)
RuntimeError: rpc::timeout: Timeout of 2000ms while calling RPC function
'get_sync_sources'
|
|
|
|
|
|
|
|
|
|
| |
All PeriphManagerBase childs need to implement
- get_{clock,time,sync}_source()
- get_{clock,time,sync}_sources()
- set_{clock,time,sync}_source()
So we populate PeriphManagerBase with defaults for all of those.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, the default clock/time source is whatever the user configured
in the last session.
This fixes the scenario were you have any MPM device and do this:
$ benchmark_rate --args $args,clock_source=external
But whoops! You forgot to attach an external 10 MHz. PLL lock fails,
nothing works. No worries, you run it again:
$ benchmark_rate --args $args
With the previous behaviour, this would retain the setting to
'external', because there's nothing to overwrite it. You would need to
append `clock_source=internal` to get a working device again. Calling
multi_usrp::set_clock_source("internal"), or a similar API call, might
not be sufficient because the PLL lock failure might crash the program
before updating the clock source is possible.
The problem with this is twofold:
- All non-MPM devices behave differently, i.e., they have a fixed
default ('internal') which is always applied if no other option is
given. This is an internal inconsistency.
- Some applications (like gr-uhd's GRC bindings) simply don't set
a clock/time source when selecting a "default", or they try and update
the clock/time source using the API calls.
Therefore, we align the behaviour of MPM devices with the other devices,
and fall back to an internal source if nothing else is provided.
|
|
|
|
|
|
|
|
|
|
|
|
| |
The E31x and E320 devices have one virtual daughterboard, and it is
always present. This is different from N3xx, which is where the MPM code
for these devices is based upon.
During the E3xx initialization, we make sure that our single
"daughterboard" exists and is responsive. That means we can remove some
code that tests for the availability and number of daughterboards, which
we need on N3xx (which works with zero, one, or two daughterboards).
This also allows us some minor deduplication of code.
|
| |
|
|
|
|
|
|
| |
This commit uses a more performant buffered I/O approach for reading the
gpsd socket. Previously, querying a gps mboard sensor on an mpm radio
would take 300-500ms due to the loop reading one byte at a time.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
These classes share a *lot* of common code, due to them both being
AD9361-based devices. This code is now factored out into a single file.
|
|
|
|
|
|
| |
- Whitespace
- Long lines
- Superfluous imports
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ref_locked mboard sensor on the n320 always returned true without
querying hardware. On this device family, mboard sensor callback in
n3xx.py returns the "and" of its daughterboard LMK PLLs by querying the
get_ref_lock() function on each dboard manager. However, that function
only existed for the Magnesium daughterbaord. For the Rhodium
daughterboard, the function didn't exist and so a true value was
automatically returned.
This commit adds the get_ref_lock() implementations for Rhodium and
EISCAT daughterboards, which are identical to the implementation
already present for Magnesium.
Co-authored-by: Martin Braun <martin.braun@ettus.com>
|
| |
|
|
|
|
|
| |
The receiving socket can be used to send responses. This allows setting
firewall rules for USRP detection.
|
|
|
|
|
| |
This thread is a vestige from copy & pasting N310 code, it does
absolutely nothing but occupy resources.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
Change the --to argument to --to-destination. Both seem to work, but the
latter is what is listed in iptables-extensions(8). What's confusing is
that `--to` also exists in another context (in the `string` match
extension).
|
|
|
|
|
|
| |
- Fix some Pylint warnings in eeprom.py
- Improve comments in n3xx.py and e320.py regarding rev_compat values in
EEPROM
|
|
|
|
|
|
|
|
| |
set_gpio_src takes a list of twelve sources to apply to the pins. For
the DIO mapping, this is fine, because the twelve pins are zero through
eleven. However, for the HDMI mapping, the pin indices range from one
to nineteen. This commit adds a function to convert from the set_gpio_src
list indices into the pin number.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MPM devices currently do not report their device name in the discovery
process. This adds the device name. After the change the device name
is reported, e.g. when using uhd_find_devices, like so:
$> uhd_find_devices
--------------------------------------------------
-- UHD Device 0
--------------------------------------------------
Device Address:
serial: DEADBEEF
claimed: False
fpga: X4_200
mgmt_addr: <mpm device ip>
name: <mpm device host name>
product: x410
type: x4xx
|
| |
|
| |
|
|
|
|
|
| |
There was a mixture of KB/s and B/s in the DRAM BIST. The BIST now
returns B/s in all cases.
|
|
|
|
|
| |
This is a follow-up to 89f99fac. In 2a575bf9b, a reference to
rfnoc_num_blocks was accidentally put back into MPM.
|
| |
|
|
|
|
|
|
|
|
| |
The original commit incorrectly fails the build
uhd in the meta-ettus context. This uses prefix
instead to get the base path.
Signed-off-by: Steven Koo <steven.koo@ni.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit replaces uses of distutils.sysconfig's get_python_lib()
function with sysconfig's near-equivalent get_path() function to get the
directory for site-specific, platform-specific files. Unfortunately,
get_path() does not have a way to easily modify or strip the prefix
applied to the path like get_python_lib() does, so the code must
manually modify the path to get the same effect:
- First, the platlib path is retrieved from the get_path() call.
- Next, the default base that is used to form the pathlib path is
queried via the get_config_var('base') call.
- Next, the portion of the platlib path that matches the default base is
stripped, and any leading path separator remaining is stripped. This
fundamentally replicates the behavior of get_python_lib() with an empty
prefix (i.e., the prefix positional parameter is specified as '').
- If a different prefix is desired, then the os.path.join() function is
used to combine the new prefix with the stripped pathlib path, ensuring
that the platform-specific path separator is used in crafting the path.
|
|
|
|
|
|
|
| |
This commit replaces the use of distutils.version.LooseVersion() with
CMake's version comparison operator, which implements relational version
string checking in the same manner (i.e., comparing numeric components
of a version string numerically).
|
|
|
|
|
|
|
|
|
|
| |
When the minor FPGA compat number on the device is ahead of what MPM
expects, we no longer print a warning. That's because by definition, the
FPGA is still compatible with the software in this case.
If UHD or MPM require a certain minor compat number to enable a feature,
the appropriate behaviour would be to print a warning only for that
case.
|
|
|
|
|
|
| |
The comment behind the tuning word is correct but 0x200 does not
give a voltage of 1.65V but 2.5V, because the full range of the
DAC is 5V not 3.3V).
|
|
|
|
| |
No code changes, only comment changes.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The LO-locked sensors on these devices were getting routed to the MPM
API call get_lo_lock_sensor(), which takes a 'which' argument (rx or
tx). However, UHD wants to pass a 'chan' argument (0 or 1). The way the
code was structured, it would always return 'False' (LO not locked) when
the argument was neither 'rx' or 'tx'.
The solution is to add get_rx_lo_lock_sensor() and
get_tx_lo_lock_sensor(), which generate the appropriate 'which'
argument, but discard the 'chan' argument (there is only one LO per Tx
and Rx, respectively).
|
|
|
|
|
|
|
|
|
| |
In UHD 3, we had two sensors names for LO lock on these devices:
lo_lock, and lo_locked. The latter is the more standard, and is checked
in examples like rx_samples_to_file.
In UHD 4, the latter was removed without comment. This adds the sensor
back again and also updates the documentation accordingly.
|
|
|
|
|
|
| |
Older DIO boards don't support all the features of newer ones, but from
the log messages, it's not clear what revision the board has. We add
a log statement to clarify.
|
|
|
|
|
|
|
|
|
| |
No functional changes whatsoever, only:
- Move DioControl to its own module (x4xx_dio_control.py)
- Where PyLint was complaining about whitespace issues, fix those
- Fix import list in x4xx_periphs.py after removing DioControl
- Fix import list in x4xx.py to import DioControl from the correct
location
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The X4x0 MPM code doesn't always load the object for the DIO control, it
only does that when certain checks pass (EEPROM readouts need to match
expected values). Therefore, `self.dio_control` may be NoneObject during
operations, and in other areas of the code, we already check if that's
the case.
The APIs added in c36fc5f don't have these checks, which means accessing
these new APIs may result in odd exceptions when trying to dereference
a NoneType object. By adding checks for the initialization state of
`self.dio_control`, we can avoid these and either substitute better
error messages / exception messages, or return safe values.
Note that mpmd_mb_controller also accesses this object indirectly by
checking the length of the return value of get_gpio_banks(). This check
is not affected by this change, as we now are guaranteed to return an
empty list if there is no self.dio_control.
|
| |
|
|
|
|
| |
Signed-off-by: Virendra Kakade <virendra.kakade@ni.com>
|
|
|
|
| |
Signed-off-by: Virendra Kakade <virendra.kakade@ni.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.
|