date:20171024

Re: [USRP-users] UHD 3.10.2 | X300 - High CPU load even for low samples rate

2017-10-24 Thread Kai-Uwe Storek via USRP-users

Is there something else I can in order to support the investigation of
the problem? Is it useful to open a new issue on github?

2017-10-20 19:23 GMT+02:00 Marcus D. Leech via USRP-users
:
> On 10/20/2017 04:20 AM, Kai-Uwe Storek via USRP-users wrote:
>>
>> Hey Marcus and Brent,
>>
>> thanks for suggestions. I'm not working in a VM.
>>
>> The benchmark tool underpins the behaviour:
>>
>> If I use the UHD version of the debian distribution, everything seems
>> normal:
>
> Interesting.  This is definitely something to be followed up on.
>
> I took a closer look at my own FG in this context, and indeed one of the
> CPUs is completely pegged.
>
>
>
>>
>> --
>> /usr/lib/uhd/examples % ./benchmark_rate --args="address=192.168.10.2"
>> --rx_rate 20e6 --tx_rate 20e6
>> linux; GNU C++ version 6.3.0 20170221; Boost_106200;
>> UHD_003.009.005-0-unknown
>>
>>
>> Creating the usrp device with: address=192.168.10.2...
>> -- X300 initialization sequence...
>> -- Determining maximum frame size... 1472 bytes.
>> -- Setup basic communication...
>> -- Loading values from EEPROM...
>> -- Setup RF frontend clocking...
>> -- Radio 1x clock:200
>> -- Initialize Radio0 control...
>> -- Performing register loopback test... pass
>> -- Initialize Radio1 control...
>> -- Performing register loopback test... pass
>> Using Device: Single USRP:
>>Device: X-Series Device
>>Mboard 0: X300
>>RX Channel: 0
>>  RX DSP: 0
>>  RX Dboard: A
>>  RX Subdev: WBXv3 RX+GDB
>>RX Channel: 1
>>  RX DSP: 1
>>  RX Dboard: B
>>  RX Subdev: WBXv3 RX+GDB
>>TX Channel: 0
>>  TX DSP: 0
>>  TX Dboard: A
>>  TX Subdev: WBXv3 TX+GDB
>>TX Channel: 1
>>  TX DSP: 1
>>  TX Dboard: B
>>  TX Subdev: WBXv3 TX+GDB
>>
>> Setting device timestamp to 0...
>> Testing receive rate 20.00 Msps on 1 channels
>> Testing transmit rate 20.00 Msps on 1 channels
>> UUU
>> Benchmark rate summary:
>>Num received samples:200137060
>>Num dropped samples: 0
>>Num overflows detected:  0
>>Num transmitted samples: 200114096
>>Num sequence errors: 0
>>Num underflows detected: 3
>>Num late commands:   0
>>Num timeouts:0
>>
>>
>> Done!
>> --
>>
>>
>> If I use the the maint version:
>>
>> --
>> ~/gr_prefixes/stable/lib/uhd/examples % ./benchmark_rate
>> --args="address=192.168.10.2" --rx_rate 20e6 --tx_rate 20e6
>> linux; GNU C++ version 6.3.0 20170516; Boost_106200;
>> UHD_003.010.002.000-3-g122bfae1
>>
>>
>> Creating the usrp device with: address=192.168.10.2...
>> -- X300 initialization sequence...
>> -- Determining maximum frame size... 1472 bytes.
>> -- Setup basic communication...
>> -- Loading values from EEPROM...
>> -- Setup RF frontend clocking...
>> -- Radio 1x clock:200
>> -- Detecting internal GPSDO No GPSDO found
>> -- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1296.0MB/s)
>> -- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1299.4MB/s)
>> -- [RFNoC Radio] Performing register loopback test... pass
>> -- [RFNoC Radio] Performing register loopback test... pass
>> -- [RFNoC Radio] Performing register loopback test... pass
>> -- [RFNoC Radio] Performing register loopback test... pass
>> -- Performing timer loopback test... pass
>> -- Performing timer loopback test... pass
>> Using Device: Single USRP:
>>Device: X-Series Device
>>Mboard 0: X300
>>RX Channel: 0
>>  RX DSP: 0
>>  RX Dboard: A
>>  RX Subdev: WBXv3 RX+GDB
>>RX Channel: 1
>>  RX DSP: 0
>>  RX Dboard: B
>>  RX Subdev: WBXv3 RX+GDB
>>TX Channel: 0
>>  TX DSP: 0
>>  TX Dboard: A
>>  TX Subdev: WBXv3 TX+GDB
>>TX Channel: 1
>>  TX DSP: 0
>>  TX Dboard: B
>>  TX Subdev: WBXv3 TX+GDB
>>
>> Setting device timestamp to 0...
>> Testing receive rate 20.00 Msps on 1 channels
>> Testing transmit rate 20.00 Msps on 1 channels
>> Receiver error: ERROR_CODE_TIMEOUT, continuing...
>> Receiver error: ERROR_CODE_TIMEOUT, continuing...
>> Receiver error: ERROR_CODE_TIMEOUT, continuing...
>> Receiver error: ERROR_CODE_TIMEOUT, continuing...
>> UDOReceiver error: ERROR_CODE_TIMEOUT, continuing...
>> Receiver error: ERROR_CODE_TIMEOUT, continuing...
>> Receiver error: ERROR_CODE_TIMEOUT, continuing...
>> Receiver error: ERROR_CODE_TIMEOUT, continuing...
>> Receiver error: ERROR_CODE_TIMEOUT, continuing...
>> Receiver error: ERROR_CODE_TIMEOUT, continuing...
>> Receiver error: ERROR_CODE_TIMEOUT, continuing...
>> Receiver error: ERROR_CODE_TIMEOUT, continuing...
>> Receiver error: ERROR_CODE_TIMEOUT, continuing...
>> Receiver error: ERROR_CODE_TIMEOUT, continuing...
>> Receiver error: ERROR_CODE_TIMEOUT, continuing...
>> Receiver error: ERROR_CODE_TIMEOUT, continuing...
>>
>> UHD Error:
>>  x300 fw communication failure #1
>>  EnvironmentError: IOError: x300 fw poke32 - reply

