Hi Jason, I still don't think I understand the problem. Unless you are using the RF transmission from one USRP as a time-alignment reference for the other USRP (which I think would work), I don't see how the algorithm can work.
I don't immediately see how it could be helpful, but I will mention that you could instead use set_time_next_pps() (or maybe its called set_time_unknown_pps?) and get_time_last_pps(). With these two functions (operating using the internal PPS generator), you could add a fixed delta to the current clock value that would not be dependent on any network latencies. Rob On Wed, Dec 8, 2021 at 10:24 PM Marcus D. Leech <patchvonbr...@gmail.com> wrote: > > On 2021-12-08 18:57, EGR Email wrote: > > 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 > > There's no "Clock, adjust thyself" primitive in the FPGA already. So it > would have to be added. > > Normally, the TOD (time of day) clock is set either "right now" to the value > provided, or a holding register is loaded with the provided value, and then > when triggered by a 1PPS > even, the TOD clock is loaded from the "holding" register. > _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com _______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
