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 > On Dec 8, 2021, at 3:29 PM, Rob Kossler <[email protected]> wrote: > > Hi Jason, > A few questions: > - why do you want to avoid using PPS? > - are you using a common 10 MHz ref? > - what is the level of "synchronous" you are looking for? Are you hoping to > have simultaneous sampling across all channels? > Rob > > On Wed, Dec 8, 2021 at 3:15 PM Jason Merlo <[email protected] > <mailto:[email protected]>> wrote: > Hi All, > > I’m currently working to synchronize multiple X310’s clocks without a PPS > input, however right now the best method I can find to update the clock from > a host PC (using the C++ API) is to query the current time from the USRP > device (using usrp::multi_usrp::get_time_now), add a time delta to the > current time, then send back the new clock time to the USRP device (using > usrp::multi_usrp::set_time_now). Unfortunately, this method introduces large > timing errors due to the nondeterministic nature of packet processing on both > he CPU and network stack. > > I’m wondering if anyone knows of any other techniques for an "in-place" time > update. I.e., is there a method for the host PC to send a time delta to the > USRP which would be added to the clock register in a single operation? > > I see there are other get/set_time_now functions in the rfnoc::mb_control and > rfnoc::radio_control classes, but I’m not sure if these would allow me to > accomplish this using only the C++ API. I can’t seem to find much > documentation on this aside from the examples in the > “uhd/host/examples/rfnoc*” folder. > > If it’s not possible to accomplish this using a purely C++ approach, is it > possible to do this through a custom RFNoC block? I don’t have experience > with RFNoC at the moment and I’m not sure if that register is exposed to user > blocks, or if so, if the register update would be deterministic in time, but > if there’s motivation I would be willing go down the RFNoC path. > > Thanks in advance, > Jason > _______________________________________________ > USRP-users mailing list -- [email protected] > <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[email protected]>
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
