| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds a utility class for use with the Python RFNoC block
controller PyBind bindings which facilitates constructing instances of a
specific block controller type from its noc_block_base base class. This
allows Python code to create and configure specific block controller
instances by calling get_block on a uhd.rfnoc.RfnocGraph object with the
block ID of the block in question and then passing the result into the
constructor method of the block controller, e.g.:
graph = uhd.rfnoc.RfnocGraph("addr=...")
block = graph.get_block(uhd.rfnoc.BlockID("0/DDC#0"))
ddc = uhd.rfnoc.DdcBlockControl(block)
ddc.set_input_rate(10e6, 0)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- 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 the B200 transmit and/or receive at given reference power
levels. Requirement is that the devices have been separately calibrated
with an external calibration device.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
get_tx_freq(), unlike get_rx_freq(), would not factor in the DSP
frequency. Before, this would happen:
>>> U = uhd.usrp.MultiUSRP("type=x300")
>>> tr = uhd.types.TuneRequest(1e9, 10e6)
>>> res = U.set_tx_freq(tr)
>>> res.clipped_rf_freq
1000000000.0
>>> U.get_tx_freq()
1010000000.0
In other words, the TuneResult object was correct, but the return value
of get_tx_freq() was not. This fixes the issue.
|
|
|
|
| |
This is a tool for running power calibration.
|
| |
|
| |
|
| |
|
|
|
|
| |
This commit adds a unit test for the split stream RFNoC block.
|
|
|
|
|
|
|
|
| |
The split stream RFNoC block is an RFNoC block that takes in a single
CHDR stream and duplicates it, creating a number of output streams for
each input stream. Consult the split_stream_block_control class header
file for more details on block configuration and behavior, including how
property and action forwarding is handled by the block.
|
|
|
|
| |
This commit adds a unit test for the USE_MAP action forwarding policy.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds a unit test for the USE_MAP property forwarding policy.
It also adds a pair of new mock RFNoC nodes for use in unit testing:
- mock_edge_node_t is a node with a configurable number of input and
output ports each having an edge property named 'prop' associated with
each. The node is also able to source actions from any of its edges and
records incoming actions in a map.
- mock_routing_node_t is a do-nothing node specifically for testing
property and action forwarding between edges with the USE_MAP forwarding
strategy. The node has functions to configure the property and action
forwarding maps.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds a new forwarding policy for properties and actions,
USE_MAP. This forwarding policy causes the node to consult a
user-provided map to determine how to forward the property or action.
The map's key is the source edge of the incoming property or action,
while the value is a list of destination edges to which the property
should be propagated or action should be forwarded. It allows clients to
construct sophisticated forwarding behaviors for specialized blocks,
such as a split stream block that needs to forward properties and
actions only to specific output edges based on the incoming edge.
|
|
|
|
|
|
| |
This commit fixes a bug in node_t::_has_port(), which was using the
wrong comparison operator to determine if the instance value in the
incoming res_source_info parameter is within a valid range.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This will allow run_testsuite.py to be called for specific devices instead
of all devices for a certain type.
|
|
|
|
|
|
| |
This complements b721621. In that commit, we directly go to HTTPS, but
in either case (direct or indirect) the --http-proxy command line
argument did not use the proxy for https.
|
|
|
|
|
|
|
| |
Refresh screen after printing the DFT data.
Use C++14 std::this_thread::sleep_for to control the refresh rate.
Signed-off-by: Etienne Wodey <wodey@iqo.uni-hannover.de>
|
|
|
|
|
|
|
| |
- min_power and max_power arguments were swapped. They were always
called correctly, so this is more of a documentation fix.
- Add a unit test for the case where power values are not regular, which
is the normal case with real data.
|
|
|
|
|
|
| |
This adds two more keys to the dictionary return from
get_usrp_{rx,tx}_info() which can be used to query the calibration key
and serial.
|
|
|
|
|
|
|
|
| |
This allows asking the radio for the keys it uses to read/write its
calibration data.
By querying radio_control::get_{rx,tx}_power_ref_keys(), the return
values can be used to access uhd::usrp::cal::database::read_cal_data().
|
| |
|
|
|
|
|
|
| |
- The tracking mode was not set to power when calling set_power()
- The data consistency check had an inverted logic, thus always printing
a warning
|
|
|
|
|
| |
Disables CLANG_ASSISTED_PARSING and CLANG_OPTIONS, which are not
available in all Doxygen version, and are unused.
|
|
|
|
|
|
| |
- Change the git URL to https (from git protocol)
- Remove references to fpga-src
- Update branch information (removed references to maint)
|
|
|
|
|
| |
When the FPGA repo was merged back into the UHD repository, this line
was forgotten.
|
|
|
|
|
| |
When the FPGA repository was merged back into the UHD repository, this
line was forgotten.
|
|
|
|
|
|
|
|
|
|
|
| |
This adds the possibility to read cal data from flash/EEPROM by adding
callbacks to the database. Unlike the RC and FILESYSTEM data, this is
very device-specific, but we can let devices register callbacks in the
database so that reading cal data from flash can use the same APIs as
from RC or filesystem.
Note that this also gives a convenient way to inject call data during
unit tests, if desired.
|
|
|
|
|
|
|
| |
This is a refactoring with no functional change. Instead of hard-coding
the lookup of RC and FILESYSTEM data, we loop over a structure holding
those. This will make it easier to add more types of data lookup in the
future.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note that the TwinRX has a different behaviour if two or one channel are
enabled. For that reason, TwinRX requires 8 different sets of
calibration data:
- For one vs. two channels
- For channel 0 and channel 1
- For RX1 and RX2
Since every combination of these settings is possible, that results in
2^3 == 8 combinations.
The choice of RX1 vs. RX2 is encoded in the calibration key. The choice
of one vs. two channels is also encoded in the calibration key, and is
derived using an expert node.
Channel 0 and 1 are assumed symmetric, thus, the encoding for those
happens in the calibration serial.
|
|
|
|
|
|
|
|
| |
This adds a property tree node "id" next to the "name" node. It is
always either basicrx/lfrx/basixtx/lftx based on the daughterboard. The
x300_radio_control uses this to help distinguish daughterboards for
calibration's sake, where length strings, potentially with special
characters, are too unwieldy.
|
|
|
|
|
|
|
|
|
|
|
| |
This is a utility that can be used to measure received power, assuming
a calibrated device.
For example, it can be called like this:
usrp_power_meter.py -a type=x300 -f 1e9 --mode continuous
To continuously measure input power at 1 GHz.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The pwr_cal::get_gain() method previously held the incorrect assumption
that power values per frequency would be equidistant, i.e., be at the
same indices as the gain values. Due to the frequency-dependent nature
of the hardware, this is not a valid assumption (if that were the case,
frequency-dependent calibration would be unnecessary).
This changes get_gain() to not rely on that assumption. Note that it
requires doing some more rounding: The bilinear interpolation method
uses requires coordinates to be on a rectangular grid. This snaps the
power values onto a single coordinate.
|
|
|
|
|
| |
This is a utility class that can be used by USRP or daughterboard
drivers to tie power calibration into their respective drivers.
|
|
|
|
|
| |
This unnecessary reads causes timed commands on rhodium to block. It
also makes it behave differently based on whether logging is enabled.
|
|
|
|
|
| |
If a timed command is in the queue, writes use a large timeout.
Changing reads to do the same.
|
|
|
|
|
| |
usrp_burn_db_eeprom operates directly on property tree paths, and so the
utility required an update to work with RFNoC devices.
|
|
|
|
|
|
|
|
|
| |
In commit 6a488d32, the RFNoC image builder module was moved from the
host/utils/bin subdirectory to host/utils. That move rendered the relative
path to the configuration directory in `get_config_path()` incorrect.
This commit fixes the relative path specification of the configuration
directory to reflect the new location of the
Python script.
|
|
|
|
|
|
| |
The implementation of set_command_time was calling wb_iface set_time,
which in turn makes a recursive call to set_command_time. This removes
the erroneous recursive call.
|
|
|
|
|
| |
Recent commits have removed all usage of the 'six' Python module from
UHD, thus removing the necessity to install it.
|
|
|
|
| |
Also fixes a few minor PyLint complaints.
|