Hi Rob,

your tip about “rfnox_rx_to_file” is great, I’ve been searching for
examples for the UHD Python/C++ API for a while now anyway.
Unfortunately it seems like the error is not due to GNU Radio. Even
when trying to create a simple “Radio -> FFT -> RX Streamer” chain by
calling ./rfnoc_rx_to_file --spp=1024 --block-id FFT --block-props length=512 the flowgraph can’t even start, I get the same error about
the atomic item size. Looking at the output, everything should be set
correctly:

             […] Requesting samples per packet of: 1024

Actual samples per packet = 1024

[…] Setting block properties to: length=512

Error: ValueError: samples per package must not be smaller than atomic
item size

Additionally, I’m very much interesting in how you created your own
FFT IP in Xilinx and separated the parameters. I would be happy to get
some information from you.

*Von:*Rob Kossler rkossler@nd.edu
Gesendet: Montag, 11. September 2023 16:54
An: Bachmaier, Luca luca.bachmaier@iis.fraunhofer.de
Cc: Marcus D. Leech patchvonbraun@gmail.com;
usrp-users@lists.ettus.com; Nieland, Michael
michael.nieland@iis.fraunhofer.de
Betreff: Re: [USRP-users] Re: RFNoC: strange behavior of FFT block

Hi Luca,

I haven't used a recent UHD version with an FFT RFNoC block (probably
4.2 is the latest that I have used), but I have successfully used FFT
lengths up to 4096.  In order to do this, I had to create my own
Xilinx FFT IP and I also had to separate the concepts of streaming
packet length from the FFT length.  If you want to do this, I can
provide additional info. However, using the "stock" FFT block provided
by Ettus, I believe that you should be able to stream with FFT length
up to 1024 using the N310.

You mentioned in a previous post that your SPP is 2048.  I think that
this is an invalid SPP for the radio because of the need for the radio
to insert "packet header" bytes which reduces the max num samples per
packet to <=2000 (or about that).  So, my suggestion is to use SPP=1024.

Another suggestion is to try the Ettus example "rfnoc_rx_to_file"
which will allow you to specify an arbitrary block - in this case the
FFT block - to create an RFNoC graph that looks like "rx_radio => DDC
=> FFT => rx_streamer".  This eliminates gnuradio from the equation.
This example will capture samples to a file that you can then plot to
see the results.  You could run this example initially without the FFT
block (rx_radio => DDC => rx_streamer) and make sure it is working as
you expect.  Then you could try again with the FFT block inserted.

Rob

On Mon, Sep 11, 2023 at 5:30 AM Bachmaier, Luca
luca.bachmaier@iis.fraunhofer.de wrote:

 Hi Rob,

 thanks for your reply. What I originally wanted to bring across
 with my message was that I cannot run the flowgraph with fft_sizes
 larger than 256, no matter whether the maximum possible limit is
 1024 or 2048. E.g. if I set the fft_size to  just 512, I also get
 the error about the atomic item size mentioned below. I keep
 wondering why that is.


 Regards

 Luca

 *Von:*Rob Kossler <rkossler@nd.edu>
 *Gesendet:* Mittwoch, 6. September 2023 21:29
 *An:* Marcus D. Leech <patchvonbraun@gmail.com>
 *Cc:*Bachmaier, Luca <luca.bachmaier@iis.fraunhofer.de>;
 usrp-users@lists.ettus.com; Nieland, Michael
 <michael.nieland@iis.fraunhofer.de>
 *Betreff:* Re: [USRP-users] Re: RFNoC: strange behavior of FFT block

 Hi Luca,

 A couple of things.  The largest FFT size might be limited to 1024
 - even with MTU=9000.  I think that the maximum packet length is
 often 2000 or 2048 such that when you add a few header bytes, you
 can no longer achieve an FFT packet of 2048.

 Additionally, if you look in fft_block_control.cpp, you will see
 that there is a constant that limits the max size to 1024. This
 also matches the parameter "C_NFFT_MAX=10" which you will find in
 "axi_fft.xci" which is the Xilinx IP file that is implemented. 
 You can change these in order to build different sizes, but these
 are the defaults.

 If you search the mailing archive, you may find discussion of this
 topic and the need to divorce the concepts of 'fft length' and
 'packet length' in order to achieve FFT lengths greater than 1024.

 Rob

 On Tue, Sep 5, 2023 at 10:06 AM Marcus D. Leech
 <patchvonbraun@gmail.com> wrote:

     On 05/09/2023 04:38, Bachmaier, Luca wrote:

         Hello Marcus,

         Thank you for your detailed explanation. I was able to fix
         the problem now: I updated GNU Radio from 3.10.5
         (installed over apt) to 3.10.7 (installed from source).
         With the newer version the FFT block now correctly
         displays a noise floor.

         So far so good, the FFT resolution is still low as I
         cannot set the size higher than 256 (Error “samples per
         package must not be smaller than atomic item size”). As
         far as I understood, the size should be able to go as high
         as 2048 when using 10Gbit streaming.

         My current configuration should enable that:

         -MTU on my interface is set to 9000

         -Parameter spp of RFNoC RX Radio is set to 2048

         -Current FPGA image is of XG type

         In case it’s helpful, here’s the relevant output of `ip a`
         of my devices:

         Host:

         4: enp9s0f1np1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000
         qdisc mq state UP group default qlen 1000

         link/ether 9c:6b:00:16:8e:96 brd ff:ff:ff:ff:ff:ff

         inet 192.168.10.3/24 <http://192.168.10.3/24> scope global
         enp9s0f1np1

         valid_lft forever preferred_lft forever

         USRP:

         3: sfp0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc
         pfifo_fast qlen 1000

         link/ether 00:80:2f:31:28:42 brd ff:ff:ff:ff:ff:ff

         inet 192.168.10.2/24 <http://192.168.10.2/24> brd
         192.168.10.255 scope global sfp0

         valid_lft forever preferred_lft forever

     I think in the "RFNOC Graph" block, you can specify the SPP in
     the "Device Args" parameter.

     _______________________________________________
     USRP-users mailing list -- usrp-users@lists.ettus.com
     To unsubscribe send an email to usrp-users-leave@lists.ettus.com

