Hi Luca,
I installed the latest from UHD-4.4 (as of last week).
Rob
On Mon, Sep 18, 2023 at 4:11 AM Bachmaier, Luca <
luca.bachma...@iis.fraunhofer.de> wrote:
> 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 <rkoss...@nd.edu>
> *Gesendet:* Donnerstag, 14. September 2023 23:41
> *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: 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 <patchvonbr...@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 <rkoss...@nd.edu> <rkoss...@nd.edu>
> *Gesendet:* Montag, 11. September 2023 16:54
> *An:* Bachmaier, Luca <luca.bachma...@iis.fraunhofer.de>
> <luca.bachma...@iis.fraunhofer.de>
> *Cc:* Marcus D. Leech <patchvonbr...@gmail.com> <patchvonbr...@gmail.com>;
> usrp-users@lists.ettus.com; Nieland, Michael
> <michael.niel...@iis.fraunhofer.de> <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 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-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
