The offset is computed based on the assumption that the radios can properly timestamp received messages and transmit messages accurate to the clock tick using schedule transmissions. This is done using by performing scheduled RX bursts by filling the stream_cmd_t struct with a receive time spec before issuing the rx_streamer::issue_stream_cmd() to the rx_streamer, and similarly by filling the tx_metadata struct with a time spec before using the tx_streamer::send() command. From my testing this appears to properly schedule TX and RX bursts within one clock tick (which I believe is the intended function of these commands).
Because the synchronization bursts are happening via scheduled/timed commands from the FPGA, the latencies of the network layer and OS will have no effect on synchronization as the timing of the critical section is happening entirely within the FPGAs. The host PC is only scheduling the synchronization bursts at some time in the future and performing the processing on the bursts after they’ve occurred. I am fairly confident this technique is working and the time bias offset is being computed correctly and with sufficient accuracy to align the clocks to a fraction of a clock cycle. Thus, the issue remains adding a delta to the local clock of the device with a deterministic latency to correct for the computed bias; This seems reasonable to achieve if it can be done on the FPGA, even if the implementation may be somewhat involved. Fundamentally it’s a fetch, add, and write back. Primarily, I’m concerned with if it is possible to instruct the FPGA to do this via pre-existing API calls, or if I will need to implement my own RFNoC block to perform it (again I’m not too familiar with RFNoC, but this seems like it should be possible, if the time register can be accessed directly). Unfortunately, our desired applications wouldn’t allow for a White Rabbit implementation, this would be an alternative to White Rabbit as it will be infeasible to run fiber between the devices. Thanks, Jason > On Dec 8, 2021, at 4:52 PM, Rob Kossler <rkoss...@nd.edu> wrote: > >> - 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. > > I don't see how it could work even on the FPGA. The FPGAs from USRPs > 1 and 2 start off with different clocks. How is it helpful to have > each FPGA read its own clock and add an offset? The problem is you > have no way to know the delta between the clocks unless you could > guarantee that each device reads its clock at the same time. Doesn't > seem possible if the 'common denominator' is the PC sending get() > commands over Linux/Ethernet. And, if the PC is not the common > denominator, what is? > > Does your problem allow for the devices to be linked by fiber in a > White Rabbit timing scenario? If so, this could be used to sync the > devices. >
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
