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 [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
