Thanks Martin, I wish to do something similar to radar measurements as
well, so I guess that is the path I'll take.

-Lakshay

> *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*
> >
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to