Re: [USRP-users] Octoclock-G gps_servo sentence

[John Shields via USRP-users]

Thanks very much, as always, Marcus – this is what I was looking for.

 Slainte,

John

From: Marcus D. Leech via USRP-users
Sent: Saturday, May 19, 2018 11:39 AM
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Octoclock-G gps_servo sentence

On 05/18/2018 06:46 PM, John Shields via USRP-users wrote:

  Hi,
  Where is the reference to the contents of the ‘gps_servo’ status message 
as supported by CDA-2990? I would expect to be able to detect warm-up and 
perhaps hold-over.

  Kind Regards,

John



Since the SERVO messages are proprietary, rather than defined by NMEA, best 
place to look for the contents of these messages is probably the
  user manual of the GPS module used:

http://www.jackson-labs.com/assets/uploads/main/LC_XO_Manual.pdf










___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Octoclock-G gps_servo sentence

[John Shields via USRP-users]

Hi,
Where is the reference to the contents of the ‘gps_servo’ status message as 
supported by CDA-2990? I would expect to be able to detect warm-up and perhaps 
hold-over.

Kind Regards,

  John

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Enable aliasing using USRP

[John Shields via USRP-users]

Hi Wahhab,
  As Kyeong had already pointed out, in this configuration, the 
bw limiting factor is the daughtercard. For the SBX the bandwidth is 40 MHz. 
There are other Ettus products covering the same frequency range which have 
wider bandwidth (80,120,160 MHz) but they seem to only plug into the X-series 
of products.
https://www.ettus.com/product/category/Daughterboards

Kind Regards,

 John

From: Wahhab Albazrqaoe
Sent: Saturday, December 30, 2017 4:39 AM
To: Kyeong Su Shin
Cc: John Shields ; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Enable aliasing using USRP

Dear Kyeong,
Thank you for the reply.
How about using USRP B210, do you think we can get aliasing by setting the RF 
bw=50MHz and sample at 2MHz?

Thank you.
Wahhab

On Dec 29, 2017 12:19 AM, "Kyeong Su Shin"  wrote:

  Hello Wahhab,


  If I recall correctly, you can *not* change the bandwidth of SBX (always 
40MHz), and the sampling rate of the USRP2 (always 100MS/s). What you are 
actually setting by setting --rate 2e6 is the decimation ratio. The signals 
will be always sampled at 100MS/s, and then decimated by the decimator within 
the FPGA.

  It is still possible to cause aliasing - one way is to just sample at a fast 
sampling rate and then decimate by yourself. An other way would be tinkering 
the digital filters used by the decimator, but I am not sure if there are good 
APIs to do that. I am pretty sure that rx_samples_to_file is not suitable for 
the task, though (correct me if I am wrong). That is just an example program.


  Regards,

  Kyeong Su Shin


  On Thu, Dec 28, 2017 at 6:29 PM, Wahhab Albazrqaoe via USRP-users 
 wrote:

Hi John,
Thank you for your reply.
We would like to create aliasing. This means that we should set ADC to 
sample at speed less than Nyquist rate.
In our setting, we target RF front end to be 50MHz and ADC speed is 2MHz.
The question is how to do it? We use some commands (as shown in my previous 
email) but seems not working as expected, i.e. RF front end bandwidth is still 
2MHz.

Best,


On Thu, Dec 28, 2017 at 9:24 PM, John Shields  
wrote:

  Hi Wahhab,
 This is a fairly basic issue – the ‘bandwidth’ (if 
that is really what you are really meaning) is related to the sample_rate by 
The Nyquist  Frequency


https://en.wikipedia.org/wiki/Nyquist_frequency

   Kind Regards,

John

  From: Wahhab Albazrqaoe via USRP-users
  Sent: Friday, December 29, 2017 3:04 PM
  To: usrp-users@lists.ettus.com
  Subject: [USRP-users] Enable aliasing using USRP

  Dear All,
  I have question about how to create aliasing using USRP.
  Basically, I have USRP2 with SBX (with recent installations of GnuRadio 
and UHD).
  I would like to set the bandwidth of the RF front end to 50 MHz, and use 
2MHz of sampling rate (ADC speed).
  I am using the following command:
  sudo ./rx_samples_to_file --args addr=192.168.10.2 master_clock_rate=50e6 
--freq=2460e6 --bw=50e6 --rate 2e6 --gain=50 --wirefmt sc8 --nsamps 0




  Problem: it seems to me that the system (GnuRadio/USRP) observes only 
2MHz of RF front end bandwdith. How do I know this? Ans: I compare such 
settings with the following settings:
  sudo ./rx_samples_to_file --args addr=192.168.10.2 master_clock_rate=50e6 
--freq=2460e6 --bw=50e6 --rate 50e6 --gain=50 --wirefmt sc8 --nsamps 0


  The later setting seems to be actual 50 MHz of Rf front end.

  Any comments and advices on how to create aliasing using USRP are 
appreciate.


  Best,
  Wahhab




--
  ___
  USRP-users mailing list
  USRP-users@lists.ettus.com
  http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


   Virus-free. www.avast.com



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Enable aliasing using USRP

