Hi Rob/all,
You are on the same page as us (I work with Robert) regarding your
rising/falling edge comments. This morning, I was looking at the schematics and
FPGA code. Unless I missed something somewhere, it looks like the N320 detects
the rising edge of the pulse. If I'm looking at the correct code, The X310
seems to detect the falling edge:
--------
//---------------------------------------------------------------------------
// Pulse Per Second
//---------------------------------------------------------------------------
reg pps_del;
reg pps_edge;
always @(posedge tb_clk) begin
if (tb_rst) begin
pps_del <= 0;
pps_edge <= 0;
end else begin
pps_del <= pps;
pps_edge<= pps_del & ~pps;
end
end
-------
I may have missed something as I didn't spend a lot of time tracing through the
code, but I think this is the case. Today I used a function generator to
generate the 1 pps input to the two devices (N320 and X310) simultaneously. I
compared their time offsets and found that it is proportional to the 1pps duty
cycle. So, this supports the theory that the X310 is detecting the falling edge
of the 1pps input. It would have been nice to just invert the signal going into
the X310 for testing, but I don't have a convenient way to do that right now.
We'll have to consider whether the best solution is to rebuild the X310's FPGA
image with a "rising_edge fix" or something else. It would nice to not always
have to use our own custom image on the X310s.
I would expect USRPs to behave the same with regards to the 1pps input edge.
Maybe this is a bug that needs to be fixed?
Thanks,
Jim
________________________________
From: Rob Kossler <[email protected]>
Sent: Thursday, November 11, 2021 10:00 AM
To: Robert Clancy <[email protected]>
Cc: [email protected] <[email protected]>
Subject: [USRP-users] Re: Timing discrepencies with X310 vs N320
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]<mailto:[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]<mailto:[email protected]>>
Sent: Wednesday, November 10, 2021 5:13:37 PM
To: Rob Kossler
Cc: [email protected]<mailto:[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]<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]
