I can certainly try to insert a delay between the set_time_unknown_pps() and the actual set_time_next_pps() call. However, in my usage of the octoclock--- without verifying this in any documentation-- the underlying uhd call to an octoclock to get time blocks until the next top of the second when it returns. I have guessed this is a feature and not a bug effectively giving you the time at the top of a second. Also there is a call to check ref lock and a print inbetween as well. I'll add more delay between the two calls and see if that makes a difference though.
Robert ________________________________ From: Marcus D. Leech <[email protected]> Sent: Wednesday, November 10, 2021 5:13:37 PM To: Rob Kossler Cc: [email protected] Subject: [USRP-users] Re: Timing discrepencies with X310 vs N320 On 2021-11-10 17:09, Rob Kossler wrote: 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? We're talking 10s-of-ms here. That's a HUGE discrepancy, and would be hard to achieve with "slight differences in analog circuitry" unless it was deliberate (but wrong!). On Wed, Nov 10, 2021 at 4:20 PM Marcus D. Leech <[email protected]<mailto:[email protected]>> 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 -- [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]