[John Shields via USRP-users]

Hi Wahhab,
   This is a fairly basic issue – the ‘bandwidth’ (if that is 
really what you are really meaning) of signals which can be sampled and 
correctly reconstituted  is related to the sample_rate by Nyquist

 https://en.wikipedia.org/wiki/Nyquist_rate

 Kind Regards,

  John

From: Wahhab Albazrqaoe via USRP-users
Sent: Friday, December 29, 2017 3:04 PM
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Enable aliasing using USRP

Dear All,
I have question about how to create aliasing using USRP.
Basically, I have USRP2 with SBX (with recent installations of GnuRadio and 
UHD).
I would like to set the bandwidth of the RF front end to 50 MHz, and use 2MHz 
of sampling rate (ADC speed).
I am using the following command:
sudo ./rx_samples_to_file --args addr=192.168.10.2 master_clock_rate=50e6 
--freq=2460e6 --bw=50e6 --rate 2e6 --gain=50 --wirefmt sc8 --nsamps 0




Problem: it seems to me that the system (GnuRadio/USRP) observes only 2MHz of 
RF front end bandwdith. How do I know this? Ans: I compare such settings with 
the following settings:
sudo ./rx_samples_to_file --args addr=192.168.10.2 master_clock_rate=50e6 
--freq=2460e6 --bw=50e6 --rate 50e6 --gain=50 --wirefmt sc8 --nsamps 0


The later setting seems to be actual 50 MHz of Rf front end.

Any comments and advices on how to create aliasing using USRP are appreciate.


Best,
Wahhab






___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] 2 N200 MIMO system phase offset varies with frequency, have used timed_command with tune and also integer-N Tuning per Marcus M post of Feb 17, 2016

[John Shields via USRP-users]

few simple Python commands!.

Realising that you would/should not express some 
shortcoming in the SBX,N200,MIMO in an Ettus product , if there is, I would 
dearly like to know from someone from Ettus Purely from an outside point of 
view, I thought that the “ we’ll transfer the Time Of Day contents to the Mate 
over MIMO cable ” doesn’t actually mean that they are in ‘real time’ synch, 
from my old DMS-100 days bit was willing to go along with the theory. 
Seriously, I have no issue with that but just want to know how to get 2 N200r4 
streams with OB GPSDO & MIMO cable ‘synchronised’

   I would love (but be embarrassed) to be told, that 
as a dummy, I made this mistake but in over a month of work I have not been 
able to establish that.

  Kind Regards,

   John

  Set up a test transmitter in the far-field of your two antenna.

  With everything synchronized the way you think it should be, plot the 
low-pass-filtered (and decimate to taste) result of a conjugate multiply of
the two sides.   This should produce a straight line, with small amounts of 
noise.   If it just produces random walks all over the place, the two
oscillators aren't locked to the same reference.

  My point about component tolerances is that they'll have some group-delay 
that isn't perfectly matched on both sides, even if things like the
LO are running in-phase, the analog pathways won't necessarily have 
precisely the same group delay on the two sides.  Just like two random
pieces of coax that are cut to the same length won't, necessarily, have 
precisely the same phase length.   This effect gets worse with frequency.

  Further, in radio astronomy applications, the coherence bandwidth is, 
technically speaking, infinitely small, due to the emission mechanisms.
But in *practice* a significant fractional bandwidth is possible without 
having to channelize the input bandwidth.

  The *other* issue, that seems to be causing consternation, is the ability to 
predict what the phase-offset between the two sides will be upon restart
of the flow-graph in the presence of the various bits of hocus-pocus (timed 
commands, etc) to try for consistent phase offsets every time you
start streaming.  It sounds like you have that, but the offset changes 
depending on tuned frequency.   I'd expect that.  Both due to analog-component
group-delay variability, and because the MIMO cable is not of zero length.  
I don't believe that there is *ANY* length compensation, so one N2XX will
receive the reference clock at a "closer" phase distance than the other 
one, because the MIMO cable is of finite length.  That phase-length difference 
will
have more effect at higher frequencies, because a PLL is a reference 
multiplier (which is why having exquisitely-low phase-noise on the reference is
important, because that noise will get worse as the multiplier ratio of the 
PLL increases).





From: mle...@ripnet.com
Sent: Wednesday, October 25, 2017 7:45 AM
To: John Shields
Cc: usrp-users
Subject: Re: [USRP-users] 2 N200 MIMO system phase offset varies with 
frequency, have used timed_command with tune and also integer-N Tuning per 
Marcus M post of Feb 17, 2016

I would expect component tolerance issues on the two sides to scale with 
frequency.  That may be what you're seeing?








On 2017-10-24 14:28, John Shields via USRP-users wrote:

  Hi,
  Still struggling with the configuration – 2x N200 r4, master O/B 
GPSDO, slave MIMO cable. Have put in python code to use timed commands and that 
produced a constant phase offset even over rerun of FG or power cycling on N200 
which was great news.

  However, the relative offset changes with frequency. The splitter is 
