[Discuss-gnuradio] Custom gnuradio GUI for OOT blocks
Hi, I have designed a gnu-radio system with different blocks (pre-defined and out-of-tree) to run on a USRP. I want to create a custom GUI, where the user can modify the behavior of the OOT blocks. I have developed the OOT blocks in C++. (it would be basically call functions of the c++ code using the parameters form the user input) The GUI should run the main .py file of the GNU-radio flowgraph, and should re-compile the C++ codes associated to the OOT blocks. I would appreciate to have some recommendation about which framework to use. Should I use wxPython? Thank you. Laura -- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] qt_gui_time
Marcus and Marcus, All understood. I will try to implement an alternative strip chart functionality in my flowchart program as Marcus L. Indicated is possible using the Qt Time Sink, Qt Vector Sink, and Vector Add Const blocks to replace my currently working WX version. Interesting. Thanks for the info! Joe > On Mar 10, 2019, at 5:09 PM, Marcus D. Leech wrote: > > On 03/10/2019 06:26 PM, Marcus Müller wrote: >> Hi Wayne, Hi Joe, >> >> you're right – we've been urging people to switch away from WX since at >> least 2014, and now we're finally removing it; with a bit of a heavy >> heart, to be honest: Without feature equality, removing an alternative >> feels bad, but we simply couldn't maintain the WX code anymore, and had >> to find the resources to maintain QT stuff first. >> So, no, we don't have that specific visualization in Qt, sorry. Joe, >> this means we've long stopped supporting your widget – it works on most >> machines, on others it doesn't, and we can't really help you in the >> latter case. >> >> Now, would one get started with developing a strip chart for Qt? Either >> one cheats a bit and just implements something that hands n_points >> sized chunks of data to the Qt GUI time sink, which always are >> basically the last chunk, with old samples "shifted out" and new >> samples "shifted in", or one would actually go and do a deep C++/Qt >> dive and write a proper stripchart widget. >> >> Best regards, >> Marcus > I use the Qt Vector sink for strip-charts. > > All the strip-chartiness is handled in helper code, and the Vector just shows > vectors at strip-chartly low rates. > > My spectro_radiometer app does this. > > Basically, feed a Qt Vector sink from an vector-add-const block which is > being feed a stream of zeros. On a regular basis, via the magic > of function probes, update the "constant" that is added. That vector > constant is the strip-chart contents. The Vector sink doesn't even > know that it's acting as a stripchart function. Easy-peasy, and nothing > special required in Qt land other than what's already there. > > I implemented the strip-chart functionality in the Wx widgets all those years > ago. It was a bit of a hack then, and I'm kinda happy to see > the Wx widgets going away. They had portability issues, and often also had > horrendous performance issues. > > >> >> On Sun, 2019-03-10 at 16:12 -0600, Joe Martin wrote: >>> Hi Wayne, >>> >>> I am using the strip-chart option of the WX GUI Scope Sink block in >>> GRC to perform drift scans in my radio astronomy project. Works like >>> a champ! >>> >>> Select “Stripchart” in the Trigger option. >>> >>> Regards, >>> >>> Joe >>> On Mar 10, 2019, at 3:24 PM, Wayne Hilliard wrote: Hello, Question. Has there been any movement on adding a strip chart option to this gui? I know WX_gui usage is discouraged and i have a radio astronomy app I've been working on that uses QT_Gui. I've looked around some on github and don't have a clue on where I would start to try something on my own. Any help would be appreciated . Thanks in advance!! Wayne Hilliard ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> ___ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] qt_gui_time
On 03/10/2019 06:26 PM, Marcus Müller wrote: Hi Wayne, Hi Joe, you're right – we've been urging people to switch away from WX since at least 2014, and now we're finally removing it; with a bit of a heavy heart, to be honest: Without feature equality, removing an alternative feels bad, but we simply couldn't maintain the WX code anymore, and had to find the resources to maintain QT stuff first. So, no, we don't have that specific visualization in Qt, sorry. Joe, this means we've long stopped supporting your widget – it works on most machines, on others it doesn't, and we can't really help you in the latter case. Now, would one get started with developing a strip chart for Qt? Either one cheats a bit and just implements something that hands n_points sized chunks of data to the Qt GUI time sink, which always are basically the last chunk, with old samples "shifted out" and new samples "shifted in", or one would actually go and do a deep C++/Qt dive and write a proper stripchart widget. Best regards, Marcus I use the Qt Vector sink for strip-charts. All the strip-chartiness is handled in helper code, and the Vector just shows vectors at strip-chartly low rates. My spectro_radiometer app does this. Basically, feed a Qt Vector sink from an vector-add-const block which is being feed a stream of zeros. On a regular basis, via the magic of function probes, update the "constant" that is added. That vector constant is the strip-chart contents. The Vector sink doesn't even know that it's acting as a stripchart function. Easy-peasy, and nothing special required in Qt land other than what's already there. I implemented the strip-chart functionality in the Wx widgets all those years ago. It was a bit of a hack then, and I'm kinda happy to see the Wx widgets going away. They had portability issues, and often also had horrendous performance issues. On Sun, 2019-03-10 at 16:12 -0600, Joe Martin wrote: Hi Wayne, I am using the strip-chart option of the WX GUI Scope Sink block in GRC to perform drift scans in my radio astronomy project. Works like a champ! Select “Stripchart” in the Trigger option. Regards, Joe On Mar 10, 2019, at 3:24 PM, Wayne Hilliard wrote: Hello, Question. Has there been any movement on adding a strip chart option to this gui? I know WX_gui usage is discouraged and i have a radio astronomy app I've been working on that uses QT_Gui. I've looked around some on github and don't have a clue on where I would start to try something on my own. Any help would be appreciated . Thanks in advance!! Wayne Hilliard ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] qt_gui_time
Hi Wayne, Hi Joe, you're right – we've been urging people to switch away from WX since at least 2014, and now we're finally removing it; with a bit of a heavy heart, to be honest: Without feature equality, removing an alternative feels bad, but we simply couldn't maintain the WX code anymore, and had to find the resources to maintain QT stuff first. So, no, we don't have that specific visualization in Qt, sorry. Joe, this means we've long stopped supporting your widget – it works on most machines, on others it doesn't, and we can't really help you in the latter case. Now, would one get started with developing a strip chart for Qt? Either one cheats a bit and just implements something that hands n_points sized chunks of data to the Qt GUI time sink, which always are basically the last chunk, with old samples "shifted out" and new samples "shifted in", or one would actually go and do a deep C++/Qt dive and write a proper stripchart widget. Best regards, Marcus On Sun, 2019-03-10 at 16:12 -0600, Joe Martin wrote: > Hi Wayne, > > I am using the strip-chart option of the WX GUI Scope Sink block in > GRC to perform drift scans in my radio astronomy project. Works like > a champ! > > Select “Stripchart” in the Trigger option. > > Regards, > > Joe > > > On Mar 10, 2019, at 3:24 PM, Wayne Hilliard > > wrote: > > > > Hello, > > Question. Has there been any movement on adding a strip chart > > option to this gui? > > > > I know WX_gui usage is discouraged and i have a radio astronomy app > > I've been working on that uses QT_Gui. > > > > I've looked around some on github and don't have a clue on where I > > would start to try something on my own. > > > > Any help would be appreciated . > > Thanks in advance!! > > > > Wayne Hilliard > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [Announcement] GNU Radio pre-3.8: pre-Change notification
FYI, Ubuntu 16.04 lets you `pip install cmake` for the latest version. On Sat, Mar 9, 2019 at 2:03 PM Marcus Müller wrote: > In order to proliferate a bit of knowledge about what is currently > changing while we're progressing on our development branch towards a > GNU Radio 3.8.0.0 release: > > CMake req. version -> CMake 3.8 (Ubuntu 16.04 deprecation) > == > > We (mostly: Andrej!) managed to rework GNU Radio's CMake > infrastructure. This comes to our great advantage, because it de-crufts > not only the main GNU Radio build system, but also OOTs, and we can now > actually build out of tree modules with far, far fewer CMake files > distributed with the module. > > But that means we need a somewhat recent CMake (3.8). Ubuntu 16.04 only > ships CMake 3.5.1. > > Best regards, > Marcus > > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] qt_gui_time
Yeah, I know, there is a drive to deprecate WX GUIs but I find them to be very useful myself. Joe > On Mar 10, 2019, at 4:12 PM, Joe Martin wrote: > > Hi Wayne, > > I am using the strip-chart option of the WX GUI Scope Sink block in GRC to > perform drift scans in my radio astronomy project. Works like a champ! > > Select “Stripchart” in the Trigger option. > > Regards, > > Joe > >> On Mar 10, 2019, at 3:24 PM, Wayne Hilliard wrote: >> >> Hello, >> Question. Has there been any movement on adding a strip chart option to this >> gui? >> >> I know WX_gui usage is discouraged and i have a radio astronomy app I've >> been working on that uses QT_Gui. >> >> I've looked around some on github and don't have a clue on where I would >> start to try something on my own. >> >> Any help would be appreciated . >> Thanks in advance!! >> >> Wayne Hilliard >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] qt_gui_time
Hi Wayne, I am using the strip-chart option of the WX GUI Scope Sink block in GRC to perform drift scans in my radio astronomy project. Works like a champ! Select “Stripchart” in the Trigger option. Regards, Joe > On Mar 10, 2019, at 3:24 PM, Wayne Hilliard wrote: > > Hello, > Question. Has there been any movement on adding a strip chart option to this > gui? > > I know WX_gui usage is discouraged and i have a radio astronomy app I've been > working on that uses QT_Gui. > > I've looked around some on github and don't have a clue on where I would > start to try something on my own. > > Any help would be appreciated . > Thanks in advance!! > > Wayne Hilliard > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] qt_gui_time
Hello, Question. Has there been any movement on adding a strip chart option to this gui? I know WX_gui usage is discouraged and i have a radio astronomy app I've been working on that uses QT_Gui. I've looked around some on github and don't have a clue on where I would start to try something on my own. Any help would be appreciated . Thanks in advance!! Wayne Hilliard ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Installation of gr-radar
Assuming you're running some fork of Debian, type apt list | grep libqwt6 to see if it's available. If it's available but not installed type apt-get install libqwt6 -- Cinaed On 3/10/19 12:53 PM, Talha Farooq wrote: > Hi > I am installing GNU gr-radar in Ubuntu. I installed all dependencies and > now while in step of making build of gr-radar by command 'make' I am > getting below mentioned error Though I upgraded QT to latest version > which is "Using Qt version 5.7.1 in /usr/lib/arm-linux-gnueabih". I read > in Issue#16 that you should use QT6 but I am unable to find any stable > version of QT6 or how to install that. > Error: > [ 1%] Building CXX object > lib/CMakeFiles/gnuradio-radar.dir/moc_scatter_plot.cxx.o > In file included from /home/pi/gr-radar/build/lib/moc_scatter_plot.cxx:9:0: > /home/pi/gr-radar/build/lib/../../lib/scatter_plot.h:24:22: fatal error: > qwt_plot.h: No such file or directory > #include > ^ > compilation terminated. > lib/CMakeFiles/gnuradio-radar.dir/build.make:77: recipe for target > 'lib/CMakeFiles/gnuradio-radar.dir/moc_scatter_plot.cxx.o' failed > make[2]: *** [lib/CMakeFiles/gnuradio-radar.dir/moc_scatter_plot.cxx.o] > Error 1 > CMakeFiles/Makefile2:137: recipe for target > 'lib/CMakeFiles/gnuradio-radar.dir/all' failed > make[1]: *** [lib/CMakeFiles/gnuradio-radar.dir/all] Error 2 > Makefile:138: recipe for target 'all' failed > make: *** [all] Error 2 > image.png > Regards: > Talha Farooq Hashmi > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Installation of gr-radar
Hello Talha, Qt and Qwt are different softwares. Gr-radar depends on Qt4 and Qwt6. The error has to do with Qwt. I guess you don’t have the correct version of Qwt installed. PS: Please avoid to send pictures to mailing lists, since this takes up space in everyone's mailbox. Better use a service like imgur and post the link to the picture in your mail :) Best, Sebastian Müller gse...@gmail.com PGP ID DC2AA3EE Am 10. März 2019 um 20:54:39, Talha Farooq (talhafaro...@gmail.com) schrieb: > Hi > I am installing GNU gr-radar in Ubuntu. I installed all dependencies and > now while in step of making build of gr-radar by command 'make' I am > getting below mentioned error Though I upgraded QT to latest version which > is "Using Qt version 5.7.1 in /usr/lib/arm-linux-gnueabih". I read in > Issue#16 that you should use QT6 but I am unable to find any stable version > of QT6 or how to install that. > Error: > [ 1%] Building CXX object > lib/CMakeFiles/gnuradio-radar.dir/moc_scatter_plot.cxx.o > In file included from /home/pi/gr-radar/build/lib/moc_scatter_plot.cxx:9:0: > /home/pi/gr-radar/build/lib/../../lib/scatter_plot.h:24:22: fatal error: > qwt_plot.h: No such file or directory > #include > ^ > compilation terminated. > lib/CMakeFiles/gnuradio-radar.dir/build.make:77: recipe for target > 'lib/CMakeFiles/gnuradio-radar.dir/moc_scatter_plot.cxx.o' failed > make[2]: *** [lib/CMakeFiles/gnuradio-radar.dir/moc_scatter_plot.cxx.o] > Error 1 > CMakeFiles/Makefile2:137: recipe for target > 'lib/CMakeFiles/gnuradio-radar.dir/all' failed > make[1]: *** [lib/CMakeFiles/gnuradio-radar.dir/all] Error 2 > Makefile:138: recipe for target 'all' failed > make: *** [all] Error 2 > [image: image.png] > Regards: > Talha Farooq Hashmi > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] compressing I/Q files
Hi Kristoff, Benny and Alban,
TL;DR:
Benny is exactly on spot. Other than that, decimate your signal if you
know the bandwidth is less than your sampling rate, and don't put too
much hope on audio encoders.
Long Version:
Point is: the signal coming from your SDR device, whatever that might
be, has finite resolution – typically, no more than 16 bits per
channel. Hence, the conversion from float to short (or directly getting
short, if your device driver allows that) is lossless. For example,
USRPs' driver (UHD), and the GNU Radio USRP source, can be configured
to hand out the signed complex 16 bit conversion of the data from the
network or USB interface instead of the float32 conversion.
Any other compression method can only do so much:
Your signal recording is essentially random – meaning that all values
should be roughly equally likely. Maybe extreme high amplitudes are a
little rarer, since you'd typically avoid those to stay clear of
clipping.
That means that the average info per sample is relatively high: From
seeing other samples, we know very little about it, so the surprise we
get from its actual value is pretty high. Information-theoretically,
the expected information content per sample is the entropy of a source.
Information and entropy are both measured in bit – the completely fair
random decision between 0 and 1 ("flipping a coin") is worth 1 bit, and
picking one out of 2¹⁶ values perfectly randomly is worth 16 bit.
(Lossless) compression can, best case, achieve a compression where the
amount of bits used per sample is equal to the entropy of the source.
Now, if your signal is somewhat noisy, and other than that relatively
interesting (i.e. you're not observing a constant value), your source
entropy often approaches the limit given by the ADC – in my tests, even
on severly backed-off signals, standard Huffmann and Lempel-Ziv-Welch
compressors (zip, gzip, 7z, zstd, bz2, xz) achieved negligible
compression ratios on radio recordings.
I've tried FLAC, too – FLAC doesn't allow to set the actual sampling
rate as high as was truly used by typical SDR hardware (i.e. the header
field for the sampling rate simply doesn't have enough size to allow
for 10⁷, for example). But that's mainly a metadata problem that can be
solved by ignorance.
However, FLAC's linear prediction coding relies on signals having
a) "small" deviation from a linear function for short time periods, and
b) the following residual coding relies on geometric distribution –
and that's usually not given, because
a) if you already know you will be in need of compression, you're
probably not significantly oversampling your signal, but are already
decimating it to a rate barely more than sufficient. Everything else
would be a larger waste of space – and has no benefits for signal
analysis later, and
b) with the prior assumption broken, only a zero-order linear precoder
doesn't make things worse – i.e., simply handing through the input
samples to the residual coder. That residual coder, as said, depends on
the distribution of amplitudes to follow a specific statistic to work
well. Sadly, that statistic doesn't apply to I signals, typically.
My experience is that FLAC doesn't work well for anything that's not
massively oversampled AM audio – which is no surprise, because that
literally isn't very different from audio, which is what FLAC was
designed for.
However, my FLAC experiments lie years in the past – maybe the encoder
got more versatile; Alban, do you have deviating experience?
Best regards,
Marcus
On Sun, 2019-03-10 at 11:54 +, Benny Alexandar wrote:
> Yes, converting float 32bit to short16 is an option, compressing
> using 7zip or gzip won't give good compression .
> From: Discuss-gnuradio <
> discuss-gnuradio-bounces+ben.alex=outlook@gnu.org> on behalf of
> Kristoff
> Sent: Sunday, March 10, 2019 3:57 PM
> To: discuss-gnuradio@gnu.org
> Subject: [Discuss-gnuradio] compressing I/Q files
>
> Hi all,
>
>
>
> Simple and short question:
> What is the best way to compress a raw I/Q file? A generic
> compression-tool like gzip, zip? Or are there better and specialised
> tools?
>
>
> Is converting the data in the I/Q file from float to short an option?
>
>
> Kristoff
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] compressing I/Q files
FLAC ? Le dim. 10 mars 2019 à 12:56, Benny Alexandar a écrit : > Yes, converting float 32bit to short16 is an option, compressing using > 7zip or gzip won't give good compression . > -- > *From:* Discuss-gnuradio outlook@gnu.org> on behalf of Kristoff > *Sent:* Sunday, March 10, 2019 3:57 PM > *To:* discuss-gnuradio@gnu.org > *Subject:* [Discuss-gnuradio] compressing I/Q files > > Hi all, > > > > Simple and short question: > What is the best way to compress a raw I/Q file? A generic > compression-tool like gzip, zip? Or are there better and specialised tools? > > > Is converting the data in the I/Q file from float to short an option? > > > Kristoff > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- Alban MEFFRE F4GSW ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] compressing I/Q files
Yes, converting float 32bit to short16 is an option, compressing using 7zip or gzip won't give good compression . From: Discuss-gnuradio on behalf of Kristoff Sent: Sunday, March 10, 2019 3:57 PM To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] compressing I/Q files Hi all, Simple and short question: What is the best way to compress a raw I/Q file? A generic compression-tool like gzip, zip? Or are there better and specialised tools? Is converting the data in the I/Q file from float to short an option? Kristoff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] compressing I/Q files
Hi all, Simple and short question: What is the best way to compress a raw I/Q file? A generic compression-tool like gzip, zip? Or are there better and specialised tools? Is converting the data in the I/Q file from float to short an option? Kristoff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
