On 16/10/2023 02:29, Bachmaier, Luca wrote:
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
Run:
uhd_config_info --version
And also:
which uhd_config_info
which uhd_usrp_probe
What do those return?
*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
To unsubscribe send an email tousrp-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