a Mini-circuits ZRFSC-123S+ which is spec-ed to has a typical of phase 
unbalance of 1/2 a degree over the frequency ranges used. The results are 
independent of source NWT 4000-1 or an SBX using uhd_siggen. When I have 
checked the ref_locked flags etc. they are good. the gpsdo is 'locked' as is 
MIMO.

  In addition to using the timed_commands to synch the SBX LOs, I also 
implement the integer-N-tuning and no improvement.

  The results are roughlyFreq (MHz)Phase offset (deg)
  450-7
  1450-30
  1950-65
  2450-100

  When I switch the cables between the 2 N200, the phase offset doesn't 
change sign so I presume it is not cabling? What on earth, else, could it be?

Kind Regards,

 John

   Virus-fr

Re: [USRP-users] 2 N200 MIMO system phase offset varies with frequency, have used timed_command with tune and also integer-N Tuning per Marcus M post of Feb 17, 2016

[John Shields via USRP-users]

than the other one, 
because the MIMO cable is of finite length.  That phase-length difference will
  have more effect at higher frequencies, because a PLL is a reference 
multiplier (which is why having exquisitely-low phase-noise on the reference is
  important, because that noise will get worse as the multiplier ratio of the 
PLL increases).





  From: mle...@ripnet.com
  Sent: Wednesday, October 25, 2017 7:45 AM
  To: John Shields
  Cc: usrp-users
  Subject: Re: [USRP-users] 2 N200 MIMO system phase offset varies with 
frequency, have used timed_command with tune and also integer-N Tuning per 
Marcus M post of Feb 17, 2016

  I would expect component tolerance issues on the two sides to scale with 
frequency.  That may be what you're seeing?








  On 2017-10-24 14:28, John Shields via USRP-users wrote:

Hi,
Still struggling with the configuration – 2x N200 r4, master O/B GPSDO, 
slave MIMO cable. Have put in python code to use timed commands and that 
produced a constant phase offset even over rerun of FG or power cycling on N200 
which was great news.

However, the relative offset changes with frequency. The splitter is a 
Mini-circuits ZRFSC-123S+ which is spec-ed to has a typical of phase unbalance 
of 1/2 a degree over the frequency ranges used. The results are independent of 
source NWT 4000-1 or an SBX using uhd_siggen. When I have checked the 
ref_locked flags etc. they are good. the gpsdo is 'locked' as is MIMO.

In addition to using the timed_commands to synch the SBX LOs, I also 
implement the integer-N-tuning and no improvement.

The results are roughlyFreq (MHz)Phase offset (deg)
450-7
1450-30
1950-65
2450-100

When I switch the cables between the 2 N200, the phase offset doesn't 
change sign so I presume it is not cabling? What on earth, else, could it be?

  Kind Regards,

   John

 Virus-free. www.avast.com



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] 2 N200 MIMO system phase offset varies with frequency, have used timed_command with tune and also integer-N Tuning per Marcus M post of Feb 17, 2016

[John Shields via USRP-users]

Hi,
Still struggling with the configuration – 2x N200 r4, master O/B GPSDO, 
slave MIMO cable. Have put in python code to use timed commands and that 
produced a constant phase offset even over rerun of FG or power cycling on N200 
which was great news.

However, the relative offset changes with frequency. The splitter is a 
Mini-circuits ZRFSC-123S+ which is spec-ed to has a typical of phase unbalance 
of 1/2 a degree over the frequency ranges used. The results are independent of 
source NWT 4000-1 or an SBX using uhd_siggen. When I have checked the 
ref_locked flags etc. they are good. the gpsdo is ‘locked’ as is MIMO.

In addition to using the timed_commands to synch the SBX LOs, I also 
implement the integer-N-tuning and no improvement.

The results are roughlyFreq (MHz)Phase offset (deg)
450-7
1450-30
1950-65
2450-100

When I switch the cables between the 2 N200, the phase offset doesn’t 
change sign so I presume it is not cabling? What on earth, else, could it be?

  Kind Regards,

   John

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
#!/usr/bin/env python2
# -*- coding: utf-8 -*-
##
# GNU Radio Python Flow Graph
# Title: Top Block
# Generated: Mon Oct 16 05:41:38 2017
##

if __name__ == '__main__':
import ctypes
import sys
if sys.platform.startswith('linux'):
try:
x11 = ctypes.cdll.LoadLibrary('libX11.so')
x11.XInitThreads()
except:
print "Warning: failed to XInitThreads()"

from PyQt4 import Qt
from gnuradio import blocks
from gnuradio import eng_notation
from gnuradio import filter
from gnuradio import gr
from gnuradio import qtgui
from gnuradio import uhd
from gnuradio.eng_option import eng_option
from gnuradio.filter import firdes
from gnuradio.qtgui import Range, RangeWidget
from optparse import OptionParser
import cmath
import math
import sip
import sys
import time
import tune_helper  # embedded python module
from gnuradio import qtgui


class top_block(gr.top_block, Qt.QWidget):