[USRP-users] IQ samples being lost/dropped when using SOB/EOB

2017-10-24 Thread Felipe Augusto Pereira de Figueiredo via USRP-users

Dear All,

I'm sending OFDM frames in a bursty manner, i.e., a have slots of 1 ms with
14 OFDM symbols.

These 1 ms slots are transmitted from time to time and I'm using SOB and
EOB to make it a busrty transmission.

What I have noticed is that some samples at the beginning of the slot are
being missed somehow. In order to solve it I had to pad 1000 zero IQ
samples to the beginning of the slot, only after that I started receiving
the slots correctly, however, now I have lots of "U" characters being
printed on the screen.

Is there some issue with the current UHD (host source or FPGA source) that
might be causing that problem?

I have tried with different UHD versions and the issue happen with all of
them:

- UHD_003.009.005-0-unknown
- UHD_003.010.002.000-3-g122bfae1
- UHD_4.0.0.rfnoc-devel-369-g1908672f

Could you guys, please, help me understand/solve this problem?

Many thanks and Kind Regards,

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

Re: [USRP-users] Underflows with simple rx/tx GNU Radio flowgraph on USRP X310 under RFNOC UHD

2017-10-24 Thread Piotr Krysik via USRP-users

W dniu 22.10.2017 o 12:04, Piotr Krysik via USRP-users pisze:
> Hi all,
>
> I'm prepared a basic GNU Radio flow-graph that does simultaneous
> transmission and reception (see the attachment). For USRP X310 and RFNOC
> UHD (version above 3.10.x) soon after starting the flow-graph there is a
> lot of buffer underflows (even for low sample rate like 1MS/s). For
> pre-RFNOC UHD (3.9.6) everything works fine.
>
> What is a bit strange is that txrx_loopback_to_file UHD example works
> fine for all versions of UHD.
>
> Is anybody here able to run GNU Radio flow-graphs with simultaneous tx
> and rx on X310 with RFNOC UHD and without underflows?
Little update:
I've got the issue only on 10 gigabit ethernet interface. For the 1
gigabit one it works well.
So it might be fault of my particular setup.

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

Re: [USRP-users] UHD 3.10.2 | X300 - High CPU load even for low samples rate

