Hi,
Please see my comment below:
On Wed, Jan 16, 2013 at 2:30 PM, Josh
Blum <address@hidden>
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
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
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
|