def __init__(self, flt_dec=1000):
gr.top_block.__init__(self, "Top Block")
Qt.QWidget.__init__(self)
self.setWindowTitle("Top Block")
qtgui.util.check_set_qss()
try:
self.setWindowIcon(Qt.QIcon.fromTheme('gnuradio-grc'))
except:
pass
self.top_scroll_layout = Qt.QVBoxLayout()
self.setLayout(self.top_scroll_layout)
self.top_scroll = Qt.QScrollArea()
self.top_scroll.setFrameStyle(Qt.QFrame.NoFrame)
self.top_scroll_layout.addWidget(self.top_scroll)
self.top_scroll.setWidgetResizable(True)
self.top_widget = Qt.QWidget()
self.top_scroll.setWidget(self.top_widget)
self.top_layout = Qt.QVBoxLayout(self.top_widget)
self.top_grid_layout = Qt.QGridLayout()
self.top_layout.addLayout(self.top_grid_layout)

self.settings = Qt.QSettings("GNU Radio", "top_block")
self.restoreGeometry(self.settings.value("geometry").toByteArray())

##
# Parameters
##
self.flt_dec = flt_dec

##
# Variables
##
self.shift_in_radians = shift_in_radians = 0
self.samp_rate = samp_rate = 1e6
self.gain = gain = 10
self.freq = freq = 450e6

##
# Blocks
##
self._shift_in_radians_range = Range(0, 7, 0.001, 0, 200)
self._shift_in_radians_win = RangeWidget(self._shift_in_radians_range, 
self.set_shift_in_radians, 'Shift', "counter_slider", float)
self.top_layout.addWidget(self._shift_in_radians_win)
self._gain_range = Range(0, 30, 1, 10, 200)
self._gain_win = RangeWidget(self._gain_range, self.set_gain, 'Gain', 
"counter_slider", float)
self.top_layout.addWidget(self._gain_win)
self._freq_range = Range(400e6, 4e9, 100e3, 450e6, 200)
self._freq_win = RangeWidget(self._freq_range, self.set_freq, 'Freq', 
"counter_slider", float)
self.top_layout.addWidget(self._freq_win)
self.uhd_usrp_source_0_0 = uhd.usrp_source(
",".join(("", "addr0=192.168.20.2,addr1=192.168.10.2")),
uhd.stream_args(
cpu_format="fc32",
channels=range(2),
  

Re: [USRP-users] Align CORDICS in the DSP ( N200x2, MIMO, SBX, GPSDO)

[John Shields via USRP-users]

Thanks Marcus,
 Good to know that I don’t need to do anything else. I 
presume your statement is true even if the slave N200 doesn’t have a ‘real’ PPS 
signal but only Time_Of_Day copied over. I say this because the slave has ‘no 
sync’ as it’s option since it fails waiting for a real PPS signal if I set 
unknown_pps as the option.

 I have sent off my GRC and modified Python file (for 
SBX LO alignment as we discussed before) a couple of days ago to support@ettus 
so will see what they come up with.

 Kind Regards,

John

From: Marcus D. Leech via USRP-users
Sent: Saturday, October 14, 2017 10:22 AM
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Align CORDICS in the DSP ( N200x2, MIMO, SBX, GPSDO)

On 10/13/2017 04:57 PM, John Shields via USRP-users wrote:

  Hi,
  From the Hardware Driver and USRP Manual, under the section on Align 
CORDICs in the DSP, it says :

  In order to achieve phase alignment between USRP devices, the CORDICS in both 
devices must be aligned with respect to each other. This is easily achieved by 
issuing stream commands with a time spec property, which instructs the 
streaming to begin at a specified time. Since the devices are already 
synchronized via the 10 MHz and PPS inputs, the streaming will start at exactly 
the same time on both devices. The CORDICs are reset at each start-of-burst 
command, so users should ensure that every start-of-burst also has a time spec 
set.

  For receive, a burst is started when the user issues a stream command. This 
stream command should have a time spec set:

  uhd::stream_cmd_t 
stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);
  stream_cmd.num_samps = samps_to_recv;
  stream_cmd.stream_now = false;
  stream_cmd.time_spec = time_to_recv;
  usrp->issue_stream_cmd(stream_cmd);


  The next section mentions how to LO align SBXs and I have done this in python 
(and it has been checked by an expert) but I still get a variable phase offset 
between both channels on the USRPs and suspect the CORDICs are spinning 
relatively.

  So I have a couple of questions re: CORDIC alignment:

  1) if my desire is to stream for a long time (e.g. days) what stream 
command do I give in Python?

  2) I have seen one posting where the person showed that alignment of the 
CORDICs should happen after a timed_cmd tune – is this correct, or should it be 
before, or does it not matter?

  3) has anyone been able to get N200r4x2, GPSDO, MIMO cable, 2xSBX to align 
with zero phase offset or, at least, a constant phase offset which doesn’t vary 
between each run of the GRC file?

   Kind Regards,

 John


The UHD source block in GRC does all of this, except for the timed-command 
wrapper for tuning.

It starts streaming at a fixed time, and uses timestamps to time-align samples.

