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