| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Fixes long lines, missing docstrings, and deprecated Pythonisms from
ethdispatch.py and xportmgr_udp.py.
|
|
|
|
|
| |
Co-authored-by: Steven Koo <steven.koo@ni.com>
Signed-off-by: Virendra Kakade <virendra.kakade@ni.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a known issue (see TODO) that the N300 and N310 have sub-Hz
tuning inaccuracies. In fact, these are explained in the corresponding
User Guide (UG-992).
This commit modifies MPM to return the actual frequency when calling
into ad937x_device::tune() or ad937x_device::get_freq(), instead of the
nearest integer value.
Co-authored-by: Arthur Moraes do Lago <arthurmoraeslago@gmail.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>
|
|
|
|
|
|
|
|
|
|
| |
- 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When executing eeprom-init on E320 (which was originally written for
N310), it would use defaults from N310, potentially causing issues.
These issues would have arisen if we letter-revved the E320 one more
time (because at rev 5, N310 had a compatibility cutover).
Summary of changes:
- eeprom-init will now read values *not* given on the command line from
the existing content of the EEPROM, if it contains valid data. This
means that DT, MCU, and rev compat values will no longer get
auto-derived if the EEPROM already contained "good" values.
- If the EEPROM is empty or corrupted, eeprom-init will no longer run if
the pid value is not provided. This is to avoid N310 defaults being
written to E320 EEPROMs.
- A README is added to explain which devices use which utilities.
- PID checks are more strict now. It is unlikely we'll build new devices
using the old EEPROM format (prior to TLV), so we can check
specifically for E320, N3x0.
- The hard-coded list of PIDs for the EEPROM tools are moved to
a central location (eeprom-pids.h).
- The code to derive values for DT/MCU/rev compat from the rev is now
pid-specific and no longer device-agnostic.
|
|
|
|
|
| |
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
|
|
|
|
|
| |
On N3x0 and E3x0 devices, we were erroneously installing EEPROM
utilities that are only relevant on X410.
|
|
|
|
|
|
|
|
| |
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.
|