2017-10-24 Thread Michael West via USRP-users

Hi Kai,

The increased CPU usage is expected.  It was done intentionally to make the
UHD code more responsive to flow control messages in order to avoid
underruns at higher sample rates.  Appropriate yields were put in place to
avoid starvation.  What is not expected are the dropped packet (D) and
receive timeout errors.  Can you reproduce the errors by running just the
RX side (./benchmark_rate --args="address=192.168.10.2" --rx_rate 20e6)?

Regards,
Michael

On Tue, Oct 24, 2017 at 5:40 AM, Kai-Uwe Storek via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Is there something else I can in order to support the investigation of
> the problem? Is it useful to open a new issue on github?
>
> 2017-10-20 19:23 GMT+02:00 Marcus D. Leech via USRP-users
> :
> > On 10/20/2017 04:20 AM, Kai-Uwe Storek via USRP-users wrote:
> >>
> >> Hey Marcus and Brent,
> >>
> >> thanks for suggestions. I'm not working in a VM.
> >>
> >> The benchmark tool underpins the behaviour:
> >>
> >> If I use the UHD version of the debian distribution, everything seems
> >> normal:
> >
> > Interesting.  This is definitely something to be followed up on.
> >
> > I took a closer look at my own FG in this context, and indeed one of the
> > CPUs is completely pegged.
> >
> >
> >
> >>
> >> --
> >> /usr/lib/uhd/examples % ./benchmark_rate --args="address=192.168.10.2"
> >> --rx_rate 20e6 --tx_rate 20e6
> >> linux; GNU C++ version 6.3.0 20170221; Boost_106200;
> >> UHD_003.009.005-0-unknown
> >>
> >>
> >> Creating the usrp device with: address=192.168.10.2...
> >> -- X300 initialization sequence...
> >> -- Determining maximum frame size... 1472 bytes.
> >> -- Setup basic communication...
> >> -- Loading values from EEPROM...
> >> -- Setup RF frontend clocking...
> >> -- Radio 1x clock:200
> >> -- Initialize Radio0 control...
> >> -- Performing register loopback test... pass
> >> -- Initialize Radio1 control...
> >> -- Performing register loopback test... pass
> >> Using Device: Single USRP:
> >>Device: X-Series Device
> >>Mboard 0: X300
> >>RX Channel: 0
> >>  RX DSP: 0
> >>  RX Dboard: A
> >>  RX Subdev: WBXv3 RX+GDB
> >>RX Channel: 1
> >>  RX DSP: 1
> >>  RX Dboard: B
> >>  RX Subdev: WBXv3 RX+GDB
> >>TX Channel: 0
> >>  TX DSP: 0
> >>  TX Dboard: A
> >>  TX Subdev: WBXv3 TX+GDB
> >>TX Channel: 1
> >>  TX DSP: 1
> >>  TX Dboard: B
> >>  TX Subdev: WBXv3 TX+GDB
> >>
> >> Setting device timestamp to 0...
> >> Testing receive rate 20.00 Msps on 1 channels
> >> Testing transmit rate 20.00 Msps on 1 channels
> >> UUU
> >> Benchmark rate summary:
> >>Num received samples:200137060
> >>Num dropped samples: 0
> >>Num overflows detected:  0
> >>Num transmitted samples: 200114096
> >>Num sequence errors: 0
> >>Num underflows detected: 3
> >>Num late commands:   0
> >>Num timeouts:0
> >>
> >>
> >> Done!
> >> --
> >>
> >>
> >> If I use the the maint version:
> >>
> >> --
> >> ~/gr_prefixes/stable/lib/uhd/examples % ./benchmark_rate
> >> --args="address=192.168.10.2" --rx_rate 20e6 --tx_rate 20e6
> >> linux; GNU C++ version 6.3.0 20170516; Boost_106200;
> >> UHD_003.010.002.000-3-g122bfae1
> >>
> >>
> >> Creating the usrp device with: address=192.168.10.2...
> >> -- X300 initialization sequence...
> >> -- Determining maximum frame size... 1472 bytes.
> >> -- Setup basic communication...
> >> -- Loading values from EEPROM...
> >> -- Setup RF frontend clocking...
> >> -- Radio 1x clock:200
> >> -- Detecting internal GPSDO No GPSDO found
> >> -- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1296.0MB/s)
> >> -- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1299.4MB/s)
> >> -- [RFNoC Radio] Performing register loopback test... pass
> >> -- [RFNoC Radio] Performing register loopback test... pass
> >> -- [RFNoC Radio] Performing register loopback test... pass
> >> -- [RFNoC Radio] Performing register loopback test... pass
> >> -- Performing timer loopback test... pass
> >> -- Performing timer loopback test... pass
> >> Using Device: Single USRP:
> >>Device: X-Series Device
> >>Mboard 0: X300
> >>RX Channel: 0
> >>  RX DSP: 0
> >>  RX Dboard: A
> >>  RX Subdev: WBXv3 RX+GDB
> >>RX Channel: 1
> >>  RX DSP: 0
> >>  RX Dboard: B
> >>  RX Subdev: WBXv3 RX+GDB
> >>TX Channel: 0
> >>  TX DSP: 0
> >>  TX Dboard: A
> >>  TX Subdev: WBXv3 TX+GDB
> >>TX Channel: 1
> >>  TX DSP: 0
> >>  TX Dboard: B
> >>  TX Subdev: WBXv3 TX+GDB
> >>
> >> Setting device timestamp to 0...
> >> Testing receive rate 20.00 Msps on 1 channels
> >> Testing transmit rate 20.00 Msps on 1 channels
> >> Receiver error: ERROR_CODE_TIMEOUT, continuing...
> >> Receiver error: ERROR_CODE_TIMEOUT, continuing...
> >> Receiver error: ERROR_CODE_T

