Just to update on my previous question. I also tried to update
"rfnoc_rx_streamer.cpp" by changing  function *spp*4 * in the*
"add_property_resolver function"* as follows:























*    add_property_resolver({atomic_item_size_in, mtu_in, type_in},
{},        [&ais = *atomic_item_size_in, &type = *type_in, chan, this]() {
          const auto UHD_UNUSED(log_chan) = chan;
RFNOC_LOG_TRACE("Calling resolver for `atomic_item_size'@" << chan);
    if (ais.is_valid()) {                const size_t bpi          =
convert::get_bytes_per_item(type.get());                const size_t spp
       = this->rx_streamer_impl::get_max_num_samps();                const
size_t spp_multiple = uhd::math::lcm<size_t>(ais.get(), bpi) / bpi;
        if (spp*4 < spp_multiple) {
RFNOC_LOG_ERROR("Cannot resolve spp! Must be a multiple of "
                    << spp_multiple << " but max value is " << spp);
            throw uhd::value_error(                        "Samples per
packet is incompatible with atomic item size!");                }
      const auto misalignment = spp % spp_multiple;                if
(misalignment > 0) {                    RFNOC_LOG_TRACE("Reducing spp by "
                                  << misalignment << " to align with atomic
item size");
this->rx_streamer_impl::set_max_num_samps(spp - misalignment);
  }            }        });*

And recompiler uhd with following commands:

*cd uhd/host*

* cd build*

*cmake ..*

*make*

* make test # Optional: run tests*


* sudo make install *



However, this also resulted in the same error.

On Mon, Nov 4, 2024 at 12:41 PM Nidhi Panda <nidhi.pa...@cyronics.com>
wrote:

> Thank you for your response, but as I have mentioned I  already tried to
> set SPP to match FFT_size for Rx_radio. I also tried to set spp with py
> script.  It shows the same error as GNu radio which is:
>
>
>
>
>
> *[ERROR] [RxStreamer#0] Cannot resolve spp! Must be a multiple of 512 but
> max value is 256Traceback (most recent call last):  File "FFT_test.py",
> line 47, in <module>    fft.set_length(fft_length)RuntimeError: ValueError:
> Samples per packet is incompatible with atomic item size!*
>
> I have attached my py script for your reference.* Is there any reference
> code (GNU radio or python or CPP) which works with FFT size = 1024/2048? *Is
> it even possible to get this FFT length (1024 and 2048 ) with USRP x300?
> Also, I have only twin RX in my design so no TX.
>
> Another thing I noticed is if I set fft|_length before committing the
> graph, the max spp value is *364 *whereas after commit if I set
> fft_length the max SPP size is *256*. Can anyone please explain what is
> the reason for this.
>
>
> On Wed, Oct 23, 2024 at 6:59 PM Wade Fife <wade.f...@ettus.com> wrote:
>
>> With this FFT block, you need to set the SPP to match the FFT size for it
>> to work correctly. I'm not very familiar with GNU Radio but I think there
>> is an SPP parameter on the RX radio. I don't know how to set it for TX.
>>
>> Wade
>>
>>
>> On Wed, Oct 23, 2024 at 5:45 AM Nidhi Panda <nidhi.pa...@cyronics.com>
>> wrote:
>>
>>> Hello,
>>>
>>> I am having USRP X300 device with following tool versions:
>>>
>>> Vivado 2021.1 - AR76780n,
>>> GNU radio version - v3.11.0.0git-820-g2adbd4ea
>>> UHD version - UHD_4.7.0.0-84-gbdada1ed
>>>
>>> I have added FFT and Spliter RFNoC blocks in my bit file. The
>>> "uhd_usrp_probe" command shows correct connection in the blocks.
>>>
>>> | | RFNoC blocks on this device:
>>> | |
>>> | | * 0/DDC#0
>>> | | * 0/FFT#0
>>> | | * 0/Radio#0
>>> | | * 0/Replay#0
>>> | | * 0/SplitStream#0
>>> | _____________________________________________________
>>> | /
>>> | | Static connections on this device:
>>>
>>> | | * 0/Radio#0:0==>0/DDC#0:0
>>> | | * 0/Radio#0:1==>0/DDC#0:1
>>> | | * 0/DDC#0:1==>0/SEP#0:0
>>> | | * 0/DDC#0:0==>0/SplitStream#0:0
>>> | | * 0/SplitStream#0:1==>0/FFT#0:0
>>> | | * 0/SplitStream#0:0==>0/SEP#2:0
>>> | | * 0/FFT#0:0==>0/SEP#1:0
>>> | | * 0/SEP#3:0==>0/Replay#0:0
>>> | | * 0/Replay#0:0==>0/SEP#3:0
>>> | | * 0/SEP#4:0==>0/Replay#0:1
>>> | | * 0/Replay#0:1==>0/SEP#4:0
>>>
>>> However, on running example code available on GNURADIO
>>> *"rfnoc_split_stream.grc"*. I get following error:
>>>
>>> *1. When FFT size = 1024 (as in the example given in gnu radio)*
>>>
>>>
>>>
>>> *--------------------------------------------------------------------------------------------------------------------------*
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *[ERROR] [RxStreamer#0] Cannot resolve spp! Must be a multiple of 1024
>>> but max value is 364Traceback (most recent call last):  File
>>> "/home/quasar/gnuradio/gr-uhd/examples/grc/rfnoc_split_stream.py", line
>>> 347, in <module>    main()  File
>>> "/home/quasar/gnuradio/gr-uhd/examples/grc/rfnoc_split_stream.py", line
>>> 326, in main    tb.start()  File
>>> "/usr/local/lib/python3.8/dist-packages/gnuradio/gr/top_block.py", line
>>> 116, in start    top_block_start_unlocked(self._impl,
>>> max_noutput_items)RuntimeError: ValueError: Samples per packet is
>>> incompatible with atomic item size!*
>>>
>>>
>>> *--------------------------------------------------------------------------------------------------------------------------*
>>> How to know what is atomic size and how can I set it. On searching for
>>> this error I came across following link:
>>>
>>> *https://github.com/EttusResearch/uhd/commit/f163af41a47ab4c702ffbdb10352cf875d604d74
>>> <https://github.com/EttusResearch/uhd/commit/f163af41a47ab4c702ffbdb10352cf875d604d74>*
>>>
>>> This says rx stream is having a bug and AIS is in unit bytes, and spp
>>> in unit items. It was a response of two years back with the uhd version
>>> v4.3.0.0-rc1
>>> <https://github.com/EttusResearch/uhd/releases/tag/v4.3.0.0-rc1>. Does
>>> this explanation still hold? What is the max FFT size I can use? I want to
>>> use *2048*, what changes need to be done for it.
>>>
>>> *1. When FFT size = 256*
>>>
>>>
>>> *--------------------------------------------------------------------------------------------------------------------------*
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *[ERROR] [RFNOC::GRAPH::DETAIL] The following properties could not be
>>> resolved:[ERROR] [RFNOC::GRAPH::DETAIL] Dirty: RxStreamer#1[INPUT_EDGE:0
>>> atomic_item_size]Traceback (most recent call last):  File
>>> "/home/quasar/gnuradio/gr-uhd/examples/grc/rfnoc_split_stream.py", line
>>> 347, in <module>    main()  File
>>> "/home/quasar/gnuradio/gr-uhd/examples/grc/rfnoc_split_stream.py", line
>>> 326, in main    tb.start()  File
>>> "/usr/local/lib/python3.8/dist-packages/gnuradio/gr/top_block.py", line
>>> 116, in start    top_block_start_unlocked(self._impl,
>>> max_noutput_items)RuntimeError: RfnocError: ResolveError: Could not resolve
>>> properties.*
>>>
>>>
>>> *--------------------------------------------------------------------------------------------------------------------------*
>>>
>>> Am I doing anything wrong in the yml script because the connection seems
>>> correct in the uhd_usrp_probe command. On further searching I found that
>>> SPP i.e. sample per packet must be the same for all the blocks. Tried doing
>>> it in gnu radio by assigning the args option with f"spp={fft_size}". Is
>>> this correct? It gives no change in error howver I get additional warning
>>> as
>>>
>>> [WARNING] [0/FFT#0] set_properties() cannot set property `spp': No such
>>> property.
>>> [WARNING] [0/DDC#0] set_properties() cannot set property `spp': No such
>>> property.
>>>
>>>
>>> Please help me to solve these errors.
>>>
>>> --
>>> Regards,
>>> *Nidhi Panda*
>>>
>>> *Cyronics Innovation Labs Pvt Ltd*
>>> #11, Electronics Co-op Estate
>>> Satara Road, Pune - 411009
>>>
>>> _______________________________________________
>>> USRP-users mailing list -- usrp-users@lists.ettus.com
>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>>>
>>
>
> --
> Regards,
> *Nidhi Panda*
>
> *Cyronics Innovation Labs Pvt Ltd*
> #11, Electronics Co-op Estate
> Satara Road, Pune - 411009
>
>

-- 
Regards,
*Nidhi Panda*

*Cyronics Innovation Labs Pvt Ltd*
#11, Electronics Co-op Estate
Satara Road, Pune - 411009
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

Reply via email to