[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Implementing timed transmission: UHD API or Strea
From: |
Martin Braun |
Subject: |
Re: [Discuss-gnuradio] Implementing timed transmission: UHD API or Stream Tags? |
Date: |
Thu, 14 Jul 2016 14:09:09 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 |
Yes, you can time down to the clock cycle. The time it takes for a
signal to propagate to the antenna after it is released depends on the
interpolation rate and the hardware, but it doesn't vary a lot (assuming
everything else constant, such as temperature). You can calibrate that
out quite well -- a few years back I did some radar measurements this
way. I had to calibrate an initial offset, but once I knew that there
was no tracking etc. required.
M
On 07/13/2016 09:24 AM, Lakshay Narula wrote:
> 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)?
>
> 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
>