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 -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com

• 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?

On Dec 8, 2021, at 3:29 PM, Rob Kossler rkossler@nd.edu 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 <merlojas@egr.msu.edu mailto:merlojas@egr.msu.edu> 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 -- usrp-users@lists.ettus.com mailto:usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com mailto:usrp-users-leave@lists.ettus.com

• 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.

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 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-leave@lists.ettus.com

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 -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com