I have had a similar issue. My theory is that there is some delay in the
PPS input circuitry and that it is different between N320 and X310 such
that it is effectively analogous to using different length PPS cables to
the X310 devices as compared to the N320 devices. If this is true, then I
expect that the delay is at least constant. In your application, is it
possible to set the start time in the set_time_next_pps() command with a
relative delay with respect to that used for the N320?
On Wed, Nov 10, 2021 at 4:20 PM Marcus D. Leech <patchvonbr...@gmail.com>
wrote:
> On 2021-11-10 14:40, Robert Clancy via USRP-users wrote:
>
> TLDR- Setting the time ( set_time_next_pps() ) on (multiple) X310 doesn't
> result in USRP time being aligned with PPS edge. Works on N320.
>
>
> I have two X310's and an N320 as well as an Octoclock. The Octoclock does
> have GPS lock. All four devices are on different computers, each of which
> has its system time set via NTP. We are using UHD version
> UHD_4.1.0.4-0-g25d617ca.
> I'll include the find_devices and probe output at the end for reference.
> We're running Ubuntu Bionic 18.04.6 LTS on all machines.
>
>
> The Octoclock is accessed via a custom network shim that runs on the
> machine to which the Octoclock is attached. Machines with radios ( X's or
> N's ) can make a request of the custom Octoclock network service to get
> Octoclock time. Octoclock time agrees very well with the NTP top of the
> second ( typically withing 25ms ) given the inherent uncertainty running
> python code on different machines. By "agrees very well" I mean the delta
> between Octoclock time and NTP time has a low variance. All that to say, I
> do not suspect the Octoclock or software used to access the Octoclock.
>
>
> The crux of the issue is that when using external clock (10MHz) and timing
> reference (1PPS) ( provided by Octoclock ) and setting an X310 time (
> set_time_next_pps ), I am seeing about a 200ms (or 800ms depending on how
> you are measuring ) difference in when the X310 reports it is at the top of
> a second versus either time.time() or the octoclock time. I do not see this
> discrepancy with the N320 radio.
>
>
> The net effect of this is that if an X and N are set to transmit at the
> very same time, we can see that the X transmits 800ish ms early relative to
> the N using a spectrum analyzer ( real hardware ). The N transmits at the
> correct time eyeballing wall clock/computer time.
>
>
> Here is some of our test code that we've been using to investigate this:
>
> usrp = uhd.usrp_sink( ",".join((options.address, "")),
> uhd.stream_args( cpu_format="fc32", args='', channels=list(range(0,1)),
> ),'', )
> usrp.set_time_source('external', 0)
> usrp.set_clock_source('external', 0)
> usrp.set_time_unknown_pps(uhd.time_spec())
>
> reflock = str(usrp.get_mboard_sensor("ref_locked", 0)).split(": ")[1]
> if reflock != 'locked':
> print('reference not locked')
> print('exiting')
> exit()
> else:
> print('referenced locked')
>
> # the get_octo_time () call is a call to our networked octoclock.
> Just imagine this line as querying the octoclock for time
> next_pps = get_octo_time() + 1
>
> usrp.set_time_next_pps(uhd.time_spec_t(next_pps))
>
> # sleep for a few seconds
> time.sleep(2.0)
>
> oc_time=get_octo_time()
> usrp_time = usrp.get_time_now()
> usrp_time_last_pps = usrp.get_time_last_pps()
> system_time = time.time()
>
> usrp_time_source = usrp.get_time_source(0)
> usrp_time_sources = usrp.get_time_sources(0)
> print(f"TRANSMIT:: OC time is {oc_time} \n" \
> f"TRANSMIT:: usrp_time_last_pps is
> {usrp_time_last_pps.get_full_secs()} \n" \
> f"TRANSMIT:: usrp_time_last_pps_frac is
> {usrp_time_last_pps.get_frac_secs()} \n" \
> f"TRANSMIT:: usrp_time is {usrp_time.get_full_secs()} \n" \
> f"TRANSMIT:: usrp_time_frac is {usrp_time.get_frac_secs()} \n" \
> f"TRANSMIT:: system time is {system_time} \n" \
> f"TRANSMIT:: usrp_time_source is {usrp_time_source} \n" \
> f"TRANSMIT:: usrp_time_sources are {usrp_time_sources}")
>
> And here is some output from an X310:
>
> TRANSMIT:: OC time is 1636568870
> TRANSMIT:: usrp_time_last_pps is 1636568869
> TRANSMIT:: usrp_time_last_pps_frac is 0.0
> TRANSMIT:: usrp_time is 1636568869
> TRANSMIT:: usrp_time_frac is 0.82498684
> TRANSMIT:: system time is 1636568870.0275745
> TRANSMIT:: usrp_time_source is external
> TRANSMIT:: usrp_time_sources are ('internal', 'external', 'gpsdo')
>
> So the problem here is that the fractional time (usrp_time_frac) is 800ish
> ms when it should be more like 25ish ms ( like time.time() i.e. system
> time ).
>
> Here is the result of running the same code on a host with an N320:
>
> TRANSMIT:: OC time is 1636570841
> TRANSMIT:: usrp_time_last_pps is 1636570841
> TRANSMIT:: usrp_time_last_pps_frac is 0.0
> TRANSMIT:: usrp_time is 1636570841
> TRANSMIT:: usrp_time_frac is 0.025938016764322915
> TRANSMIT:: system time is 1636570841.0290515
> TRANSMIT:: usrp_time_source is external
> TRANSMIT:: usrp_time_sources are ('internal', 'external', 'gpsdo', 'sfp0')
>
> * product: n320*
> * type: n3xx*
>
>
> I have a wild guess.
>
> You:
>
> set_time_unknown_pps()
> do a wee bit of stuff
> set_time_next_pps(), and it's possibly that those two "set_time.*pps()"
> calls are too close together for the X310 hardware, and it's getting the
> wrong notion of time?
>
> If you insert a, let's say, 50ms sleep just before the
> set_time_next_pps(), how does this change things?
>
>
>
> _______________________________________________
> 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