[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

2017-10-24 Thread 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] 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

2017-10-24 Thread Marcus D. Leech via USRP-users

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 
> 
> [1]
> Virus-free. www.avast.com [1]
> 
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
 

Links:
--
[1]
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] UHD Freezing after Underruns/Late Samples and Freezing

2017-10-24 Thread Richard Mcallister via USRP-users

Hi all,

I used Pybombs to update UHD to master and still had the same issue. That
would be UHD master and the rfnoc-devel branches I both tried.

-Rich

On Fri, Oct 20, 2017 at 8:28 PM, Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 10/20/2017 07:25 PM, Richard Mcallister via USRP-users wrote:
>
> Hi all,
>
> I'm currently using 4 X310's with LFTXs to transmit. The flowgraph hasn't
> changed from last semester when I made it, but its attached. When I run it
> with more than one USRP, it will eventually crash and freeze. UHD will
> output a single U (underrun) and then continuously print L (late sample?).
> With 4 USRPs, this will happen almost immediately.
>
>  I've tried running it on a different computer after system monitor showed
> that (roughly) for each USRP being used, one of the 16 cores would go to
> around 100% while the others stayed low. I also tried changing the Ethernet
> cable, with no success. No success. I've also tried using ethtool to add
> more TX/RX descriptors, and I've raised the sysctl rmem/wmem buffers as UHD
> indicates. Does anyone else have any good suggestions on what to try?
>
> Thanks,
>
> Rich McAllister
>
>
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> What version of UHD?
>
> You're using a 1GiGe interface to your X310s?
>
>
>
> ___
> 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

Re: [USRP-users] UHD 3.10.2 | X300 - High CPU load even for low samples rate

2017-10-24 Thread Michael West via USRP-users

Hi Kai,

One more thing.  To reduce the CPU load, you can try playing around with
the timeout parameter on this call:
https://github.com/EttusResearch/uhd/blob/maint/host/lib/usrp/device3/device3_io_impl.cpp#L357

Try increasing it from 1us to something like 10ms or more.  That controls
the timeout for the poll() call when waiting for a flow control packet.  On
the To Do list is to make that timeout value a function of the TX rate so
lower rates will have reduced CPU load and higher rates will be more
responsive.

Regards,
Michael

On Tue, Oct 24, 2017 at 10:19 AM, Michael West 
wrote:

