build gnuradio from source on kubuntu22.04 error

[lai wieniawski]

hi, all,

I am trying to build gnuradio from source on kubuntu22.04.

I am flowing the guide:
https://wiki.gnuradio.org/index.php?title=LinuxInstall#From_Source
Where I have done

  1.  build UHD, and installed
  2.  build volk, and installed
  3.  build gnuradio, just clone from git, and build, donot switch to v3.9 or 
else.
 *   using cmake to generate makefile
 *   make

I face error while make:
[ 85%] Linking CXX executable display_qt
/usr/bin/ld: /lib/libqwt-qt5.so: undefined reference to `qt_version_tag@Qt_5.15'
/usr/bin/ld: /lib/libqwt-qt5.so: undefined reference to 
`QPushButton::hitButton(QPoint const&) const@Qt_5'
collect2: error: ld returned 1 exit status
make[2]: *** [gr-qtgui/examples/c++/CMakeFiles/display_qt.dir/build.make:135: 
gr-qtgui/examples/c++/display_qt] Error 1
make[1]: *** [CMakeFiles/Makefile2:3196: 
gr-qtgui/examples/c++/CMakeFiles/display_qt.dir/all] Error 2
make: *** [Makefile:146: all] Error 2

It seems that the version libqwt-qt5.so is not correct.

How can I fix it?

thx

Re: build gnuradio from source on kubuntu22.04 error

[Marcus Müller]

Hi Lai,

first, naive, question:
Ubuntu 22.04 (and thus, Kubuntu 22.04) ship a GNU Radio 3.10.1.1 with backported fixes, 
built with a UHD 4.1.0.5; that's relatively recent! In short, if you don't specifically 
need a never version of either, I'd recommend you save yourself the trouble of building 
from source yourself.


(If anything, I'd simply take the uhd and gnuradio source packages from Ubuntu 23.04 and 
build them on your Ubuntu 22.04, that would shift the effort of making a clean build and 
installing all the dependencies to the package maintainer.)


The errors you're getting seem to stem from a confusion of versions on the side of the QWT 
Qt-based library, as you were saying, but it's not libqwt that's in the wrong version, 
it's that libqwt expects a different version of Qt5's core functionality and widget 
library than your linker finds!


That's very strange. Did you perhaps build QWT from source in the past, then update Qt, or 
something similar?


Best regards,
Marcus

On 27.04.23 11:41, lai wieniawski wrote:

hi, all,

I am trying to build gnuradio from source on kubuntu22.04.

I am flowing the guide:
https://wiki.gnuradio.org/index.php?title=LinuxInstall#From_Source 


Where I have done

 1. build UHD, and installed
 2. build volk, and installed
 3. build gnuradio, just clone from git, and build, donot switch to v3.9 or 
else.
 1. using cmake to generate makefile
 2. make

I face error while make:
[ 85%] Linking CXX executable display_qt
/usr/bin/ld: /lib/libqwt-qt5.so: undefined reference to `qt_version_tag@Qt_5.15'
/usr/bin/ld: /lib/libqwt-qt5.so: undefined reference to `QPushButton::hitButton(QPoint 
const&) const@Qt_5'

collect2: error: ld returned 1 exit status
make[2]: *** [gr-qtgui/examples/c++/CMakeFiles/display_qt.dir/build.make:135: 
gr-qtgui/examples/c++/display_qt] Error 1
make[1]: *** [CMakeFiles/Makefile2:3196: 
gr-qtgui/examples/c++/CMakeFiles/display_qt.dir/all] Error 2

make: *** [Makefile:146: all] Error 2

It seems that the version libqwt-qt5.so is not correct.

How can I fix it?

thx

Re: udp source - too much data warning message

[Marcus Müller]

Hey Jorge,

just to avoid duplicating effort on the mailing list, and to document it for future search 
engine users, we discussed that yesterday on chat:


jofegoor
Hi all, I have a problem with the UDP sink and UDP soruce blocks, i am working on a 

USRP > E312 and i made a copy of a .wav file and a python script on the USRP, 
the script is

from the GRC 3.8 and it is only a wav file source block and the UDP sink block, 
in
another flowgraph i have the correspondent UDP source and the audio sink, but a 
cant
hear the file just like a instant and then noise, when a run the host part of 
the test i
get this error:
gr::log :WARN: udp_source0 - Too much data; dropping packet.
what can i do?? i did a quick google search and all i could find was that i 
have to
modify the dp_source_impl.cc file, but i dont even know where that file is

funkylab

your UDP source is pushing out data as fast as it can through the network
which is much much faster than your soundcard consumes the samples, jofegoor
that means the network packets arrive at the UDP sink and that sink has nowhere 
to put
them
which means they get dropped.
So, long story short, UDP is the wrong protocol here, you need flow control. 
Try the
ZeroMQ request/reply pair of blocks, with the request on the "receiving" end 
and the
reply on the transmitting end.

jofegoor

i see, i'm gonna try this, thanks you for your time :)


Cheers,
Marcus
On 26.04.23 20:20, JORGE GONZALEZ ORELLANA via GNU Radio, the Free & Open-Source Toolkit 
for Software Radio wrote:
Hi all, I have a problem with the UDP sink and UDP source blocks, i am working on a USRP 
E312 and i made a copy of a .wav file and a python script on the USRP, the script is 
from the GRC 3.8 and it is only a wav file source block and the UDP sink block, in 
another flowgraph i have the correspondent UDP source and the audio sink, but i can't 
hear the file just like a instant and then noise, when i run the host part of the test i 
get this error:

gr::log :WARN: udp_source0 - Too much data; dropping packet.


What can I do?? i did a quick google search and all i could find was that i have to 
modify the dp_source_impl.cc  file, but i don't even know where that file is

