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