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