Re: Late packets when using set_time_next_pps and set_start_time with Function Probe

[Manav Kohli]

Yes, this is on a single USRP. I'll check the Python code to confirm the presence of set_start_time calls.

The point about group delay in the up and downconverters is well understood.

Theoretically the Rx could be started before the Tx - I am working with a real-time system so it would just require a synchronizer somewhere in the flowgraph. 

Thanks a lot - this is really helpful information and I will give the single source or sink blocks to unknown PPS a try.

On Wed, Dec 29, 2021 at 10:51 AM Marcus D. Leech <patchvonbraun@gmail.com> wrote:

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 <patchvonbraun@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 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.