> Hi Kai,
>
> The increased CPU usage is expected.  It was done intentionally to make
> the UHD code more responsive to flow control messages in order to avoid
> underruns at higher sample rates.  Appropriate yields were put in place to
> avoid starvation.  What is not expected are the dropped packet (D) and
> receive timeout errors.  Can you reproduce the errors by running just the
> RX side (./benchmark_rate --args="address=192.168.10.2" --rx_rate 20e6)?
>
> Regards,
> Michael
>
> On Tue, Oct 24, 2017 at 5:40 AM, Kai-Uwe Storek via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Is there something else I can in order to support the investigation of
>> the problem? Is it useful to open a new issue on github?
>>
>> 2017-10-20 19:23 GMT+02:00 Marcus D. Leech via USRP-users
>> :
>> > On 10/20/2017 04:20 AM, Kai-Uwe Storek via USRP-users wrote:
>> >>
>> >> Hey Marcus and Brent,
>> >>
>> >> thanks for suggestions. I'm not working in a VM.
>> >>
>> >> The benchmark tool underpins the behaviour:
>> >>
>> >> If I use the UHD version of the debian distribution, everything seems
>> >> normal:
>> >
>> > Interesting.  This is definitely something to be followed up on.
>> >
>> > I took a closer look at my own FG in this context, and indeed one of the
>> > CPUs is completely pegged.
>> >
>> >
>> >
>> >>
>> >> --
>> >> /usr/lib/uhd/examples % ./benchmark_rate --args="address=192.168.10.2"
>> >> --rx_rate 20e6 --tx_rate 20e6
>> >> linux; GNU C++ version 6.3.0 20170221; Boost_106200;
>> >> UHD_003.009.005-0-unknown
>> >>
>> >>
>> >> Creating the usrp device with: address=192.168.10.2...
>> >> -- X300 initialization sequence...
>> >> -- Determining maximum frame size... 1472 bytes.
>> >> -- Setup basic communication...
>> >> -- Loading values from EEPROM...
>> >> -- Setup RF frontend clocking...
>> >> -- Radio 1x clock:200
>> >> -- Initialize Radio0 control...
>> >> -- Performing register loopback test... pass
>> >> -- Initialize Radio1 control...
>> >> -- Performing register loopback test... pass
>> >> Using Device: Single USRP:
>> >>Device: X-Series Device
>> >>Mboard 0: X300
>> >>RX Channel: 0
>> >>  RX DSP: 0
>> >>  RX Dboard: A
>> >>  RX Subdev: WBXv3 RX+GDB
>> >>RX Channel: 1
>> >>  RX DSP: 1
>> >>  RX Dboard: B
>> >>  RX Subdev: WBXv3 RX+GDB
>> >>TX Channel: 0
>> >>  TX DSP: 0
>> >>  TX Dboard: A
>> >>  TX Subdev: WBXv3 TX+GDB
>> >>TX Channel: 1
>> >>  TX DSP: 1
>> >>  TX Dboard: B
>> >>  TX Subdev: WBXv3 TX+GDB
>> >>
>> >> Setting device timestamp to 0...
>> >> Testing receive rate 20.00 Msps on 1 channels
>> >> Testing transmit rate 20.00 Msps on 1 channels
>> >> UUU
>> >> Benchmark rate summary:
>> >>Num received samples:200137060
>> >>Num dropped samples: 0
>> >>Num overflows detected:  0
>> >>Num transmitted samples: 200114096
>> >>Num sequence errors: 0
>> >>Num underflows detected: 3
>> >>Num late commands:   0
>> >>Num timeouts:0
>> >>
>> >>
>> >> Done!
>> >> --
>> >>
>> >>
>> >> If I use the the maint version:
>> >>
>> >> --
>> >> ~/gr_prefixes/stable/lib/uhd/examples % ./benchmark_rate
>> >> --args="address=192.168.10.2" --rx_rate 20e6 --tx_rate 20e6
>> >> linux; GNU C++ version 6.3.0 20170516; Boost_106200;
>> >> UHD_003.010.002.000-3-g122bfae1
>> >>
>> >>
>> >> Creating the usrp device with: address=192.168.10.2...
>> >> -- X300 initialization sequence...
>> >> -- Determining maximum frame size... 1472 bytes.
>> >> -- Setup basic communication...
>> >> -- Loading values from EEPROM...
>> >> -- Setup RF frontend clocking...
>> >> -- Radio 1x clock:200
>> >> -- Detecting internal GPSDO No GPSDO found
>> >> -- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1296.0MB/s)
>> >> -- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1299.4MB/s)
>> >> -- [RFNoC Radio] Performing register loopback test... pass
>> >> -- [RFNoC Radio] Performing register loopback test... pass
>> >> -- [RFNoC Radio] Performing register loopback test... pass
>> >> -- [RFNoC Radio] Performing register loopback test... pass
>> >> -- Performing timer loopback test... pass
>> >> -- Performing timer loopback test... pass
>> >> Using Device: Single USRP:
>> >>Device: X-Series

