Re: [Discuss-gnuradio] Implementing timed transmission: UHD API or Stream Tags?

[Lakshay Narula]

Thanks Usman, That was some really useful information. So if this is the case then I should be able to calibrate out both the DSP and analog delay (analog delays are supposed to be smaller and stable).

Also, a DAC delay must also be included in those calculations.

Best,

Lakshay.

Hi Martin,

Appreciate your reply to my questions. I agree that I cannot do better than a clock cycle, so that is settled. Let us say that I use GPSDO for my reference and I wish to transmit at GPS time t. Is it possible to control the transmit time to within (t plus/minus 1 clock cycle)? I have read other threads on this topic and it looks like the "tx_time" tag controls the time at which the packet is released to the DSP on-board USRP. So it would take some additional time for the packet to go through the DSP, DAC, and the antenna.

Now I would like to perform the experiment myself and see if this delay is something that I can calibrate out, but unfortunately we do not have the hardware on hand (I currently have DBSRX2 which cannot transmit). So I was wondering if you have some intuition about the kind of consistent/variable delays I would be seeing, and how bad you would expect the variation to be (~10 ns, ~100 ns, ~1 ms)?

It depends on the sample rate you selected in USRP sink block (for TX). Please see the following link for details.

http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-December/011802.html

Regards,

Usman
 

Thanks,

Lakshay.

> Hello,
>
> I am a new GNU Radio user. I am looking to build a system that can
> transmit a packet at a pre-defined time with very high accuracy (about 1
> nanosecond). Having gone through the mailing list I am aware that timed
> transmission is a common task and many people have asked similar
> questions. However, I am still a bit confused.
>
> 1. I see that there is an example tx_timed_samples that comes with the
> UHD source code. This is in C++ and uses the UHD API. Am I right in
> thinking that when implemented this way, it has nothing to do with GNU
> Radio at all? Is there any "reported accuracy" of this method in terms
> of difference between actual and required time of transmission?

Yes, that's accurate. This is more of a UHD/USRP issue. Note that you
can time to a clock cycle, which is longer than a nanosecond. Whether or
not your sample is lined up with a time reference of your choice to
sufficient accuracy also depends on the reference signal you're providing.

> 2. I also see that it is possible to achieve similar objectives using
> tx_time stream tags in GNU Radio. My question is if this method is
> equivalent to method 1 in terms of what goes on "under the hood"? If
> not, how do these differ, and which method would provide better accuracy
> in terms of agreement between actual and required time of transmission.
> Does GNU Radio use the UHD API "under the hood"?

Yes, it does, and tags are no better or worse than the API calls. They
may be more convenient, depending on your software. Internally, the UHD
send() call (which is how samples get to devices) is populated with a
timestamp in both cases.

> Please feel free to point me to resources I can read to get a better
> understanding of this architecture and relationship between UHD, GNU
> Radio, and USRP.

There's also the usrp-users mailing list, and UHD has a bunch of
examples. gr-uhd code is also a useful reference.

Cheers,
M