Re: [Discuss-gnuradio] How do I capture of the time of USRP N210 samples with host computer system time?

[LD Zhang]

Hi Folks,

Sorry for trying to resurrect this topic thought to be settled at one time. My earlier impression was somehow incorrect. Let me summarize the situation: basically one wants to gather data at approximately the same time for 2 USRPs. Using the 2 host computers sync'd to NTP, this appears to be feasible in principle. If they differ by 1 or 2 ms, I don't care and it's within tolerance of the particular application. 

So the quickest thing to do was to modify the top_block.py generated from GRC as follows:

                self.uhd_usrp_source_0.set_time_now(uhd.time_spec_t(time.time()))
                self.uhd_usrp_source_0.set_start_time(uhd.time_spec_t(time.time() + 0.5))

which basically set the USRP to system time and schedule the data gather start at 0.5 seconds away from the current time. A first test appeared to OK, roughly. But subsequent test shows that the start gather time differ between the 2 units by quite a bit, maybe 20-100 ms, or so. So looks like this approach does not work (So it looks Marcus was right when he said that one has to some dancing around to make sure it works, though I am curious what that dancing around is.).

At this point, there appears to be 2 other approaches:

1. drop the GRC approach and try to use the rx_samples_to_file command. The order of command I see would be as:
       first:  do an equivalent set_time_now command, although I am still searching for the exact syntax.
   second: according to what I read from an earlier topic, it seems that one has to make sure both the rx_samples_to_file.cpp and the rx_timed_samples.cpp need to be set a time_spec at the part of the code where the stream_cmd_t is set up. It appears that the rx_timed_samples.cpp is already set up correctly but not rx_samples_to_file.cpp? If so, how do I change the rx_samples_to_file.cpp? Also, once I am done changing, how do I rebuild the code suite?
    third: I suppose one do a rx_samples_to_file command with the right options - time in the future, etc. But this does seem to be doing the same thing as I was doing before. I don't see how this approach fixes the problem.
    Please provide suggestions for solving this problem.

2. A safer bet might be to try to get the timestamps of the data. This would require modifying the code that contains the metadata structure, which I currently don't know how to do. Also I have a question: suppose the code is modified correctly and metadata structure is properly retained. How can this metadata be saved either into a separate file or together with the captured sample streams in the same file?

Maybe there are other approaches, I am still on a path that avoids using the PPS. Your help is appreciated.

Thanks,

LD

On Mon, Jan 7, 2013 at 3:14 PM, Marcus D. Leech <address@hidden> wrote:

On 01/07/2013 04:46 PM, LD Zhang wrote:

Thanks to Josh and Marcus for their comments. The set_time_now command
works! After I put it in, the earlier observed 0.5 sec offset between the 2
USRP became ~0.1 second. So there is still work to do. I guess my options
are:

1. Make the set_start_time command to work. My question is how I can make it
work in python. I hand edited the set_time_now command to embed in the
initialization part of the top_block.py code generated from GRC (which has
worked). Do I just hand edit the set_start_time just following that command?
Now the problem is that after set_time_now, the USRP time is sync'd to the
system time. But what is the argument I should give to set_start_time?

If you're running this on two different computers, and using the local system clock, it'll be hard to make both USRPs really agree on what time
  it is.  Even if the two hosts are synchronized with NTP, you'll have to do a fair bit of dancing about to make sure that they both, more-or-less,
  do the set_time_now() with the same value, and at the same time.

This is why for precision synchronized samples, people use a GPSDO with a 1PPS output (to allow set_time_next_pps() ), and a 10Mhz
  refclock (so that the clocks on the two-or-more USRPs all step together at the same rate and phase).



--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org



_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio