Re: [USRP-users] TwinRX: +/-90 degree phase jumps between channels of different daughter-boards

[Piotr Krysik via USRP-users]

Hi Kevin,

I got inverted spectrum (that means sign of I or Q is changed) when I
only set the frequency with use of timed commands. I described the
ranges in the original post. We did measurements in 100-500MHz band. You
can see phase difference between two TwinRXes here:
https://imgur.com/4C09MSf

Slight change of frequency didin't seem to help. I.e. in whole
128-172MHz the phase difference was continuous, then there was ~90
degree discontinuity at 172MHz, then at 245MHz there was another with
opposite sign and so on.

I don't know what might be causing this. After looking at the diagram of
TwinRX there doesn't seem to be any circuit that might do such changes
of the LO phase. Maybe something in the FPGA. I'm puzzled...

Best Regards,
Piotr Krysik

W dniu 04.04.2019 o 23:00, Rigney, Kevin E via USRP-users pisze:
> Pitor:
>
> We've seen a similar issue and have worked around it by just using a slightly 
> different frequency. Can you post the frequencies that you're seeing it on? I 
> think Ettus should be able to duplicate. I saw an issue with spectral 
> inversion (I think I and Q are getting swapped somewhere) at 2.8GHz but not 
> 2.9GHz.
>
> -Kevin
>  
> On 4/4/19, 12:00 PM, "USRP-users on behalf of 
> usrp-users-requ...@lists.ettus.com"  behalf of usrp-users-requ...@lists.ettus.com> wrote:
>
> Hi,
> 
> After disconnecting LO cables signal on the daughter-board that imports
> LOs disappears. So GNU Radio correctly configures distribution of LOs.
> Also the +/- 90 degree changes happen completely deterministically in
> given ranges of carrier frequencies.
> 
> So the question remains open: what is causing the issue described in the
> first post of this thread?
> 
> --
> Best Regards,
> Piotr Krysik
> 
> W dniu 03.04.2019 o?12:15, Fabian Schwartau via USRP-users pisze:
> >Hi,
> >
> >yes, the result for multiple measurements (start ups of the system) at
> >a single frequency was different by multiples of 90?.
> >We did not investigated the problem any further, but I am quite sure
> >that gnuradio was not synchronizing the channels using the LO-sharing,
> >although it was selected. So do the test I described. If you see that
> >he is not using the LO-sharing, you know where to look further.
> >Keep in mind that it is not necessary to use LO-sharing to get a well
> >defined phase relation between the channels. Depending on your
> >frequency and bandwidth settings, it is possible to also achive this,
> >as all LOs are driven from a common 200 MHz reference clock.
> >
> >Best regards,
> >Fabian
> >
> >Am 03.04.2019 um 12:05 schrieb Piotr Krysik via USRP-users:
> >>Hi Fabian,
> >>
> >>W dniu 03.04.2019 o?11:05, Fabian Schwartau via USRP-users pisze:
> >>>Hi Piotr,
> >>>
> >>>we once had a very similar issue. But we also saw this on the same
> >>>frequency when switching between frequencies. Can you try this as
> >>>well? Just switch forth and back between two frequencies and just plot
> >>>one of them?
> >>
> >>I'm not sure I understand correctly what you mean. You mean that the
> >>result for a given frequency was not stable in your case across many
> >>measurements? In our case this situation was repeating, but the
> >>application doing the recording was restarted for each measurement.
> >>
> >>>As far as I remember the issue was because we were not using the
> >>>LO-Sharing. We were able to get everything running by using a C++
> >>>application and not gnuradio (I can see you are using python - which
> >>>is basically the same). There was a bug in gnuradio/python causing
> >>>this issue.
> >>>You can try to remove one of the LO-sharing cables while doing a
> >>>measurement and see if the phase suddenly starts to do crazy things
> >>>(the signal should also be lost). If that is not the case, you are not
> >>>actually using LO-sharing.
> >>>
> >>Do you know what this bug was exactly? GNU Radio didn't configure
> >>LO-Sharing the way it was specified?
> >>
> >>-- 
> >>Best Regards,
> >>Piotr Krysik


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

