Hi, Sorry for reviving this thread, I still have found no solution to this problem. I moved my application from python to c++ for performance reasons and the issue is somehow different.
I found this old thread about the fft length on rfnoc: https://www.mail-archive.com/[email protected]/msg07587.html Apparently you can modify the fft block to accept multiple smaller packets, perform the fft and output multiple packets. The drawbacks are that you have to manually reset the fft (to avoid frames being mixed in different streams) and that errors will somehow be mishandled. Has there been any work in this direction? Is the modification as simple as changing some parameter in the xilinx FFT IP definition in uhd? Would be nice to have this feature by default, I'm trying to implement it, regardless of the drawbacks, because in the end I will need a real time FFT of 2048 samples. Thanks, Lorenzo ________________________________ From: Rob Kossler <[email protected]> Sent: Tuesday, September 13, 2022 6:54 AM To: Minutolo, Lorenzo <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: [USRP-users] RFNOC4, FFT Block, Python Hi Lorenzo, The FFT block requires the number of samples per packet to exactly equal the FFT size. When the graph commits, UHD will try to resolve a packet size that all of the blocks are happy with. Perhaps if the FFT size is 2^11, this packet size may be bigger than the radio wants to deliver (or bigger than the SPP you specified in the rx_streamer, I don't really know). In my opinion, this is a really unnecessary limitation of the stock FFT block. With relatively minor changes, this block would not need any linkage between packet size and FFT length. Rob On Mon, Sep 12, 2022 at 8:20 PM Minutolo, Lorenzo <[email protected]<mailto:[email protected]>> wrote: Hi All, I'm using UHD 4.2 to play around with RFNOC4. I successfully added an FFT block to the XG image of an X300, no static connections. uhd_usrp_probe returns as expected. I use the attached code to test it out. When I commit the graph I get the following error: Traceback (most recent call last): File "/home/lorenzo/test_rfnoc_fft.py", line 71, in <module> graph.commit() RuntimeError: ValueError: samples per package must not be smaller than atomic item size Digging a bit in the libraries I see that it originates from rfnoc_streamer.cpp, specifically: [...] if (ais.is_valid()) { const auto spp = this->rx_streamer_impl::get_max_num_samps(); if (spp < ais.get()) { throw uhd::value_error("samples per package must not be smaller than atomic item size"); } [...] Has someone encountered this error before? Thenks, Lorenzo Attached code: args = "addr=192.168.30.2" graph = uhd.rfnoc.RfnocGraph(args) radio_ID_A = uhd.rfnoc.BlockID(0, "Radio", 0); radio_block_A = graph.get_block(radio_ID_A); radio_ctrl_A = uhd.rfnoc.RadioControl(radio_block_A) set_freq = 300e6 spp = 512 radio_ctrl_A.set_tx_frequency(set_freq, 0) tx_freq = radio_ctrl_A.get_tx_frequency(0) radio_ctrl_A.set_rx_frequency(set_freq, 0) rx_freq = radio_ctrl_A.get_rx_frequency(0) print("Tuning is TX %.1f, RX: %.1f MHz" % (tx_freq/1e6,rx_freq/1e6 ) ) radio_ctrl_A.set_properties(f'spp={spp}', 0) radio_ctrl_A.set_rx_antenna('RX2',0) radio_ctrl_A.set_rate(200e6) DDC_ID = graph.find_blocks("DDC")[0] DDC_block = graph.get_block(DDC_ID) DDC_control = uhd.rfnoc.DdcBlockControl(DDC_block) DDC_control.set_input_rate(200e6, 0) DDC_control.set_output_rate(5e6, 0) FFT_ID = graph.find_blocks("FFT")[0] FFT_block = graph.get_block(FFT_ID) FFT_control = uhd.rfnoc.FftBlockControl(FFT_block) FFT_control.set_length(spp) FFT_control.set_magnitude(uhd.libpyuhd.rfnoc.fft_magnitude.COMPLEX) FFT_control.set_direction(uhd.libpyuhd.rfnoc.fft_direction.FORWARD) FFT_control.set_shift_config(uhd.libpyuhd.rfnoc.fft_shift.REVERSE) stream_args = uhd.usrp.StreamArgs('fc32','sc16') stream_args.args = 'spp='+str(spp) rx_stream = graph.create_rx_streamer(1, stream_args) graph.connect( radio_ID_A,0, DDC_ID,0, False ) graph.connect( DDC_ID,0, FFT_ID,0, False ) graph.connect( FFT_ID,0, rx_stream,0 ) graph.commit() _______________________________________________ USRP-users mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
