Re: [USRP-users] n3xx master clock rate selection

[EJ Kreinar via USRP-users]

So, I'm trying to understand the fundamental clock rate selection
limitations for the 9371... From what I understand, this is plausibly due
to some limitations of the JESD interface (?).

This wiki answer suggests possible rates of 122.88M, 153.6M, 184.32M,
245.76M, or 307.2M:
https://ez.analog.com/wide-band-rf-transceivers/design-support-ad9371/f/q-a/100289/ad9371-sync-clock-frequencies

Then the 9371 datasheet also shows example rates of 122.88, 153.6, 245.76,
and 307.2 MHz: https://www.analog.com/en/products/ad9371.html

So how is it that there's a master clock rate at 125MHz??

EJ

On Wed, Oct 17, 2018, 5:49 PM EJ Kreinar  wrote:

> Hi Daniel,
>
> Sad to hear that! By the way, I forgot to mention another important rate I
> need, 3 MHz, that also has an integer relationship to 120 MHz... Perhaps
> I'd like to make a formal feature request for 120 MHz master clock?? It
> strikes me as odd that so many of the "whole number" MHz sample rates are
> neglected on the n3xx series by default-- it's often the case that I'll
> want to interact with other hardware with baud rates at, say, 2 MHz or 10
> MHz or something, but I just don't have the fpga-based fractional
> conversions onhand right now...
>
> I'm certainly not afraid of nontrivial changes, so if the AD9371 supports
> a clock rate that can give me these derived sample rates, I really see this
> as the best solution since other platforms can already achieve these rates
> without extra user-space processing requirements.
>
> However, if needed, potentially a "quick and dirty" approach might be to
> make an rfnoc fractional resampler that combines a DUC and DDC into one
> "ce", with a block controller to calculate the magical conversions... It's
> not an optimal solution but it might do the trick here. Anyone else
> interested in such an fpga-based fractional resampler?
>
> EJ
>
> On Wed, Oct 17, 2018, 1:52 PM Daniel Jepson via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi EJ,
>>
>> The fundamental limitation comes from the AD9371. Although the datasheet
>> specifies a wide reference clock input range, there are only certain
>> supported rates within the public side of their API (at least that I'm
>> aware of). These include the rates you mentioned from the KB.
>>
>> Assuming the AD9371 allows it, adding a new MCR is not trivial and would
>> require a good deal of work across hardware, FPGA code, and MPM. The
>> fractional resampler sounds like a much better path forward, albeit
>> difficult right now.
>>
>> Hopefully that explains some of the background on the chosen MCRs. Sorry
>> it wasn't exactly what you were hoping for!
>>
>> -Daniel
>>
>> On Wed, Oct 17, 2018 at 10:50 AM EJ Kreinar via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi all,
>>>
>>> I'm working on an FPGA application on the n310/n300, and I'm bumping
>>> into a limitation of the master_clock_rate selection I'd like to be
>>> able to use sample rates in the FPGA of 2 MHz, 4 MHz, and 10 MHz, but none
>>> of these values are integer multiples of the supported rates (122.88e6,
>>> 125e6, 153.6e6 -- from here:
>>> https://kb.ettus.com/N300/N310_Getting_Started_Guides#Supported_Sample_Rates).
>>> This causes a problem in the FPGA since I would need a fractional
>>> resampler, which I dont currently have, unfortunately.
>>>
>>> What's the fundamental limitation of these master clock rates? I would
>>> have assumed that the AD9371-based architecture would have resulted in a
>>> wider variety of plausible clock rates, similar to the AD9361 on the E310.
>>> I havent found these limits yet in the software or FPGA, so any pointers
>>> where to look would be appreciated.
>>>
>>> As a follow up question, how feasible would it be to add a master clock
>>> rate of 120 MHz?? Any ideas where to make these changes? This would answer
>>> the mail for my sample rates of interest right now.
>>>
>>> Thanks!
>>> EJ
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>>
>> --
>>
>> Daniel Jepson
>>
>> Digital Hardware Engineer
>>
>> National Instruments
>>
>>
>>
>> O: +1.512.683.6163
>>
>> daniel.jep...@ni.com
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
> On Wed, Oct 17, 2018, 1:52 PM Daniel Jepson via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi EJ,
>>
>> The fundamental limitation comes from the AD9371. Although the datasheet
>> specifies a wide reference clock input range, there are only certain
>> supported rates within the public side of their API (at least that I'm
>> aware of). These include the rates you mentioned from the KB.
>>
>> Assuming the AD9371 allows it, adding a new MCR is not trivial and would
>> require a good deal of work across hardware, FPGA code, and MPM. The
>> fractional re

[USRP-users] Another test

[Marcus D. Leech via USRP-users]

test.


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

Re: [USRP-users] n3xx master clock rate selection

[EJ Kreinar via USRP-users]

Hi Daniel,

Sad to hear that! By the way, I forgot to mention another important rate I
need, 3 MHz, that also has an integer relationship to 120 MHz... Perhaps
I'd like to make a formal feature request for 120 MHz master clock?? It
strikes me as odd that so many of the "whole number" MHz sample rates are
neglected on the n3xx series by default-- it's often the case that I'll
want to interact with other hardware with baud rates at, say, 2 MHz or 10
MHz or something, but I just don't have the fpga-based fractional
conversions onhand right now...

I'm certainly not afraid of nontrivial changes, so if the AD9371 supports a
clock rate that can give me these derived sample rates, I really see this
as the best solution since other platforms can already achieve these rates
without extra user-space processing requirements.

However, if needed, potentially a "quick and dirty" approach might be to
make an rfnoc fractional resampler that combines a DUC and DDC into one
"ce", with a block controller to calculate the magical conversions... It's
not an optimal solution but it might do the trick here. Anyone else
interested in such an fpga-based fractional resampler?

EJ

On Wed, Oct 17, 2018, 1:52 PM Daniel Jepson via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi EJ,
>
> The fundamental limitation comes from the AD9371. Although the datasheet
> specifies a wide reference clock input range, there are only certain
> supported rates within the public side of their API (at least that I'm
> aware of). These include the rates you mentioned from the KB.
>
> Assuming the AD9371 allows it, adding a new MCR is not trivial and would
> require a good deal of work across hardware, FPGA code, and MPM. The
> fractional resampler sounds like a much better path forward, albeit
> difficult right now.
>
> Hopefully that explains some of the background on the chosen MCRs. Sorry
> it wasn't exactly what you were hoping for!
>
> -Daniel
>
> On Wed, Oct 17, 2018 at 10:50 AM EJ Kreinar via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi all,
>>
>> I'm working on an FPGA application on the n310/n300, and I'm bumping into
>> a limitation of the master_clock_rate selection I'd like to be able to
>> use sample rates in the FPGA of 2 MHz, 4 MHz, and 10 MHz, but none of these
>> values are integer multiples of the supported rates (122.88e6, 125e6,
>> 153.6e6 -- from here:
>> https://kb.ettus.com/N300/N310_Getting_Started_Guides#Supported_Sample_Rates).
>> This causes a problem in the FPGA since I would need a fractional
>> resampler, which I dont currently have, unfortunately.
>>
>> What's the fundamental limitation of these master clock rates? I would
>> have assumed that the AD9371-based architecture would have resulted in a
>> wider variety of plausible clock rates, similar to the AD9361 on the E310.
>> I havent found these limits yet in the software or FPGA, so any pointers
>> where to look would be appreciated.
>>
>> As a follow up question, how feasible would it be to add a master clock
>> rate of 120 MHz?? Any ideas where to make these changes? This would answer
>> the mail for my sample rates of interest right now.
>>
>> Thanks!
>> EJ
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
> --
>
> Daniel Jepson
>
> Digital Hardware Engineer
>
> National Instruments
>
>
>
> O: +1.512.683.6163
>
> daniel.jep...@ni.com
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>

On Wed, Oct 17, 2018, 1:52 PM Daniel Jepson via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi EJ,
>
> The fundamental limitation comes from the AD9371. Although the datasheet
> specifies a wide reference clock input range, there are only certain
> supported rates within the public side of their API (at least that I'm
> aware of). These include the rates you mentioned from the KB.
>
> Assuming the AD9371 allows it, adding a new MCR is not trivial and would
> require a good deal of work across hardware, FPGA code, and MPM. The
> fractional resampler sounds like a much better path forward, albeit
> difficult right now.
>
> Hopefully that explains some of the background on the chosen MCRs. Sorry
> it wasn't exactly what you were hoping for!
>
> -Daniel
>
> On Wed, Oct 17, 2018 at 10:50 AM EJ Kreinar via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi all,
>>
>> I'm working on an FPGA application on the n310/n300, and I'm bumping into
>> a limitation of the master_clock_rate selection I'd like to be able to
>> use sample rates in the FPGA of 2 MHz, 4 MHz, and 10 MHz, but none of these
>> values are integer multiples of the supported rates (122.88e6, 125e6,
>> 153.6e6 -- from here:
>> https://kb.ettus.com/N300/N310_Getting_Started_Guides#Supported_Sample_Rates).
>> This causes a problem in th

Re: [USRP-users] Saturation issue with low amplitude (USRP N310)

[Ali Dormiani via USRP-users]

 Attempt 2. Sorry for breaking mailing list rules with the attachments.
Here is a google drive link to the screenshots, GRC file, and binary files.
(3 MB zip)

https://drive.google.com/a/eng.ucsd.edu/file/d/1TvmHuEMFb2QpkiMMdiUEW6aVoUfLYayi/view?usp=sharing

We have three sliders in GNUradio.

1. TX gain

2. RX gain

3. Digital Gain (multiply constant block between our binary file and the
UHD block.

We also have one TX connected directly to an RX with a 30 dB analog
attenuation for safety.

Our binary files were generated in MATLAB and are normalized to unity
magnitude.

Attached, please find the GRC file and our binary files. For reference, the
waveform we made is a multitone signal so it should be a bunch of evenly
spaced spikes. I have included some screenshots too. Additionally we have
verified this strange behavior with a spectrum analyzer.
By playing around with the sliders you can see how narrow the zone is for
good results. Intuitivly it seems like TX and RX gain don't really matter.
They just shift the narrow usability zone for Digital gain.

On Wed, Oct 17, 2018 at 12:45 PM Ali Dormiani  wrote:

> We have three sliders in GNUradio.
>
> 1. TX gain
>
> 2. RX gain
>
> 3. Digital Gain (multiply constant block between our binary file and the
> UHD block.
>
> We also have one TX connected directly to an RX with a 30 dB analog
> attenuation for safety.
>
> Our binary files were generated in MATLAB and are normalized to unity
> magnitude.
>
> Attached, please find the GRC file and our binary files. For reference,
> the waveform we made is a multitone signal so it should be a bunch of
> evenly spaced spikes. I have included some screenshots too. Additionally we
> have verified this strange behavior with a spectrum analyzer.
> By playing around with the sliders you can see how narrow the zone is for
> good results. Intuitivly it seems like TX and RX gain don't really matter.
> They just shift the narrow usability zone for Digital gain.
>
>
>
> On Wed, Oct 10, 2018 at 6:20 PM Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On 10/10/2018 03:08 PM, Ali Dormiani via USRP-users wrote:
>>
>> Hello,
>>
>> We have the exact same problem. My lab is waiting on some sfp+ cables so
>> in a few days I will share our screenshots, code, and data binary files in
>> order to provide this thread with a second example of this issue. For now,
>> all I can say is this problem is not isolated to your N310 or Windows.
>>
>> We have two N310's running with the same version of UHD (and GNUradio
>> 3.7.13.4) on Linux kernel 4.18. By using amplitude sliders in GNUradio we
>> found that there is a very small and strange gain "Goldilocks" zone around
>> .002 that gives good results. Going higher starts to raise the noise floor
>> until all signal definition is gone.
>>
>> Ali Dormiani
>> UCSD Noiselab
>>
>> What is your RF gain set to in these examples?  Does that change things?
>>
>> If you raise things to a level where non-linearity is apparent, does
>> placing a 10dB attenuator in-line fix it (trying to distinguish between
>>   the transmitter being non-linear, and your receiver/spectrum analyser).
>>
>>
>>
>> On Wed, Oct 10, 2018 at 11:33 AM Mathieu Lizée via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi,
>>>
>>> When using the UHD "tx_waveforms" example, I can see that the signal
>>> emitted by my N310 USRP is saturated when it’s not supposed to be.
>>>
>>> Here's a snapshot of the signal when I set the amplitude to 0.003:
>>> .\tx_waveforms.exe --rate 12.5e6 --nsamps 125000 --freq 1575.42e6
>>> --ampl 0.003 --otw sc16 --wave-type SINE --wave-freq 10e3 --channels 2
>>>
>>> [image: tx_waveforms_3e-3_amp]
>>> 
>>>
>>> Here's a snapshot of the signal when I set the amplitude to 0.03:
>>> .\tx_waveforms.exe --rate 12.5e6 --nsamps 125000 --freq 1575.42e6
>>> --ampl 0.03 --otw sc16 --wave-type SINE --wave-freq 10e3 --channels 2
>>>
>>> [image: tx_waveforms_3e-2_amp]
>>> 
>>>
>>> As you can see from the pictures above, it seems that there's a
>>> saturation in the signal when the amplitude is set to 0.03 (which is
>>> unexpected with such a small amplitude). We have double-checked with a X300
>>> device, and the signal is normal in both cases.
>>>
>>> Do you have an idea of what could be wrong, or a suggestion to try on
>>> our side?
>>>
>>> Technical Information:
>>>
>>>- Windows 10
>>>- USRP N310
>>>- UHD 3.13.0.3-rc1
>>>
>>>
>>> Thank you!
>>>
>>> --
>>> *Mathieu Lizee*
>>> *Software Development Intern*
>>>
>>> *Skydel Solutions*
>>> WeWork 5th Floor (Skydel)
>>> 1275 Av des Canadiens-de-Montreal
>>> Montreal, QC
>>> H3B 0G4
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/lis

Re: [USRP-users] B210 EnvironmentError: IOError: usb rx6 transfer status: LIBUSB_TRANSFER_OVERFLOW

[Robin Coxe via USRP-users]

Hi Andrew.  It looks like your USRP B210 is connected via USB2.  Do you
still see the same error when connected to a USB3 port?

-Robin

On Wed, Oct 17, 2018 at 1:00 PM Harper, Andrew via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi, I'm having trouble receiving samples with my B210. I get the following
> error when I run either a GNU Radio Companion script or the benchmark
> utillity:
>
> EnvironmentError: IOError: usb rx6 transfer status:
> LIBUSB_TRANSFER_OVERFLOW
>
>
> Does anyone have a way to resolve this? Below is the benchmark output:
>
>
> sdrl@star00:/usr/local/lib/uhd/examples$ ./benchmark_rate --random
> --rx_rate 320
> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_3.14.0.0-62-g3b42e6f0
> [WARNING] [UHD] Unable to set the thread priority. Performance may be
> negatively affected.
> Please see the general application notes in the manual for instructions.
> EnvironmentError: OSError: error in pthread_setschedparam
> Using random number of samples in send() and recv() calls.
>
> [00:00:00.05] Creating the usrp device with: ...
> [INFO] [B200] Detected Device: B210
> [INFO] [B200] Operating over USB 2.
> [INFO] [B200] Detecting internal GPSDO
> [INFO] [GPS] Found an internal GPSDO: GPSTCXO , Firmware Rev 0.929a
> [INFO] [B200] Initialize CODEC control...
> [INFO] [B200] Initialize Radio control...
> [INFO] [B200] Performing register loopback test...
> [INFO] [B200] Register loopback test passed
> [INFO] [B200] Performing register loopback test...
> [INFO] [B200] Register loopback test passed
> [INFO] [B200] Setting master clock rate selection to 'automatic'.
> [INFO] [B200] Asking for clock rate 16.00 MHz...
> [INFO] [B200] Actually got clock rate 16.00 MHz.
> Using Device: Single USRP:
>   Device: B-Series Device
>   Mboard 0: B210
>   RX Channel: 0
> RX DSP: 0
> RX Dboard: A
> RX Subdev: FE-RX2
>   RX Channel: 1
> RX DSP: 1
> RX Dboard: A
> RX Subdev: FE-RX1
>   TX Channel: 0
> TX DSP: 0
> TX Dboard: A
> TX Subdev: FE-TX2
>   TX Channel: 1
> TX DSP: 1
> TX Dboard: A
> TX Subdev: FE-TX1
>
> [00:00:03.369817] Setting device timestamp to 0...
> [INFO] [B200] Asking for clock rate 51.20 MHz...
> [INFO] [B200] Actually got clock rate 51.20 MHz.
> [INFO] [B200] Asking for clock rate 51.20 MHz...
> [INFO] [B200] OK
> [INFO] [B200] Asking for clock rate 51.20 MHz...
> [INFO] [B200] OK
> [INFO] [B200] Asking for clock rate 51.20 MHz...
> [INFO] [B200] OK
> [WARNING] [UHD] Unable to set the thread priority. Performance may be
> negatively affected.
> Please see the general application notes in the manual for instructions.
> EnvironmentError: OSError: error in pthread_setschedparam
> [00:00:03.783883] Testing receive rate 3.20 Msps on 1 channels
> [00:00:03.785322] Caught an IO exception.
> EnvironmentError: IOError: usb rx6 transfer status:
> LIBUSB_TRANSFER_OVERFLOW
> [00:00:13.783967] Benchmark complete.
>
> Benchmark rate summary:
>   Num received samples: 0
>   Num dropped samples:  0
>   Num overruns detected:0
>   Num transmitted samples:  0
>   Num sequence errors (Tx): 0
>   Num sequence errors (Rx): 0
>   Num underruns detected:   0
>   Num late commands:0
>   Num timeouts (Tx):0
>   Num timeouts (Rx):0
>
>
> Done!
>
>
> ___
> 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] B210 EnvironmentError: IOError: usb rx6 transfer status: LIBUSB_TRANSFER_OVERFLOW

[Harper, Andrew via USRP-users]

Hi, I'm having trouble receiving samples with my B210. I get the following 
error when I run either a GNU Radio Companion script or the benchmark utillity:

EnvironmentError: IOError: usb rx6 transfer status: LIBUSB_TRANSFER_OVERFLOW


Does anyone have a way to resolve this? Below is the benchmark output:


sdrl@star00:/usr/local/lib/uhd/examples$ ./benchmark_rate --random --rx_rate 
320
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; 
UHD_3.14.0.0-62-g3b42e6f0
[WARNING] [UHD] Unable to set the thread priority. Performance may be 
negatively affected.
Please see the general application notes in the manual for instructions.
EnvironmentError: OSError: error in pthread_setschedparam
Using random number of samples in send() and recv() calls.

[00:00:00.05] Creating the usrp device with: ...
[INFO] [B200] Detected Device: B210
[INFO] [B200] Operating over USB 2.
[INFO] [B200] Detecting internal GPSDO
[INFO] [GPS] Found an internal GPSDO: GPSTCXO , Firmware Rev 0.929a
[INFO] [B200] Initialize CODEC control...
[INFO] [B200] Initialize Radio control...
[INFO] [B200] Performing register loopback test...
[INFO] [B200] Register loopback test passed
[INFO] [B200] Performing register loopback test...
[INFO] [B200] Register loopback test passed
[INFO] [B200] Setting master clock rate selection to 'automatic'.
[INFO] [B200] Asking for clock rate 16.00 MHz...
[INFO] [B200] Actually got clock rate 16.00 MHz.
Using Device: Single USRP:
  Device: B-Series Device
  Mboard 0: B210
  RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: FE-RX2
  RX Channel: 1
RX DSP: 1
RX Dboard: A
RX Subdev: FE-RX1
  TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: FE-TX2
  TX Channel: 1
TX DSP: 1
TX Dboard: A
TX Subdev: FE-TX1

[00:00:03.369817] Setting device timestamp to 0...
[INFO] [B200] Asking for clock rate 51.20 MHz...
[INFO] [B200] Actually got clock rate 51.20 MHz.
[INFO] [B200] Asking for clock rate 51.20 MHz...
[INFO] [B200] OK
[INFO] [B200] Asking for clock rate 51.20 MHz...
[INFO] [B200] OK
[INFO] [B200] Asking for clock rate 51.20 MHz...
[INFO] [B200] OK
[WARNING] [UHD] Unable to set the thread priority. Performance may be 
negatively affected.
Please see the general application notes in the manual for instructions.
EnvironmentError: OSError: error in pthread_setschedparam
[00:00:03.783883] Testing receive rate 3.20 Msps on 1 channels
[00:00:03.785322] Caught an IO exception.
EnvironmentError: IOError: usb rx6 transfer status: LIBUSB_TRANSFER_OVERFLOW
[00:00:13.783967] Benchmark complete.

Benchmark rate summary:
  Num received samples: 0
  Num dropped samples:  0
  Num overruns detected:0
  Num transmitted samples:  0
  Num sequence errors (Tx): 0
  Num sequence errors (Rx): 0
  Num underruns detected:   0
  Num late commands:0
  Num timeouts (Tx):0
  Num timeouts (Rx):0


Done!


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

[USRP-users] Pybombs error for gnuradio

[Pratik Chatterjee via USRP-users]

Hello all,

I have used pybombs in the past and it worked just fine. But recently I get
compatibility issues of uhd and fpga, as well as the following error while
building gnuradio. Has anyone seen this before? I am following the getting
started rfnoc guide.

[ 87%] Building CXX object
gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o
/home/pratik/rfnoc/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:
In function ‘PyObject* _wrap_time_spec_t___addSWIG_0(PyObject*,
PyObject*)’:
/home/pratik/rfnoc/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:20964:33:
error: ‘class uhd::time_spec_t’ has no member named ‘operator+’
   result = (arg1)->operator +(*arg2);
 ^
/home/pratik/rfnoc/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:
In function ‘PyObject* _wrap_time_spec_t___addSWIG_1(PyObject*,
PyObject*)’:
/home/pratik/rfnoc/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:21009:33:
error: ‘class uhd::time_spec_t’ has no member named ‘operator+’
   result = (arg1)->operator +((uhd::time_spec_t const &)*arg2);
 ^
gr-uhd/swig/CMakeFiles/_uhd_swig.dir/build.make:70: recipe for target
'gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o' failed
make[2]: ***
[gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o] Error 1
CMakeFiles/Makefile2:15091: recipe for target
'gr-uhd/swig/CMakeFiles/_uhd_swig.dir/all' failed
make[1]: *** [gr-uhd/swig/CMakeFiles/_uhd_swig.dir/all] Error 2
Makefile:160: recipe for target 'all' failed
make: *** [all] Error 2
[ERROR] Build failed. See output above for error messages.
[ERROR] Problem occurred while building package gnuradio:
Build failed.
[ERROR] Error installing package gnuradio. Aborting.

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

Re: [USRP-users] X310 synchronization over White Rabbit

[Daniel Jepson via USRP-users]

Hi Jean-Michel,

As you hinted, it might be best to re-post this to the White Rabbit list:
https://lists.ohwr.org/sympa/info/white-rabbit-dev

>From my limited experience with White Rabbit and the N310 product, I don't
see any obvious issues, other than possibly within the switch.

-Daniel

On Wed, Oct 17, 2018 at 1:17 PM jean-michel friedt via USRP-users <
usrp-users@lists.ettus.com> wrote:

> [copy to the White Rabbit Developers mailing list]
>
> I am considering distributed radiofrequency signal acquisition and
> generation using
> two Ettus Research X310 SDR platforms, fed with the 1 PPS and 10 MHz
> outputs from our
> White Rabbit (WR) network. In addition to these signals, the control
> software (libuhd) running
> on the computer collecting data from all SDR platforms needs to timestamp
> packets in order
> to synchronize acquisitions. If I run a 1GbE network through a switch, all
> works fine, I can
> collect synchronous data from the local and remote site. In real life I'd
> like to use the
> WR network to transfer the data: I know my network configuration is good
> since I can ping
> the USRPs. I have increased MTUs on the host Ethernet interfaces and the
> WRS (running
> firmware 5.0.1) to 9000 as advised by libuhd.
> In all cases the synchronization of the USRPs fail with error messages
> UHD Error:
> x300 fw communication failure #1
> EnvironmentError: IOError: x300 fw poke32 - reply timed out
> while the same configuration works when replacing the WR network with a
> 1GbE switch. Is there
> some sort of excess latency introduced by the networking layer of WR that
> might be the cause
> of the timeout ? Is there any configuration I can tune to try to solve the
> issue ? Or lower some
> of the timeout limit on libuhd ?
>
> Thanks, Jean-Michel
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>


-- 

Daniel Jepson

Digital Hardware Engineer

National Instruments



O: +1.512.683.6163

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

Re: [USRP-users] N310 SPF+ compatability

[Ali Dormiani via USRP-users]

Never-mind. It was an issue unrelated to USRP. At least those searching the
mailing list in the future know now that these parts are known good.

On Tue, Oct 16, 2018 at 11:39 AM Ali Dormiani  wrote:

> Hello
>
> I am having a lot of problems getting 10 Gbe SFP+ working between an N310
> and a server.
>
> I want to isolate the problem. It seems that SFP+ is a very finicky
> standard. The readme for the Intel drivers say only certain cables will
> work with it.
>
> Is an N310 running UHD 3.13.0.2 and the latest XG image compatible with
> the following parts?
>
> 1. Intel x520-DA2 NIC (dell branded card with Intel controller chip)
>
> 2. 5m passive copper direct attach SFP+ cable validated for Intel parts
>
> Thank you for your time,
>
> Ali Dormiani
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] X310 synchronization over White Rabbit

[jean-michel friedt via USRP-users]

[copy to the White Rabbit Developers mailing list]

I am considering distributed radiofrequency signal acquisition and generation 
using
two Ettus Research X310 SDR platforms, fed with the 1 PPS and 10 MHz outputs 
from our
White Rabbit (WR) network. In addition to these signals, the control software 
(libuhd) running
on the computer collecting data from all SDR platforms needs to timestamp 
packets in order
to synchronize acquisitions. If I run a 1GbE network through a switch, all 
works fine, I can
collect synchronous data from the local and remote site. In real life I'd like 
to use the
WR network to transfer the data: I know my network configuration is good since 
I can ping
the USRPs. I have increased MTUs on the host Ethernet interfaces and the WRS 
(running 
firmware 5.0.1) to 9000 as advised by libuhd. 
In all cases the synchronization of the USRPs fail with error messages
UHD Error:
x300 fw communication failure #1
EnvironmentError: IOError: x300 fw poke32 - reply timed out
while the same configuration works when replacing the WR network with a 1GbE 
switch. Is there
some sort of excess latency introduced by the networking layer of WR that might 
be the cause
of the timeout ? Is there any configuration I can tune to try to solve the 
issue ? Or lower some
of the timeout limit on libuhd ?

Thanks, Jean-Michel

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

Re: [USRP-users] n3xx master clock rate selection

[Daniel Jepson via USRP-users]

Hi EJ,

The fundamental limitation comes from the AD9371. Although the datasheet
specifies a wide reference clock input range, there are only certain
supported rates within the public side of their API (at least that I'm
aware of). These include the rates you mentioned from the KB.

Assuming the AD9371 allows it, adding a new MCR is not trivial and would
require a good deal of work across hardware, FPGA code, and MPM. The
fractional resampler sounds like a much better path forward, albeit
difficult right now.

Hopefully that explains some of the background on the chosen MCRs. Sorry it
wasn't exactly what you were hoping for!

-Daniel

On Wed, Oct 17, 2018 at 10:50 AM EJ Kreinar via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> I'm working on an FPGA application on the n310/n300, and I'm bumping into
> a limitation of the master_clock_rate selection I'd like to be able to
> use sample rates in the FPGA of 2 MHz, 4 MHz, and 10 MHz, but none of these
> values are integer multiples of the supported rates (122.88e6, 125e6,
> 153.6e6 -- from here:
> https://kb.ettus.com/N300/N310_Getting_Started_Guides#Supported_Sample_Rates).
> This causes a problem in the FPGA since I would need a fractional
> resampler, which I dont currently have, unfortunately.
>
> What's the fundamental limitation of these master clock rates? I would
> have assumed that the AD9371-based architecture would have resulted in a
> wider variety of plausible clock rates, similar to the AD9361 on the E310.
> I havent found these limits yet in the software or FPGA, so any pointers
> where to look would be appreciated.
>
> As a follow up question, how feasible would it be to add a master clock
> rate of 120 MHz?? Any ideas where to make these changes? This would answer
> the mail for my sample rates of interest right now.
>
> Thanks!
> EJ
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>


-- 

Daniel Jepson

Digital Hardware Engineer

National Instruments



O: +1.512.683.6163

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

[USRP-users] Test

[Marcus D. Leech via USRP-users]

Sorry about this.  Testing.


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

[USRP-users] n3xx master clock rate selection

[EJ Kreinar via USRP-users]

Hi all,

I'm working on an FPGA application on the n310/n300, and I'm bumping into a
limitation of the master_clock_rate selection I'd like to be able to
use sample rates in the FPGA of 2 MHz, 4 MHz, and 10 MHz, but none of these
values are integer multiples of the supported rates (122.88e6, 125e6,
153.6e6 -- from here:
https://kb.ettus.com/N300/N310_Getting_Started_Guides#Supported_Sample_Rates).
This causes a problem in the FPGA since I would need a fractional
resampler, which I dont currently have, unfortunately.

What's the fundamental limitation of these master clock rates? I would have
assumed that the AD9371-based architecture would have resulted in a wider
variety of plausible clock rates, similar to the AD9361 on the E310. I
havent found these limits yet in the software or FPGA, so any pointers
where to look would be appreciated.

As a follow up question, how feasible would it be to add a master clock
rate of 120 MHz?? Any ideas where to make these changes? This would answer
the mail for my sample rates of interest right now.

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

Re: [USRP-users] Synch'ing two USRP-X310

[Marcus D Leech via USRP-users]

You can test the hypothesis using a heat gun. 

Sent from my iPhone

> On Oct 17, 2018, at 1:13 AM, Francois Quitin  wrote:
> 
> We use 30cm high quality sma cables, so I'm a bit surprised that this would 
> be thermal noise...
> 
> n 17.10.2018 05:23, Marcus D. Leech wrote:
>>> On 10/16/2018 04:49 PM, Francois Quitin wrote:
>>> Units are radians. There is some noise because the post processing is a bit 
>>> crummy, but we were more concerned about the drift.
>> How long is the cable that is being used to link the two X310 REF ports?
>> Looks like the drift is about 0.3 radian, and it looks like a thermal
>> effect to me, but that would likely not be the case for a short cable.
>>> n 16.10.2018 22:46, Marcus D. Leech via USRP-users wrote:
> On 10/16/2018 04:39 PM, Francois Quitin via USRP-users wrote:
> Oops, I forgot to explain the figures. We're sending a pilot tone with a 
> different usrp, and split it over the 4 channels using a 4-port RF 
> SPLITTER. The graph shows the phase of the received signals as a function 
> of time (1 point every ten seconds)
> Francois
 OK, but what are the phase units?  Degrees?  Radians?
> 16.10.2018 18:13, Marcus D. Leech via USRP-users wrote:
>>> On 10/16/2018 07:44 AM, Francois Quitin via USRP-users wrote:
>>> Dear all,
>>> We encountered a small problem when we try to build a 4-element MIMO
>>> array with two X310 (equipped with UBX daughterboards). We are
>>> working on UHD-3.10.3:
>>> -  When we use an octoclock to provide the 10 MHz
>>> Ref and the PPS to both X310, the phase of each receiving front-end
>>> stays nicely constant (see octoclock.png). The Ref Source and Time
>>> Source are set to “external” in GNU Radio (the points represent
>>> a measurement taken every ten seconds)
>>> -  When we use the 10 MHz Ref Out and PPS Out from
>>> one X310 and feed it to the Ref In and PPS In of the other X310, we
>>> observe a drift in the phases of the channels from the second X310.
>>> This is shown in the graph daisyChain.png, where we take one point
>>> every ten seconds. We configured GNU Radio to set the Ref Source and
>>> Time source of the first USRP to “default”, the ones of the
>>> second USRP to “external”.
>>> This drift is something more severe, sometimes less, but it’s
>>> always present. Any idea why we observe this?
>>> Many thanks,
>>> François
>> What is the Y-axis scale on these plots?
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> ---
> Francois QUITIN
> Assistant Professor
> BEAMS Dpt. – Embedded Electronics
> Brussels School of Engineering
> Université Libre de Bruxelles (ULB)
> Web   https://sites.google.com/site/fquitin2/
> Phone +32 2 650 2829
> ___
> 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
>>> ---
>>> Francois QUITIN
>>> Assistant Professor
>>> BEAMS Dpt. – Embedded Electronics
>>> Brussels School of Engineering
>>> Université Libre de Bruxelles (ULB)
>>> Web   https://sites.google.com/site/fquitin2/
>>> Phone +32 2 650 2829
> 
> ---
> Francois QUITIN
> Assistant Professor
> 
> BEAMS Dpt. – Embedded Electronics
> Brussels School of Engineering
> Université Libre de Bruxelles (ULB)
> 
> Web   https://sites.google.com/site/fquitin2/
> Phone +32 2 650 2829

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

Re: [USRP-users] Multiple B200, Python API.

[Marcus D. Leech via USRP-users]

On 10/17/2018 10:53 AM, J Subash via USRP-users wrote:


Hi,

Hope you're doing well. I am new here and new to the USRP API. 
Attached is a setup to record signals at 380MHz and 2.4Ghz on two 
B200's. The aim is to sync the devices using the 10Mhz and 1PPS 
provided from an external source to both devices.


Using the python API to achieve this and here is a snippet used to 
test multiple-usrp


In [1]: import uhd
In [2]: my_usrp = uhd.usrp.MultiUSRP("serial0=xxx310C,serial1=xxx311F")
In [3]: my_usrp.get_master_clock_rate(0)
Out[3]: 1600.0
In [4]: my_usrp.get_master_clock_rate(1)
Traceback (most recent call last):  File 
"", line 1, in 

   my_usrp.get_master_clock_rate(1)
RuntimeError: LookupError: IndexError: multi_usrp::mb_root(1) - 
LookupError: IndexError: multi_usrp::mb_root(1) - path not found


Clearly the second device is not registered by the MultiUSRP method. I 
found the C++ equivalent to this for the x series devices on the usrp 
manual; which is:


uhd::device_addr_t 
 args 
("addr0=192.168.10.2,addr1=192.168.20.2");
uhd::usrp::multi_usrp::sptr 
 
usrp = uhd::usrp::multi_usrp::make 
(args 
);



Have these methods been exposed to the python API? If yes, a quick 
example would be helpful.


Thanks very much.


Unless something has changed, you can't have more than 1 B2xx in a 
single multi-usrp object.



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

[USRP-users] Multiple B200, Python API.

[J Subash via USRP-users]

Hi,

Hope you're doing well. I am new here and new to the USRP API. Attached 
is a setup to record signals at 380MHz and 2.4Ghz on two B200's. The aim 
is to sync the devices using the 10Mhz and 1PPS provided from an 
external source to both devices.


Using the python API to achieve this and here is a snippet used to test 
multiple-usrp


In [1]: import uhd
In [2]: my_usrp = uhd.usrp.MultiUSRP("serial0=xxx310C,serial1=xxx311F")
In [3]: my_usrp.get_master_clock_rate(0)
Out[3]: 1600.0
In [4]: my_usrp.get_master_clock_rate(1)
Traceback (most recent call last):  File 
"", line 1, in 

   my_usrp.get_master_clock_rate(1)
RuntimeError: LookupError: IndexError: multi_usrp::mb_root(1) - 
LookupError: IndexError: multi_usrp::mb_root(1) - path not found


Clearly the second device is not registered by the MultiUSRP method. I 
found the C++ equivalent to this for the x series devices on the usrp 
manual; which is:


uhd::device_addr_t 
 args 
("addr0=192.168.10.2,addr1=192.168.20.2");
uhd::usrp::multi_usrp::sptr 
 
usrp = uhd::usrp::multi_usrp::make 
(args 
);



Have these methods been exposed to the python API? If yes, a quick 
example would be helpful.


Thanks very much.

--
Joel

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

Re: [USRP-users] getting parser error with uhd-usrp for rx-ofdm example

[Michael Dickens via USRP-users]

Hi dapodun nudopad - Yes there are a variety of possible ways the Tx/Rx
can result in the "Parser returned #f" issue. What it means is that the
S&C detected a header, but the header CRCs (computed versus embedded)
didn't match up. Since we can't see your whole flowgraph, its a little
difficult to give you more than generalities that I'm sure you've found
in your internet searches. Hence, can you attach your full GRC flowgraph
for us to test & see what's going on? One doesn't require a specific
USRP (or any USRP) to do such testing ... - MLD
On Wed, Oct 17, 2018, at 7:38 AM, dapodun nudopad via USRP-users wrote:> Hi,
> I am trying to use usrp N210 in a system running ubuntu16.04 for rx-
> ofdm in gnuradio while using TX/RX antenna but i get the following
> error below.> linux; GNU C++ version 5.4.0 20160609; Boost_105800; 
> UHD_003.010.001.HEAD-0-
> g929e3b32> 
> -- Opening a USRP2/N-Series device...
> -- Current recv frame size: 1472 bytes
> -- Current send frame size: 1472 bytes
> -- Detecting internal GPSDO No GPSDO found
> 
> UHD Warning:
> Unable to set the thread priority. Performance may be negatively
> affected.> Please see the general application notes in the manual for
> instructions.> EnvironmentError: OSError: error in 
> pthread_setschedparam
> Press Enter to quit: INFO: Detected an invalid packet at item 0
> INFO: Parser returned #f
> INFO: Detected an invalid packet at item 48
> INFO: Parser returned #f
> INFO: Detected an invalid packet at item 96
> INFO: Parser returned #f
> INFO: Detected an invalid packet at item 144
> INFO: Parser returned #f
> I have read many possibilities on how to fix this error but all came
> to not solving this. the flow graph is attached hereby. Could anyone
> Please suggest anything i can do so i can transmit and receive using
> two different systems running on ubuntu16.04> 
> _
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> Email had 1 attachment:


>  * Screenshot from 2018-10-17 19-35-59.png 83k (image/png)
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] getting parser error with uhd-usrp for rx-ofdm example

[dapodun nudopad via USRP-users]

Hi,
I am trying to use usrp N210 in a system running ubuntu16.04 for rx-ofdm in
gnuradio while using TX/RX antenna but i get the following error below.
linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_003.010.001.HEAD-0-g929e3b32

-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
-- Detecting internal GPSDO No GPSDO found

UHD Warning:
Unable to set the thread priority. Performance may be negatively
affected.
Please see the general application notes in the manual for instructions.
EnvironmentError: OSError: error in pthread_setschedparam
Press Enter to quit: INFO: Detected an invalid packet at item 0
INFO: Parser returned #f
INFO: Detected an invalid packet at item 48
INFO: Parser returned #f
INFO: Detected an invalid packet at item 96
INFO: Parser returned #f
INFO: Detected an invalid packet at item 144
INFO: Parser returned #f
I have read many possibilities on how to fix this error but all came to not
solving this. the flow graph is attached hereby. Could anyone Please
suggest anything i can do so i can transmit and receive using two different
systems running on ubuntu16.04
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com