Re: [USRP-users] PPS to custom RFNoC block

[Cherif Diouf via USRP-users]

Hi Leandro

Thank you for the answer, I will try to go that way and see what will be going 
on.

Cherif

-Original Message-
From: Leandro Echevarría  
Sent: dinsdag 9 april 2019 16:29
To: Cherif Diouf 
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] PPS to custom RFNoC block

Hey Cherif,

I have no experience with this whatsoever, but taking the X310 code as an 
example, I see that PPS is an input signal to x300_core.v, where the RFNoC 
blocks are instantiated. I'd assume you could route this directly to your 
custom block.

Regards,

Leo.

On Tue, Apr 9, 2019 at 6:32 AM Cherif Diouf via USRP-users 
 wrote:
>
> Hello guys,
>
>
> I would like to know how to directly feed my custom
>
> HW RfNoC block by the external PPS signal.
>
>
> Many thanks
>
> Cherif
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



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

Re: [USRP-users] changing frequency on the fly

[Marcus D. Leech via USRP-users]

On 04/10/2019 01:49 AM, Koyel Das (Vehere) via USRP-users wrote:


Hi,


I am streaming data from USRP 2955R from 4 channels. Basic code is 
rx_multisamples.cpp .



1.I want to scan frequencies that is change centre frequency on the 
fly. So do I have to discard some packets after changing frequencies 
so that data from one frequency doesn't enter another frequency data 
buffer? If so how many data samples? Or what precautions have to be 
taken  to avoid data from one frequency entering another frequency 
data buffer?



You'll have to just determine that experimentally.



2.Is there some other precaution I need to take for implementing 
scanning or changing frequencies?



Regards,

Koyel Das

Senior – Product Engineer

Vehere | Proactive Communications Intelligence & Cyber Defence
M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: 
www.vehere.com /

/
/unnamed 
unnamed (1) 
unnamed (2) 



Vehere is the proud recipient of the Fastest Growing Technology 
Company Awards in India & Asia since 2012!/


The content of this e-mail is confidential and intended solely for the 
use of the addressee. The text of this email (including any 
attachments) may contain information, which is proprietary and/or 
confidential or privileged in nature belonging to Vehere Interactive 
Pvt Ltd and/or its associates/ group companies/ subsidiaries. If you 
are not the addressee, or the person responsible for delivering it to 
the addressee, any disclosure, copying, distribution or any action 
taken or omitted to be taken in reliance on it is prohibited and may 
be unlawful. If you have received this e-mail in error, please notify 
the sender and remove this communication entirely from your system. 
The recipient acknowledges that no guarantee or any warranty is given 
as to completeness and accuracy of the content of the email. The 
recipient further acknowledges that the views contained in the email 
message are those of the sender and may not necessarily reflect those 
of Vehere Interactive Pvt Ltd. Before opening and accessing the 
attachment please check and scan for virus. WARNING: Computer viruses 
can be transmitted via email. The recipient should check this email 
and any attachments for the presence of viruses. The company accepts 
no liability for any damage caused by any virus transmitted by this email.



___
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] Subdev spec when BasicRX installed in SlotA and BasicTx in slotB - other slots empty X310

[Michael R. Freedman via USRP-users]

Hello,

Can anyone tell me what the subdev spec should be when there is only one 
BasicRX on one side and a


Basic TX is on the other side.  I am only using the GPIO pins so don't 
care at all about the analog section.



Thanks,

  Mike


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

Re: [USRP-users] Subdev spec when BasicRX installed in SlotA and BasicTx in slotB - other slots empty X310

[Michael R. Freedman via USRP-users]

I believe I answered my own question.  For anyone wondering -


RX subdev spec = A:AB B:0

Tx subdev spec = A:0 B:AB


Mike



On 04/10/2019 11:13 AM, Michael R. Freedman via USRP-users wrote:

Hello,

Can anyone tell me what the subdev spec should be when there is only 
one BasicRX on one side and a


Basic TX is on the other side.  I am only using the GPIO pins so don't 
care at all about the analog section.