Hi Marcus,

Thanks for your reply.
The original ring buffer is 1024 for Tx and Rx. Now I have changed
them to 4096. Still see overruns and underruns.
Ring parameters for enp59s0f0np0:
Pre-set maximums:
RX:             8192
RX Mini:        n/a
RX Jumbo:       n/a
TX:             8192
Current hardware settings:
RX:             4096
RX Mini:        n/a
RX Jumbo:       n/a
TX:             4096

Ring parameters for enp59s0f1np1:
Pre-set maximums:
RX:             8192
RX Mini:        n/a
RX Jumbo:       n/a
TX:             8192
Current hardware settings:
RX:             4096
RX Mini:        n/a
RX Jumbo:       n/a
TX:             4096

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

I think my computer is not fast enough for 500MHz sampling rate. The
computer I am using is Dell PowerEdge R740, CPU is Intel(R) Xeon(R)
Bronze 3106 CPU @ 1.70GHz
What is the recommended computer HW configuration?

Another question is UHD4.5. I tried UHD4.5, but there was MPM issue
The MPM software on your device is older than the FPGA you're trying to
use. Because you're using master, they haven't published updated
filesystems with the new MPM yet, but there will be a release candidate
very soon for UHD 4.5 you could try.

So, I have to use UHD4.4 now.

Kind regards,
Hongwei

On Monday, 11 September 2023 at 22:15:21 BST, Marcus D. Leech
patchvonbraun@gmail.com wrote:

On 11/09/2023 12:09, zhou via USRP-users wrote:
Hi all,

I just set up a system with X410 USRP. Tried to run a benchmark rate
test and saw a lot of errors. Please suggest what could be the reason
for the test failure.
Host is R740 (16 CPU cores) and Linux is Ubuntu 22.04 with low-latency
kernel.
100G Mellanox ConnectX-6 NIC cards

$ sudo /usr/local/lib/uhd/examples/benchmark_rate 
--args
"type=x4xx,mgmt_addr=192.168.88.2,addr=192.168.20.2,master_clock_rate=500e6"

--priority "high"
--multi_streamer
--duration 60
--channels "0"
--rx_rate 10e6
--rx_subdev "A:0"
--tx_rate 10e6
--tx_subdev "A:0"
[sudo] password for user:

