On Thu, Sep 14, 2023 at 5:43 PM Marcus D. Leech <patchvonbr...@gmail.com>
wrote:
> On 14/09/2023 17:40, Rob Kossler wrote:
>
> 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");
> }
>
>
> This must be a relatively-recent bug, because I clearly remember using FFT
> > 256 a few years back.
>
> Thanks so much for finding this, Rob. Did you file a bug? I'll try to
> point R&D at it.
>
I didn't file a bug. This bug is recent because the concept of "atomic item
size" is relatively recent. The concept has the nice feature that it
automatically coerces the radio packet length to be an integer multiple of
the FFT length (or whatever blocks are in the RFNoC block chain). Thus, it
is not even necessary to explicitly set the radio SPP because it will be
set automatically by the RFNoC property resolution process. Although the
code seems to work fine to do this, the bug is just the improper throw-ing
of an exception because of the "byte vs sample" unit issue.
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