Thanks,

  Mike


___
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] rfnoc build for an e320

[Jason Matusiak via USRP-users]

I am looping back to this.  I thought I had things working, but I realized late 
yesterday that my working prefix seemed to be based on a different 
cross-compile environment (by working, I mean building.  I still don't have my 
e320 yet).

After I had it "working,"  I followed my steps again to make sure I really did. 
 That was when I realized I had done something wrong and it still doesn't work. 
 Here is my steps (my error will follow them):
PREFIX=/opt/gnuradio/e320

chmod +x oecore-x86_64-cortexa9hf-neon-toolchain-nodistro.0.sh
sh ./oecore-x86_64-cortexa9hf-neon-toolchain-nodistro.0.sh -y -d $PREFIX
cd $PREFIX
source ./environment-setup-cortexa9hf-neon-oe-linux-gnueabi
mkdir src && cd src

git clone --recursive -b UHD-3.14 https://github.com/EttusResearch/uhd.git
cd uhd
git submodule foreach --recursive git checkout UHD-3.14
cd host && mkdir arm-build && cd arm-build
cmake -DCMAKE_TOOLCHAIN_FILE=../host/cmake/Toolchains/oe-sdk_cross.cmake 
-DCMAKE_INSTALL_PREFIX=/usr -DENABLE_E300=ON -DENABLE_E320=ON -DENABLE_B100=OFF 
-DENABLE_X300=OFF -DENABLE_B200=OFF -DENABLE_USRP1=OFF -DENABLE_USRP2=OFF 
-DENABLE_N300=OFF -DENABLE_OCTOCLOCK=OFF -DENABLE_N230=OFF -DENABLE_N320=OFF 
-DENABLE_DOXYGEN=OFF -DENABLE_MANUAL=OFF -DENABLE_MAN_PAGES=OFF 
-DENABLE_RFNOC=ON ../
make -j32
make install DESTDIR=$PREFIX
make install DESTDIR=$PREFIX/sysroots/cortexa9hf-neon-oe-linux-gnueabi

cd $PREFIX/src
git clone -b v3.7.13.4 --recursive https://github.com/gnuradio/gnuradio.git
cd gnuradio && mkdir arm-build && cd arm-build
cmake -Wno-dev -DCMAKE_TOOLCHAIN_FILE=../cmake/Toolchains/oe-sdk_cross.cmake 
-DENABLE_GR_WXGUI=OFF -DENABLE_GR_VOCODER=OFF -DENABLE_GR_DTV=OFF 
-DENABLE_GR_ATSC=OFF -DENABLE_DOXYGEN=OFF -DCMAKE_INSTALL_PREFIX=/usr ../
make -j32
make install DESTDIR=$PREFIX
make install DESTDIR=$PREFIX/sysroots/cortexa9hf-neon-oe-linux-gnueabi

cd $PREFIX/src
git clone -b master https://github.com/EttusResearch/gr-ettus.git
cd gr-ettus/ && mkdir arm-build && cd arm-build
cmake -Wno-dev 
-DCMAKE_TOOLCHAIN_FILE=$PREFIX/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake 
-DENABLE_DOXYGEN=OFF -DCMAKE_INSTALL_PREFIX=/usr  -DENABLE_QT=OFF ..


And the error:

CMake Error: The following variables are used in this project, but they are set 
to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake 
files:
CPPUNIT_INCLUDE_DIRS (ADVANCED)



I see that there was a commit on 2/25 that made it so that cppunit was 
optional, but I am using the most recent commit (3/7) and that doesn't seem to 
work (I checked and the changes are indeed in the files from that 2/25 
commit).

From: Nate Temple 
Sent: Monday, April 8, 2019 4:03 PM
To: Jason Matusiak
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] rfnoc build for an e320

Hi Jason,

You can disable the QT widgets (not needed on the E320 itself) by adding the 
cmake flag -DENABLE_QT=OFF



Regards,
Nate Temple


On Mon, Apr 8, 2019 at 1:00 PM Nate Temple 
mailto:nate.tem...@ettus.com>> wrote:
Hi Jason,