[USRP-users] Fwd: Removing DC offset on USRP B200

2017-10-24 Thread Oliver Wayne via USRP-users

Apologies for not forwarding to the full list. I'm attempting to run the
attached flowgraph with the following hardware, but getting underflows.

I have 8 GB of RAM, so don't think that's a problem. Running lspci | grep
-i usb, I get the following output

00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset
Family USB Enhanced Host Controller #2 (rev 04)
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset
Family USB Enhanced Host Controller #1 (rev 04)

I've attached a copy of cpuinfo.

Thanks!
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 42
model name  : Intel(R) Xeon(R) CPU E31240 @ 3.30GHz
stepping: 7
microcode   : 0x17
cpu MHz : 1612.617
cache size  : 8192 KB
physical id : 0
siblings: 8
core id : 0
cpu cores   : 4
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm 
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc 
aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 
cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave 
avx lahf_lm epb tpr_shadow vnmi flexpriority ept vpid xsaveopt dtherm ida arat 
pln pts
bugs:
bogomips: 6584.96
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 42
model name  : Intel(R) Xeon(R) CPU E31240 @ 3.30GHz
stepping: 7
microcode   : 0x17
cpu MHz : 1599.855
cache size  : 8192 KB
physical id : 0
siblings: 8
core id : 1
cpu cores   : 4
apicid  : 2
initial apicid  : 2
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm 
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc 
aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 
cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave 
avx lahf_lm epb tpr_shadow vnmi flexpriority ept vpid xsaveopt dtherm ida arat 
pln pts
bugs:
bogomips: 6584.96
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor   : 2
vendor_id   : GenuineIntel
cpu family  : 6
model   : 42
model name  : Intel(R) Xeon(R) CPU E31240 @ 3.30GHz
stepping: 7
microcode   : 0x17
cpu MHz : 1601.917
cache size  : 8192 KB
physical id : 0
siblings: 8
core id : 2
cpu cores   : 4
apicid  : 4
initial apicid  : 4
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm 
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc 
aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 
cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave 
avx lahf_lm epb tpr_shadow vnmi flexpriority ept vpid xsaveopt dtherm ida arat 
pln pts
bugs:
bogomips: 6584.96
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor   : 3
vendor_id   : GenuineIntel
cpu family  : 6
model   : 42
model name  : Intel(R) Xeon(R) CPU E31240 @ 3.30GHz
stepping: 7
microcode   : 0x17
cpu MHz : 1607.074
cache size  : 8192 KB
physical id : 0
siblings: 8
core id : 3
cpu cores   : 4
apicid  : 6
initial apicid  : 6
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm 
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc 
aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 
cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave 
avx lahf_lm epb tpr_shadow vnmi flexpriority ept vpid xsaveopt dtherm ida arat 
pln pts
bugs:
bogomips: 6584.96
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor   : 4
vendor_id   : GenuineIntel
cpu family  : 6
model   : 42
model name  : Intel(R)

[USRP-users] Help in building pfb channelizer

2017-10-24 Thread Snehasish Kar via USRP-users

Hello


I am trying to build and use the pfb channelizer in the directory 
fpga/usrp3/lib/rfnoc/
 . Please let help me how do I build an FPGA image out of it. And  after 
building how do I set the various parameters like center frequency, sample 
rate, bandwidth and filter to it.


BR

Snehasish


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

Re: [USRP-users] Fwd: Removing DC offset on USRP B200

2017-10-24 Thread Marcus D. Leech via USRP-users

You could perhaps do a "perf top" and see what's consuming time. 

The Gnu Radio signal source blocks are not screamingly efficient, so it
may be that they just aren't keeping up, although at 4Msps, you wouldn't
expect them to be too stressed. 

