Re: [USRP-users] creating an rfnoc block on master branch

[Hodges, Jeff via USRP-users]

I also would like to know the answer to Rob’s question:

Rfnocmodtool is in gr-ettus but if I try to install gr-ettus with the uhd 
master branch, I get the following error:


[  5%] Building CXX object lib/CMakeFiles/gnuradio-ettus.dir/device3.cc.o
In file included from /home/nvd/rfnoc/src/gr-ettus/lib/device3.cc:27:0:
/home/nvd/rfnoc/src/gr-ettus/include/ettus/device3.h:30:10: fatal error: 
uhd/device3.hpp: No such file or directory
#include 
  ^
compilation terminated.
lib/CMakeFiles/gnuradio-ettus.dir/build.make:72: recipe for target 
'lib/CMakeFiles/gnuradio-ettus.dir/device3.cc.o' failed
make[2]: *** [lib/CMakeFiles/gnuradio-ettus.dir/device3.cc.o] Error 1
CMakeFiles/Makefile2:139: recipe for target 
'lib/CMakeFiles/gnuradio-ettus.dir/all' failed
make[1]: *** [lib/CMakeFiles/gnuradio-ettus.dir/all] Error 2
Makefile:140: recipe for target 'all' failed
make: *** [all] Error 2


So how does rfnoc work with master branch?


I have also installed UHD-3.15.LTS without PYBOMBS and there were errors that 
have been fixed in the master branch but not UHD-3.15.LTS.

There are no current versions of UHD that work with RFNoC to build OOT without 
the PYBOMBS method.



Jeff

From: USRP-users  On Behalf Of Rob Kossler 
via USRP-users
Sent: Thursday, May 21, 2020 3:19 PM
To: usrp-users 
Subject: [USRP-users] creating an rfnoc block on master branch

Hi,
How do I create an rfnoc block using master branch?  I am familiar with using 
rfnoc_mod_tool with UHD 3.15 and earlier.  My understanding was that things are 
different with master (and uhd 4.0) such that a different tool would be used 
and that this new tool would be part of UHD rather than part of a gnuradio 
installation.  But, I don't see any such tool in my uhd master checkout.
Rob
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] B210 LO signal leakage above 5GHz

[guowang qiu via USRP-users]

Hi Marcus,

Thank you for your reply.
We have tried to set the magnitude of the modulating baseband signal from
0.1 to 0.6, it only affects the single tone signal strength and has no
effect on the LO leakage.

Best regards,
Damon

On Fri, 29 May 2020 at 02:03, Marcus D Leech 
wrote:

> Have you tried adjusting the magnitude of the modulating baseband signal?
> Does that make a difference.
>
> My guess is that the leakage path isn’t through the VGA but rather through
> something else in the package. In which case, no amount of software mods
> will reduce it.
>
> Sent from my iPhone
>
> > On May 28, 2020, at 1:50 PM, guowang qiu via USRP-users <
> usrp-users@lists.ettus.com> wrote:
> >
> > 
> > Hi all,
> >
> > We use USRP b210 as a signal generator, and adjust the tx gain to make
> the tx power from - 90dbm to 0dbm. USRP b210 works fine in 2.4GHz frequency
> band, but it has a very strong LO signal leakage at frequencies higher than
> 5GHz.
> > In my test, the frequency of  baseband (cos signal source) is set to
> 1MHz, so LO signal leakage and single tone signal can be easily
> distinguished. When the tx gain is set from 0 to 30 db, the strength of the
> LO signal hardly changes, and it is higher than the strength of the single
> tone signal. With the increase of tx gain, the strength of single tone
> signal will increase obviously. It seems that the local oscillator signal
> generated by the PLL in ad9361 bypasses the internal adjustable gain power
> amplifier and leaks directly to the antenna port.
> > Is it possible to reduce the local leakage by modifying the UHD source
> code?
> >
> > Best regards,
> > Damon
> > ___
> > 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] many spurs in spectrum scanning with E310

[guowang qiu via USRP-users]

Hi all,
We are using USRP E310 to do spectrum scanning. There are many spurs in the
scanned spectrum, some of which are at integral times of 40MHz and some of
which are unpredictable. We used b210 for comparison, and found that the
spectrum scanned by b210 is much cleaner. Attached please find the pictures
of the scanning results.
The scanning step is set to 40MHz, sample rate is set to 51.2MHz. We also
have tried with other sample rate, and we got similar results.
Is there any way to reduce the spurs in spectrum scanning using E310?

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