So the only thing left would be PLL synthesizer ambiguity.






___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Frequency offset between two USRPs B210 synchronized with use of Octoclock-G

[john Shields via USRP-users]

On 06/10/17 19:47, Piotr Krysik via USRP-users wrote:

W dniu 06.10.2017 o 21:33, Piotr Krysik via USRP-users pisze:

Hello everyone,

I synchronized two USRPs B210 with use of Octoclock-G and the attached
gnuradio-companion flowgraph.

I've connected signal generator generating sinusoid to both devices (it
was on frequency 694.5MHz while USRPs were tuned to 694.3MHz, signal
power was about -40dBm). What I would expect is to see constant phase
offset between signals received by both USRPs (perhaps changing slightly
with temperature etc.). However what I see is constant changes of phase
that corresponds to frequency offset between two devices. Moreover this
frequency offset changes significantly from one execution of a flowgraph
to another (look at the image):

relative phase of two B210's


Missing image of phase offsets in the attachment.

Best Regards,
Piotr Krysik




___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


Hi Piotr,

    While I have a slightly different h/w configuration 
(2xN200, one GPSDO connected through MIMO cable (i.e. I use slightly 
different time/clock sources; and 2 SBXs) and while I have modified the 
Python code to use  timed_commands per the ettus sync page , I have not 
been able to get a consistent relative phase offset between the devices 
on successive GRC runs. I have been struggling for quite a while - 
hopefully, you will get a resolution quickly and I believe it might also 
fix my problem!



 Kind Regards,


 John

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Verifying MIMO cable integrity

[John Shields via USRP-users]

Hi,
I have been struggling with trying to get two coherent channels from a pair 
of N200 , one with GPSDO and the other with a MIMO cable. I realise that, 
according to the sync_page doc, I need to do some software magic in order to 
attempt to phase-sync but the slave unit reports that it cannot detect the PPS 
in time. While trying various options (e.g. moving the GPSDO from one N200r4 to 
the other) the conclusion appeared to be that each N200 was OK and that either 
the MIMO cable was faulty (unlikely) or there is a software problem with UHD.

  What I am now attempting to do is to take the GPSDO module out of the 
equation and test purely the MIMO cable/software. I have separated out the UHD 
sources in GRC so I have some control – not all control unfortunately because 
if there is a GPSDO, it appears that it is detected and used no matter the 
settings but that can be easily remedied.

  So, after removing UART connection on GPSDO, I have 2 free-running N200s – I 
want to make one the ‘master’ so I have set Red:  Sync = Don’t Sync, Clock 
Source = Internal, Time source=Default.

  On the other unit, Blue, I have set : Sync= Don’t Sync, Clock Source and Time 
Source= MIMO Cable. If I set the sync parameter to “unknown PPS” we are back to 
the situation where there is no PPS detected.

Are these the correct settings to test the integrity of the MIMO cable and/or 
UHD sync software?

  Kind Regards,

   John



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] N200 MIMO PPS not being detected on mate...

[John Shields via USRP-users]

Sorry Marcus, I should have been more explicit, I did wait many minutes for the 
GPS lock to be confirmed by query_gpsdo_sensors before proceeding with running 
test_pps_input on either the master or mate.

   Kind Regards,

John

From: Marcus D. Leech
Sent: Thursday, September 21, 2017 8:46 AM
To: John Shields
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] N200 MIMO PPS not being detected on mate...

On 09/20/2017 04:39 PM, John Shields wrote:

  So, as a result of moving the Firefly to ...20.2 (red) :

  Obs 1) when using query_gpsdo_sensors I occasionally received USRP NOT locked 
to 10 MHz Reference but after a retry it finds it OK. I switched PPS/Ref cables 
from the Firefly to USRP motherboard and the issue remained, occasionally, as a 
10 MHz issue.  I have not seen this when the Firefly was in 10.2 (blue) but I 
have not needed to run the query_gpsdo_sensors very often on this unit.

  Obs 2) After, query_gpsdo,sensors confirms lock on red, when I do a 
test_pps_input (—source mimo) on blue, I still get no PPS.

  As best I can tell, Obs 2) would indicate that the issue is not with either 
N200? The only issue might be the MIMO cable? but it is a robust beast so I 
would doubt that.

  Being a BNR/Nortel pensioner, just buying a new N200 ($kiwi 2500.00) in the 
hope that it would change the situation to a pleasant outcome would appear 
imprudent. My gut feel is that using the MIMO cable with N200 is not that 
common a config and there might be something gnarly going on?

  Kind Regards,

 John

The MIMO cable is just a SASI cable as I recall.But, agreed, seems like the 
cable is unlikely to have failed.

I'd wait for the unit with the GPSDO in it to achieve solid GPS lock -- it may 
be that it's not providing reliable PPS until it is locked.




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] N200 MIMO PPS not being detected on mate...

[John Shields via USRP-users]

So, as a result of moving the Firefly to ...20.2 (red) :

