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
On 08/28/2012 12:03 PM, Anisha G. 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
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?
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 08/28/2012 01:39 PM, Anisha G. 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
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
On 08/28/2012 03:24 PM, Anisha G. 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:
-
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. -
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 -
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
Hello,
Sorry for the lack of response, I was on vacation. We actually managed
to
fix most of our problems, mostly due to hardware setup issues. Thank you
for your help!
On 29 Aug 2012 15:13, Josh B. wrote:
On 08/28/2012 03:24 PM,
Anisha G. 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, AnishaCan 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:
- 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.
I’ve observed, in a previous life, phase-hits between two GPSDOs
connected to the same antenna, watching the same cluster of satellites.
Never figured out why, which is why for phase-sensitive work, it makes
sense to use a common reference, (like an external GPSDO), rather than a
GPSDO-per-unit.