Hello Marcus, when starting my flowgraph in GNU Radio it puts out this first: Generating: '/home/sdr/dev/rfnoc/fft3/fft3.py'
Executing: /usr/bin/python3 -u /home/sdr/dev/rfnoc/fft3/fft3.py [INFO] [UHD] linux; GNU C++ version 12.2.0; Boost_107400; UHD_4.4.0.0-33-g4a77791c It’s correct that I used to have the distro packages of GNU Radio and UHD installed on my system but since then I removed these versions and installed both from source, first UHD and then GNU Radio. In last line of the output above, “UHD_4.4.0.0…” should be a definitive indicator that GNU Radio uses the installation from source, right? UHD 4.4 is the version I installed from source, apt (I’m on a Debian system) only offers UHD 4.3 to be installed. Regards Luca Von: Marcus D. Leech <patchvonbr...@gmail.com> Gesendet: Montag, 9. Oktober 2023 18:24 An: usrp-users@lists.ettus.com Betreff: [USRP-users] Re: RFNoC + GNU Radio: spp is set differently On 09/10/2023 10:56, Bachmaier, Luca wrote: Hi all, I’m currently implementing a GNU Radio flowgraph that makes use of the RFNoC FFT block. After fixing a bug found out by Rob Kossler (mail in this mailing list from September 14) in the UHD repository, the original problem persists in GNU Radio: trying to use FFT lengths greater than 256 throws the error “samples per package must not be smaller than atomic item size”. When trying to look closer into the problem I noticed that the spp parameter is set differently when using the UHD python API directly (script rfnoc_rx_to_file) and when using GNU Radio. I added debug statements to the rfnoc_rx_streamer block that print the values of spp and ais.get() (atomic item size). When calling the rfnoc_rx_to_file script with a spp set to 1024 and an FFT length of 1024 I get the following output: [INFO] [0/LogPwr#0] Setting default MTU forward policy. Using radio 0, channel 0 Attempting to connect FFT:0 to 0/Radio#0:0... Requesting RX Freq: 0 MHz... Actual RX Freq: 1 MHz... Waiting for "lo_locked": ++++++++++ locked. Requesting samples per packet of: 1024 Actual samples per packet = 1024 Using streamer args: [DEBUG] spp = 18446744073709551615 [DEBUG] ais.get() = 1 [DEBUG] spp = 2000 [DEBUG] ais.get() = 1 [DEBUG] spp = 2000 [DEBUG] ais.get() = 1024 [DEBUG] spp = 1024 [DEBUG] ais.get() = 1024 Since here spp is not smaller than ais.get(), the flowgraph is able to run. When trying the same as a GNU Radio flowgraph, the output is the following: [INFO] [0/LogPwr#0] Setting default MTU forward policy. [DEBUG] spp = 18446744073709551615 [DEBUG] ais.get() = 1 [DEBUG] spp = 2000 [DEBUG] ais.get() = 1 [DEBUG] spp = 2000 [DEBUG] ais.get() = 2048 [DEBUG] spp = 0 [DEBUG] ais.get() = 2048 For some reason, spp is finally set to zero and ais.get() is set to 2048. I do not understand why, and I also don’t get why the behavior is different for GNU Radio at all. Is it possible that GNU Radio uses its own version of UHD? Up until now I believed that GNU Radio simply uses the already installed UHD implementation over the UHD Python API. If this is not the case, how can I change this specific GNU Radio UHD version? I tried looking into the source code of gnuradio/gr-uhd/lib/rfnoc but I do not understand it unfortunately. Regards Luca _______________________________________________ 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> If you installed Gnu Radio from the distros package, it will have been linked against whatever version of the UHD was also packaged by the distro. If you then build UHD from source (with your fixes), Gnu Radio won't see that version of UHD. What you might need to do is having built your patched UHD from source, also build Gnu Radio from source, having first removed the installed-by-the-distro UHD and Gnu Radio packages. This is just an emergent property of large complex software systems, the semantics of compiled languages and linking, and conflicts between built-from-source, and installed-from-the-distro packages.
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