Re: [USRP-users] B210 LO signal leakage above 5GHz

[Marcus D Leech via USRP-users]

Have you tried adjusting the magnitude of the modulating baseband signal? Does 
that make a difference. 

My guess is that the leakage path isn’t through the VGA but rather through 
something else in the package. In which case, no amount of software mods will 
reduce it. 

Sent from my iPhone

> On May 28, 2020, at 1:50 PM, guowang qiu via USRP-users 
>  wrote:
> 
> 
> Hi all,
> 
> We use USRP b210 as a signal generator, and adjust the tx gain to make the tx 
> power from - 90dbm to 0dbm. USRP b210 works fine in 2.4GHz frequency band, 
> but it has a very strong LO signal leakage at frequencies higher than 5GHz. 
> In my test, the frequency of  baseband (cos signal source) is set to 1MHz, so 
> LO signal leakage and single tone signal can be easily distinguished. When 
> the tx gain is set from 0 to 30 db, the strength of the LO signal hardly 
> changes, and it is higher than the strength of the single tone signal. With 
> the increase of tx gain, the strength of single tone signal will increase 
> obviously. It seems that the local oscillator signal generated by the PLL in 
> ad9361 bypasses the internal adjustable gain power amplifier and leaks 
> directly to the antenna port.
> Is it possible to reduce the local leakage by modifying the UHD source code?
> 
> Best regards,
> Damon
> ___
> 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 LO signal leakage above 5GHz

[guowang qiu via USRP-users]

Hi all,

We use USRP b210 as a signal generator, and adjust the tx gain to make the
tx power from - 90dbm to 0dbm. USRP b210 works fine in 2.4GHz frequency
band, but it has a very strong LO signal leakage at frequencies higher than
5GHz.
In my test, the frequency of  baseband (cos signal source) is set to 1MHz,
so LO signal leakage and single tone signal can be easily distinguished.
When the tx gain is set from 0 to 30 db, the strength of the LO signal
hardly changes, and it is higher than the strength of the single tone
signal. With the increase of tx gain, the strength of single tone signal
will increase obviously. It seems that the local oscillator signal
generated by the PLL in ad9361 bypasses the internal adjustable gain power
amplifier and leaks directly to the antenna port.
Is it possible to reduce the local leakage by modifying the UHD source code?

Best regards,
Damon
___
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 standard image x310 failing

[Hodges, Jeff via USRP-users]

Thanks for that advice to install UHD-3.15.LTS. I was able to synthesize the 
standard blocks, but I could not synthesize the OOT gain block from the 
tutorial. I get the error message:

ERROR: [Synth 8-439] module 'noc_block_gain' not found 
[/home/nvd/rfnoc/src/uhd/fpga-src/usrp3/top/x300/rfnoc_ce_auto_inst_x310.v:20]

I have installed UHD.3.15-LTS and I had to correct one error in order to get 
the OOT gain block to build from the tutorial website:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2020-May/061991.html

This makes me wonder, if UHD-3.15.LTS has known errors that have been since 
been fixed in the master branch, should I be using the master branch instead? 
Are there plans to update these errors in the UHD-3.15.LTS branch?

The noc_gain_block does appear in the OOT list in uhd_image_builder_gui.py. I 
was able to get the standard blocks to synthesize, but now I cannot get the OOT 
gain block to synthesize. Here’s the output after running uhd_image_builder.py. 
When the gain block is selected in the GUI it adds the the path -I 
/home/nvd/rfnoc/src/rfnoc-tutorial/rfnoc/ which is the correct path to the OOT 
fpga-src/ directory.








--Using the following blocks to generate image:
* gain
* fosphor
* axi_fifo_loopback
* axi_fifo_loopback
* fir_filter
* fft
* window
* ddc
* duc
* siggen
Adding CE instantiation file for 'X310_RFNOC_HG'
No valid makefile found at /home/nvd/rfnoc/src/rfnoc-tutorial/rfnoc
changing temporarily working directory to 
/home/nvd/rfnoc/src/uhd/fpga-src/usrp3/tools/scripts/../../top/x300
Setting up a 64-bit FPGA build environment for the USRP-X3x0...
- Vivado: Found (/opt/Xilinx/Vivado/2018.3/bin)