On 2017-10-24 15:12, Oliver Wayne via USRP-users wrote:

> Apologies for not forwarding to the full list. I'm attempting to run the 
> attached flowgraph with the following hardware, but getting underflows. 
> 
> I have 8 GB of RAM, so don't think that's a problem. Running lspci | grep -i 
> usb, I get the following output 
> 
> 00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family 
> USB Enhanced Host Controller #2 (rev 04) 
> 00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family 
> USB Enhanced Host Controller #1 (rev 04) 
> 
> I've attached a copy of cpuinfo. 
> 
> Thanks! 
> 
> ___
> 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

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

2017-10-24 Thread John Shields via USRP-users

Thanks Marcus,
So it appears that the synching of the SBX LOs doesn’t 
work; or perhaps I should say, it doesn’t work during my measurement period? 
The integer-N tuning doesn’t work either.

I can say that, with some level of precision, the phase 
is fairly constant with center-frequency but if, for example, I had a 5 MHz 
spectrum how could I ‘correct for that’? I be;ieve that there is the whole 
Hilbert transform issue when you wish to translate the phase/frequency of a 
band of signals to a different one –is that what I should use?

From my point of view, there is quite a 
misinterpretation of what ‘synchronistation’ means; in particular for SBXs and 
their LOs which, as advertised, are supposed to be capable of such operation 
with a 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

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

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

2017-10-24 Thread Marcus D. Leech via USRP-users


On 10/24/2017 07:45 PM, John Shields wrote:

Thanks Marcus,
So it appears that the synching of the SBX LOs 
doesn’t work; or perhaps I should say, it doesn’t work during my 
measurement period? The integer-N tuning doesn’t work either.
I can say that, with some level of precision, 
the phase is fairly constant with center-frequency but if, for 
example, I had a 5 MHz spectrum how could I ‘correct for that’? I 
be;ieve that there is the whole Hilbert transform issue when you wish 
to translate the phase/frequency of a band of signals to a different 
one –is that what I should use?
From my point of view, there is quite a 
misinterpretation of what ‘synchronistation’ means; in particular for 
SBXs and their LOs which, as advertised, are supposed to be capable of 
such operation with a 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 th

[USRP-users] TCP/IP can't ping using N210

2017-10-24 Thread Sarah Tran via USRP-users

Hi everyone!


I am trying to use the example tunnel.py in 
~/gnuradio/gr-digital/examples/ofdm. I have two N210's connected to two 
separate Linux computers, and I am using the following settings:


Machine A (TX):

sudo ./tunnel.py --freq 5e9 --verbose

opened another terminal

sudo ifconfig gr0 192.168.200.1


Machine B (RX):

sudo ./tunnel.py --freq 5e9 --verbose

opened another terminal

sudo ifconfig gr0 192.168.200.2


Unfortunately when I try to ping either machine, it does not work. Does anyone 
have any idea where I could be going wrong? Or am i missing something? I have 
seen others ask similar questions in the past, but it doesn't look like it has 
gotten resolved yet.


Thank you for your time!


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

[USRP-users] set_processor_affinity for python block

2017-10-24 Thread john liu via USRP-users

Dear all,
We write a python block based gr-sync,everything ok,but which can
not set_processor_affinity.error as below:
object has no attribute 'set_processor_affinity'
So we need other special settings?

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

Re: [USRP-users] UHD 3.10.2 | X300 - High CPU load even for low samples rate

[USRP-users] IQ samples being lost/dropped when using SOB/EOB

Re: [USRP-users] Underflows with simple rx/tx GNU Radio flowgraph on USRP X310 under RFNOC UHD

Re: [USRP-users] UHD 3.10.2 | X300 - High CPU load even for low samples rate

[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

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

Re: [USRP-users] UHD Freezing after Underruns/Late Samples and Freezing

Re: [USRP-users] UHD 3.10.2 | X300 - High CPU load even for low samples rate

[USRP-users] Fwd: Removing DC offset on USRP B200

[USRP-users] Help in building pfb channelizer

Re: [USRP-users] Fwd: Removing DC offset on USRP B200

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

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

[USRP-users] TCP/IP can't ping using N210

[USRP-users] set_processor_affinity for python block

15 matches

Site Navigation

Mail list logo

Footer information