Hi,
Please see my response below:
self.uhd_usrp_source_0.set_start_time(start_time)
(round forward to a future integer 10 second point) to perform the same
execution of the flow graph and creation of device objects is
introducing all this extra variability.
-josh
My understanding is that the approximately same start time is enforced
at
the 2 computer that have just been sync’d to NTP, because the
top_block.py
is executed at the approximately (~ 1 ms accuracy) the same time. And
inside top_block.py the same code is applied to the 2 units. So I would
expect approximately the same start time is used. Maybe not. Maybe the
better way to do this is to get away from the top_block.py script and
start
using the rx_samples_to_file command, and get the metadata structure
info
and correct for the difference in the metadata timestamp. My question is
what are the files to modify and how I save the metadata, whether in a
separate file or in the same file as the sampled data.
Thanks,
LD
On 01/16/2013 05:17 PM, LD Zhang wrote:
GRC as follows:
self.uhd_usrp_source_0.set_time_now(uhd.time_spec_t(time.time()))
“_0” and “_1” distinction because each is operating independently. I am
The code snippet was just supposed to help demonstrate. You need to
share the same start time for both flow graphs for this to work. The
fact that you are using different start times and scheduling the
execution of the flow graph and creation of device objects is
introducing all this extra variability.
-josh
On 01/16/2013 06:26 PM, LD Zhang wrote:
sync’d in time via NTP update. Since NTP time is accurate to ~ 1ms, I
the 2 computer that have just been sync’d to NTP, because the top_block.py
Once you sync the USRP time to NTP. The same start time is enforced by
actually using the same start time. I highly recommend doing this.
#syncs to NTP with some small error
self.uhd_usrp_source_0.set_time_now(uhd.time_spec_t(time.time()))
#tells device to stream at time X
self.uhd_usrp_source_0.set_start_time(start_time_for_both_devices)
is executed at the approximately (~ 1 ms accuracy) the same time. And
inside top_block.py the same code is applied to the 2 units. So I would
expect approximately the same start time is used. Maybe not. Maybe the
By executing the flowgraphs at the same time, instead of actually using
the same time, you adding the variability of how long it takes to open
python, construct blocks, and construct the usrp object (which is quite
long).
better way to do this is to get away from the top_block.py script and start
using the rx_samples_to_file command, and get the metadata structure info
and correct for the difference in the metadata timestamp. My question is
what are the files to modify and how I save the metadata, whether in a
separate file or in the same file as the sampled data.
The rx_samples_to_file example does not write out the metadata to file.
But it can be modified.
But don’t you think its harder to do it this way? have two unaligned
streams, process the start time, remove some samples for the offset in
time… When you could just have two streams at the same time?
-josh
Hi,
This is a very useful input and it may very well explain the situation
(some
one has also suggested that NTP is not the right protocol for 1-2 ms
accuracy. This is a separate problem from what we are discussing here)
and
the variability. There has been a growing dissatisfaction with the GRC
generated python approach and I would like to move to the
rx_sample_to_file
command approach and start modifying the associated cpp files. Would you
say
that the performance will be more stable with the latter approach?
However, I don’t how to do the command line method. I suppose there
would be
many arguments given to the “rx_sample_to_file” command to make it do
what I
want. But the help menu info on this command is very limited, does not
touch
on needs with set_time_now and set_start_time parameters in the data
gathering process. Basically I suppose if I can do the rx_sample_to_file
command and correctly impose the set_time_now and set_start_time option,
there should be much less variability than the python approach. Does
this
look right?
Thanks,
LD
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.
Hi,
Please see my comments below: