-Add gevent rtnetlink listener for interface and IP changes.
-Refresh cached transport info immediately after network changes.
-Extend x4xx cache TTL to 300 seconds with epoch-based invalidation.
get_xport_info() enumerates network interfaces via netlink/pyudev on every
GetDeviceInfo call (~350ms, non-yielding). Since GetDeviceInfo is
unclaimed and gets flooded during discovery, this could starve claimed
RPCs past their short deadlines like 2 seconds.
Cache the result for 10s (X400_XPORT_INFO_CACHE_TTL); it's stable per
session, and init() drops the cache since IPs may change. This turns most
GetDeviceInfo calls much faster.
Add a dedicated lock for the xport_info_cache so concurrent
GetDeviceInfo calls don't race on refresh/invalidations
Update MPM GPIO handling for the updated X4xx GPIO SPI register
interface.
Require the FPGA compatibility number bump introduced with the new
SPI support so MPM does not operate against an incompatible FPGA image.
Bump MPM compat number.
- Verify signature in case the device does not support customizable
FPGA (just as sanity check before actual loading the bitstream).
- Extract the bitstream from the bootgen generated .bin file
otherwise.
host:
Replace the msgpack-RPC (rpclib) client with a gRPC-based
implementation. Add auto-generated C++ client and Python bindings
from protobuf definitions. Remove rpclib dependency and integrate
FindgRPC into CMake.
mpm:
Replace the msgpack-RPC server with a gRPC server generated from
protobuf definitions. Add pb_utils.py for type conversion between
Python and protobuf. Update rpc_server.py to dispatch calls via
gRPC stubs. Update mpm_shell to use gRPC. Replace pyudev with sysfs
scan in uio device discovery.
Bump MPM compatibility number to 7.0 and RPC version to 2.
This change requires new depedencies. E.g. for Ubuntu 24.04 or 25.10:
libgrpc++-dev, libprotobuf-dev, protobuf-compiler-grpc, python3-grpcio
Introduce HwmonTempSensors (sysfs_hwmon.py) and refactor
SysfsThermalSensors (sysfs_thermal.py) to enumerate available sensors
once at construction time and cache device references in a sensor_map
dict, avoiding repeated udev context creation and device-tree walks on
every readout.
HwmonTempSensors supports the cros-ec hwmon subsystem and accepts a
sensor_list parameter to discover both temp and fan sensors. A new
read_fan_sensor_value() method is added alongside the existing
read_thermal_sensor_value(). Multiple subsystems (hwmon, iio) and
sensor formats are supported via a read_sysfs_sensors_value() utility.
SysfsThermalSensors is extended to support multiple subsystems (IIO
and thermal) and a data_probe parameter for flexible attribute reading.
A read_fan_sensor_value() method is added to match the hwmon interface.
Both classes expose the same read_thermal_sensor_value(sensor_names,
reduce_fn) interface, making them interchangeable at the call site.
All affected peripheral managers are updated:
- E320: updated to use the new sensor abstraction pattern
- N3xx: refactored temp and fan sensor methods for hwmon/thermal backends
- X4xx: unified _temp_fan_sensors handle with hwmon/thermal dispatch,
add missing HwmonTempSensors import
- E310: add dynamic MB temperature sensor type detection instead of
hardcoding "jc-42.4-temp", fixing usrp_list_sensors compatibility
A _hwmon_based_sensors flag at init time selects the correct backend
for fan and temperature reads on all platforms.
This adds a new sensor called `ref_stable` to the X4xx series. Unlike
`ref_locked`, which only checks the current ref-lock status, this will
also query the sticky bits of the LMK04832 lock-detect circuitry, and
then clear them. This allows checking if ref-lock was lost any time
between queries to the `ref_stable` sensor (unlike the `ref_locked`
sensor, which queries the current ref-lock status).
This changes the LMK04832 class to only optionally (and not always)
check the sticky LD_LOST flags in the 0x182 lock-detect register of the
LMK04832. As a result, the ref_locked sensor will now only return the
current lock status of this PLL, and the ref-locked LED
This adds support for the new USRP X420. It is the latest addition to
our X4xx series and comes with two HBX daughterboards. The HBX is
a one-channel direct conversion transceiver that covers 5G NR FR3 and
X-/KU-Band needs for Research and Prototyping in a frequency range of 10
MHz up to 20 GHz. It supports analog bandwidths of up to 1 GHz.
This commit is the MPM portion of the X420 support.
Co-authored-by: Martin Anderseck <martin.anderseck@emerson.com>
Co-authored-by: Ahmed Salman <ahmed.salman@emerson.com>
Co-authored-by: Max Köhler <max.koehler@emerson.com>
Co-authored-by: Markus Schill <markus.schill@emerson.com>
With this change, it is possible to have different sub-channels within
one channel to serve different purposes. For instance it is possible to
have one converter run in Real mode while two other converters serve I
and Q respectively. They all count as the same channel for UHD and the
driver software needs to take care to switch between them if required.
For the IQ architecture we also disable the NCO in the RFDC.
This moves the ADC/DAC tile startup after the daughterboard power-up.
Reason for this is that especially the ADC needs silence when starting
up as it runs its foreground calibration then. If during that time the
daughterboards are not yet powered up we cannot guarantee that which
might impact the noise floor. To move the tile startup, it was factored
out into a (re)start method.
Add functions to read the temperature sensors of the following
components:
- main power (PMBUS 0 and 1)
- sample clock (SPLL)
- DRAM
- TMP464
- Power supply PCB
Importing from usrp_mpm.rpc_server imports a lot of dependencies which are
unnecessary if the rpc_server functionality is not actually needed.
Move the decorator functions to a new file rpc_utils.py and import only
from this file inside periph_manager.
usrp_hwd.py needs additional dependencies which are specifically imported:
- usrp_mpm.rpc_server.spawn_rpc_process
- usrp_mpm.discovery.spawn_discovery_process
- Bumps FPGA compat from 8.2 to 8.3
- Adds three global motherboard registers to read the 96-bit device DNA
- MPM is updated to read these registers and update the device_info if
compat version 8.3 is available
Change all references to "gps_lock" to "gps_locked" for consistency
across the code base. Fixes incorrect use of "gps_lock" for the sensor
name on X4xx.
Signed-off-by: michael-west <michael.west@ettus.com>
This change ensures that ADC selfcal is triggered during session start
if the clocking was reconfigured. So it saves time if several
consecutive sessions are opened with always the same settings.
It also makes the ADC self cal run if in an open session either
set_clock_source(), set_time_source() or set_sync_source() are called
and a clock reconfiguration was triggered by that.
This adds an updateable_components overridable dictionary into the
daughterboards base class.
On X410, because some of the FPGA compatibility stems from DB-specific
components, they are moved into class ZBX.
FPGA:
- Split up MB registers that control daughterboard specific settings so
that daughterboards 0 and 1 could have different setings, in
preparation for future devices that require different settings.
This requires a compat number bump to 8.0.
- Add registers for additional RFDC information, including the
block/tile mapping of the individual channels, and information about
resampling capabilities
- Identify sections of code that would be specific to X410/ZBX and move
them to their own headers, so it's trivial to add device-specific
sections of code instead for other devices in the future.
- This includes constraints for clocks and I/O pins.
- Remove ability to do timed ctrlport transactions to the MB CPLD, this
was unused and possibly broken.
- Move daughterboard-specific code into its own code location
(dboards/zbx)
- Move X410-specific register documentation to its own location
(doc/X410)
- Refactor Makefiles to split out X410/ZBX specific components and allow
switching between device types
- Add 512-bit AXI interconnects
- Make number of timekeepers configurable (X410 keeps the single
timekeeper)
MPM:
- Required compat is bumped to 8.0
- Now supports new registers for detecting DSP capabilities and
multi-rate settings for the daughterboards
- Adds MMCM controls (currently unused)
Co-authored-by: Wade Fife <wade.fife@ni.com>
Co-authored-by: Ryan Marlow <ryan@lmarlow.com>
Co-authored-by: Martin Braun <martin.braun@ettus.com>
Co-authored-by: Humberto Jimenez <humberto.jimenez@ni.com>
This by itself does not enable dual-rate (or multi-mcr), but it
refactors the code to enable it in the future. Additional changes may be
required.
X4xxClockMgr is renamed to X4xxClockManager.
Before this change, x4xx_rfdc_ctrl.py had various backdoors to read out
required settings. Now that we have the clock policy object, we can
simply read them out from there.
This obviates some code paths (get_rfdc_resampling_factor(),
get_default_mcr(), set_rfdc_reset_cb()).
On tear_down() (this is most commonly seen by users when updating the
FPGA image), we add a check to verify that subcomponents of the X4xx are
actually initialized, to avoid displaying a non-fatal error message that
looks like this:
[ERROR] [MPM.RPCServer] Error in update_component while resetting:
'NoneType' object has no attribute 'tear_down'
The most common/easy way to trigger this error is by loading MPM with
a bitfile that has an invalid compat number (which would stop MPM from
initializing the RFDC controls) and then running `uhd_image_loader`
(which would force a tear_down()). In that circumstance, MPM would try
to call tear_down() on an uninitialized object.
The X4x0 device is an outlier with respect to all other MPM devices when
it comes to this API. All other MPM-devices define this API on the
daughterboard, not the motherboard.
For all the reasons laid out in dboard_manager/base.py, we move this API
call for X4x0 also into the daughterboard RPC space.
Both get_master_clock_rate() and set_master_clock_rate() are explicitly
declared @no_rpc in MPM.
This is an API breakage in the UHD/MPM communication API.
Main changes:
- x4xx_mb_cpld.MboardCPLD is renamed to X4xxMboardCPLD and is now a base
class. Specific implementations of the MB CPLD require derived classes
and have to provide their corresponding signature.
- In x4xx.py, we don't init the MB CPLD and then assert we have
a specific signature. Instead, we init the MB CPLD, and choose
a derived class based on the signature. If there is no such class,
then the same error is generated as before (by itself, this means
there is no behavioural change).
- The MB CPLD image for the X410 (ZBX daughterboards) is moved to
a derived class X410MboardCPLD.
- New: The ZBX daughterboard driver verifies that the MB CPLD image is
in fact compatible with the daughterboard. For this, the MB CPLD
control classes require a COMPATIBLE_DB_PIDS attribute.
By itself, this change has no behavioural- or API changes. However, it
allows easily slotting in new CPLD images with different signatures.
Without further modifications, it does not allow *any* CPLD image
though: The PS API (e.g., enable/disable daughterboards, CMI status,
etc.) remain the same.
This reverts the Raw UDP host changes which is breaking
multiple interface streaming.
Commits addb81aa5d2d6adcd3a0c7a8d59fcd96af0c1ec4^..b1ca51f97aaa2226ed6ef339fb26fbea54ab7593
are reverted.
Reverts:
doc: Update manual on streaming
examples: Add remote RX streaming example
rfnoc: Enable remote UDP streaming
mpm: e320: Enable raw UDP streaming
mpm: n3xx: Enable raw UDP streaming
mpm: x4xx: Enable transport manager adapter
mpm: Enable opt-in transport adapter control
rfnoc: Transition stream managers and mgmt_portal to topo_graph_t
rfnoc: Add topology graph object
uhd/mpm: Add API to set remote routes
mpm: xports: Add XportAdapterMgr class
