On 01/04/2013 01:55 AM, LD Zhang wrote: > Hello, > > > > Thanks for the note below. > > > > I am reading an older email exchange between Josh Blum and a guest. Josh > mentioned that there is a downstream block (in GRC I guess) that can use the > timestamp tag to decide which samples are to be stored. Also there appears > to be metadata utility to use. Maybe these magic functions such as stream > tags (or) and get_time_last_pps to get the job done. So far I have used none > of these utilities. My goal here is trying to avoid using the PPS if > possible. Since the data gathering is done infrequently, I tend to think > that the PPS can be avoided. I am trying not to use the PPS at least for > this phase of the development. Yes for the next phase with enhanced > capabilities, the external reference need will resurrect again. But it is > better not to use the PPS right now, unless I am wrong here and need > re-education of the USRP. The mimo cable is not an option since the 2 units > are not co-located. >
If you want to use the PC clock, I recommend calling set time now with the current PC time before scheduling streaming. This will make the USRP tick counter roughly match the PC clock. python: usrp_source.set_time_now(uhd.time_spec_t(time.time()) c++ usrp_source->set_time_now(uhd::time_spec_t(secs, micros, long(1e6)); This way, your only time-ambiguity is the variance in ethernet control packets and the difference in time between the different PCs. That should satisfy referenced to PC's time anyway... -------------------------------------- The next step would be to schedule when a stream begins for each device so they send RX samples to the host at the "same time" (according to the USRP anyway). I think the USRP source block supports setting the time, and streaming at a specific time, but there isnt a way to do this at the GRC level. So you might need some hand coded python added to the generated flowgraph, if you are using GRC. > > So is it possible to do the downstream block and metadata stream tags in GRC > (currently using UHD source block and file sink block)? > > The file sink does not save metadata, but I suspect you dont need to save the metadata if you presumably have asked the devices to stream at the same time. -josh > > Thanks very much, > > > > LD > > > > From: John Malsbury [mailto:[email protected]] > Sent: Thursday, January 03, 2013 11:24 PM > To: LD Zhang > Cc: [email protected] > Subject: Re: [Discuss-gnuradio] How do I capture of the time of USRP N210 > samples with host computer system time? > > > > You can get the synchronize two USRPs with an external reference or a USRP > MIMO <https://www.ettus.com/product/details/MIMO-CBL> cable, and specifying > the time to start streaming for both. > > -John > > > > > On Thu, Jan 3, 2013 at 11:18 PM, LD Zhang <[email protected]> wrote: > > Hi Folks, > > > > We are testing 2 USRP N210 units with data gathering (using GRC source and > file sink). The command from the host to the N210 is sent at the > approximately simultaneous time (referenced to system NTP time). However, > the samples gathered from the 2 units appear to differ by as much as 0.4-0.5 > seconds! The intention is to gather data at the 2 units at approximately the > same time as the pre-programmed system time commands. The gathering is done > with the top_block.py code generated from GRC. What happens inside the USRP > appears to be beyond my control here. So the natural thing to do here is to > time-stamp the samples with host computer system time. I hope that we don't > have to use an external reference for the USRP. Isn't there an internal USRP > clock that is continuously counting. If we can get the USRP clock counts to > tie together the samples counts and the host computer system time, we would > be in good shape. Is this a good idea? > > > > Your thoughts and help are appreciated. > > > > LD Zhang > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