Obs 1) when using query_gpsdo_sensors I occasionally received USRP NOT locked 
to 10 MHz Reference but after a retry it finds it OK. I switched PPS/Ref cables 
from the Firefly to USRP motherboard and the issue remained, occasionally, as a 
10 MHz issue.  I have not seen this when the Firefly was in 10.2 (blue) but I 
have not needed to run the query_gpsdo_sensors very often on this unit.

Obs 2) After, query_gpsdo,sensors confirms lock on red, when I do a 
test_pps_input (—source mimo) on blue, I still get no PPS.

As best I can tell, Obs 2) would indicate that the issue is not with either 
N200? The only issue might be the MIMO cable? but it is a robust beast so I 
would doubt that.

Being a BNR/Nortel pensioner, just buying a new N200 ($kiwi 2500.00) in the 
hope that it would change the situation to a pleasant outcome would appear 
imprudent. My gut feel is that using the MIMO cable with N200 is not that 
common a config and there might be something gnarly going on?

Kind Regards,

   John



From: John Shields via USRP-users
Sent: Thursday, September 21, 2017 7:52 AM
To: Marcus D. Leech
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] N200 MIMO PPS not being detected on mate...

Yes, exactly what I was thinking – have the tops off both units just now

 Slainte,

John

From: Marcus D. Leech
Sent: Thursday, September 21, 2017 7:21 AM
To: John Shields
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] N200 MIMO PPS not being detected on mate...

On 09/20/2017 03:11 PM, John Shields wrote:

  Yes, Marcus, the other USRP (the one with the GPSDO) passes the 
test_pps_input with source type gpsdo or mimo or external!

  Kind Regards,

 John
You could swap the GPSDO over and see if the "bad" USRP still fails to see 1PPS.




  From: Marcus D. Leech
  Sent: Thursday, September 21, 2017 7:01 AM
  To: John Shields
  Cc: usrp-users@lists.ettus.com
  Subject: Re: [USRP-users] N200 MIMO PPS not being detected on mate...

  On 09/20/2017 02:58 PM, John Shields wrote:

Thanks Marcus,
 Here is the output of test_pps_input for the mate 
N200 connected through MIMO cable:

john@i7ubuntu:~$ test_pps_input --args addr=192.168.20.2 --source=mimo
linux; GNU C++ version 6.3.0 20170406; Boost_106200;
UHD_003.010.002.000-3-g122bfae1


Creating the usrp device with: addr=192.168.20.2...
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
Using Device: Single USRP:
   Device: USRP2 / N-Series Device
   Mboard 0: N200r4
   RX Channel: 0
 RX DSP: 0
 RX Dboard: A
 RX Subdev: SBXv3 RX
   TX Channel: 0
 TX DSP: 0
 TX Dboard: A
 TX Subdev: SBXv3 TX


Attempt to detect the PPS and set the time...

-- 1) catch time transition at pps edge
Error: RuntimeError: Board 0 may not be getting a PPS signal!
No PPS detected within the time interval.
See the application notes for your device.


  Hmmm, this is puzzling for sure.

  I've never used the MIMO cable, so I don't have much experience.

  If the other USRP is running properly, it should be producing 1PPS.




   Virus-free. www.avast.com






___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] N200 MIMO PPS not being detected on mate...

[John Shields via USRP-users]

Yes, exactly what I was thinking – have the tops off both units just now

 Slainte,

John

From: Marcus D. Leech
Sent: Thursday, September 21, 2017 7:21 AM
To: John Shields
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] N200 MIMO PPS not being detected on mate...

On 09/20/2017 03:11 PM, John Shields wrote:

  Yes, Marcus, the other USRP (the one with the GPSDO) passes the 
test_pps_input with source type gpsdo or mimo or external!

  Kind Regards,

 John
You could swap the GPSDO over and see if the "bad" USRP still fails to see 1PPS.




  From: Marcus D. Leech
  Sent: Thursday, September 21, 2017 7:01 AM
  To: John Shields
  Cc: usrp-users@lists.ettus.com
  Subject: Re: [USRP-users] N200 MIMO PPS not being detected on mate...

  On 09/20/2017 02:58 PM, John Shields wrote:

Thanks Marcus,
 Here is the output of test_pps_input for the mate 
N200 connected through MIMO cable:

john@i7ubuntu:~$ test_pps_input --args addr=192.168.20.2 --source=mimo
linux; GNU C++ version 6.3.0 20170406; Boost_106200;
UHD_003.010.002.000-3-g122bfae1


Creating the usrp device with: addr=192.168.20.2...
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
Using Device: Single USRP:
   Device: USRP2 / N-Series Device
   Mboard 0: N200r4
   RX Channel: 0
 RX DSP: 0
 RX Dboard: A
 RX Subdev: SBXv3 RX
   TX Channel: 0
 TX DSP: 0
 TX Dboard: A
 TX Subdev: SBXv3 TX


Attempt to detect the PPS and set the time...

-- 1) catch time transition at pps edge
Error: RuntimeError: Board 0 may not be getting a PPS signal!
No PPS detected within the time interval.
See the application notes for your device.


  Hmmm, this is puzzling for sure.

  I've never used the MIMO cable, so I don't have much experience.

  If the other USRP is running properly, it should be producing 1PPS.




   Virus-free. www.avast.com




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] N200 MIMO PPS not being detected on mate...

