Hi Robert, I'm not sure if you are talking about the delay that Marcus suggested or the delay that I suggested. These 2 are different. My suggestion was to intentionally set a different start time for the X310 relative to the N320 so that it would compensate for this strange PPS delay. With this approach, when you later tell each USRP to stream at a given time, you will see all of the streaming start simultaneously. Of course, this does not solve the riddle of why the problem exists in the first place - it simply compensates for it.
As a possible explanation of the "riddle", could it be that one of the USRPs is synchronizing on the PPS leading edge while the other is using the falling edge (perhaps through an FPGA bug)? I'm not sure what the pulse width of the PPS signal is, but it may be to the tune of 100-200 ms. Rob On Thu, Nov 11, 2021 at 7:27 AM Robert Clancy via USRP-users < [email protected]> wrote: > 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]> > 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] >> To unsubscribe send an email to [email protected] >> > > _______________________________________________ > USRP-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
