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 <rkoss...@nd.edu>
*Gesendet:* Montag, 11. September 2023 16:54
*An:* Bachmaier, Luca <luca.bachma...@iis.fraunhofer.de>
*Cc:* Marcus D. Leech <patchvonbr...@gmail.com>;
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,
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
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