[John Shields via USRP-users]

Yes, Marcus, the other USRP (the one with the GPSDO) passes the test_pps_input 
with source type gpsdo or mimo or external!

Kind Regards,

   John

From: Marcus D. Leech
Sent: Thursday, September 21, 2017 7:01 AM
To: John Shields
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] N200 MIMO PPS not being detected on mate...

On 09/20/2017 02:58 PM, John Shields wrote:

  Thanks Marcus,
   Here is the output of test_pps_input for the mate 
N200 connected through MIMO cable:

  john@i7ubuntu:~$ test_pps_input --args addr=192.168.20.2 --source=mimo
  linux; GNU C++ version 6.3.0 20170406; Boost_106200;
  UHD_003.010.002.000-3-g122bfae1


  Creating the usrp device with: addr=192.168.20.2...
  -- Opening a USRP2/N-Series device...
  -- Current recv frame size: 1472 bytes
  -- Current send frame size: 1472 bytes
  Using Device: Single USRP:
 Device: USRP2 / N-Series Device
 Mboard 0: N200r4
 RX Channel: 0
   RX DSP: 0
   RX Dboard: A
   RX Subdev: SBXv3 RX
 TX Channel: 0
   TX DSP: 0
   TX Dboard: A
   TX Subdev: SBXv3 TX


  Attempt to detect the PPS and set the time...

  -- 1) catch time transition at pps edge
  Error: RuntimeError: Board 0 may not be getting a PPS signal!
  No PPS detected within the time interval.
  See the application notes for your device.


Hmmm, this is puzzling for sure.

I've never used the MIMO cable, so I don't have much experience.

If the other USRP is running properly, it should be producing 1PPS.




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] N200 MIMO PPS not being detected on mate...

[John Shields via USRP-users]

Thanks Marcus,
 Here is the output of test_pps_input for the mate N200 
connected through MIMO cable:

john@i7ubuntu:~$ test_pps_input --args addr=192.168.20.2 --source=mimo
linux; GNU C++ version 6.3.0 20170406; Boost_106200;
UHD_003.010.002.000-3-g122bfae1


Creating the usrp device with: addr=192.168.20.2...
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
Using Device: Single USRP:
   Device: USRP2 / N-Series Device
   Mboard 0: N200r4
   RX Channel: 0
 RX DSP: 0
 RX Dboard: A
 RX Subdev: SBXv3 RX
   TX Channel: 0
 TX DSP: 0
 TX Dboard: A
 TX Subdev: SBXv3 TX


Attempt to detect the PPS and set the time...

-- 1) catch time transition at pps edge
Error: RuntimeError: Board 0 may not be getting a PPS signal!
No PPS detected within the time interval.
See the application notes for your device.

john@i7ubuntu:~$

so the problem is obvious but is there anything I can have done wrong such that 
the PPS would not get over the MIMO?

If I had another N200 and/or another MIMO cable, I would try them but, 
unfortunately, I don’t have such.

   Kind Regards,

   John


From: mle...@ripnet.com
Sent: Wednesday, September 20, 2017 4:09 AM
To: John Shields
Cc: usrp-users
Subject: Re: [USRP-users] N200 MIMO PPS not being detected on mate...

Try using the --source argument to test_pps_input, specifying "mimo" for the 
mimo-connected unit.

Device addressing is "addressed" here:



https://files.ettus.com/manual/page_usrp2.html#usrp2_

You should probably also investigate using integer_n tuning, which will 
definitely improve phase-coherence, but carries with it certain penalties, 
AFAIR, like much-coarser frequency step size.








On 2017-09-19 02:56, John Shields via USRP-users wrote:

  Have been getting help on the Discuss-gnuradio site but I think, recent 
investigations indicate this forum might be a better place to raise my further 
questions.

  I have 2 N200r4s each with an SBXv3. The unit with address 192.168.10.2 has 
an O/B GPSDO and both units are connected by a MIMO cable. I am feeding an 
attenuated signal, through a splitter to both units and am calculating the 
phase offset.

  Ubuntu 17.04, GNURadio 3.10.2.000 and both USRPs have been updated to the 
correct FW (12.4) and FPGA (11.1).

  I utilise GRC to come up with a simple FG.
  When both usrps are in the same container, I can get both channels to work 
and the phase offset calculation seems to work but each time I run the FG, I 
get a different offset. In order to mitigate for this, I have included the 
set_command_time and clear_command_time code (in Python) from your sync page 
(and Marcus L has verified it looks good) but still there is an offset which is 
constant but changes between runs.

  When I run test_pps_input for ...10.2 it says it found an internal GPSDO 
Jackson.. Firmware Rev 0.926 and reports the attempt to detect the pps and 
set next time as Success!
"   "   "20.2 it says the same
  and in both cases there is ethernet traffic to both devices.

  Anyway, in order to debug the variable phase offset situation further, I 
