Re: [USRP-users] next pps issues with TwinRX
Neel, I updated to: UHD_3.14.1.1-0-g0347a6d8 as well as v3.7.13.5 for GR, still the same issues. It almost feels like some sort of double/float mismatch somewhere since the alignment is so close to being right. From: Neel Pandeya Sent: Monday, September 30, 2019 11:19 AM To: Jason Matusiak Cc: usrp-users Subject: Re: [USRP-users] next pps issues with TwinRX Hello Jason: We'll look into this and get back to you shortly. If you get a chance, could you please try it with the tagged UHD 3.14.1.1 ? Which version of GNU Radio are you using? --Neel Pandeya On Mon, 30 Sep 2019 at 10:10, Jason Matusiak via USRP-users mailto:usrp-users@lists.ettus.com>> wrote: We are having another issues with our TwinRXs. A co-worker has been trying to get this to work for a while, but has had no luck with the PPS timing. Here is the notes: We are running UHD_3.14.1.HEAD-12-g5f75f73f. The setup is a single X310 (revision: 11, revision_compat: 7) with two TwinRX boards. The device gets Ref/PPS from an Octoclock. The attached script has a hard-coded IP address and clock rate. It works for other X310s with UBX/SBX daughter boards as well as the E320. Good results are (note line 5 below): Synchronizing Radios to Reference Signals Checking PPS synchronization next_pps from 1569851984.633563 is 1569851985.00 Setting time for radio `gr uhd usrp source`: 2019-09-30 09:59:45 PPS alignment PASSED!: [1569851986.0, 1569851986] All radios are Synchronized Bad results are: Synchronizing Radios to Reference Signals Checking PPS synchronization next_pps from 1569851508.136703 is 1569851509.00 Setting time for radio `gr uhd usrp source`: 2019-09-30 09:51:49 PPS alignment mismatch: [1569851509.995, 1569851509] Any thoughts of why this might be happening? ___ USRP-users mailing list USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com=DwMFaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=W_MQLyUWPXWHfsF4mr51mTMqpeO4RbBBLexficV9DG8=VzsjpGSylp7F9peAKPOcnLbFzmAh8CNVnwzwket3hCo=_gOstnMMEDkfFbD1tcNsLqzHaSnMGcIjP7W9NVzbH6M=> ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] next pps issues with TwinRX
Howdy Neel, We are running GR v3.7.13.4. We will get UHD 3.14.1.1 installed on one of our machines today and give that a shot. Thanks. From: Neel Pandeya Sent: Monday, September 30, 2019 11:19 AM To: Jason Matusiak Cc: usrp-users Subject: Re: [USRP-users] next pps issues with TwinRX Hello Jason: We'll look into this and get back to you shortly. If you get a chance, could you please try it with the tagged UHD 3.14.1.1 ? Which version of GNU Radio are you using? --Neel Pandeya On Mon, 30 Sep 2019 at 10:10, Jason Matusiak via USRP-users mailto:usrp-users@lists.ettus.com>> wrote: We are having another issues with our TwinRXs. A co-worker has been trying to get this to work for a while, but has had no luck with the PPS timing. Here is the notes: We are running UHD_3.14.1.HEAD-12-g5f75f73f. The setup is a single X310 (revision: 11, revision_compat: 7) with two TwinRX boards. The device gets Ref/PPS from an Octoclock. The attached script has a hard-coded IP address and clock rate. It works for other X310s with UBX/SBX daughter boards as well as the E320. Good results are (note line 5 below): Synchronizing Radios to Reference Signals Checking PPS synchronization next_pps from 1569851984.633563 is 1569851985.00 Setting time for radio `gr uhd usrp source`: 2019-09-30 09:59:45 PPS alignment PASSED!: [1569851986.0, 1569851986] All radios are Synchronized Bad results are: Synchronizing Radios to Reference Signals Checking PPS synchronization next_pps from 1569851508.136703 is 1569851509.00 Setting time for radio `gr uhd usrp source`: 2019-09-30 09:51:49 PPS alignment mismatch: [1569851509.995, 1569851509] Any thoughts of why this might be happening? ___ USRP-users mailing list USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com=DwMFaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=W_MQLyUWPXWHfsF4mr51mTMqpeO4RbBBLexficV9DG8=VzsjpGSylp7F9peAKPOcnLbFzmAh8CNVnwzwket3hCo=_gOstnMMEDkfFbD1tcNsLqzHaSnMGcIjP7W9NVzbH6M=> ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] next pps issues with TwinRX
Hello Jason: We'll look into this and get back to you shortly. If you get a chance, could you please try it with the tagged UHD 3.14.1.1 ? Which version of GNU Radio are you using? --Neel Pandeya On Mon, 30 Sep 2019 at 10:10, Jason Matusiak via USRP-users < usrp-users@lists.ettus.com> wrote: > We are having another issues with our TwinRXs. A co-worker has been > trying to get this to work for a while, but has had no luck with the PPS > timing. Here is the notes: > > We are running UHD_3.14.1.HEAD-12-g5f75f73f. > > The setup is a single X310 (revision: 11, revision_compat: 7) with two > TwinRX boards. The device gets Ref/PPS from an Octoclock. > > The attached script has a hard-coded IP address and clock rate. It works > for other X310s with UBX/SBX daughter boards as well as the E320. > > Good results are (note line 5 below): > > Synchronizing Radios to Reference Signals > Checking PPS synchronization > next_pps from 1569851984.633563 is 1569851985.00 > Setting time for radio `gr uhd usrp source`: 2019-09-30 09:59:45 > > *PPS alignment PASSED!: [1569851986.0, 1569851986] * > All radios are Synchronized > > Bad results are: > Synchronizing Radios to Reference Signals > Checking PPS synchronization > next_pps from 1569851508.136703 is 1569851509.00 > Setting time for radio `gr uhd usrp source`: 2019-09-30 09:51:49 > *PPS alignment mismatch: [1569851509.995, 1569851509]* > > Any thoughts of why this might be happening? > > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] next pps issues with TwinRX
We are having another issues with our TwinRXs. A co-worker has been trying to
get this to work for a while, but has had no luck with the PPS timing. Here is
the notes:
We are running UHD_3.14.1.HEAD-12-g5f75f73f.
The setup is a single X310 (revision: 11, revision_compat: 7) with two TwinRX
boards. The device gets Ref/PPS from an Octoclock.
The attached script has a hard-coded IP address and clock rate. It works for
other X310s with UBX/SBX daughter boards as well as the E320.
Good results are (note line 5 below):
Synchronizing Radios to Reference Signals
Checking PPS synchronization
next_pps from 1569851984.633563 is 1569851985.00
Setting time for radio `gr uhd usrp source`: 2019-09-30 09:59:45
PPS alignment PASSED!: [1569851986.0, 1569851986]
All radios are Synchronized
Bad results are:
Synchronizing Radios to Reference Signals
Checking PPS synchronization
next_pps from 1569851508.136703 is 1569851509.00
Setting time for radio `gr uhd usrp source`: 2019-09-30 09:51:49
PPS alignment mismatch: [1569851509.995, 1569851509]
Any thoughts of why this might be happening?
#!/usr/bin/env python2
from gnuradio import uhd
import time
import sys
import math
from datetime import datetime
MAX_ATTEMPTS = 5
ADDR = '192.168.10.2'
CLKRATE = 200e6
# make sure we start the time reset iterations on the PPS Edge
def get_pps_edge(usrp):
last_pps_time = usrp.get_time_last_pps()
while last_pps_time == usrp.get_time_last_pps():
pass
START #
try:
usrp = uhd.usrp_source('addr=' + ADDR,
uhd.stream_args(cpu_format='sc16',
channels=range(1)))
except Exception as e:
print str(e)
sys.exit()
# get external clock
try:
usrp.set_clock_source('external', 0)
except RuntimeError:
print "Radio " + ADDR + " is not seeing 10 MHz clock"
sys.exit()
# configure the usrp
usrp.set_clock_rate(CLKRATE, uhd.ALL_MBOARDS)
# check lock to 10 MHz reference signal
print "Synchronizing Radios to Reference Signals"
attempts = 0
ref_locked = ["not_queried_yet"]
while ref_locked != [" locked"]:
ref_locked[0] = str(usrp.get_mboard_sensor("ref_locked", 0)).split(':')[-1]
attempts += 1
if attempts >= MAX_ATTEMPTS:
print 'Unable to achieve ref lock. Exiting...'
sys.exit()
# check PPS synchronization
print "Checking PPS synchronization"
passed_test = False
attempts = 0
while not passed_test:
# re-align all radios
get_pps_edge(usrp)
# get far away from the "top of a second" so all clock sources will be on the same full second
time.sleep(.4)
time_real = time.time() # system time should be synced with GPS time
#Round up to the next whole second
next_pps = math.ceil(time_real)
print 'next_pps from %f is %f' % (time_real, next_pps)
# set_time_next_pps is non-blocking, so set all radios immediately after finding an edge
print 'Setting time for radio `{}`: {}'.format(
usrp.name(), datetime.fromtimestamp(next_pps))
usrp.set_time_next_pps(uhd.time_spec_t(next_pps))
# sleep through one pps edge so time is set correctly on all USRPs
time.sleep(1)
# check if the pps is correct for all radios
get_pps_edge(usrp)
# get pps for each radio
last_pps = []
last_pps.append(usrp.get_time_last_pps().get_real_secs())
last_pps.append(int(time.time()))
# compare pps for each radio
if last_pps and last_pps.count(last_pps[0]) != len(last_pps):
print "PPS alignment mismatch: {}".format(last_pps)
passed_test = False
else:
print "PPS alignment PASSED!: {}".format(last_pps)
passed_test = True
attempts += 1
if attempts >= MAX_ATTEMPTS:
print 'Failed to synchronize radios after %d attempts' % MAX_ATTEMPTS
print 'Exiting...'
sys.exit()
print "All radios are Synchronized"
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