It looks like you are missing the package: python-setuptools

Note, you should not use rfnoc-devel, but instead use a newer version of UHD 
like v3.14.0.0, and then you can enable RFNoC by adding the cmake flag 
-DENABLE_RFNOC=ON

Regards,
Nate Temple


On Mon, Apr 8, 2019 at 12:34 PM Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
I should be getting an e320 in this week, so I started to get my environment 
setup.  I started off like I do for the e310 and ran the cross-compile shell 
script.  I then sourced the environment.  I cloned uhd and checked out 
rfnoc-devel like I usually do.  Within uhd, I created a folder called 
build_mpm.  Within that, I ran: cmake 
-DCMAKE_TOOLCHAIN_FILE=../host/cmake/Toolchains/oe-sdk_cross.cmake 
-DCMAKE_INSTALL_PREFIX=/usr ../mpm/

That seemed to work OK.  I then ran mak -j12 and it looks like it is done and 
worked, but it actually throws an error at the end:
[ 98%] Linking CXX shared library libpyusrp_periphs.so
[ 98%] Built target pyusrp_periphs
[100%] Generating build/timestamp
Traceback (most recent call last):
  File "/opt/gnuradio/e320/src/uhd/build_mpm/python/setup.py", line 11, in 

from setuptools import setup
ImportError: No module named 'setuptools'
make[2]: *** [python/build/timestamp] Error 1
make[1]: *** [python/CMakeFiles/usrp_mpm.dir/all] Error 2
make: *** [all] Error 2

Is something missing that needs to be built before building UHD?

___
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] OOT RFNoC not building on latest

[Jason Matusiak via USRP-users]

Trying to build a FPGA image with an OOT module is not going well.  I first 
built with standard blocks and that worked, so I know my setup is OK.

I then tried to build with my OOT module (and this used to work on an old 
prefix), but now is erroring out because it can't find my OOT block.  The 
command I am running is:
python uhd_image_builder.py -y 
/opt/gnuradio/e320/src/rfnoc-nocblocks/fpga_build/my_yaml.yml -I 
/opt/gnuradio/e320/src/rfnoc-nocblocks -d e320 -t E320_RFNOC_XG

The error I see is:
ERROR: [Synth 8-439] module 'noc_block_keepMinN' not found 
[/opt/gnuradio/e320/src/uhd/fpga-src/usrp3/top/e320/rfnoc_ce_auto_inst_e320.v:54]
ERROR: [Synth 8-285] failed synthesizing module 'e320_core' 
[/opt/gnuradio/e320/src/uhd/fpga-src/usrp3/top/e320/e320_core.v:17]
ERROR: [Synth 8-285] failed synthesizing module 'e320' 
[/opt/gnuradio/e320/src/uhd/fpga-src/usrp3/top/e320/e320.v:13]
[00:10:22] Current task: Synthesis +++ Current Phase: Starting
ERROR: [Common 17-69] Command failed: Synthesis failed - please see the console 
or run log file for details
[00:10:23] Current task: Synthesis +++ Current Phase: Finished
[00:10:23] Process terminated. Status: Failure

Did something change with the image builder (I am running a newer UHD than I 
used to since this is for an E320)?



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

Re: [USRP-users] OOT RFNoC not building on latest

[Jason Matusiak via USRP-users]

OK, I have a work-around to this for now.  I needed to comment out the two 
lines:
 ${CPPUNIT_INCLUDE_DIRS}
and
 ${CPPUNIT_LIBRARY_DIRS}

on lines 190 and 197 of gr-ettus/CMakeLists.txt.

I guess maybe a check needs to be done so that when it is determined that 
CPPUINIT is getting ignored (like it is in the this case), it doesn't try to 
include it anymore?


From: USRP-users  on behalf of Jason 
Matusiak via USRP-users 
Sent: Wednesday, April 10, 2019 1:23 PM
To: usrp-users@lists.ettus.com
Subject: [USRP-users] OOT RFNoC not building on latest

Trying to build a FPGA image with an OOT module is not going well.  I first 
built with standard blocks and that worked, so I know my setup is OK.

