| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The default block controller is used whenever no other block controller
is used. It currently defaults to dropping both property propagation and
actions.
When a custom block is injected into a graph like this for example:
Radio -> DDC -> Custom Block -> Rx Streamer
This default behaviour causes the Rx Streamer to not be able to send
actions (like stream commands) nor does it allow MTU propagation (or any
other property's propagation).
The default block behaviour is ONE_TO_ONE, meaning that actions and
properties on input channel N will get forwarded to output channel N. In
absence of an actual block controller, this is more useful default than
setting the propagation to DROP for both actions and properties. Most
blocks that pass through data, or do some simple processing, will now
work in the absence of a block controller.
The new disadvantage is that blocks which would modify properties such as
sampling rate, scaling, or MTU will no longer work properly in the
absence of a block controller.
However, the recommended behaviour is anyway not to operate without a
block controller. For the cases where no block controller is present,
ONE_TO_ONE is considered the generally more useful default.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These two values where being mixed up in the code. To summarize:
- The MTU is the max CHDR packet size, including header & timestamp.
- The max payload is the total number of bytes regular payload plus
metadata that can be fit into into a CHDR packet. It is strictly
smaller than the MTU. For example, for 64-bit CHDR widths, if
a timestamp is desired, the max payload is 16 bytes smaller than
the MTU.
The other issue was that we were using a magic constant (DEFAULT_SPP)
which was causing conflicts with MTUs and max payloads.
This constant was harmful in multiple ways:
- The explanatory comment was incorrect (it stated it would cap packets
to 1500 bytes, which it didn't)
- It imposed random, hardcoded values that interfered with an 'spp
discovery', i.e., the ability to derive a good spp value from MTUs
- The current value capped packet sizes to 8000 bytes CHDR packets, even
when we wanted to use bigger ones
This patch changes the following:
- noc_block_base now has improved docs for MTU, and additional APIs
(get_max_payload_size(), get_chdr_hdr_len()) which return the
current payload size given MTU and CHDR width, and the CHDR header
length.
- The internally used graph nodes for TX and RX streamers also get
equipped with the same new two API calls.
- The radio, siggen, and replay block all where doing different
calculations for their spp/ipp values. Now, they all use the max
payload value to calculate spp/ipp. Unit tests where adapted
accordingly. Usage of DEFAULT_SPP was removed.
- The replay block used a hardcoded 16 bytes for header lengths, which
was replaced by get_chdr_hdr_len()
- The TX and RX streamers where discarding the MTU value and using the
max payload size as the MTU, which then propagated throughout the
graph. Now, both values are stored and can be used where appropriate.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The replay block is more like the radio block than like a FIFO. In
particular, consider this flow graph:
Replay -> DDC -> Replay
Imagine you're using the replay block to test the DDC block with
prerecorded data. If we treated the Replay Block like a FIFO, then we'd
have a loop in the graph (which is already wrong). If we used the DDC to
resample, then the input- and output sample rate of the Replay mismatch,
which is a legal way to use the Replay block, but not possible if we
treat the graph like a loop.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The async message handler and the async message validator would
erroneously compare channel numbers for RX async messages with the
number of valid TX channels. On TwinRX, where there are zero TX
channels, this would always fail. Elsewhere in the code, the comparisons
for TX and RX channels mixed up input and output ports.
The second issue is that the comparison made was a "greater than" rather
than "greater or equal".
The effect of these two bugs was that potentially, we could have
accepted async messages for an invalid port N, where N is the number of
valid ports of this block, and that for TwinRX/X300 users, async
messages on channel 1 would not get accepted (they would, however, get
accepted for channel 0 because of the second issue). This includes
overrun handling, which was broken for channel 1 and 3 on an X300.
Another effect of the bug was that EPIDs for async messages weren't
always programmed correctly.
|
|
|
|
|
|
|
| |
Getting the time from the mb_controller is slow, so try to get the time
from the Radio on the fast path first.
Signed-off-by: michael-west <michael.west@ettus.com>
|
|
|
|
|
|
| |
Add API calls to Radio control to get ticks and time.
Signed-off-by: michael-west <michael.west@ettus.com>
|
|
|
|
|
|
|
|
|
|
|
| |
The order must:
- Check transaction has the right number of hops, then read hop
- Check hop has the right number of operations (at least 2), then read
those ops
- Check the ops have the correct opcodes
The code was doing checks in the wrong order. Thanks to Github user
johnwstanford for pointing this out.
|
|
|
|
|
|
|
| |
This provides every block controller with a copy of its CHDR width.
Note: mock blocks always get configured with a 64-bit CHDR width, to
retain API compatibility.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes some constants from UHD that were left over from RFNoC/UHD
3.x. They are unused.
rfnoc_rx_to_file had a commented-out section that was also UHD-3 only.
Note that rfnoc/constants.hpp is pretty bare now, and could be removed.
However, it is in the public header section, so we shall leave the used
constants where they are.
This requires fixing includes in mgmt_portal.cpp.
|
|
|
|
|
|
|
|
|
| |
The I and Q were swapped in sine_tone, which caused confusion and made
the rotation of REG_CARTESIAN clockwise by default. This effectively
made the resulting frequency negative. This PR makes the I and Q order
consistent with RFNoC and fixes the direction of rotation so that a
positive value for REG_PHASE_INC (phase increment) results in a
counter-clockwise rotation, which yields a positive frequency.
|
|
|
|
| |
Thanks for github user johnwstanford for pointing those out.
|
|
|
|
|
|
|
|
|
| |
The variable max_size_bytes has a different name in the source than in
the header and is not self-explanatory in both. Therefore when comparing
against it in the assertion in line 142 one could assume that a number
of bytes needs to be compared with a byte value. Change variable to
`buff_size` in source and header file to avoid confusion and add
documentation.
|
|
|
|
|
| |
This modifies some log messages or exception strings when using
auto-correction APIs that are not supported by the underlying device.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The tuning range of the DUC depends on the output sample rate (which is
larger), but it was using the input sample rate. This was causing a bug
where for Tx, the DSP tuning range was limited when using multi_usrp API,
and thus would not allow to DSP-tune beyond the current sampling rate.
In this patch, we also re-use the existing calculation of the sampling
rate, and harmonize that code between duc_block_control and
ddc_block_control.
Consider the following Python REPL code:
>>> import uhd
>>> U = uhd.usrp.MultiUSRP('type=x300')
>>> U.set_rx_rate(10e6)
>>> U.set_tx_rate(10e6)
>>> # Creating a streaming is required, or the input rate will not be
>>> # set:
>>> S = U.get_tx_stream(uhd.usrp.StreamArgs("fc32", "sc16"))
>>> treq = uhd.types.TuneRequest(1e9)
>>> treq.rf_freq = 1e9
>>> treq.dsp_freq = 50e6
>>> treq.dsp_freq_policy = uhd.types.TuneRequestPolicy.manual
>>> treq.rf_freq_policy = uhd.types.TuneRequestPolicy.manual
>>> tres = U.set_rx_freq(treq, 0)
>>> print(str(tres))
Tune Result:
Target RF Freq: 1000.000000 (MHz)
Actual RF Freq: 1000.000000 (MHz)
Target DSP Freq: 50.000000 (MHz)
Actual DSP Freq: 5.000000 (MHz)
>>> # Note the last two lines: The *target* DSP freq was already clipped
>>> # to 5 MHz. These lines show 50.0 MHz when this patch is applied.
This bugfix is accompanied some related changes:
- The unit test is amended to verify the behaviour
- The API documentation is amended with details on its behaviour
|
|
|
|
|
| |
This commit adds `get_src_epid()` and `get_port_num()` method bindings
to the Python bindings for `noc_block_base`.
|
|
|
|
|
|
| |
Fix implicit typecasts that could potentially lose data. Doing this to
show that these typecasts are done on purpose (and to resolve warnings
from VS).
|
|
|
|
|
|
| |
Fix the "Enum.3: Prefer class enums over "plain" enums" warning for the
node_type enum and update the calls to the enumerators as proposed by
the C++ Core Guidelines.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By changing the type for accesses to noc_block_base calls in the Python
from sptr& to a simple reference (&), we fix the "holder type" issues
that crop up when trying to use radio_control from multi_usrp, which
returns access to the block as a reference rather than a `sptr`.
The error message seen without this fix always contains this string:
Unable to cast from non-held to held instance (T& to Holder<T>)
(The exact message depends on the API call made).
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In current implementation it is not possible to find all blocks of
a device by calling find_blocks("0/"). The same is true for the
block count. This is caused by the valid block id regex which
requires a block name. This regex is used to validate the block
name as well as to match block ids in search.
This fix looses the requirement for the block name to allow
searches by device number and block count and also extends the
is_valid_block_id method to require the block name match to be
non empty (which restores the previous behaviour at this point).
|
|
|
|
|
|
|
| |
meta_range_t(0,0) actually calls the iterator-based constructor for
meta_range_t, which is almost certainly not the intended constructor
for that call syntax. Therefore, we add a static_assert to prevent
such usage, and fix all failing instances.
|
|
|
|
|
|
|
|
| |
The Boost version is identical to the std:: version (which is available
since C++11) and thus is no longer needed.
Because of implicit includes, this breaks compilation in other parts.
Appropriate includes were added there also.
|
|
|
|
|
|
|
| |
Its behaviour is almost identical to std::lround, which we use instead.
The only downside of std::lround is that it always returns a long, which
we don't always need. We thus add some casts for those cases to make the
compiler happy.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Co-authored-by: Lars Amsel <lars.amsel@ni.com>
Co-authored-by: Michael Auchter <michael.auchter@ni.com>
Co-authored-by: Martin Braun <martin.braun@ettus.com>
Co-authored-by: Paul Butler <paul.butler@ni.com>
Co-authored-by: Cristina Fuentes <cristina.fuentes-curiel@ni.com>
Co-authored-by: Humberto Jimenez <humberto.jimenez@ni.com>
Co-authored-by: Virendra Kakade <virendra.kakade@ni.com>
Co-authored-by: Lane Kolbly <lane.kolbly@ni.com>
Co-authored-by: Max Köhler <max.koehler@ni.com>
Co-authored-by: Andrew Lynch <andrew.lynch@ni.com>
Co-authored-by: Grant Meyerhoff <grant.meyerhoff@ni.com>
Co-authored-by: Ciro Nishiguchi <ciro.nishiguchi@ni.com>
Co-authored-by: Thomas Vogel <thomas.vogel@ni.com>
|
|
|
|
|
|
|
|
|
|
|
| |
When a node has an action callback assigned this must be cleared
along with the block removal. Otherwise a post action callback
might try to modify node that are already removed which results
in an undefined behavior.
In particular this one fixes the
Unexpected error [ERROR] [CTRLEP] Caught exception during async message handling: map::at
when running the multi_usrp_test.py
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In 073574e24, the MTU property resolver in `noc_block_base` was
refactored to make the resolver's output sensitivity list less
broad. The broadness was intentional as a consequence of allowing the
MTU forwarding policy to be changed at will, but had the unintended side
effect of being incompatible with certain RFNoC graph use cases. The
refactoring solved the issues, but added a new restriction that the MTU
forwarding policy could only be called once per instance of a NoC block.
Unfortunately, that refactoring introduced a bug. By moving the
registration of MTU resolvers to `set_mtu_forwarding_policy()`, no
resolvers would be added if the MTU forwarding policy was never changed
from the default of `DROP` (which is the case for the vast majority of
NoC blocks). However, the resolver had code that would run in the `DROP`
case to coerce the incoming MTU edge property to be the smaller of the
new value or the existing MTU value on that edge. With the resolvers
only getting added when the MTU forwarding policy is changed, this
coercion behavior would never execute, thus breaking a number of
devtests.
This commit ensures that the default coercion behavior is always present
regardless of whether the MTU forwarding policy is changed or not.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to this commit, the MTU property resolver in noc_block_base had an
issue: for every MTU edge property (both input and output on each port)
on the block, the property resolver listed every other MTU edge property
in its output sensitivity list, regardless of whether or not the output
edge properties would ever be affected by the current MTU forwarding
policy. This breaks an inherent (and up until now, unwritten) contract
between a property resolver and UHD that only properties that can be
affected by the resolver should be included in the output sensitivity
list. The result of breaking the contract leads to errors being thrown
when committing an RFNoC graph in certain multi-channel use cases.
This commit refactors the MTU property resolver to use the MTU
forwarding policy to determine the correct set of edge properties to
include in the output sensitivity list. The change also introduces a new
restriction--the MTU forwarding policy may only be set once per instance
of a noc_block_base. Typically, a subclass implementing an RFNoC block
will call `set_mtu_forwarding_policy()` in its constructor to set a
custom MTU forwarding policy (if desired) and leave it untouched for the
lifetime of the block.
|
|
|
|
|
|
|
|
|
| |
A loop in mgmt_portal::_validate_stream_setup() was missing a sleep,
which was causing it to return long before the timeout with a timeout
error. This change adds that sleep and reduces the duration of the
sleep so it responds faster.
Signed-off-by: Michael West <michael.west@ettus.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Disabling this feature will allow the USRP to send a continuous stream
of Rx data to a host machine without throttling due to lack of flow
control credits. This is unnecessary overhead on lossless transports
such as pcie or aurora.
Usage: add 'enable_fc=false' to stream_args.args
Signed-off-by: mattprost <matt.prost@ni.com>
|
|
|
|
|
|
| |
This adds uhd::rfnoc::radio_control::get_spc(). It can be overridden by
radio implementations, but radio_control_impl has a sensible default
implementation, return the value that is in the SPC radio register.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The const-ness of some radio_control differed between base class and
implementation. This fixes the consistency, but also makes sure these
methods follow the rules for when to make methods 'const'.
The following rules apply:
- Methods that query static capabilities are const. Here, we made
get_tx_lo_sources() const (the RX version was already const).
- Getters that may have to interact with the device (e.g., peek
a register) are not const, because the act of peeking is usually also
non-const. Here, we changed get_rx_lo_export_enabled() to non-const.
- All base classes are fixed such that the derived classes and the base
classes have the same const-ness. Clang was warning about differences.
This can cause very tricky bugs, where the radio_control_impl version
can get called instead of the intended child class.
|
|
|
|
|
|
|
|
|
|
|
|
| |
The checks from the new clang-tidy file are applied to the source tree
using:
$ find . -name "*.cpp" | sort -u | xargs \
--max-procs 8 --max-args 1 clang-tidy --format-style=file \
--fix -p /path/to/compile_commands.json
Note: This is the same procedure as 107a49c0, but applied to all the new
code since then.
|
|
|
|
| |
This is a pessimizing move, and clang warns about it.
|
| |
|
|
|
|
|
| |
The constants were either commented out, when their value is still
useful to the reader, or removed if not.
|
|
|
|
|
|
|
|
|
| |
The checks from the new clang-tidy file are applied to the source tree
using:
$ find . -name "*.cpp" | sort -u | xargs \
--max-procs 8 --max-args 1 clang-tidy --format-style=file \
--fix -p /path/to/compile_commands.json
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds another resolve_all_properties method to use the
node instead of the vertex descriptor. The vertex descriptor could be
removed. This could cause the lambda capture to have an outdated
vertex descriptor, which would result in a hang when looking for it.
This resolves the issue by capturing the node and looking for the vertex
descriptor.
Signed-off-by: Steven Koo <steven.koo@ni.com>
|
| |
|
|
|
|
|
|
| |
- Add get_item_width() and get_nipc() methods to the Null/Source/Sink
block controller.
- Add missing enumerated types for get_count() method.
|
|
|
|
|
|
| |
These rf_control interfaces allow easier implementation of
radio controls as well as allowing easier sharing of code
for implementing e.g. gain_profile.
|
|
|
|
|
|
|
|
| |
When configuring remote streams, we were setting the format at the
source stream endpoint, but not at the destination stream endpoint.
Therefore, the destination used the default or whatever it was set to
during a previous run. This change sets the format at the destination
stream to match the format of the source stream.
|
| |
|
|
|
|
|
|
|
|
| |
Requesting zero samples was resulting in an error and causing applications
to crash. This was a change frome previous versions of UHD. Demoted to
warning so applications continue as they did before.
Signed-off-by: Michael West <michael.west@ettus.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The default resolve callback behavior for a newly-instantiated `node_t`
object resolves all dirty properties associated with the node, then
marks the properties as clean. When the node is added to a graph, its
resolver callback is updated to use the graph property propagation
algorithm in `graph_t::resolve_all_properties()`, which is considerably
more sophisticated and relies on the graph topology to do its work.
When a connection between two nodes is broken via the
`graph::disconnect()` method, nodes which no longer have incoming or
outgoing edges (connections) are removed from the graph. Prior to this
change, the removed node's resolver callback was left pointing at the
graph property propagation algorithm. In certain use cases, this could
result in unexpected client-facing behavior. Consider, for example, this
code (incomplete and for illustrative purposes only) which creates a
streamer on one transmit chain of a multi-channel device, destroys that
streamer, then creates a stream on the other transmit chain. Attempting
to set the TX rate on the first chain after destroying the streamer does
not result in the expected rate change, despite the same code working
correctly before creating the streamer:
constexpr size_t CH0 = ..., CH1 = ...;
uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(...);
// Set a TX rate on both chains; this succeeds
usrp->set_tx_rate(initial_rate, CH0);
usrp->set_tx_rate(initial_rate, CH1);
assert(initial_rate == usrp->get_tx_rate(CH0));
assert(initial_rate == usrp->get_tx_rate(CH1));
// Create a TX streamer for channel 0
std::vector<size_t> chain0_chans{CH0};
stream_args_t sa;
sa.channels = chain0_chans;
sa.otw_format = ...;
sa.cpu_format = ...;
uhd::tx_streamer::sptr txs = usrp->get_tx_stream(sa);
// Destroy the first streamer (disconnecting the graph) and
// create a streamer for channel 1
txs.reset();
std::vector<size_t> chain1_chans{CH1};
sa.channels = chain1_chans;
txs = usrp->get_tx_stream(sa);
// Now try to set a new TX rate on both chains
usrp->set_tx_rate(updated_rate, CH0);
usrp->set_tx_rate(updated_rate, CH1);
assert(updated_rate == usrp->get_tx_rate(CH0)); // <--- FAILS
assert(updated_rate == usrp->get_tx_rate(CH1));
The reason this fails is because the second call to `set_tx_rate()` on
channel 0 internally sets the 'interp' (interpolation ratio) property on
the DUC node via the call to the DUC block controller's
`set_input_rate()` function. As the DUC node is no longer part of the
graph, having been removed from it when the first streamer instance was
destroyed, the graph property propagation algorithm doesn't 'see' the
node with the dirty property, and the 'interp' property resolver
callback is never invoked. As a result, the DUC's input rate property,
which depends on the interpolation ratio value, is never updated, and
thus calling the `get_tx_rate()` function to query the new rate of the
TX chain results in an unexpected value. In fact, in this particular
case, `set_tx_rate()` actually raises a warning that the TX rate
couldn't be set, and a message is printed to the console.
This commit remedies the situation by restoring the default resolve
callback behavior for a node when it is removed from the graph. This
allows the framework to be able to invoke the property resolver callback
on that node when a property is updated, the expected behavior of a
newly instantiated node.
|
|
|
|
|
|
|
| |
Fixes incorrect value for the DDS_GAIN that was causing the TX output
power to be 6 dB lower than it was supposed to be.
Signed-off-by: michael-west <michael.west@ettus.com>
|
|
|
|
|
|
|
|
| |
This commit expands the scope of the former _release_mutex, renaming it
_graph_mutex and ensuring that all graph modification functions are
serialized against each other. This ensures that callers to graph_t's
public functions are always operating on a coherent view of the
underlying BGL graph object.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The graph_t::disconnect(src_node, dst_node) function removes connections
(edges) from src_node to dst_node in the graph, and then removes the
nodes (vertices) if their degree is zero after removing the connections.
Because removing a vertex from the graph invalidates vertex descriptors,
the graph_t::_remove_node() function resynchronizes the node-to-vertex
descriptor map after removing the vertex.
However, in graph_t::disconnect(), the vertex descriptor corresponding
to dst_node was not being refetched after the potential removal of
src_node, which results in the incorrect removal of innocent nodes under
certain circumstances. This commit ensures that the node-to-vertex
descriptor is reconsulted for the vertex descriptor corresponding to
dst_node before removing it from the tree.
|
| |
|