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 <rkoss...@nd.edu> <mailto:rkoss...@nd.edu>
*Gesendet:* Montag, 11. September 2023 16:54
*An:* Bachmaier, Luca <luca.bachma...@iis.fraunhofer.de>
<mailto:luca.bachma...@iis.fraunhofer.de>
*Cc:* Marcus D. Leech <patchvonbr...@gmail.com>
<mailto:patchvonbr...@gmail.com>; usrp-users@lists.ettus.com;
Nieland, Michael <michael.niel...@iis.fraunhofer.de>
<mailto:michael.niel...@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.bachma...@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 <rkoss...@nd.edu>
*Gesendet:* Mittwoch, 6. September 2023 21:29
*An:* Marcus D. Leech <patchvonbr...@gmail.com>
*Cc:*Bachmaier, Luca <luca.bachma...@iis.fraunhofer.de>;
usrp-users@lists.ettus.com; Nieland, Michael
<michael.niel...@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
<patchvonbr...@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-le...@lists.ettus.com