Re: QAM constellation script

[Marcus Müller]

Hi George,

> Also I have implemented 1.000.000 hops/sec frequency hopping at QO100 
satellite, spread
> over 1 MHz, using 10240 different frequencies.
> Is this project of general interest?

Well, that's impossible to say, but honestly: it probably is! And also, you shouldn't care 
too much :) It's cool in any case!

My advise is: Just put it out there.

But I do have signal theory questions:

We know that if a signal has a bandwidth of 1 MHz, we can (complex) sample it and contain 
all its signal content with a sampling rate of 1 MS/s.


If you're doing a million hops per second, how are you achieving a bandwidth of only 1 
MHz? That means that every hop only gets a single sample, and you can't signify 
"frequency" with just a single number.


So, I might have misunderstood you there, but it would seem what you claim to have done is 
mathematically not possible :(



I create this script using Python to create QAM constellations points.
May be of general interest.


It's nice, but GNU Radio already comes with that!

from gnuradio import digital
constellation = digital.constellation_16qam()
points = constellation.points()

(and you can just use digital.constellation_16qam().points() in a GRC block parameter, no 
need to build a string!)


These are also power-normalized to 1.

If you don't want normalized (or different sizes of) QAM constellation,

digital.qam.make_non_differential_constellation(M, gray_coded)

is your friend;

digital.qam.make_non_differential_constellation(4096, True)

makes a nice 4096-QAM, but it's average power isn't 1; you can fix that

points = digital.qam.make_non_differential_constellation(4096, True)
average_pwr = sum(point**2 for point in points) / len(points)
print(f"Average power: {average_pwr}; normalization factor hence: 
{average_pwr**(-1/2)}")
normalized_points = [ point * average_pwr**(-1/2) for point in points ]

Similarly, since you're doing satellite communications, you might be interested in PSKs, 
an A-PSKs.


You can create a PSK using

digital.psk.psk_constellation(m=4, mod_code='gray', differential=True)

e.g.

digital.psk.psk_constellation(16, differential=False)


If you don't have GNU Radio but just python,

str([(i, j) for i in range(-n, n, 2) for j in range (-n, n, 2)])

does the same as your code, but might be a bit easier to read (again, if you want to use 
this in GRC, don't do the conversion to `str`; GRC accepts any valid Python in its fields).


Best regards,
Marcus

Qt frequency sink

[David Martini]

Hi all

I upgrade gnuradio from 3.8 to 3.10 on ubuntu 20.04.
Everythink is working good except that qt-frequency sink that now is much
slower that in 3.8 on same flowchart
Also look like to be insensitive to update rate.

Someone have same issue?

Thanks

David Martini


Il Gio 27 Apr 2023, 13:30 Marcus Müller  ha
scritto:

> Hey Jorge,
>
> just to avoid duplicating effort on the mailing list, and to document it
> for future search
> engine users, we discussed that yesterday on chat:
>
> jofegoor
> > Hi all, I have a problem with the UDP sink and UDP soruce blocks, i am
> working on a
> USRP > E312 and i made a copy of a .wav file and a python script on the
> USRP, the script is
> > from the GRC 3.8 and it is only a wav file source block and the UDP sink
> block, in
> > another flowgraph i have the correspondent UDP source and the audio
> sink, but a cant
> > hear the file just like a instant and then noise, when a run the host
> part of the test i
> > get this error:
> > gr::log :WARN: udp_source0 - Too much data; dropping packet.
> > what can i do?? i did a quick google search and all i could find was
> that i have to
> > modify the dp_source_impl.cc file, but i dont even know where that file
> is
> funkylab
> > your UDP source is pushing out data as fast as it can through the network
> > which is much much faster than your soundcard consumes the samples,
> jofegoor
> > that means the network packets arrive at the UDP sink and that sink has
> nowhere to put
> > them
> > which means they get dropped.
> > So, long story short, UDP is the wrong protocol here, you need flow
> control. Try the
> > ZeroMQ request/reply pair of blocks, with the request on the "receiving"
> end and the
> > reply on the transmitting end.
> jofegoor
> > i see, i'm gonna try this, thanks you for your time :)
>
> Cheers,
> Marcus
> On 26.04.23 20:20, JORGE GONZALEZ ORELLANA via GNU Radio, the Free &
> Open-Source Toolkit
> for Software Radio wrote:
> > Hi all, I have a problem with the UDP sink and UDP source blocks, i am
> working on a USRP
> > E312 and i made a copy of a .wav file and a python script on the USRP,
> the script is
> > from the GRC 3.8 and it is only a wav file source block and the UDP sink
> block, in
> > another flowgraph i have the correspondent UDP source and the audio
> sink, but i can't
> > hear the file just like a instant and then noise, when i run the host
> part of the test i
> > get this error:
> > gr::log :WARN: udp_source0 - Too much data; dropping packet.
> >
> > <
> https://matrix.to/#/!PiiKkGTcBDLmPnxhoT:gnuradio.org/$tjRUpZbSBqdBSVt4j7pZ6YdDnpl1QRqhynkr1lK4g48?via=gnuradio.org&via=libera.chat&via=matrix.org
> >
> > What can I do?? i did a quick google search and all i could find was
> that i have to
> > modify the dp_source_impl.cc  file, but i don't even
> know where that file is
>
>

static ip on E312 not working

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi all

i want to assign a static ip address to my E312, i have modify the
eth0.network file in /data/network, this is the content:

[Match]
Name=eth0
KernelCommandLine=!nfsroot

[Network]
Address=192.168.10.42
IPForward=ipv4

[DHCP]
UseHostname=true
UseDomains=true
ClientIdentifier=mac

But I rebooted the E312 and did not have the ip assigned, ¿does anyone know
why this is not happening?