Environment successfully initialized.
make -f Makefile.x300.inc bin NAME=X310_RFNOC_HG ARCH=kintex7 
PART_ID=xc7k410t/ffg900/-2 BUILD_1G=1 BUILD_10G=1 SFP0_1GBE=1 SFP1_10GBE=1  
RFNOC=1 X310=1 TOP_MODULE=x300 EXTRA_DEFS="BUILD_1G=1 BUILD_10G=1 SFP0_1GBE=1 
SFP1_10GBE=1  RFNOC=1 X310=1"
make[1]: Entering directory '/home/nvd/rfnoc/src/uhd/fpga-src/usrp3/top/x300'
BUILDER: Checking tools...
* GNU bash, version 4.4.20(1)-release (x86_64-pc-linux-gnu)
* Python 2.7.17
* Vivado v2018.3 (64-bit)
Using parser configuration from: 
/home/nvd/rfnoc/src/uhd/fpga-src/usrp3/top/x300/dev_config.json
[00:00:00] Executing command: vivado -mode batch -source 
/home/nvd/rfnoc/src/uhd/fpga-src/usrp3/top/x300/build_x300.tcl -log build.log 
-journal x300.jou
CRITICAL WARNING: [filemgmt 20-1440] File 
'/home/nvd/rfnoc/src/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/ddr3_32bit/ddr3_32bit/user_design/rtl/clocking/mig_7series_v4_2_tempmon.v'
 already exists in the project as a part of sub-design file 
'/home/nvd/rfnoc/src/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/ddr3_32bit/ddr3_32bit.xci'.
 Explicitly adding the file outside the scope of the sub-design can lead to 
unintended behaviors and is not recommended.
[00:00:23] Current task: Initialization +++ Current Phase: Starting
[00:00:23] Current task: Initialization +++ Current Phase: Finished
[00:00:23] Executing Tcl: synth_design -top x300 -part xc7k410tffg900-2 
-verilog_define BUILD_1G=1 -verilog_define BUILD_10G=1 -verilog_define 
SFP0_1GBE=1 -verilog_define SFP1_10GBE=1 -verilog_define RFNOC=1 
-verilog_define X310=1 -verilog_define GIT_HASH=32'hf9fb84a1
[00:00:23] Starting Synthesis Command
ERROR: [Synth 8-439] module 'noc_block_gain' not found 
[/home/nvd/rfnoc/src/uhd/fpga-src/usrp3/top/x300/rfnoc_ce_auto_inst_x310.v:20]
ERROR: [Synth 8-6156] failed synthesizing module 'x300_core' 
[/home/nvd/rfnoc/src/uhd/fpga-src/usrp3/top/x300/x300_core.v:8]
ERROR: [Synth 8-6156] failed synthesizing module 'x300' 
[/home/nvd/rfnoc/src/uhd/fpga-src/usrp3/top/x300/x300.v:20]
ERROR: [Common 17-69] Command failed: Synthesis failed - please see the console 
or run log file for details
[00:07:19] Current task: Synthesis +++ Current Phase: Starting
[00:07:19] Current task: Synthesis +++ Current Phase: Finished
[00:07:19] Process terminated. Status: Failure


Warnings:   158
Critical Warnings:  1
Errors: 4

Makefile.x300.inc:106: recipe for target 'bin' failed
make[1]: *** [bin] Error 1
make[1]: Leaving directory '/home/nvd/rfnoc/src/uhd/fpga-src/usrp3/top/x300'
Makefile:112: recipe for target 'X310_RFNOC_HG' failed
make: *** [X310_RFNOC_HG] Error 2




Thanks,

Jeff


From: USRP-users  On Behalf Of Hodges, Jeff 
via USRP-users
Sent: Thursday, May 21, 2020 11:50 AM
To: Michael Dickens 
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] rfnoc build standard image x310 failing

Ahhh…thanks for that. I was using the method described here to update by tag 
not branch:

https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source

Jeff

From: Michael Dickens 
mailto:michael.dick...@ettus.com>>
Sent: Thursday, May 21, 2020 11:39 AM
To: Hodges, Jeff 
mailto:jeff.ho

Re: [USRP-users] X310: control frontend with custom RFNoC blocks

[Haberleitner David - S1810567006 via USRP-users]

Thanks Sam, Marcus,


The approach with timed commands indeed seems a lot more manageable. We're 
gonna try this first.


From: Marcus D Leech 
Sent: Wednesday, May 27, 2020 7:07 PM
To: Sam Reiter
Cc: Haberleitner David - S1810567006; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] X310: control frontend with custom RFNoC blocks

I don't know that much about RFNOC structure, but the tuning latency is 
dominated by SPI transaction time, and the tome it takes the chips to tune to a 
new frequency.

That is much larger than the host and Ethernet side of things.