I then tried to build with my OOT module (and this used to work on an old 
prefix), but now is erroring out because it can't find my OOT block.  The 
command I am running is:
python uhd_image_builder.py -y 
/opt/gnuradio/e320/src/rfnoc-nocblocks/fpga_build/my_yaml.yml -I 
/opt/gnuradio/e320/src/rfnoc-nocblocks -d e320 -t E320_RFNOC_XG

The error I see is:
ERROR: [Synth 8-439] module 'noc_block_keepMinN' not found 
[/opt/gnuradio/e320/src/uhd/fpga-src/usrp3/top/e320/rfnoc_ce_auto_inst_e320.v:54]
ERROR: [Synth 8-285] failed synthesizing module 'e320_core' 
[/opt/gnuradio/e320/src/uhd/fpga-src/usrp3/top/e320/e320_core.v:17]
ERROR: [Synth 8-285] failed synthesizing module 'e320' 
[/opt/gnuradio/e320/src/uhd/fpga-src/usrp3/top/e320/e320.v:13]
[00:10:22] Current task: Synthesis +++ Current Phase: Starting
ERROR: [Common 17-69] Command failed: Synthesis failed - please see the console 
or run log file for details
[00:10:23] Current task: Synthesis +++ Current Phase: Finished
[00:10:23] Process terminated. Status: Failure

Did something change with the image builder (I am running a newer UHD than I 
used to since this is for an E320)?



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

[USRP-users] B210 bypass Tx FIR filter

[S Hamilton via USRP-users]

We'd like to bypass the Tx FIR filter and I'm wondering how to go about
this using the C++ api.
For the filter_base_info class there is the is_bypassed() function to read
the state, but no function to set it.
Should we be creating a new filter pointer with bypass set, and then using
it to overwrite the filter via uhd::usrp::multi_usrp::set_filter ?
Does anyone have some sample code that sets the bypass on FIR or HB1/HB2 ?

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

[USRP-users] Max Sample Rate Exceeds Capacity

[Mark Gannet via USRP-users]

