Hi,
Please see my comment below:
On Wed, Jan 16, 2013 at 2:30 PM, Josh Blum <[email protected]
<mailto:[email protected]>> wrote:
On 01/16/2013 03:37 PM, LD Zhang wrote:
> 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))
>
How are you communicating the same start time to each device in your
setup? Suppose there were two devices, would it not be more like this:
self.uhd_usrp_source_0.set_time_now(uhd.time_spec_t(time.time()))
self.uhd_usrp_source_1.set_time_now(uhd.time_spec_t(time.time()))
#start stream time common for all N devices
start_time = uhd.time_spec_t(time.time() + 0.5)
self.uhd_usrp_source_0.set_start_time(start_time)
self.uhd_usrp_source_1.set_start_time(start_time)
-josh
The 2 USRP is each connected to a different computer. Each computer is
sync'd in time via NTP update. Since NTP time is accurate to ~ 1ms, I
consider the 2 computers sync'd right after the NTP update. There is
network communication (socket signal) between the 2 computer so that
they note their system time immediately after the socket signal and
schedule (round forward to a future integer 10 second point) to
perform the same action (data gathering) at the same time in the
future. That is, each schedule an amount of time and each watch its
clock, when it gets to that scheduled point, it immediately launches
the top_block.py script in which the same set_time_now and
set_start_time command are performed. There is no "_0" and "_1"
distinction because each is operating independently. I am still
scratching my head on what happens inside the USRP in grabbing the
first sample in a continuous data stream. Maybe the better solution
here is to grab the metadata structure which gives the timestamp of
the first sample? Since I have never messed with USRP cpp code before,
I want to be careful in what I am doing. I would like to find out what
cpp file to modify, how to modify it, and how to rebuild afterwards.
Thanks very much,
LD
_______________________________________________
Discuss-gnuradio mailing list
[email protected] <mailto:[email protected]>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
There's a profoundly-variable and "jittery" amount of time that it takes
to start a Python interpreter and "get things going" between any two
serial invocations on the *same machine*, let alone on two different
machines. They may well agree on what time it is (to a first order
approximations) when they both say "go", but after that, I can easily
imagine the behaviour to be not entirely deterministic.
--
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