[INFO] [UHD] linux; GNU C++ version 11.4.0; Boost_107400; DPDK_21.11;
UHD_4.4.0.HEAD-0-g5fac246b
[00:00:00.000566] Creating the usrp device with:
type=x4xx,mgmt_addr=192.168.88.2,addr=192.168.20.2,master_clock_rate=500e6...
[INFO] [MPMD] Initializing 1 device(s) in parallel with args:
mgmt_addr=192.168.88.2,type=x4xx,product=x410,serial=3289B23,name=ni-x4xx-3289B23,fpga=CG_400,claimed=False,addr=192.168.20.2,master_clock_rate=500e6
[WARNING] [MPM.RPCServer] A timeout event occured!
[INFO] [MPM.PeriphManager] init() called with device args
`fpga=CG_400,master_clock_rate=500e6,mgmt_addr=192.168.88.2,name=ni-x4xx-3289B23,product=x410,clock_source=internal,time_source=internal'.
Using Device: Single USRP:
  Device: X400-Series Device
  Mboard 0: x410
  RX Channel: 0
    RX DSP: n/a
    RX Dboard: A
    RX Subdev: 0
  TX Channel: 0
    TX DSP: n/a
    TX Dboard: A
    TX Subdev: 0

[00:00:05.797505591] Setting device timestamp to 0...
[WARNING] [0/Radio#0] Requesting invalid sampling rate from device: 10
MHz. Actual rate is: 500 MHz.
[WARNING] [MULTI_USRP] Could not set RX rate to 10.000 MHz. Actual
rate is 500.000 MHz
[WARNING] [0/Radio#0] Requesting invalid sampling rate from device: 10
MHz. Actual rate is: 500 MHz.
[WARNING] [MULTI_USRP] Could not set TX rate to 10.000 MHz. Actual
rate is 500.000 MHz
Setting TX spb to 1984
[00:00:05.799789467] Testing receive rate 500.000000 Msps on 1 channels
[00:00:05.801875415] Testing transmit rate 500.000000 Msps on 1 channels
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUD[U00:00:06.33502762]
Detected Rx sequence error.
UU[D00:00:06.33952517] Detected Rx sequence error.
UUUU[D00:00:06.34387503] Detected Rx sequence error.
U[D00:00:06.34802030] Detected Rx sequence error.
UUUUU[D00:00:06.35212894] Detected Rx sequence error.
U[D00:00:06.35640910] Detected Rx sequence error.

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

Done!

$ ifconfig
enp59s0f0np0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9000
        inet 192.168.20.1  netmask 255.255.255.0  broadcast 192.168.20.255
        inet6 fe80::ba3f:d2ff:fe57:b77a prefixlen 64  scopeid 0x20<link>
        ether b8:3f:d2:57:b7:7a  txqueuelen 1000  (Ethernet)
        RX packets 15144837  bytes 101888797100 (101.8 GB)
/RX errors 0  dropped 2423  overruns 0  frame 0/
        TX packets 12311297  bytes 87947193629 (87.9 GB)
        TX errors 0  dropped 0 overruns 0 carrier 0  collisions 0

enp59s0f1np1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9000
        inet 192.168.10.1  netmask 255.255.255.0  broadcast 192.168.10.255
        inet6 fe80::ba3f:d2ff:fe57:b77b prefixlen 64  scopeid 0x20<link>
        ether b8:3f:d2:57:b7:7b  txqueuelen 1000  (Ethernet)
        RX packets 406107  bytes 2296309836 (2.2 GB)
        RX errors 0  dropped 0  overruns 0 frame 0
        TX packets 502690  bytes 3421432091 (3.4 GB)
        TX errors 0  dropped 0 overruns 0 carrier 0  collisions 0

Kind regards,
Hongwei

On 12/09/2023 07:35, Bachmaier, Luca wrote:

Hi Rob,

your tip about “rfnox_rx_to_file” is great, I’ve been searching for
examples for the UHD Python/C++ API for a while now anyway. Unfortunately
it seems like the error is not due to GNU Radio. Even when trying to create
a simple “Radio -> FFT -> RX Streamer” chain by calling ./rfnoc_rx_to_file --spp=1024 --block-id FFT --block-props length=512 the flowgraph can’t
even start, I get the same error about the atomic item size. Looking at the
output, everything should be set correctly:

          […] Requesting samples per packet of: 1024

Actual samples per packet = 1024

[…] Setting block properties to: length=512

Error: ValueError: samples per package must not be smaller than atomic
item size

Additionally, I’m very much interesting in how you created your own FFT IP
in Xilinx and separated the parameters. I would be happy to get some
information from you.

Have you tried spp=fft_length?  I think the last time I did this (years
ago), that was the requirement...

Von: Rob Kossler rkossler@nd.edu rkossler@nd.edu
Gesendet: Montag, 11. September 2023 16:54
An: Bachmaier, Luca luca.bachmaier@iis.fraunhofer.de
luca.bachmaier@iis.fraunhofer.de
Cc: Marcus D. Leech patchvonbraun@gmail.com patchvonbraun@gmail.com;
usrp-users@lists.ettus.com; Nieland, Michael
michael.nieland@iis.fraunhofer.de michael.nieland@iis.fraunhofer.de
Betreff: Re: [USRP-users] Re: RFNoC: strange behavior of FFT block

Hi Luca,

I haven't used a recent UHD version with an FFT RFNoC block (probably 4.2
is the latest that I have used), but I have successfully used FFT lengths
up to 4096.  In order to do this, I had to create my own Xilinx FFT IP and
I also had to separate the concepts of streaming packet length from the FFT
length.  If you want to do this, I can provide additional info.  However,
using the "stock" FFT block provided by Ettus, I believe that you should be
able to stream with FFT length up to 1024 using the N310.

You mentioned in a previous post that your SPP is 2048.  I think that this
is an invalid SPP for the radio because of the need for the radio to insert
"packet header" bytes which reduces the max num samples per packet to
<=2000 (or about that).  So, my suggestion is to use SPP=1024.

Another suggestion is to try the Ettus example "rfnoc_rx_to_file" which
will allow you to specify an arbitrary block - in this case the FFT block -
to create an RFNoC graph that looks like "rx_radio => DDC => FFT =>
rx_streamer".  This eliminates gnuradio from the equation. This example
will capture samples to a file that you can then plot to see the results.
You could run this example initially without the FFT block (rx_radio => DDC
=> rx_streamer) and make sure it is working as you expect.  Then you could
try again with the FFT block inserted.

Rob

On Mon, Sep 11, 2023 at 5:30 AM Bachmaier, Luca <
luca.bachmaier@iis.fraunhofer.de> wrote:

Hi Rob,

thanks for your reply. What I originally wanted to bring across with my
message was that I cannot run the flowgraph with fft_sizes larger than 256,
no matter whether the maximum possible limit is 1024 or 2048. E.g. if I set
the fft_size to  just 512, I also get the error about the atomic item size
mentioned below. I keep wondering why that is.

Regards

Luca

Von: Rob Kossler rkossler@nd.edu
Gesendet: Mittwoch, 6. September 2023 21:29
An: Marcus D. Leech patchvonbraun@gmail.com
Cc: Bachmaier, Luca luca.bachmaier@iis.fraunhofer.de;
usrp-users@lists.ettus.com; Nieland, Michael <
michael.nieland@iis.fraunhofer.de>
Betreff: Re: [USRP-users] Re: RFNoC: strange behavior of FFT block

Hi Luca,

A couple of things.  The largest FFT size might be limited to 1024 - even
with MTU=9000.  I think that the maximum packet length is often 2000 or
2048 such that when you add a few header bytes, you can no longer achieve
an FFT packet of 2048.

Additionally, if you look in fft_block_control.cpp, you will see that
there is a constant that limits the max size to 1024. This also matches the
parameter "C_NFFT_MAX=10" which you will find in "axi_fft.xci" which is the
Xilinx IP file that is implemented.  You can change these in order to build
different sizes, but these are the defaults.

If you search the mailing archive, you may find discussion of this topic
and the need to divorce the concepts of 'fft length' and 'packet length' in
order to achieve FFT lengths greater than 1024.

Rob

On Tue, Sep 5, 2023 at 10:06 AM Marcus D. Leech patchvonbraun@gmail.com
wrote:

On 05/09/2023 04:38, Bachmaier, Luca wrote:

Hello Marcus,

Thank you for your detailed explanation. I was able to fix the problem
now: I updated GNU Radio from 3.10.5 (installed over apt) to 3.10.7
(installed from source). With the newer version the FFT block now correctly
displays a noise floor.

So far so good, the FFT resolution is still low as I cannot set the size
higher than 256 (Error “samples per package must not be smaller than atomic
item size”). As far as I understood, the size should be able to go as high
as 2048 when using 10Gbit streaming.

My current configuration should enable that:

•      MTU on my interface is set to 9000
  

•      Parameter spp of RFNoC RX Radio is set to 2048
  

•      Current FPGA image is of XG type
  

In case it’s helpful, here’s the relevant output of ip a of my devices:

Host:

          4: enp9s0f1np1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000

qdisc mq state UP group default qlen 1000

 link/ether 9c:6b:00:16:8e:96 brd ff:ff:ff:ff:ff:ff

 inet 192.168.10.3/24 scope global enp9s0f1np1

    valid_lft forever preferred_lft forever

USRP:

          3: sfp0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc

pfifo_fast qlen 1000

 link/ether 00:80:2f:31:28:42 brd ff:ff:ff:ff:ff:ff

 inet 192.168.10.2/24 brd 192.168.10.255 scope global sfp0

    valid_lft forever preferred_lft forever

I think in the "RFNOC Graph" block, you can specify the SPP in the "Device
Args" parameter.

USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com

Hi Luca,
The problem with FFT lengths > 256 is an Ettus bug in
"rfnoc_rx_streamer.cpp" (also an issue in "rfnoc_tx_streamer.cpp"). 
The following snippet from the atomic_item_size property resolver
shows the issue.  The problem is that "spp" has units of "samples"
whereas "ais.get()" has units of bytes.  If you modify this code to
use "spp*4" and recompile UHD, you can run with fft length 1024.
Rob

                if (spp < ais.get()) {
                    throw uhd::value_error("samples per package must
not be smaller than atomic item size");
                }

Hi Rob,

thank you very much for putting effort into finding this bug. Since you’re
talking about recompiling UHD I’m going to assume you installed UHD from
source. Which exact version did you build and install? I remember running
into problems I couldn’t solve when installing the branches UHD-4.3 und
UHD-4.4 from source.

Regards

Luca

Von: Rob Kossler rkossler@nd.edu
Gesendet: Donnerstag, 14. September 2023 23:41
An: Marcus D. Leech patchvonbraun@gmail.com
Cc: Bachmaier, Luca luca.bachmaier@iis.fraunhofer.de;
usrp-users@lists.ettus.com; Nieland, Michael <
michael.nieland@iis.fraunhofer.de>
Betreff: Re: AW: [USRP-users] Re: RFNoC: strange behavior of FFT block

Hi Luca,

The problem with FFT lengths > 256 is an Ettus bug in
"rfnoc_rx_streamer.cpp" (also an issue in "rfnoc_tx_streamer.cpp").  The
following snippet from the atomic_item_size property resolver shows the
issue.  The problem is that "spp" has units of "samples" whereas
"ais.get()" has units of bytes.  If you modify this code to use "spp*4" and
recompile UHD, you can run with fft length 1024.

Rob

             if (spp < ais.get()) {
                 throw uhd::value_error("samples per package must not

be smaller than atomic item size");
}

On Tue, Sep 12, 2023 at 9:55 AM Marcus D. Leech patchvonbraun@gmail.com
wrote:

On 12/09/2023 07:35, Bachmaier, Luca wrote:

Hi Rob,

your tip about “rfnox_rx_to_file” is great, I’ve been searching for
examples for the UHD Python/C++ API for a while now anyway. Unfortunately
it seems like the error is not due to GNU Radio. Even when trying to create
a simple “Radio -> FFT -> RX Streamer” chain by calling ./rfnoc_rx_to_file --spp=1024 --block-id FFT --block-props length=512 the flowgraph can’t
even start, I get the same error about the atomic item size. Looking at the
output, everything should be set correctly:

          […] Requesting samples per packet of: 1024

Actual samples per packet = 1024

[…] Setting block properties to: length=512

Error: ValueError: samples per package must not be smaller than atomic
item size

Additionally, I’m very much interesting in how you created your own FFT IP
in Xilinx and separated the parameters. I would be happy to get some
information from you.

Have you tried spp=fft_length?  I think the last time I did this (years
ago), that was the requirement...

Von: Rob Kossler rkossler@nd.edu rkossler@nd.edu
Gesendet: Montag, 11. September 2023 16:54
An: Bachmaier, Luca luca.bachmaier@iis.fraunhofer.de
luca.bachmaier@iis.fraunhofer.de
Cc: Marcus D. Leech patchvonbraun@gmail.com patchvonbraun@gmail.com;
usrp-users@lists.ettus.com; Nieland, Michael
michael.nieland@iis.fraunhofer.de michael.nieland@iis.fraunhofer.de
Betreff: Re: [USRP-users] Re: RFNoC: strange behavior of FFT block

Hi Luca,

I haven't used a recent UHD version with an FFT RFNoC block (probably 4.2
is the latest that I have used), but I have successfully used FFT lengths
up to 4096.  In order to do this, I had to create my own Xilinx FFT IP and
I also had to separate the concepts of streaming packet length from the FFT
length.  If you want to do this, I can provide additional info.  However,
using the "stock" FFT block provided by Ettus, I believe that you should be
able to stream with FFT length up to 1024 using the N310.

You mentioned in a previous post that your SPP is 2048.  I think that this
is an invalid SPP for the radio because of the need for the radio to insert
"packet header" bytes which reduces the max num samples per packet to
<=2000 (or about that).  So, my suggestion is to use SPP=1024.

Another suggestion is to try the Ettus example "rfnoc_rx_to_file" which
will allow you to specify an arbitrary block - in this case the FFT block -
to create an RFNoC graph that looks like "rx_radio => DDC => FFT =>
rx_streamer".  This eliminates gnuradio from the equation. This example
will capture samples to a file that you can then plot to see the results.
You could run this example initially without the FFT block (rx_radio => DDC
=> rx_streamer) and make sure it is working as you expect.  Then you could
try again with the FFT block inserted.

Rob

On Mon, Sep 11, 2023 at 5:30 AM Bachmaier, Luca <
luca.bachmaier@iis.fraunhofer.de> wrote:

Hi Rob,

thanks for your reply. What I originally wanted to bring across with my
message was that I cannot run the flowgraph with fft_sizes larger than 256,
no matter whether the maximum possible limit is 1024 or 2048. E.g. if I set
the fft_size to  just 512, I also get the error about the atomic item size
mentioned below. I keep wondering why that is.

Regards

Luca

Von: Rob Kossler rkossler@nd.edu
Gesendet: Mittwoch, 6. September 2023 21:29
An: Marcus D. Leech patchvonbraun@gmail.com
Cc: Bachmaier, Luca luca.bachmaier@iis.fraunhofer.de;
usrp-users@lists.ettus.com; Nieland, Michael <
michael.nieland@iis.fraunhofer.de>
Betreff: Re: [USRP-users] Re: RFNoC: strange behavior of FFT block

Hi Luca,

A couple of things.  The largest FFT size might be limited to 1024 - even
with MTU=9000.  I think that the maximum packet length is often 2000 or
2048 such that when you add a few header bytes, you can no longer achieve
an FFT packet of 2048.

Additionally, if you look in fft_block_control.cpp, you will see that
there is a constant that limits the max size to 1024. This also matches the
parameter "C_NFFT_MAX=10" which you will find in "axi_fft.xci" which is the
Xilinx IP file that is implemented.  You can change these in order to build
different sizes, but these are the defaults.

If you search the mailing archive, you may find discussion of this topic
and the need to divorce the concepts of 'fft length' and 'packet length' in
order to achieve FFT lengths greater than 1024.

Rob

On Tue, Sep 5, 2023 at 10:06 AM Marcus D. Leech patchvonbraun@gmail.com
wrote:

On 05/09/2023 04:38, Bachmaier, Luca wrote:

Hello Marcus,

Thank you for your detailed explanation. I was able to fix the problem
now: I updated GNU Radio from 3.10.5 (installed over apt) to 3.10.7
(installed from source). With the newer version the FFT block now correctly
displays a noise floor.

So far so good, the FFT resolution is still low as I cannot set the size
higher than 256 (Error “samples per package must not be smaller than atomic
item size”). As far as I understood, the size should be able to go as high
as 2048 when using 10Gbit streaming.

My current configuration should enable that:

•      MTU on my interface is set to 9000
  

•      Parameter spp of RFNoC RX Radio is set to 2048
  

•      Current FPGA image is of XG type
  

In case it’s helpful, here’s the relevant output of ip a of my devices:

Host:

          4: enp9s0f1np1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000

qdisc mq state UP group default qlen 1000

 link/ether 9c:6b:00:16:8e:96 brd ff:ff:ff:ff:ff:ff

 inet 192.168.10.3/24 scope global enp9s0f1np1

    valid_lft forever preferred_lft forever

USRP:

          3: sfp0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc

pfifo_fast qlen 1000

 link/ether 00:80:2f:31:28:42 brd ff:ff:ff:ff:ff:ff

 inet 192.168.10.2/24 brd 192.168.10.255 scope global sfp0

    valid_lft forever preferred_lft forever

I think in the "RFNOC Graph" block, you can specify the SPP in the "Device
Args" parameter.

USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com