discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] How do I capture of the time of USRP N210 samples


From: LD Zhang
Subject: Re: [Discuss-gnuradio] How do I capture of the time of USRP N210 samples with host computer system time?
Date: Wed, 16 Jan 2013 23:32:45 -0800

Hi,

Please see my comments below:

-----Original Message-----
From: Josh Blum [mailto:address@hidden On Behalf Of Josh Blum
Sent: Wednesday, January 16, 2013 5:19 PM
To: LD Zhang
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] How do I capture of the time of USRP N210
samples with host computer system time?

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

>>>
By now I think all parties agree that going thru python adds a lot of
variability to the approach. However, if the two flowgraphs can be made to
USE THE SAME TIME, the variability should be gone. Right now the problem is
that the following identical set of commands are executed at 2 different
computers (both sync'd to NTP but at different site):

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

I believe the basic uncertainty is that the time of executing set_time_now
is somewhat uncertain within 2 totally independent computer's python script,
even though the time of executing the python script is well behaved. If I
understand Josh correctly, he is suggesting to actually use the same time. I
understand this to be doing something between command 1 and 2 above. They
then become:

1.      self.uhd_usrp_source_0.set_time_now(uhd.time_spec_t(time.time()))
1.a - figure out what time it is now, say use: time_now = ???command???
1.b - round forward to schedule at a future common time:  suppose time_now =
xxx54.6 seconds, time_future =round((time_now+10)/10)*10 = xxx60.0 seconds.
2.      self.uhd_usrp_source_0.set_start_time(uhd.time_spec_t(time_future))

Does this look right?

Thanks,

LD




reply via email to

[Prev in Thread] Current Thread [Next in Thread]