On 08/28/2012 03:24 PM, Anisha Gorur wrote: > Sorry for the confusion. We are trying to synchronize 3 usrps for collect. > The devices seem to be time aligned in that the samples are timestamped > with the same metadata, so we believed that synchronization had been > achieved. However, when the data collected from the usrps was correlated, > samples that should have had 0 time difference of arrival were off by as > many as 5 samples, at a sample rate of 6.25MS/S. So even though the > timestamps are time aligned, the data does not seem to be. The devices have > been synchronized PPS times, not uspr.get_time_now(). > Thank you, > Anisha
Can you tell me more about the correlation? Are you sending a impulse split to all 3 devices and determining the pulse arrival. Is the error in time of arrival consistent between runs or does it seem to be random? If you ask all N USRPs to stream at time X, the time reported in the metadata will still be X, even if the internal tick count in each device is not marching in lock step. I have a few suggestions: 1) I think you have 1 GPSDO per USRP providing each a different reference. I would first try the experiment with a shared 10 MHz reference and PPS to all devices to confirm the algorithm. You will need to move the 10 MHz reference jumper back so you can provide an external ref via SMA. 2) When you use the GPSDO, make sure that each one reports locked. The gps_locked is available through the python interface as well: http://files.ettus.com/uhd_docs/manual/html/gpsdo.html#using-the-gpsdo-in-your-application 3) Its good to make sure that you are correctly setting the time. A quick check would be to read get_time_now() on all devices after setting the time on the next pps. You should be able to see that the time from each device is about the same, within an RTT. -josh > On Tue, Aug 28, 2012 at 5:40 PM, Josh Blum <j...@ettus.com> wrote: > >> >> >> On 08/28/2012 01:39 PM, Anisha Gorur wrote: >>> Thats actually what we are using, however, when printing out the tick >>> count, we randomly, and only sometimes, see a jump of about 30 ticks, and >>> if each tick is 10ns, that is a huge 300ns jump. Do you know why this >> could >>> be happening? >>> >> >> I'm very lost. Where are you getting the time_spec from? A receive >> packet? usrp.get_time_now()? Or is this a time difference between devices? >> >> get_time_now is completely asynchronous to the device, if thats what you >> are calling in a loop, I would expect to see a lot of variation in time >> deltas. >> >> -josh >> >>> We are using gpsdo's as both a time and clock reference, though this >>> problem seems to occur even if we set the clock and time reference to >>> external. However, setting them to gpsdo seems to make it more stable, as >>> we have seen the ~30 tick jump fewer times with those references. Another >>> question is why would there be a big difference in what the reference is >>> set as when either way, supposedly the internal GPSDO is being used. >>> >>> Thanks, >>> >>> On Tue, Aug 28, 2012 at 4:13 PM, Josh Blum <j...@ettus.com> wrote: >>> >>>> >>>> >>>> On 08/28/2012 12:03 PM, Anisha Gorur wrote: >>>>> Hello, >>>>> We've been having some trouble with the synchronizing aspects of our >>>>> project. What we want is the exact same time as the FPGA tick counter, >>>> not >>>>> a time_spec_t representation of time. Where can we get access to that? >>>>> Thanks! >>>>> -Anisha >>>>> >>>>> >>>> >>>> call to_ticks with the clock rate of the device: >>>> >>>> >> http://files.ettus.com/uhd_docs/doxygen/html/classuhd_1_1time__spec__t.html#ad75960ba4c788cd30a5d0c8904888da3 >>>> >>>> -josh >>>> >>>>> >>>>> _______________________________________________ >>>>> Discuss-gnuradio mailing list >>>>> Discuss-gnuradio@gnu.org >>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>> >>>> >>>> _______________________________________________ >>>> Discuss-gnuradio mailing list >>>> Discuss-gnuradio@gnu.org >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>> >>> >>> >>> >> > > > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
