diff options
| author | Martin Braun <martin.braun@ettus.com> | 2019-05-02 16:10:52 -0700 |
|---|---|---|
| committer | michael-west <michael.west@ettus.com> | 2019-05-21 21:37:19 -0700 |
| commit | 62e6e2899d6bc2c709473ffe059e6ff786a813f0 (patch) | |
| tree | ce92073f06ec9cb406f94559b3c68e5444d5637f /host/lib/usrp/fe_connection_python.hpp | |
| parent | 32ececbf36508a374d471ea370897b1c17cf1294 (diff) | |
| download | uhd-62e6e2899d6bc2c709473ffe059e6ff786a813f0.tar.gz uhd-62e6e2899d6bc2c709473ffe059e6ff786a813f0.tar.bz2 uhd-62e6e2899d6bc2c709473ffe059e6ff786a813f0.zip | |
rfnoc: tick_node: Search all nodes for tick rates
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.
Diffstat (limited to 'host/lib/usrp/fe_connection_python.hpp')
0 files changed, 0 insertions, 0 deletions