Doing what the host does to tune the chips (a bunch of math to set various 
registers) in the FPGA will consume a fair amount of real estate on the FPGA.

Sent from my iPhone

On May 27, 2020, at 12:38 PM, Sam Reiter via USRP-users 
 wrote:

?
David,

Do you know ahead of time what the frequency sweeps are going to be, or do you 
need to have your RFNoC block creating and scheduling them dynamically?

If you know your frequency sweep list ahead of time, a much easier technique 
would be for you to send your tune requests from host to radio as timed 
commands. This way you can queue up hops that will execute at a precise 
timestamp in your data  stream. Depending on the length of your frequency list, 
you may need to expand the size of the command queue in your FPGA image, but 
that would be a much more manageable task than creating a block that constructs 
and issues commands.

-Sam

On Wed, May 27, 2020 at 7:04 AM Haberleitner David - S1810567006 via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:

Hi everyone,


for our project we would like to control frontend settings directly from the 
hardware to perform fast frequency sweeps.
Is there a way to do that?


>From out research it seems that the frontend chips (UBX160 in our case) are 
>controlled via a SPI register in the Radio-NoC block. But we haven't figured 
>out how to control this register from our custom block (via the Command 
>Interface?).


Thanks,
David

___
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] RFNoC Replay Bloch timmed commands

[Sam Reiter via USRP-users]

Tarik,

That KB is current - timed commands were added to the replay block in the
last 6 months.

-Sam

On Thu, May 28, 2020 at 4:52 AM Emil Bjelski via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello All,
>
> I would like to use RFNoC Replay Block with timed commands, in order to
> transmit
> waveform at allocated time slots.
>
> I see relatively new post and Ettus wiki (
> https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD
> )
> which mentions that Replay Block can be used with timed commands. (see
> line "Using RFNoC blocks like the Replay Block to transmit phase coherent
> bursts").
>
> In same time I have found an earlier post (
> http://ettus.80997.x6.nabble.com/USRP-users-X310-Replay-Block-and-receiver-timming-td11818.html
> )
> where it is mentioned that Replay Block does not support timed commands.
>
> I am wondering what is current status related to support of timed commands
> with Replay Block?
>
> Kind Regards,
>
> Tarik
>
>
> ___
> 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] RFNoC Replay Bloch timmed commands

[Emil Bjelski via USRP-users]

Hello All,

I would like to use RFNoC Replay Block with timed commands, in order to
transmit
waveform at allocated time slots.

I see relatively new post and Ettus wiki (
https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD)
which mentions that Replay Block can be used with timed commands. (see line
"Using RFNoC blocks like the Replay Block to transmit phase coherent
bursts").

In same time I have found an earlier post (
http://ettus.80997.x6.nabble.com/USRP-users-X310-Replay-Block-and-receiver-timming-td11818.html
)
where it is mentioned that Replay Block does not support timed commands.

I am wondering what is current status related to support of timed commands
with Replay Block?

Kind Regards,

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

Re: [USRP-users] Modulation technique for sliding correlator channel sounder

[AKINYELE ITAMAKINDE via USRP-users]

Kyeong, Thanks a lot. Pls, can you inform me those things I need  to be
careful with when designing the sequence transmitter? I designed one, but I
am not sure of it, though I received signals from the receiver.
Thanks.
Akinyele

On Thu, May 28, 2020, 1:56 AM Kyeong Su Shin  wrote:

> Hello Akinyele:
>
> You do not need to use any specific modulation techniques to implement a
> channel sounder. This is because the receiver already knows the
> transmitted I-Q sequence, and correlation is taken directly on the incoming
> I-Q sequences to measure the channel.
>
> Of course, you should still carefully design the transmitted sequences, as
> some sequences have poor correlation properties. Maybe you can use
> something like BPSK-modulated PN sequences.
>
> Regards,
> Kyeong Su Shin
> --
> *보낸 사람:* AKINYELE ITAMAKINDE via USRP-users 
> 대신 USRP-users 
> *보낸 날짜:* 2020년 5월 28일 목요일 오전 8:26
> *받는 사람:* usrp-users@lists.ettus.com 
> *제목:* [USRP-users] Modulation technique for sliding correlator channel
> sounder
>
> I am working on propagation channel measurement using a sliding correlator
> channel sounder flowgraph for Tx and Rx. The sliding correlator channel
> sounder flowgraphs I've gotten so far from internet search have no
> modulation technique. Does that show it does not require modulation
> technique? If yes, why?
> Thanks.
> Akinyele
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com