This a mapping of uhd::device::find() into uhd.find() on the Python
side. The uhd::device is intentionally not mapped into Python (prefer
MultiUSRP or RfnocGraph instead), so the namespace is moved up one
level.
Example:
>>> import uhd
>>> # Now print the device args for all found B200s:
>>> for dev_args in uhd.find("type=b200")): print(dev_args.to_string())
This is a new API call, only available on Python, and only available for
MPM devices (it is added dynamically). It returns an object that allows
calling RPC calls in a Pythonic manner.
Example:
>>> rpcc = usrp.get_mpm_client()
>>> print(rpcc.get_device_info()) # Will print device info, as returned
# by uhd_find_devices
When ENABLE_SIM and ENABLE_PYTHON_API are set, this commit embeds MPM
(Built with -DMPM_DEVICE=sim) into the pyuhd package.
Signed-off-by: Samuel O'Brien <sam.obrien@ni.com>
- Fix some typos
- Fix incorrect arg name for RFSGPowerGenerator.enable()
- Fix case where incorrect args would cause an uncaught TypeError. Now,
if USRP is chose as signal generator, but fails to find one, a proper
error is shown.
This changes the default name of the image core file to
<DEVICE>_rfnoc_image_core.v instead of naming it after the YAML file.
This ensures that when you use a custom YAML file, the resulting
FPGA build will use the generated rfnoc_image_core and static_router
files, rather than just the generated static_router file.
Originally, the setup.py file for pyuhd listed only one package
packages=['uhd']
the setuptools docs: https://setuptools.readthedocs.io/en/latest/setuptools.html#using-find-packages
specify that this should also include subpackages, i.e uhd.dsp,
uhd.usrp, etc. Currently, when packaging libpyuhd, we are not including
the subpackages, and then when you run `import uhd`, it fails because
uhd.usrp and uhd.dsp don't exist.
This commit alleviates this issue by using setuptools.find_packages like
the docs recommend.
Signed-off-by: Samuel O'Brien <sam.obrien@ni.com>
A segment of the build() function updates the working directory. This
change converts several paths to absolute paths to avoid having a
relative path (such as one containing up-level references) deviate from
its' intended meaning after the directory change.
In the c++ api, methods like chdr_packet#set_payload() and
chdr_packet#get_payload() are templated over the payload type
(payload_t). For methods like set_payload, they are overloaded by the
type of an argument, so in pybind we can just explicitly instaniate the
template for each payload_t and register it with pybind under the same
name. At runtime, pybind looks at the type of the argument and decides
which to call.
The problem arose with methods like get_payload, which are overloaded by
return type. In C++, the compiler can infer the template type by the
type of the target at the call site. In python, there is no way for the
pybind to determine which variant of get_payload to call, and it would
crash. Previously, the workaround for this was to declare
get_payload_ctrl, get_payload_mgmt, etc, but this was rather
anti-pythonic. This commit utilizes the fact that python methods don't
have a constrained return type to resolve this. Now, get_payload will
call a python method which looks at the chdr_packet#header#pkt_type
field to determine which variant of get_payload to call and returns that
type of payload_t.
Signed-off-by: Samuel O'Brien <sam.obrien@ni.com>
This commit adds pybind11 glue code for the userland chdr parsing code
introduced in the uhd::utils::chdr namespace. Additionally, it moves
some pybind11 adapter code to a common pybind_adaptors.hpp file which
originally existed in the cal_python.hpp file.
This commit also adds unit tests for the python bindings using a
captured wireshark trace which is located in rfnoc_packets_*.py and some
handwritten packets in hardcoded_packets.py
Signed-off-by: Samuel O'Brien <sam.obrien@ni.com>
This commit allows the RFNoC image builder utility to support block
definition .yml files where the num_ports values are numerical
expressions using values sourced from the parameters section when the
block is used in an RFNoC image. An example of such an expression for
num_ports is the split stream block, where the number of output ports is
defined as the product of the NUM_PORTS and NUM_BRANCHES parameters:
data:
fpga_iface: axis_chdr
clk_domain: rfnoc_chdr
inputs:
in:
num_ports: NUM_PORTS
outputs:
out:
num_ports: NUM_PORTS*NUM_BRANCHES
In an RFNoC image definition .yml file, these parameters can be
specified when a split stream block is instantiated in an image:
split0:
block_desc: 'split_stream.yml'
parameters:
NUM_PORTS: 2
NUM_BRANCHES: 3
Thus, the split0 instance of the split stream block is configured with 2
input ports and 6 output ports (2*3 from NUM_PORTS*NUM_BRANCHES).
When the RFNoC image builder runs and encounters a block instantiation
where that block has a non-integer string in the num_ports key of its
block definition, it performs a textual replacement of the identifiers
in the string with the corresponding values from the parameters section
of the block's instantiation. If no such parameter corresponding to the
identifier exists, the block definition file's parameters section is
consulted for a default value for the parameter. If no such parameter
can be found in either of these locations, the identifier is left
unchanged in place.
After the text substitution step, the expression is evaluated using
Python's expression evaluator. The expression should evaluate to an
integer value, which is then used as the num_ports value. If the
expression does not evaluate to an integer, or fails to evaluate, an
error will be reported.
Current implementation needed manual interaction to calibrate each
antenna. More sophisticated setups are able to switch between channels
and antennas programmatically.
This commit introduces a base class that handle the switch behaviour. The
previous implementation moved to a ManualSwitch class which is the
default switch. Without any options the previous flow remains unchanged.
A new class is able to handle NI switch models. The switch port can
be given via options parameter (comA is default). The channels are connected
in ascending order. The user has to ensure that the cable setup matches
the order given for channels and antennas.
Co-authored-by: Martin Braun <martin.braun@ettus.com>
Power measurements for TX calibration can be done using NI-RFSA devices
and the RFmx SpecAn library. Use "rfsa" as meas_device option for this.
The implementation mimics the behaviour of the "RFMXSpecAn TXP (Basic)"
example.
Signal generation for RX calibration can be done using NI-RFSG devices.
Use "rfsg" as meas_device option for this. The implementation mimics
the behaviour of the "RFSG Frequency Sweep" example.
The device can be selected by passing its name in the option string.
This is only necessary if more than one device of the same family is
installed in the system.
The support is limited to Windows operating System. Drivers for RFSA and
RFSG must be installed as well as the RFmx SpecAn library. The "nimodinst"
Python package must be installed to be able to detect the devices.
The implementation uses ctypes to call into the C-API of the device drivers.
Only the bare minimum to fulfill the calibration requirements is implemented.
- Remove some PyLint issues by aligning the argument list for
SignalGeneratorBase.enable()
- Improve an assertion: Since a valid power level is 0 dBm, we need to
explicitly check max power against None, not 0
- Improve the error message for when no device is found ("signal
generator" instead of "RX measurement device", since the latter is
confusing/ambiguous)
This lets you do
>>> from uhd import dsp
>>> s = dsp.signals.get_continuous_tone(...)
>>> pwr = dsp.signals.get_power_dbfs(s)
...and so on. This module is for UHD-based utilities to have some
additional signal processing functions to tap into.
This changes two things in all applicable files:
- Remove imports from __future__
- Change default shebangs from /usr/bin/env python to /usr/bin/env
python3
On UNIX systems, CMake will set the RPATH of the Python library to the
build directory, which is very helpful because it allows unit and other
tests to be executed from within the build directory.
On installation, the RPATH is removed, but only if install(TARGETS) is
used, which we were not, thus resulting in incorrect RPATHs.
This would surface as a bug, too. Calling uhd.get_lib_path() would
always point to the build directory, thus resulting in no FPGA images
being found automatically, e.g. when running a B200 through the Python
API.
This change installs the Python .so file separately, using the correct
CMake mechanisms.
Note: This commit changes nothing to the way the image builder is being
called. One can still run
rfnoc_image_builder [...]
as before. The difference is in the Python guts:
Where previously one had to do
import rfnoc
now the incantation becomes:
from uhd import imgbuilder
(Note that the submodule uhd.rfnoc already exists for wrapping the RFNoC
API into Python, hence the renaming from rfnoc to imgbuilder).
This is done for a variety of reasons:
- Now, there is only one and exactly one Python module for UHD that
contains all the things, as opposed to before where there were two.
- The rfnoc and uhd modules were installed in different ways (setuptools
vs. CMake); that is now harmonized. This also removes a lot of CMake
plumbing.
- It is not common to import the rfnoc module for anyone other than
rfnoc_image_builder
This class can be used to store calibration coefficients for the X300
DC offset and IQ imbalance calibration.
Note: This also modifies Doxyfile.in to not document files generated by
flatc.
This class contains methods to store and retrieve data from the local
calibration database. Note that in this case, the "database" is just a
bunch of files on the local filesystem.
All of the functions defined in uhd/utils/paths.hpp are now available in
Python, with the exception of get_module_paths().
#!/usr/bin/env python3
import uhd
print(uhd.get_lib_path()) # Prints location of libuhd
This adds the host/python/uhd subdirectory, which will add all files
that go into the actual Python module once installed. Before, all Python
files were directly in host/python and got sorted into their appropriate
destination folders during configuration and installation.
This change doesn't change anything (Python modules will look the same
as they do now), except that it makes the source tree a tad neater, but
more importantly, it creates a consistent directory structure when
adding submodules to the uhd module. Apart from the PyBind11-generated
shared object file (which gets generated during build time), the uhd/
subdirectory in host/python exactly resembles the Python module once
installed, so it's more obvious where to add new submodules and files.
This fixes a segmentation fault when trying to use the python module on
OSX when built with conda (unsure why it doesn't arise otherwise).
Instead of linking against the python library, it is proper to not link
against the library and, for OSX builds, add linker options for
"-undefined" and "dynamic_lookup". This is precisely what the CMake
FindPython module does for linking against the Python::Module target.
See https://blog.tim-smith.us/2015/09/python-extension-modules-os-x
and https://bugs.python.org/issue36721
Instead of renaming the library file, this sets the suffix in CMake so
that the filename turns out as desired and also linker references know
the correct name.
