Added configuration of version.cpp file so @UHD_VERSION@ would be
properly replaced by the version string and @UHD_COMPONENT@ would
be properly replaced by the component string.
Signed-off-by: michael-west <michael.west@ettus.com>
Added cmake variable to set the component (currently UHD or MPM).
so the banner printed by the log_resource would reference the correct
component. Added accessor function and appropriate calls in log.cpp.
Signed-off-by: michael-west <michael.west@ettus.com>
- Reduce long tests from 3600 seconds to 600 seconds.
- Remove 2xRX@153.6e6 test for N310 10 GbE (not practical).
Signed-off-by: michael-west <michael.west@ettus.com>
- Fixes a case where the e320 would be unable to lock to an external 10 MHz
reference
- Previously, calling set_time_source would set the reference clock source to
internal as a side effect
This value should be 9 to correspond with the rev J motherboards.
This property was renamed to mboard_last_rev_compat in a previous commit.
But mboard_max_rev is actually a more accurate description,
since it specifies the latest hardware revision that the software
is aware of. I renamed all references back to mboard_max_rev.
The latest change to fix MTU and default frame sizes inadvertantly removed
the default send and recv buffer sizes in the MPMD UDP transport, which
caused receive timeouts and underruns at higher sample rates. This change
restores those values.
Signed-off-by: Michael West <michael.west@ettus.com>
Prior commit disabled flow control for all lossless links,
including links between blocks on the same crossbar. That
caused packets to jam up the crossbar leading to control
packets failing to ACK under certain conditions. This
reverts it so flow control is enabled and the crossbar is
kept clear.
Signed-off-by: Michael West <michael.west@ettus.com>
To check if a device is fully reachable through the
chdr address i.e. SFP port, an RPC request is sent
to "second_addr" and "addr" of that device. This commit
fixes the case where if "second_addr" is not connected to
the host, the function returns earlier and does not
check for "addr".
- Fixes an issue where a multi-device device3 object would cause connections to
be generated across devices in legacy_compat
- The connect_blocks function previously assumed that find_blocks would always
return blocks in the same device number order
Updated b2xx_fx3_utils to add a --query_bootloader option to check if
the bootloader is loaded or not.
Signed-off-by: michael-west <michael.west@ettus.com>
The latest changes to the get_*x_stream() functions to calculate the MTU for
the channel caused default frame size values to be ignored. This change fixes
that by changing the key from "send/recv_frame_size" to "mtu" and then changing
the implementations of make_transport() constrain the frame size values based
on the "mtu" value as well as any device and/or transport-specific limits.
Signed-off-by: Michael West <michael.west@ettus.com>
In the PACKET_INLINE_MESSAGE case, we need to extract the error code
from the packet buffer. But the buffer was being released before that
happens, resulting in garbage values for metadata.error_code.
There are edge cases where the lack of initialization of _current_freq
could crash libuhd. To resolve this, we initialize all elements of those
cores to sensible values using NSDMI.
Newer revisions of the E320 and N3xx motherboards use EEPROM version 3,
and store a rev_compat field. The rev_compat is the last revision that
this hardware is compatible with. We now use that instead of simply the
revision.
This includes a rev_compat field, which we can use to identify the last
hardware revision this hardware is compatible with. Example: Say the
current hardware revision is 7, but it is compatible with version 5,
then we store 7 as the current rev, and 5 as the rev_compat. Software
can now check the rev_compat rather than the current rev for
compatibility. This makes MPM more future-proof against minor,
compatible hardware changes.
The tick_node was trying to find the current tick rate by only querying
active blocks (i.e., blocks that were flagged active-streaming).
However, this is not necessary since we require all blocks to run at the
same tick rate.
In theory, querying active-only ports should be fine, but due to some
idiosyncrasies in our current graph code, connecting a single streamer
to channel 1 (out of 0, 1) would try and get the info from the wrong
port. This is not a fix to the graph code, but the change to tick_node
is also appropriate and is sufficient to fix the "late packets on
channel 1" issue.
This issue would manifest when sending timed packats to channel 1 in
a single-channel streamer. The problem is that it wouldn't be able to
read the correct tick rate.
The colour codes used for console logging were incorrectly defined.
Some colours would simply not rendered this way (e.g., red), others
had the boldness flag wrong.
