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>
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<mailto: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<mailto:rkoss...@nd.edu>>
Gesendet: Mittwoch, 6. September 2023 21:29
An: Marcus D. Leech <patchvonbr...@gmail.com<mailto:patchvonbr...@gmail.com>>
Cc: Bachmaier, Luca
<luca.bachma...@iis.fraunhofer.de<mailto:luca.bachma...@iis.fraunhofer.de>>;
usrp-users@lists.ettus.com<mailto: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,
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<mailto: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<mailto:usrp-users@lists.ettus.com>
To unsubscribe send an email to
usrp-users-le...@lists.ettus.com<mailto: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