decided to run the USRPs in separate UHD containers but with the same options 
10.2 Clock src & Time src both O/B GPSDO and for 20.2 both MIMO cable and both 
source blocks have Sync as "unknown PPS".

  With query_gpsdo_sensors indicating "GPS Lock" I proceed to attempt to run 
the modified FG, I get:

  Detecting internal GPSDO No GPSDO found
  -- 1) catch time transition at pps edge
  Traceback (most recent call last):
 File "/home/john/top_block.py", line 401, in 
   main()
 File "/home/john/top_block.py", line 389, in main
   tb = top_block_cls(tpint=options.tpint)
 File "/home/john/top_block.py", line 106, in __init__
   self.uhd_usrp_source_1.set_time_unknown_pps(uhd.time_spec())
 File
  "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line
  3787, in set_time_unknown_pps
   return _uhd_swig.usrp_source_sptr_set_time_unknown_pps(self, time_spec)
  RuntimeError: RuntimeError: Board 0 may not be getting a PPS signal!
  No PPS detected within the time interval.
  See the application notes for your device.

  I have determined that 'Board 0' is ...20.2 by replacing that block with a 
null source under which configuration the FG runs.

  So my questions are:

  1) in a MIMO cable connected system such as this, when I run test_pps_input 
on the mate, is it correct for that utility to report that the mate has an 
'internal GPSDO' and to set things up using it?


  2) if the answer to 1)  is No, then what could I have done/not done to cause 
this error condition?

  3) if the answer to 1) is Yes, then why does the mate block not

[USRP-users] N200 MIMO PPS not being detected on mate...

[John Shields via USRP-users]

Have been getting help on the Discuss-gnuradio site but I think, recent 
investigations indicate this forum might be a better place to raise my further 
questions.

I have 2 N200r4s each with an SBXv3. The unit with address 192.168.10.2 has an 
O/B GPSDO and both units are connected by a MIMO cable. I am feeding an 
attenuated signal, through a splitter to both units and am calculating the 
phase offset.

Ubuntu 17.04, GNURadio 3.10.2.000 and both USRPs have been updated to the 
correct FW (12.4) and FPGA (11.1).

I utilise GRC to come up with a simple FG.
When both usrps are in the same container, I can get both channels to work and 
the phase offset calculation seems to work but each time I run the FG, I get a 
different offset. In order to mitigate for this, I have included the 
set_command_time and clear_command_time code (in Python) from your sync page 
(and Marcus L has verified it looks good) but still there is an offset which is 
constant but changes between runs.

When I run test_pps_input for ...10.2 it says it found an internal GPSDO 
Jackson.. Firmware Rev 0.926 and reports the attempt to detect the pps and 
set next time as Success!
  “   “   “20.2 it says the same
and in both cases there is ethernet traffic to both devices.

Anyway, in order to debug the variable phase offset situation further, I 
decided to run the USRPs in separate UHD containers but with the same options 
10.2 Clock src & Time src both O/B GPSDO and for 20.2 both MIMO cable and both 
source blocks have Sync as “unknown PPS”.

With query_gpsdo_sensors indicating “GPS Lock” I proceed to attempt to run the 
modified FG, I get:

Detecting internal GPSDO No GPSDO found
-- 1) catch time transition at pps edge
Traceback (most recent call last):
   File "/home/john/top_block.py", line 401, in 
 main()
   File "/home/john/top_block.py", line 389, in main
 tb = top_block_cls(tpint=options.tpint)
   File "/home/john/top_block.py", line 106, in __init__
 self.uhd_usrp_source_1.set_time_unknown_pps(uhd.time_spec())
   File
"/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line
3787, in set_time_unknown_pps
 return _uhd_swig.usrp_source_sptr_set_time_unknown_pps(self, time_spec)
RuntimeError: RuntimeError: Board 0 may not be getting a PPS signal!
No PPS detected within the time interval.
See the application notes for your device.

I have determined that ‘Board 0’ is ...20.2 by replacing that block with a null 
source under which configuration the FG runs.

So my questions are:

1) in a MIMO cable connected system such as this, when I run test_pps_input on 
the mate, is it correct for that utility to report that the mate has an 
‘internal GPSDO’ and to set things up using it?

2) if the answer to 1)  is No, then what could I have done/not done to cause 
this error condition?

3) if the answer to 1) is Yes, then why does the mate block not detect PPS when 
test_pps_input says it can?

4) in the case of dual usrps in the same container, for the Device Address 
field I put in: addr0=192.168.10.2,addr1=192.168.20.2 – is this correct? I only 
mention this because, if I have a USRP1 powered on, the original FG would 
detect it, saying it was opening “a USRP1 device” and would bomb out on 
set_clock_source. So it seems that my address parameters might not be specific 
enough!

5) if 4) is in error, in the case where I have individual UHD sources, for the 
Device Address fields I have: addr=192.168.10.2 and addr=192.168.20.2 
respectively. Is this the correct? even with a USRP1 powered, it only Open a 
“USRP2/N-Series device” so it seems to find the devices I want only.

 Kind Regards,

   John



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com