I have 4 USRP x310s running at 12.5 MSa/sec on a quad 10GbE network adapter
(each USRP has it's own 10 GbE connection).  I'm using the 16 bit short
format.

I can operate one USRP at a time 100 MSa/sec with no overflows or drops
(200 MSa/sec total for one USRP).  If I want to run all 4 USRP, I can only
achieve 25 MSa/sec for all 8 channels (total of 200 MSa/sec).

Basically the sum of sample rates cannot exceed 200 MSa/sec which is about
6400 Mbps (200*4 bytes/sa * 8 b/B).

Why is this?  I thought with a dedicated 10GbE network port for each USRP,
the sample rate limit would be 100 MSa/sec for each (6400 Mbps).

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

Re: [USRP-users] Max Sample Rate Exceeds Capacity

[Marcus D. Leech via USRP-users]

On 04/10/2019 04:41 PM, Mark Gannet via USRP-users wrote:
I have 4 USRP x310s running at 12.5 MSa/sec on a quad 10GbE network 
adapter (each USRP has it's own 10 GbE connection).  I'm using the 16 
bit short format.


I can operate one USRP at a time 100 MSa/sec with no overflows or 
drops (200 MSa/sec total for one USRP).  If I want to run all 4 USRP, 
I can only achieve 25 MSa/sec for all 8 channels (total of 200 MSa/sec).


Basically the sum of sample rates cannot exceed 200 MSa/sec which is 
about 6400 Mbps (200*4 bytes/sa * 8 b/B).


Why is this?  I thought with a dedicated 10GbE network port for each 
USRP, the sample rate limit would be 100 MSa/sec for each (6400 Mbps).


Thanks,
Mark


What version of UHD are you using?

How are you addressing the USRPs?



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

Re: [USRP-users] Max Sample Rate Exceeds Capacity

[Mark Gannet via USRP-users]

I've addressed the USRP as the following:
USRP[0-3]: 192.168.4x.2, where x=0,1,2,3

UHD 3.9.2

On Wed, Apr 10, 2019 at 1:47 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 04/10/2019 04:41 PM, Mark Gannet via USRP-users wrote:
> > I have 4 USRP x310s running at 12.5 MSa/sec on a quad 10GbE network
> > adapter (each USRP has it's own 10 GbE connection).  I'm using the 16
> > bit short format.
> >
> > I can operate one USRP at a time 100 MSa/sec with no overflows or
> > drops (200 MSa/sec total for one USRP).  If I want to run all 4 USRP,
> > I can only achieve 25 MSa/sec for all 8 channels (total of 200 MSa/sec).
> >
> > Basically the sum of sample rates cannot exceed 200 MSa/sec which is
> > about 6400 Mbps (200*4 bytes/sa * 8 b/B).
> >
> > Why is this?  I thought with a dedicated 10GbE network port for each
> > USRP, the sample rate limit would be 100 MSa/sec for each (6400 Mbps).
> >
> > Thanks,
> > Mark
> >
> What version of UHD are you using?
>
> How are you addressing the USRPs?
>
>
>
> ___
> 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] Max Sample Rate Exceeds Capacity

[Marcus D. Leech via USRP-users]

On 04/10/2019 05:31 PM, Mark Gannet wrote:

I've addressed the USRP as the following:
USRP[0-3]: 192.168.4x.2, where x=0,1,2,3

UHD 3.9.2
You should probably upgrade to a newer UHD version.  There were bugs in 
that area, as I recall, that have since been fixed.




On Wed, Apr 10, 2019 at 1:47 PM Marcus D. Leech via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


On 04/10/2019 04:41 PM, Mark Gannet via USRP-users wrote:
> I have 4 USRP x310s running at 12.5 MSa/sec on a quad 10GbE network
> adapter (each USRP has it's own 10 GbE connection).  I'm using
the 16
> bit short format.
>
> I can operate one USRP at a time 100 MSa/sec with no overflows or
> drops (200 MSa/sec total for one USRP).  If I want to run all 4
USRP,
> I can only achieve 25 MSa/sec for all 8 channels (total of 200
MSa/sec).
>
> Basically the sum of sample rates cannot exceed 200 MSa/sec
which is
> about 6400 Mbps (200*4 bytes/sa * 8 b/B).
>
> Why is this?  I thought with a dedicated 10GbE network port for
each
> USRP, the sample rate limit would be 100 MSa/sec for each (6400
Mbps).
>
> Thanks,
> Mark
>
What version of UHD are you using?

How are you addressing the USRPs?



___
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] Max Sample Rate Exceeds Capacity

[Mark Gannet via USRP-users]

Okay thank you Marcus.

Mark

On Wed, Apr 10, 2019 at 3:09 PM Marcus D. Leech 
wrote:

> On 04/10/2019 05:31 PM, Mark Gannet wrote:
>
> I've addressed the USRP as the following:
> USRP[0-3]: 192.168.4x.2, where x=0,1,2,3
>
> UHD 3.9.2
>
> You should probably upgrade to a newer UHD version.  There were bugs in
> that area, as I recall, that have since been fixed.
>
>
> On Wed, Apr 10, 2019 at 1:47 PM Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On 04/10/2019 04:41 PM, Mark Gannet via USRP-users wrote:
>> > I have 4 USRP x310s running at 12.5 MSa/sec on a quad 10GbE network
>> > adapter (each USRP has it's own 10 GbE connection).  I'm using the 16
>> > bit short format.
>> >
>> > I can operate one USRP at a time 100 MSa/sec with no overflows or
>> > drops (200 MSa/sec total for one USRP).  If I want to run all 4 USRP,
>> > I can only achieve 25 MSa/sec for all 8 channels (total of 200 MSa/sec).
>> >
>> > Basically the sum of sample rates cannot exceed 200 MSa/sec which is
>> > about 6400 Mbps (200*4 bytes/sa * 8 b/B).
>> >
>> > Why is this?  I thought with a dedicated 10GbE network port for each
>> > USRP, the sample rate limit would be 100 MSa/sec for each (6400 Mbps).
>> >
>> > Thanks,
>> > Mark
>> >
>> What version of UHD are you using?
>>
>> How are you addressing the USRPs?
>>
>>
>>
>> ___
>> 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] Max Sample Rate Exceeds Capacity

[Nate Temple via USRP-users]

Hi Mark,

We just merged DPDK support for the X3xx. You can try it out if you build
the current head of master. DPDK may help with 8 channels running at 100
MS/s each.

https://github.com/EttusResearch/uhd/commits/master

https://files.ettus.com/manual/page_dpdk.html

Regards,
Nate Temple


On Wed, Apr 10, 2019 at 3:33 PM Mark Gannet via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Okay thank you Marcus.
>
> Mark
>
> On Wed, Apr 10, 2019 at 3:09 PM Marcus D. Leech 
> wrote:
>
>> On 04/10/2019 05:31 PM, Mark Gannet wrote:
>>
>> I've addressed the USRP as the following:
>> USRP[0-3]: 192.168.4x.2, where x=0,1,2,3
>>
>> UHD 3.9.2
>>
>> You should probably upgrade to a newer UHD version.  There were bugs in
>> that area, as I recall, that have since been fixed.
>>
>>
>> On Wed, Apr 10, 2019 at 1:47 PM Marcus D. Leech via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> On 04/10/2019 04:41 PM, Mark Gannet via USRP-users wrote:
>>> > I have 4 USRP x310s running at 12.5 MSa/sec on a quad 10GbE network
>>> > adapter (each USRP has it's own 10 GbE connection).  I'm using the 16
>>> > bit short format.
>>> >
>>> > I can operate one USRP at a time 100 MSa/sec with no overflows or
>>> > drops (200 MSa/sec total for one USRP).  If I want to run all 4 USRP,
>>> > I can only achieve 25 MSa/sec for all 8 channels (total of 200
>>> MSa/sec).
>>> >
>>> > Basically the sum of sample rates cannot exceed 200 MSa/sec which is
>>> > about 6400 Mbps (200*4 bytes/sa * 8 b/B).
>>> >
>>> > Why is this?  I thought with a dedicated 10GbE network port for each
>>> > USRP, the sample rate limit would be 100 MSa/sec for each (6400 Mbps).
>>> >
>>> > Thanks,
>>> > Mark
>>> >
>>> What version of UHD are you using?
>>>
>>> How are you addressing the USRPs?
>>>
>>>
>>>
>>> ___
>>> 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 mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Max Sample Rate Exceeds Capacity

[Mark Gannet via USRP-users]

Thanks I will look into this.  Right now, I have a modified FPGA HG image
for the x310 along with modified UHD and GNURadio source to handle some
additional inputs to the USRP.  I'd like to try the new UHD, but I will
have to incorporate those changes into the source.  I believe this will
necessitate moving to a newer FPGA image as well but I'm not sure.  Anyway
I may have some upgrading to do across the board if I want to use a newer
UHD.

Thanks,
Mark

On Wed, Apr 10, 2019 at 5:13 PM Nate Temple  wrote:

> Hi Mark,
>
> We just merged DPDK support for the X3xx. You can try it out if you build
> the current head of master. DPDK may help with 8 channels running at 100
> MS/s each.
>
> https://github.com/EttusResearch/uhd/commits/master
>
> https://files.ettus.com/manual/page_dpdk.html
>
> Regards,
> Nate Temple
>
>
> On Wed, Apr 10, 2019 at 3:33 PM Mark Gannet via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Okay thank you Marcus.
>>
>> Mark
>>
>> On Wed, Apr 10, 2019 at 3:09 PM Marcus D. Leech 
>> wrote:
>>
>>> On 04/10/2019 05:31 PM, Mark Gannet wrote:
>>>
>>> I've addressed the USRP as the following:
>>> USRP[0-3]: 192.168.4x.2, where x=0,1,2,3
>>>
>>> UHD 3.9.2
>>>
>>> You should probably upgrade to a newer UHD version.  There were bugs in
>>> that area, as I recall, that have since been fixed.
>>>
>>>
>>> On Wed, Apr 10, 2019 at 1:47 PM Marcus D. Leech via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 On 04/10/2019 04:41 PM, Mark Gannet via USRP-users wrote:
 > I have 4 USRP x310s running at 12.5 MSa/sec on a quad 10GbE network
 > adapter (each USRP has it's own 10 GbE connection).  I'm using the 16
 > bit short format.
 >
 > I can operate one USRP at a time 100 MSa/sec with no overflows or
 > drops (200 MSa/sec total for one USRP).  If I want to run all 4 USRP,
 > I can only achieve 25 MSa/sec for all 8 channels (total of 200
 MSa/sec).
 >
 > Basically the sum of sample rates cannot exceed 200 MSa/sec which is
 > about 6400 Mbps (200*4 bytes/sa * 8 b/B).
 >
 > Why is this?  I thought with a dedicated 10GbE network port for each
 > USRP, the sample rate limit would be 100 MSa/sec for each (6400 Mbps).
 >
 > Thanks,
 > Mark
 >
 What version of UHD are you using?

 How are you addressing the USRPs?



 ___
 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 mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] B210 bypass Tx FIR filter

[Julian Arnold via USRP-users]

Sean,

if I remember correctly, the filter configuration (whether or not a filter is 
bypassed) is determined by the ratio of DAC rate to master-clock rate (the 
interpolation that needs to happen inside the ad9361) thus, you can only 
somewhat,
indirectly, control it by changing the master-clock rate.

However, if you can live with the interpolation inside the FIR, you can 
reprogram the fir taps to whatever suits your needs.

For examples take a look at:

https://github.com/jarn0ld/uhd-filter-tool

Hope that helps.

Cheers,
Julian

Julian Arnold, M.Sc

> On 10. Apr 2019, at 22:30, S Hamilton via USRP-users 
>  wrote:
> 
> We'd like to bypass the Tx FIR filter and I'm wondering how to go about this 
> using the C++ api.
> For the filter_base_info class there is the is_bypassed() function to read 
> the state, but no function to set it.
> Should we be creating a new filter pointer with bypass set, and then using it 
> to overwrite the filter via uhd::usrp::multi_usrp::set_filter ?
> Does anyone have some sample code that sets the bypass on FIR or HB1/HB2 ?
> 
> Thanks,
> Sean Hamilton
> ___
> 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] B210 bypass Tx FIR filter

[Ian Buckley via USRP-users]

Yeah, the driver tries to keep the DAC clock close to it’s max legal frequency 
with the highest possible interpolation ratio from master_clock_rate.
That code doesn’t have any API access but I can show Sean how to hack it into 
UHD if necessary.

> On Apr 10, 2019, at 10:57 PM, Julian Arnold via USRP-users 
>  wrote:
> 
> Sean,
> 
> if I remember correctly, the filter configuration (whether or not a filter is 
> bypassed) is determined by the ratio of DAC rate to master-clock rate (the 
> interpolation that needs to happen inside the ad9361) thus, you can only 
> somewhat,
> indirectly, control it by changing the master-clock rate.
> 
> However, if you can live with the interpolation inside the FIR, you can 
> reprogram the fir taps to whatever suits your needs.
> 
> For examples take a look at:
> 
> https://github.com/jarn0ld/uhd-filter-tool 
> 
> 
> Hope that helps.
> 
> Cheers,
> Julian
> 
> Julian Arnold, M.Sc “The Intern of the month"
> 
> On 10. Apr 2019, at 22:30, S Hamilton via USRP-users 
> mailto:usrp-users@lists.ettus.com>> wrote:
> 
>> We'd like to bypass the Tx FIR filter and I'm wondering how to go about this 
>> using the C++ api.
>> For the filter_base_info class there is the is_bypassed() function to read 
>> the state, but no function to set it.
>> Should we be creating a new filter pointer with bypass set, and then using 
>> it to overwrite the filter via uhd::usrp::multi_usrp::set_filter ?
>> Does anyone have some sample code that sets the bypass on FIR or HB1/HB2 ?
>> 
>> Thanks,
>> Sean Hamilton
>> ___
>> 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 mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com