On 2021-12-28 23:04, Manav Kohli wrote:
Dear Marcus,
Thanks a lot for your reply and hope you are enjoying the Holidays.
I am trying to have the Tx and Rx of a radio start at the same time. I
(currently) need to have a well-defined, consistent sample offset
between Tx and Rx in my flowgraph. When the Tx and Rx start is not
important, just that they start at the same time.
What you said makes a lot of sense. I left out what is probably a
critical detail, which is that the USRP in question is synchronized to
an Octoclock. As long as I have the "sync" option set to "Unknown PPS"
should I not need any further function calls to ensure Tx and Rx start
at the same time in a consistent manner?
Thanks again
Just set *ONE* of either the source or sink blocks to "unknown PPS" (I
assume this is on a single USRP?). The generated code, assuming a
recent Gnu Radio, will include
set_start_time calls, which you can modify to whatever you want.
Also, because of group delay in DUC/DDC filters, there'll still be delay
that you'll need to characterize for your particular set-up.
Also, is it *ACTUALLY* the case that you need to start RX and TX at the
same time, or is it the case that RX could be started before TX, and you
could simply eliminate samples
in the stream that are from before TX notional start-up?
On Thu, Dec 23, 2021 at 9:39 AM Marcus D. Leech
<patchvonbr...@gmail.com> wrote:
On 2021-12-23 00:30, Manav Kohli wrote:
Hello,
Hope everyone is doing well. I am encountering an issue regarding
late packet arrivals when using Function Probe blocks to
call set_start_time and set_time_next_pps.
I have a flowgraph with a USRP Source and Sink and I am applying
the following two function calls to each (so four function probes
in total). The function probes have their rate set to 1e-9 (so
they should only ever run once).
set_time_next_pps(uhd.time_spec_t(0.0))
set_start_time(uhd.time_spec_t(2.0))
The USRP Sink is fed by a file source and the USRP Source feeds a
QT Frequency Sink. There is nothing else going on and the Sink
and Source are on the same subdev. If I run the flowgraph, the
following will invariably occur: a cascade of LLLL... printed to
stdout and the following warning: "gr::log :WARN: usrp_source0 -
USRP Source Block caught rx error code: 2"
Disabling the Function Probes with
set_start_time(uhd.time_spec_t(2.0)) or removing the time_spec_t
function parameter in the set_start_time function call let the
flowgraph run fine.
I've tried to look up exactly what is going on behind these two
function calls but I have been unable to make any headway. I saw
a previous thread here
<https://lists.gnu.org/archive/html/discuss-gnuradio/2015-10/msg00035.html>
which
doesn't seem to have a resolution.
GNU Radio & USRP environment:
Ubuntu 20.04
UHD 4.0.0.0
GNU Radio 3.8
USRP 2974
I think this may have something to do with the USRP and PC clocks
drifting apart, but this happens as soon as the Tx and Rx should
turn on, i.e. two seconds after running the flowgraph, so I am
not sure. Any help would be greatly appreciated, and thank you
for your time in reading through this post.
Take care
Manav
My suspicion is that your approach is "all wrong". What is it
you're trying to actually do?
The gr-uhd module already does this when you select "unknown_pps"
or "next_pps" in the "SYNC" option in the source/sink blocks.
Your approach is going to cause multiple
resets of the system clock on the radio, at unpredictable times,
likely leading to the results you're seeing.
