On 2021-12-08 16:29, Jason Merlo wrote:
Hi Rob,
Thanks for the quick response.
- why do you want to avoid using PPS?
I’m working on techniques for aligning the clocks on the X310's in
environments where a shared frequency reference and PPS distribution
by conventional means (cabled, or via GNSS) is not feasible.
- are you using a common 10 MHz ref?
For testing purposes I have a shared 10 MHz reference to keep the
clocks from drifting, so I only need to remove the initial timing bias.
- what is the level of "synchronous" you are looking for? Are you
hoping to have simultaneous sampling across all channels?
The goal is for the sampling to occur within +/-0.5 clock cycles
between two X310s while the shared frequency reference is present; the
time bias estimator has been verified to have sufficient accuracy to
support this, thus I’m limited by the accuracy with which I can set
the clock. To achieve the goal, the the clock set operation would need
to be accurate to within one clock cycle which I believe requires a
method of setting the local time offset (fetch, add, write-back) that
occurs with a deterministic latency that can be calibrated for.
In theory, this should be possible on the FPGA, but I’m wondering if
this is possible via existing means in the UHD API, or if it may be
implemented using custom RFNoC blocks somehow.
Thanks again,
Jason
There's no way you can expect a general-purpose OS like Linux to have
predictable latency at scales of 100nsec or better, and that's
pretty-much what you're
"fighting" when you use set_time_now()/get_time_now(), even over a
very-fast interface like 10GiGe. It is precisely for this reason that
things like 1PPS
triggering on the clock reset was developed as a technique for
synchronizing the time clocks on USRPs of various flavors. In the
almost two decades I've
mucked-about with SDR in general, and USRPs in particular, I haven't
seen anything better that a physical, shared, trigger signal like 1PPS,
combined with
a shared 10MHz reference.
_______________________________________________
USRP-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
