Re: [Discuss-gnuradio] QT Vector sink question?

[Glen I Langston]

Hi Marcus,

Thanks for your note.  Yes, certainly I know that I should have not had IQ 
balance running now,
but I falsely assumed leaving the default setting would not hurt anything.  
Really a
major time sink, finding this trivial problem…

Concerning your use of the Odroids  did you say use VNC with them or just ssh 
in and run
without graphics display?   If you do use VNC, which VNC program did you 
install?

Thanks again,

Glen



> On Jun 8, 2018, at 11:12 AM, Marcus D. Leech  wrote:
> 
> On 06/08/2018 11:04 AM, Glen I Langston wrote:
>> Hello Gnuradio Aficionados,
>> 
>> In case any has had similar problems with the AIRSPY and spectra aliases,
>> the problem is solved very simply.   Do not heave the IQ balance setting at 
>> “Automatic”
>> as this causes IQ balancing on Linux devices.  This was the cause of our 
>> problems
>> with aliases in the spectra.  The code seems to be OK on Macs but definitely 
>> causes
>> problems on Linux.
>> 
>> Who should I talk to about this and other OSMOSDR issues with Airspy code 
>> for Linux?
>> 
>> Thanks
>> 
>> Glen
>> 
>> PS there was an OSMOSDR Gnuradio companion interface change and I’m confused
>> over what, exactly, the settings for “linearity” and “sensitivity” do for 
>> AIRSPY.
> The I/Q balancing code in gr-osmosdr doesn't work very well with radio 
> astronomy--it will essentially never converge.  It's only really useful for
>  spectra that contain a number of narrow-band features, which, hopefully, 
> radio astronomy doesn't have :)
> 
> Automated I/Q balancing is a subject where there are NO universal "passive" 
> solutions.  Each approach has its place. Radio Astronomy isn't one of
>  them :(
> 
> 
>> 
>>> On May 21, 2018, at 2:50 PM, Glen I Langston  
>>> wrote:
>>> 
>>> Hello all,
>>> 
>>> Thanks for all the interesting discussion.  Very educational.
>>> 
>>> I’ve got a pair of questions concerning the QT vector sink.
>>> 
>>> My application uses the vector sink for plotting and diagnostics
>>> of averaged spectra.
>>> 
>>> I’m getting the impression that the QT vector sink is using a good fraction
>>> of my computer resources, despite trying to reduce the update intervals.
>>> 
>>> My question is 1) can I somehow turn off the Min and Max functions and any
>>> averaging of the data in the QT vector plotter?
>>> 
>>> The second question concerns a waterfall plot for the vectors I’m
>>> generating.   The QT waterfall plot does not accept a vector.
>>> If I turn the vector back into a stream, then the QT waterfall plot then
>>> Fourier transforms the spectra back. making a mess.
>>> 
>>> So the Second question: 2) is there a way to provide the QT water fall 
>>> plotter
>>> with a Vector and not have it FFT the data?
>>> 
>>> Thanks
>>> 
>>> Glen
>>> 
>>> FYI The code for Radio Astronomy is currently available
>>> (both observing interface and examples) at:
>>> 
>>> git clone http://www.github.com/glangsto/gr-nsf
>>> 
>>> 
>>> 
>>> 
>> 
>> ___
>> 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] Visualising data with GNURadio

[CEL]

Hi Jaco,

this is really a reasonable thing to want, but to be honest, GNU
Radio's visualizations are very much oriented along the streaming
nature of GNU Radio – and scrollback doesn't fit all to well.

I recommend https://github.com/miek/inspectrum , which is relatively
new, and relatively cool :)

Other than that, there was a quite interesting email thread about this
in 2014 [1] with scores of ideas and tool recommendations!

Best regards,
Marcus

[1] https://lists.gnu.org/archive/html/discuss-gnuradio/2014-07/msg0021
1.html
On Fri, 2018-06-08 at 18:07 +0200, Jaco Versfeld wrote:
> Good day,
> 
> The short story:
> 
> I have data sets (quite large) in .wav format.  I want to perform
> basic signal processing as well as more complex algorithms on blocks
> of the data and then display the output.  It would be great if one
> could "scroll" through the data.  Are there any blocks that can do
> that?
> 
> 
> Slightly longer story:
> 
> I am busy with passive acoustic monitoring of cetaceans.  Data is
> collected by hydrophones and stored in .wav files.  These files tend
> to be very large.  I want to analyse these signals, and view blocks
> of the data stream.  I successfully created a flowgraph where I
> filtered the data, and then displayed both the time and frequency
> domain graphs.  Because of some basic prior work with SDRs, I love
> the GNURadio environment.   However, if one could view a block of the
> data at a time and then scroll/proceed to the next block, it would be
> really great to do post-analysis.
> 
> Kind regards,
> Jaco 
> 
> ___
> 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] make maint-3.7 fails

[Tom McDermott]

Indeed that was the issue.   git submodule update fixed.
All build and runs now.   Many thanks !

Seems that git submodule is a bit confusing for me.

-- Tom, N5EG



On Fri, Jun 8, 2018 at 9:27 AM, Müller, Marcus (CEL) 
wrote:

> Hi Tom,
>
> got a bit of worries about this one:
>
> On Fri, 2018-06-08 at 09:17 -0700, Tom McDermott wrote:
> > modified:   volk (new commits)
>
> Which basically means that the Volk submodule isn't in the state the
> main module's branch expects it to be, and that's exactly what's going
> wrong there.
>
> Best guess: git `submodule update` should fix this. Afterwards, `git
> status` should not contain any info about the submodule containing any
> changes.
>
> Best regards,
> Marcus
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio not installing: Build Failed

[Jason Matusiak]

Derek, this was much appreciated and seems to have fixed my problems on Centos 
7.
 
A note about the C++11 mandatory changes that would help me (and probably 
others).  There are a lot of us who have been forced into using Centos 7 and 
their so very antiquated tools.  Ubuntu's newer tools (probably cmake) are 
smart enough to know to switch to c++11 because of the need in the source code. 
 Centos doesn't appear to be smart enough to do that, and so even though we can 
build the c++11 code if the tools that are installed if we hand-touched the 
source with some mods, the system wasn't smart enough to do it on its own.
 
So my hope is that there might be something you can do in the recipes or 
gnuradio itself that would force the Centos tools to use c++11 (it appears that 
some mods to the CMakeLists.txt file like I mentioned in my other thread might 
be enough (and it shouldn't heart the Ubuntu users any).
 
Anyway, thanks for the temporary rollback!
 
- Original Message - 

  Hello Curt,
 
The fix for this issue was merged into the GNU Radio master branch last night. 
Thank you for posting the PR and describing your solution here. The 3.8 release 
is going to raise the minimum version requirements of an appreciable number of 
dependencies in order to make sure that GNU Radio development can keep moving 
forward smoothly. C++11 will be mandatory on master at some time before that 
release occurs, but today isn't here quite yet.
 
Thanks,
Derek


 On Fri, Jun 8, 2018 at 2:11 AM, Curt Corum  wrote:
   Mir and Jason,
 I've been working through something similar and have found a solution.
 Please see the github issue: https://github.com/gnuradio/pybombs/issues/502 
and below.
 -Curt
  
 Dear pybombs team and community,
 Had issues with building gnuradio-default on relatively clean but up to date 
Ubuntu 16.04 LTS. Seems related to 
https://www.mail-archive.com/discuss-gnuradio@gnu.org/msg66739.html 
https://www.mail-archive.com/discuss-gnuradio@gnu.org/msg66739.html #424 #448
 $ pybombs --version
 2.3.2
 $ gcc --version
 gcc (Ubuntu 6.4.0-17ubuntu1~16.04) 6.4.0 20180424
 It was necessary to do the following to get the gnuradio-default recipe to 
build thrift, boost, uhd and gnuradio without errors:
 >sudo apt-get install g++-6
 >sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-6 60 --slave 
 >/usr/bin/g++ g++ /usr/bin/g++-6
 >sudo update-alternatives --config gcc
  and setting gcc-6 to default
 uninstall most of boost 1.58 binary packages (all but non -dev distribution 
packages)
 adding the following to gnuradio-default.lwr
 # gnuradio-default.lwr
 #binary boost linking fails *** CAC
 boost:
 forcebuild: True
  and modifying config.yml (directly as could not figure out how to escape 
-std=c++-11 for pybombs config --env)
 # config.yml
 env:
 CXXFLAGS: -std=c++11 -fext-numeric-literals
  and modifying boost.lwr
  # boost.lwr
 satisfy:
 deb: libboost-all-dev >= 1.6 || libboost-dev >= 1.6
 rpm: (boost-devel >= 1.6) || (boost_1_61-devel >= 1.6) || (boost_1_64-devel >= 
1.6) || (boost_1_65-devel >= 1.6)
 pacman: boost >= 1.6
 port: boost >= 1.6
 portage: dev-libs/boost >= 1.6
  Wanted to make sure this got captured as it took several days to resolve and 
seems to be an ongoing issue.
 -Curt
  
  
 
 On 06/07/2018 11:00 AM, discuss-gnuradio-requ...@gnu.org wrote:
 Message: 5
 Date: Thu, 7 Jun 2018 15:13:38 +0100
 From: Mir Muhammad Lodro 
 To: discuss-gnuradio@gnu.org
 Subject: [Discuss-gnuradio] GNU Radio not installing: Build Failed
 Message-ID:
 
 Content-Type: text/plain; charset="utf-8"
 
 Hi All
 i am installing GNU Radio on Linux 16.04, but it's not installing by saying
 this file requires compiler and library support for ISO 2011 standard. This
 can be done by issuing -std=c++11 or -std=gnu++11 when one has to run
 single file. But here the build process is automated. I would be grateful
 if you can look into the following prompt response and guide what could be
 the possible solution. I have already installed GNU Radio on different
 machine running 16.04, but I am surprise to see the error when installing
 on another machine and despite repeating the very same steps.
 
 The as it as prompt response is:
 
 root@pezp63763:/home/eexmmlo# pybombs prefix init -a default
 prefix/default/ -R gnuradio-default
 PyBOMBS - INFO - PyBOMBS Version 2.3.2
 PyBOMBS.prefix - WARNING - There already is a prefix in
 `/home/eexmmlo/prefix/default'.
 Continue using this path Y/[N]? y
 Alias `default' already exists, overwrite Y/[N]? y
 PyBOMBS.prefix - INFO - Installing default packages for prefix...
 PyBOMBS.prefix - INFO -
 - gnuradio
 PyBOMBS.install_manager - INFO - Phase 1: Creating install tree and
 installing binary packages:
 Install tree:
 |
 \- gnuradio
 PyBOMBS.install_manager - INFO - Phase 2: Recursively installing source
 packages to prefix:
 PyBOMBS.install_manager - INFO - Installing package: gnuradio
 PyBOMBS.Packager.source - WARNING - Build dir already exists:
 

[Discuss-gnuradio] Visualising data with GNURadio

[Jaco Versfeld]

Good day,

The short story:

I have data sets (quite large) in .wav format.  I want to perform basic
signal processing as well as more complex algorithms on blocks of the data
and then display the output.  It would be great if one could "scroll"
through the data.  Are there any blocks that can do that?


Slightly longer story:

I am busy with passive acoustic monitoring of cetaceans.  Data is collected
by hydrophones and stored in .wav files.  These files tend to be very
large.  I want to analyse these signals, and view blocks of the data
stream.  I successfully created a flowgraph where I filtered the data, and
then displayed both the time and frequency domain graphs.  Because of some
basic prior work with SDRs, I love the GNURadio environment.   However, if
one could view a block of the data at a time and then scroll/proceed to the
next block, it would be really great to do post-analysis.

Kind regards,
Jaco
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] make maint-3.7 fails

[Tom McDermott]

Ubuntu 16.04

I've switched to maint-3.7 branch from maint.

$ git checkout maint-3.7
$ git pull --recurse-submodules=ON

$ git status
On branch maint-3.7
Your branch is up-to-date with 'origin/maint-3.7'.
Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git checkout -- ..." to discard changes in working directory)

modified:   volk (new commits)


I then deleted all contents of /build

$ cmake -j8 ..
   successful result, all components enabled, none disabled

$ make ..
   fails with:

... snip ...

[ 65%] Building CXX object
gr-blocks/lib/CMakeFiles/test-gr-blocks.dir/qa_gr_block.cc.o
[ 65%] Building CXX object
gr-filter/lib/CMakeFiles/gnuradio-filter.dir/interp_fir_filter_ccf_impl.cc.o
[ 66%] Building CXX object
gr-fec/lib/CMakeFiles/gnuradio-fec.dir/polar_common.cc.o
[ 66%] Building CXX object
gr-fec/lib/CMakeFiles/gnuradio-fec.dir/polar_decoder_sc_list.cc.o
[ 66%] Building CXX object
gr-filter/lib/CMakeFiles/gnuradio-filter.dir/interp_fir_filter_fcc_impl.cc.o
[ 66%] Building CXX object
gr-fec/lib/CMakeFiles/gnuradio-fec.dir/polar_decoder_common.cc.o
[ 66%] Building CXX object
gr-fec/lib/CMakeFiles/gnuradio-fec.dir/scl_list.cc.o
[ 66%] Building CXX object
gr-fec/lib/CMakeFiles/gnuradio-fec.dir/polar_encoder_systematic.cc.o
[ 66%] Building CXX object
gr-fec/lib/CMakeFiles/gnuradio-fec.dir/polar_decoder_sc_systematic.cc.o
/home/tom/gnuradio/gr-fec/lib/polar_decoder_common.cc: In member function
‘void gr::fec::code::polar_decoder_common::butterfly_volk(float*, unsigned
char*, int, int, int)’:
/home/tom/gnuradio/gr-fec/lib/polar_decoder_common.cc:128:81: error: too
few arguments to function
 volk_32f_8u_polarbutterfly_32f(llrs, u, block_power(), stage,
u_num, row);


... snip ...

It looks like perhaps volk and polar have conflicting interface somewhere.

Any advice on how to get volk / maint-3.7 to build?

-- Tom, N5EG
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] make maint-3.7 fails

[CEL]

Hi Tom,

got a bit of worries about this one:

On Fri, 2018-06-08 at 09:17 -0700, Tom McDermott wrote:
> modified:   volk (new commits)

Which basically means that the Volk submodule isn't in the state the
main module's branch expects it to be, and that's exactly what's going
wrong there.

Best guess: git `submodule update` should fix this. Afterwards, `git
status` should not contain any info about the submodule containing any
changes.

Best regards,
Marcus
 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio not installing: Build Failed

[Derek Kozel]

Hi Jason,

Centos 7 is being specifically looked at for 3.8 as it will define the
minimum version of most dependencies. We don't yet have a CentOS 7
regression test VM, but it is something to consider. We will be enforcing
the C++11 requirement in CMake which I believe is sufficient to make all
this work on Centos, but it would be great to get your eyes on it once
we've made that change to ensure that it does work properly for you. I
believe the hope is to make that change in the next month.

Ubuntu 14.04 is the other older OS which pushes the minimum versions of
dependencies, it remains supported (by Canonical) till the middle of next
year. My *entirely personal* guess is that CentOS 7(.0?) official support
on master will be dropped around the same time, but of course no one has
any interest in making an arbitrary break in compatibility. The maint-X.X
branches should help reduce the impact and increase the longevity of GNU
Radio on these very long term support OSs.

Cheers,
Derek


On Fri, Jun 8, 2018 at 4:01 PM, Jason Matusiak <
ja...@gardettoengineering.com> wrote:

> Derek, this was much appreciated and seems to have fixed my problems on
> Centos 7.
>
> A note about the C++11 mandatory changes that would help me (and probably
> others).  There are a lot of us who have been forced into using Centos 7
> and their so very antiquated tools.  Ubuntu's newer tools (probably cmake)
> are smart enough to know to switch to c++11 because of the need in the
> source code.  Centos doesn't appear to be smart enough to do that, and so
> even though we can build the c++11 code if the tools that are installed if
> we hand-touched the source with some mods, the system wasn't smart enough
> to do it on its own.
>
> So my hope is that there might be something you can do in the recipes or
> gnuradio itself that would force the Centos tools to use c++11 (it appears
> that some mods to the CMakeLists.txt file like I mentioned in my other
> thread might be enough (and it shouldn't heart the Ubuntu users any).
>
> Anyway, thanks for the temporary rollback!
>
>
> - Original Message -
>
>
> Hello Curt,
>
> The fix for this issue was merged into the GNU Radio master branch last
> night. Thank you for posting the PR and describing your solution here. The
> 3.8 release is going to raise the minimum version requirements of an
> appreciable number of dependencies in order to make sure that GNU Radio
> development can keep moving forward smoothly. C++11 will be mandatory on
> master at some time before that release occurs, but today isn't here quite
> yet.
>
> Thanks,
> Derek
>
> On Fri, Jun 8, 2018 at 2:11 AM, Curt Corum  wrote:
>
>> Mir and Jason,
>>
>> I've been working through something similar and have found a solution.
>>
>> Please see the github issue: https://github.com/gnuradio/
>> pybombs/issues/502 and below.
>>
>> -Curt
>>
>>
>>
>> Dear pybombs team and community,
>>
>> Had issues with building gnuradio-default on relatively clean but up to
>> date Ubuntu 16.04 LTS. Seems related to https://www.mail-archive.com/
>> discuss-gnuradio@gnu.org/msg66739.html https://www.mail-archive.com/
>> discuss-gnuradio@gnu.org/msg66739.html #424
>>  #448
>> 
>>
>> $ pybombs --version
>> 2.3.2
>>
>> $ gcc --version
>> gcc (Ubuntu 6.4.0-17ubuntu1~16.04) 6.4.0 20180424
>>
>> It was necessary to do the following to get the gnuradio-default recipe
>> to build thrift, boost, uhd and gnuradio without errors:
>>
>> >sudo apt-get install g++-6
>> >sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-6 60 
>> >--slave /usr/bin/g++ g++ /usr/bin/g++-6
>> >sudo update-alternatives --config gcc
>>
>> and setting gcc-6 to default
>>
>> uninstall most of boost 1.58 binary packages (all but non -dev
>> distribution packages)
>> adding the following to gnuradio-default.lwr
>>
>> # gnuradio-default.lwr
>> #binary boost linking fails *** CAC
>> boost:
>>   forcebuild: True
>>
>> and modifying config.yml (directly as could not figure out how to escape
>> -std=c++-11 for pybombs config --env)
>>
>> # config.yml
>> env:
>>   CXXFLAGS: -std=c++11 -fext-numeric-literals
>>
>> and modifying boost.lwr
>>
>>  # boost.lwr
>>   satisfy:
>>   deb: libboost-all-dev >= 1.6 || libboost-dev >= 1.6
>>   rpm: (boost-devel >= 1.6) || (boost_1_61-devel >= 1.6) || 
>> (boost_1_64-devel >= 1.6) || (boost_1_65-devel >= 1.6)
>>   pacman: boost >= 1.6
>>   port: boost >= 1.6
>>   portage: dev-libs/boost >= 1.6
>>
>> Wanted to make sure this got captured as it took several days to resolve
>> and seems to be an ongoing issue.
>>
>> -Curt
>>
>>
>>
>>
>>
>> On 06/07/2018 11:00 AM, discuss-gnuradio-requ...@gnu.org wrote:
>>
>> Message: 5
>> Date: Thu, 7 Jun 2018 15:13:38 +0100
>> From: Mir Muhammad Lodro  
>> To: discuss-gnuradio@gnu.org
>> Subject: [Discuss-gnuradio] GNU Radio not installing: Build Failed
>> Message-ID:
>>   
>> 
>> Content-Type: text/plain; 

[Discuss-gnuradio] [GSoC'18][MIMO] Updates of the week

[Moritz Luca Schmid]

Hi all,

my new blog post 
just 
went online. I finished all milestones for the first coding period and 
started to implement the V-BLAST architecture.


Next week starts the first evaluation period.


Cheers

Luca

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] QT Vector sink question?

[Marcus D. Leech]

On 06/08/2018 12:06 PM, Glen I Langston wrote:

Hi Marcus,

Thanks for your note.  Yes, certainly I know that I should have not had IQ 
balance running now,
but I falsely assumed leaving the default setting would not hurt anything.  
Really a
major time sink, finding this trivial problem…

Concerning your use of the Odroids  did you say use VNC with them or just ssh 
in and run
without graphics display?   If you do use VNC, which VNC program did you 
install?

Thanks again,

Glen

I've been in the "I/Q correction hurting me" space before.  Took me 
quite a while to figure out what was going on, too...


My Odroid systems (C1 and XU4Q) are oriented towards completely-headless 
operating.  For 99.9% of an observing run, you
  don't need real-time visualization.  You just need the data recorded 
for further processing.


So, to that end, I've been working, as you may know, on a system to 
"meet in the middle".  With data recording and 1st-order processing
  happening on the Odroids, and quasi-real-time visualization via the 
web.  Starting/stopping experiments is also via the web, as is rudimentary

  system configuration.

I call this system "Orion".   Observational Radio Instrument On the 
Net.   I hope to have system images available for both C1 and XU4Q 
sometime in

  the next "little while".  For certain values of "little while".

Right now the system supports what I call a "combo radiometer" mode with 
both FX and "fast" versions.  This is a two-channel affair, computing
  the total power on each channel, the differential, and the 
cross-correlation, as well as the spectral estimates for both channels.  
The "fast"
  version eliminates the FX structure, and does scalar 
cross-correlation only, and the spectral estimators run in a "stuttered" 
mode.  This
  should roughly double the maximum sample rate on an XU4Q to somewhere 
around 12-15Msps.


The other mode, that I just added, is really targeted at a Odroid C1 
with 3 RTLSDR dongles, to do that D1 exploration we discussed on another 
forum.


The current code-base (most of it, some of the system-config stuff isn't 
in the repo  yet, and I don't have a Makefile yet) is at:


https://github.com/ccera-astro/school_telescopes



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] QT Vector sink question?

[Glen I Langston]

Hello Gnuradio Aficionados,

In case any has had similar problems with the AIRSPY and spectra aliases,
the problem is solved very simply.   Do not heave the IQ balance setting at 
“Automatic”
as this causes IQ balancing on Linux devices.  This was the cause of our 
problems
with aliases in the spectra.  The code seems to be OK on Macs but definitely 
causes
problems on Linux.

Who should I talk to about this and other OSMOSDR issues with Airspy code for 
Linux?

Thanks

Glen

PS there was an OSMOSDR Gnuradio companion interface change and I’m confused
over what, exactly, the settings for “linearity” and “sensitivity” do for 
AIRSPY.


> On May 21, 2018, at 2:50 PM, Glen I Langston  
> wrote:
> 
> Hello all,
> 
> Thanks for all the interesting discussion.  Very educational.
> 
> I’ve got a pair of questions concerning the QT vector sink.
> 
> My application uses the vector sink for plotting and diagnostics
> of averaged spectra.
> 
> I’m getting the impression that the QT vector sink is using a good fraction
> of my computer resources, despite trying to reduce the update intervals.
> 
> My question is 1) can I somehow turn off the Min and Max functions and any
> averaging of the data in the QT vector plotter?
> 
> The second question concerns a waterfall plot for the vectors I’m 
> generating.   The QT waterfall plot does not accept a vector.
> If I turn the vector back into a stream, then the QT waterfall plot then
> Fourier transforms the spectra back. making a mess.
> 
> So the Second question: 2) is there a way to provide the QT water fall plotter
> with a Vector and not have it FFT the data?
> 
> Thanks
> 
> Glen
> 
> FYI The code for Radio Astronomy is currently available
> (both observing interface and examples) at:
> 
> git clone http://www.github.com/glangsto/gr-nsf
> 
> 
> 
> 


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] QT Vector sink question?

[Marcus D. Leech]

On 06/08/2018 11:04 AM, Glen I Langston wrote:

Hello Gnuradio Aficionados,

In case any has had similar problems with the AIRSPY and spectra aliases,
the problem is solved very simply.   Do not heave the IQ balance setting at 
“Automatic”
as this causes IQ balancing on Linux devices.  This was the cause of our 
problems
with aliases in the spectra.  The code seems to be OK on Macs but definitely 
causes
problems on Linux.

Who should I talk to about this and other OSMOSDR issues with Airspy code for 
Linux?

Thanks

Glen

PS there was an OSMOSDR Gnuradio companion interface change and I’m confused
over what, exactly, the settings for “linearity” and “sensitivity” do for 
AIRSPY.
The I/Q balancing code in gr-osmosdr doesn't work very well with radio 
astronomy--it will essentially never converge.  It's only really useful for
  spectra that contain a number of narrow-band features, which, 
hopefully, radio astronomy doesn't have :)


Automated I/Q balancing is a subject where there are NO universal 
"passive" solutions.  Each approach has its place. Radio Astronomy isn't 
one of

  them :(





On May 21, 2018, at 2:50 PM, Glen I Langston  wrote:

Hello all,

Thanks for all the interesting discussion.  Very educational.

I’ve got a pair of questions concerning the QT vector sink.

My application uses the vector sink for plotting and diagnostics
of averaged spectra.

I’m getting the impression that the QT vector sink is using a good fraction
of my computer resources, despite trying to reduce the update intervals.

My question is 1) can I somehow turn off the Min and Max functions and any
averaging of the data in the QT vector plotter?

The second question concerns a waterfall plot for the vectors I’m
generating.   The QT waterfall plot does not accept a vector.
If I turn the vector back into a stream, then the QT waterfall plot then
Fourier transforms the spectra back. making a mess.

So the Second question: 2) is there a way to provide the QT water fall plotter
with a Vector and not have it FFT the data?

Thanks

Glen

FYI The code for Radio Astronomy is currently available
(both observing interface and examples) at:

git clone http://www.github.com/glangsto/gr-nsf






___
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] Constellations, EVM and SNR Questions

[Luis Felipe Albarracin Sanchez]

Thank you all,

I will try that.

Kind regards.

On Thu, Jun 7, 2018 at 10:16 PM, Martin K 
wrote:

> The following call is how I read data into MATLAB from the GNURadio file
> sink. I think this would almost work in Octave as well but I haven't tried.
> If not it, it at least illustrates the proper format.
>
> FileID = fopen('Filename','r');
> import_channels = 2;
> SamplesPerFrame = 1024;
> import_format = 'float32';
> x = fread(FileID,[import_channels SamplesPerFrame],import_format)';
> complex_baseband = complex(x(:,1),x(:,2));
>
> I have this embedded in a MATLAB system class. I extricated the
> fopen/fread() calls for clarity.
> HTH
> --
> Martin K.
>
>
>
> On Thu, Jun 7, 2018 at 9:30 AM, Federico 'Larroca' La Rocca <
> flarr...@gmail.com> wrote:
>
>> Hello again,
>>
>> To export from GNU Radio to octave, you should first use a "File Sink"
>> block and then one of the scripts in gr-utils/octave. I'm pretty sure they
>> are compatible with matlab too.
>>
>> About the SNR, that depends on what you want. If you want the power of
>> noise that actually affects your decision system divided by the power of
>> the symbols, then MER is what you are looking for (assuming your sampling
>> and frequency correction works properly). If you want the more classic SNR
>> (i.e. power of the useful signal divided by the total noise power in the
>> band), then that's more involved. You may try the following: since you know
>> the constellation points and the pulse, you may easily calculate the power
>> of the useful signal (assuming your AGC works properly and that the channel
>> is flat fading). The difference between this power and the actual received
>> power is due to noise (assuming independence).
>>
>> However, what matters performance-wise is the amount of noise that gets
>> into the decision system, and not the actual SNR.
>>
>> Hope it helps!
>>
>>
>>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 
Eng. Luis Felipe Albarracin
PMP
CCNA/CCDA/CCNP/CCDP/CCIP
ITIL v3 Foundation
Msc. Telematics / MBA
"Die Grenzen meiner Sprache bedeuten die Grenzen meiner Welt"
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] A few questions regarding gr-ieeee802-11

[CEL]

Hi Tal,

3.7 is the maint-3.7 branch, master works towards 3.8, and a milestone
of that will be when next is merged into it. You can expect a 3.8
release when next is merged, and all the serious kinks that came with
it are contained enough for us to risk a release :)

Best regards,
Marcus

On Fri, 2018-06-08 at 14:03 +0200, Tal Peer wrote:
> Hi Bastian,
> 
> Thanks for the clarification about the matched filter -- I basically got the 
> scaling part wrong. Now everything makes sense. 
> About the next into master merge: I understand that currently master is the 
> 3.7 branch and next the 3.8 branch (or is it?), so can we expect a 3.8 
> release when the merge happens?
> 
> Cheers,
> Tal
> 
> On Fri, Jun 8, 2018 at 12:48 PM, Bastian Bloessl  wrote:
> > Hi,
> > 
> > On 06/08/2018 10:18 AM, Tal Peer wrote:
> > > 1. In the Sync Long block, the input is put through a matched filter 
> > > defined by the long training sequence in time domain. I'm probably 
> > > overseeing something here, but  I would expect this sequence to be the 
> > > same as the sequence given in table I-6 of the standard (well, a part of 
> > > it at least, since it repeats 2.5 times). Now, I understand the LONG 
> > > vector is generated using the create_long.R script and not knowing any R 
> > > I tried to reproduce this in MATLAB. However, after some experiments I 
> > > figured that in order to reproduce the same sequence I have to run in 
> > > MATLAB (a is the freq. domain sequence):
> > > 
> > > fliplr(fft(ifftshift(a)/sqrt(52)))
> > > 
> > > where from the R script I would actually expect (as we're transforming 
> > > the sequence from frequency to time domain and also conjugating it to 
> > > create a matched filter):
> > > 
> > > fliplr(conj(ifft(fftshift(a)/sqrt(52
> > > 
> >  
> > I'm not sure if I understand you correctly. It sounds like you think the 
> > steps in the R-script are reasonable, but you fail to reproduce it in 
> > MATLAB. I don't have MATLAB, so I cannot test it, but maybe you forgot an 
> > 'i' and were using the fft instead of the ifft.
> > 
> > I've done it again in Python and it results in exactly the steps that you 
> > seem to expect.
> > 
> > To reproduce the sequence in the standard:
> > 
> > 
> > import numpy as np
> > 
> > # frequency domain
> > fd = np.array([0]*6 + [1, 1, -1, -1, 1, 1, -1, 1, -1, 1, 1, 1, 1, 1, 1, -1, 
> > -1, 1, 1, -1, 1, -1, 1, 1, 1, 1, 0, 1, -1, -1, 1, 1, -1, 1, -1, 1, -1, -1, 
> > -1, -1, -1, 1, 1, -1, -1, 1, -1, 1, -1, 1, 1, 1, 1] + [0]*5)
> > 
> > # time domain
> > td = np.fft.ifft(np.fft.ifftshift(fd/64**.5), norm="ortho")
> > 
> > sync_long = np.append(td[32:], [td, td])
> > # sequence in standard considers windowing
> > sync_long[0] = sync_long[0] / 2
> > 
> > # Standard, Appendix I
> > sync_long
> > 
> > 
> > 
> > 
> > To reproduce the sequence in the code:
> > 
> > 
> > 
> > # taps for matched filter (I used a different/weird scaling)
> > m = np.fft.ifft(np.fft.ifftshift(fd), norm="ortho") * (64.0/52)**.5
> > m = np.conj(m)
> > m = m[::-1] # reverse for d_fir kernel (which reverses again)
> > # sequence in sync_long block
> > m
> > 
> > 
> > 
> > 
> > 
> > 
> > > I think I might be missing something here and would be glad if someone 
> > > could shed some light on this.
> > > 
> > > 2. As seen in the provided examples, the (Random) Periodic Message Source 
> > > from gr-foo is useful for simulations. However, due to a bug in GR 3.7, 
> > > flowgraphs using it won't stop automatically. I'm aware that this has 
> > > already been fixed by this PR: 
> > > https://github.com/gnuradio/gnuradio/pull/797 . However, I would like to 
> > > be able to use a vanilla GR 3.7 and the fix was applied to the next 
> > > branch due to API change. Are there any known workarounds not requiring 
> > > patching?
> > > 
> >  
> > No, you'll have to use `next` or wait some more time until next is merged 
> > in master. Marcus is working on thatn (see PR 
> > https://github.com/gnuradio/gnuradio/pull/1809)
> > 
> > Best,
> > Bastian
> > 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] A few questions regarding gr-ieeee802-11

[Tal Peer]

Hi Bastian,

Thanks for the clarification about the matched filter -- I basically got
the scaling part wrong. Now everything makes sense.
About the next into master merge: I understand that currently master is the
3.7 branch and next the 3.8 branch (or is it?), so can we expect a 3.8
release when the merge happens?

Cheers,
Tal

On Fri, Jun 8, 2018 at 12:48 PM, Bastian Bloessl  wrote:

> Hi,
>
> On 06/08/2018 10:18 AM, Tal Peer wrote:
>
>> 1. In the Sync Long block, the input is put through a matched filter
>> defined by the long training sequence in time domain. I'm probably
>> overseeing something here, but  I would expect this sequence to be the same
>> as the sequence given in table I-6 of the standard (well, a part of it at
>> least, since it repeats 2.5 times). Now, I understand the LONG vector is
>> generated using the create_long.R script and not knowing any R I tried to
>> reproduce this in MATLAB. However, after some experiments I figured that in
>> order to reproduce the same sequence I have to run in MATLAB (a is the
>> freq. domain sequence):
>>
>> fliplr(fft(ifftshift(a)/sqrt(52)))
>>
>> where from the R script I would actually expect (as we're transforming
>> the sequence from frequency to time domain and also conjugating it to
>> create a matched filter):
>>
>> fliplr(conj(ifft(fftshift(a)/sqrt(52
>>
>
> I'm not sure if I understand you correctly. It sounds like you think the
> steps in the R-script are reasonable, but you fail to reproduce it in
> MATLAB. I don't have MATLAB, so I cannot test it, but maybe you forgot an
> 'i' and were using the fft instead of the ifft.
>
> I've done it again in Python and it results in exactly the steps that you
> seem to expect.
>
> To reproduce the sequence in the standard:
>
> 
> import numpy as np
>
> # frequency domain
> fd = np.array([0]*6 + [1, 1, -1, -1, 1, 1, -1, 1, -1, 1, 1, 1, 1, 1, 1,
> -1, -1, 1, 1, -1, 1, -1, 1, 1, 1, 1, 0, 1, -1, -1, 1, 1, -1, 1, -1, 1, -1,
> -1, -1, -1, -1, 1, 1, -1, -1, 1, -1, 1, -1, 1, 1, 1, 1] + [0]*5)
>
> # time domain
> td = np.fft.ifft(np.fft.ifftshift(fd/64**.5), norm="ortho")
>
> sync_long = np.append(td[32:], [td, td])
> # sequence in standard considers windowing
> sync_long[0] = sync_long[0] / 2
>
> # Standard, Appendix I
> sync_long
>
> 
>
>
> To reproduce the sequence in the code:
>
> 
>
> # taps for matched filter (I used a different/weird scaling)
> m = np.fft.ifft(np.fft.ifftshift(fd), norm="ortho") * (64.0/52)**.5
> m = np.conj(m)
> m = m[::-1] # reverse for d_fir kernel (which reverses again)
> # sequence in sync_long block
> m
>
> 
>
>
>
>
>
>> I think I might be missing something here and would be glad if someone
>> could shed some light on this.
>>
>> 2. As seen in the provided examples, the (Random) Periodic Message Source
>> from gr-foo is useful for simulations. However, due to a bug in GR 3.7,
>> flowgraphs using it won't stop automatically. I'm aware that this has
>> already been fixed by this PR: https://github.com/gnuradio/gn
>> uradio/pull/797 . However, I would like to be able to use a vanilla GR
>> 3.7 and the fix was applied to the next branch due to API change. Are there
>> any known workarounds not requiring patching?
>>
>
> No, you'll have to use `next` or wait some more time until next is merged
> in master. Marcus is working on thatn (see PR
> https://github.com/gnuradio/gnuradio/pull/1809)
>
> Best,
> Bastian
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio not installing: Build Failed

[Derek Kozel]

Hello Curt,

The fix for this issue was merged into the GNU Radio master branch last
night. Thank you for posting the PR and describing your solution here. The
3.8 release is going to raise the minimum version requirements of an
appreciable number of dependencies in order to make sure that GNU Radio
development can keep moving forward smoothly. C++11 will be mandatory on
master at some time before that release occurs, but today isn't here quite
yet.

Thanks,
Derek

On Fri, Jun 8, 2018 at 2:11 AM, Curt Corum  wrote:

> Mir and Jason,
>
> I've been working through something similar and have found a solution.
>
> Please see the github issue: https://github.com/gnuradio/
> pybombs/issues/502 and below.
>
> -Curt
>
>
> Dear pybombs team and community,
>
> Had issues with building gnuradio-default on relatively clean but up to
> date Ubuntu 16.04 LTS. Seems related to https://www.mail-archive.com/
> discuss-gnuradio@gnu.org/msg66739.html https://www.mail-archive.com/
> discuss-gnuradio@gnu.org/msg66739.html #424
>  #448
> 
>
> $ pybombs --version
> 2.3.2
>
> $ gcc --version
> gcc (Ubuntu 6.4.0-17ubuntu1~16.04) 6.4.0 20180424
>
> It was necessary to do the following to get the gnuradio-default recipe to
> build thrift, boost, uhd and gnuradio without errors:
>
> >sudo apt-get install g++-6
> >sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-6 60 
> >--slave /usr/bin/g++ g++ /usr/bin/g++-6
> >sudo update-alternatives --config gcc
>
> and setting gcc-6 to default
>
> uninstall most of boost 1.58 binary packages (all but non -dev
> distribution packages)
> adding the following to gnuradio-default.lwr
>
> # gnuradio-default.lwr
> #binary boost linking fails *** CAC
> boost:
>   forcebuild: True
>
> and modifying config.yml (directly as could not figure out how to escape
> -std=c++-11 for pybombs config --env)
>
> # config.yml
> env:
>   CXXFLAGS: -std=c++11 -fext-numeric-literals
>
> and modifying boost.lwr
>
>  # boost.lwr
>   satisfy:
>   deb: libboost-all-dev >= 1.6 || libboost-dev >= 1.6
>   rpm: (boost-devel >= 1.6) || (boost_1_61-devel >= 1.6) || (boost_1_64-devel 
> >= 1.6) || (boost_1_65-devel >= 1.6)
>   pacman: boost >= 1.6
>   port: boost >= 1.6
>   portage: dev-libs/boost >= 1.6
>
> Wanted to make sure this got captured as it took several days to resolve
> and seems to be an ongoing issue.
>
> -Curt
>
>
>
>
> On 06/07/2018 11:00 AM, discuss-gnuradio-requ...@gnu.org wrote:
>
> Message: 5
> Date: Thu, 7 Jun 2018 15:13:38 +0100
> From: Mir Muhammad Lodro  
> To: discuss-gnuradio@gnu.org
> Subject: [Discuss-gnuradio] GNU Radio not installing: Build Failed
> Message-ID:
>
> 
> Content-Type: text/plain; charset="utf-8"
>
> Hi All
> i am installing GNU Radio on Linux 16.04, but it's not installing by saying
> this file requires compiler and library support for ISO 2011 standard. This
> can be done by issuing -std=c++11 or -std=gnu++11  when one has to run
> single file. But here the build process is automated. I would be grateful
> if you can look into the following prompt response and guide what could be
> the possible solution. I have already installed GNU Radio on different
> machine running 16.04, but I am surprise to see the error when installing
> on another machine  and despite repeating the very same steps.
>
> The as it as prompt response is:
>
> root@pezp63763:/home/eexmmlo# pybombs prefix init -a default
> prefix/default/ -R gnuradio-default
> PyBOMBS - INFO - PyBOMBS Version 2.3.2
> PyBOMBS.prefix - WARNING - There already is a prefix in
> `/home/eexmmlo/prefix/default'.
> Continue using this path Y/[N]? y
> Alias `default' already exists, overwrite Y/[N]? y
> PyBOMBS.prefix - INFO - Installing default packages for prefix...
> PyBOMBS.prefix - INFO -
>   - gnuradio
> PyBOMBS.install_manager - INFO - Phase 1: Creating install tree and
> installing binary packages:
> Install tree:
> |
> \- gnuradio
> PyBOMBS.install_manager - INFO - Phase 2: Recursively installing source
> packages to prefix:
> PyBOMBS.install_manager - INFO - Installing package: gnuradio
> PyBOMBS.Packager.source - WARNING - Build dir already exists:
> /home/eexmmlo/prefix/default/src/gnuradio/build
> Building:(100%) [=
> 
> ]
> [  4%] Built target volk_obj
> [  4%] Built target volk
> [  4%] Built target volk_test_all
> [  4%] Built target volk_profile
> [  5%] Built target volk-config-info
> [  6%] Built target pygen_volk_python_volk_modtool_34493
> [  6%] Built target pygen_volk_python_volk_modtool_04eb6
> [  7%] Built target pmt_generated
> [  7%] Built target gnuradio-pmt
> [ 10%] Built target gnuradio-runtime
> [ 11%] Built target test-gnuradio-runtime
> [ 11%] Built target gr_runtime_test
> [ 11%] Built target test-gnuradio-pmt
> [ 11%] Built target gr_pmt_test
> [ 11%] Built target 

Re: [Discuss-gnuradio] A few questions regarding gr-ieeee802-11

[Bastian Bloessl]

Hi,

On 06/08/2018 10:18 AM, Tal Peer wrote:
1. In the Sync Long block, the input is put through a matched filter 
defined by the long training sequence in time domain. I'm probably 
overseeing something here, but  I would expect this sequence to be the 
same as the sequence given in table I-6 of the standard (well, a part of 
it at least, since it repeats 2.5 times). Now, I understand the LONG 
vector is generated using the create_long.R script and not knowing any R 
I tried to reproduce this in MATLAB. However, after some experiments I 
figured that in order to reproduce the same sequence I have to run in 
MATLAB (a is the freq. domain sequence):


fliplr(fft(ifftshift(a)/sqrt(52)))

where from the R script I would actually expect (as we're transforming 
the sequence from frequency to time domain and also conjugating it to 
create a matched filter):


fliplr(conj(ifft(fftshift(a)/sqrt(52


I'm not sure if I understand you correctly. It sounds like you think the 
steps in the R-script are reasonable, but you fail to reproduce it in 
MATLAB. I don't have MATLAB, so I cannot test it, but maybe you forgot 
an 'i' and were using the fft instead of the ifft.


I've done it again in Python and it results in exactly the steps that 
you seem to expect.


To reproduce the sequence in the standard:


import numpy as np

# frequency domain
fd = np.array([0]*6 + [1, 1, -1, -1, 1, 1, -1, 1, -1, 1, 1, 1, 1, 1, 1, 
-1, -1, 1, 1, -1, 1, -1, 1, 1, 1, 1, 0, 1, -1, -1, 1, 1, -1, 1, -1, 1, 
-1, -1, -1, -1, -1, 1, 1, -1, -1, 1, -1, 1, -1, 1, 1, 1, 1] + [0]*5)


# time domain
td = np.fft.ifft(np.fft.ifftshift(fd/64**.5), norm="ortho")

sync_long = np.append(td[32:], [td, td])
# sequence in standard considers windowing
sync_long[0] = sync_long[0] / 2

# Standard, Appendix I
sync_long




To reproduce the sequence in the code:



# taps for matched filter (I used a different/weird scaling)
m = np.fft.ifft(np.fft.ifftshift(fd), norm="ortho") * (64.0/52)**.5
m = np.conj(m)
m = m[::-1] # reverse for d_fir kernel (which reverses again)
# sequence in sync_long block
m








I think I might be missing something here and would be glad if someone 
could shed some light on this.


2. As seen in the provided examples, the (Random) Periodic Message 
Source from gr-foo is useful for simulations. However, due to a bug in 
GR 3.7, flowgraphs using it won't stop automatically. I'm aware that 
this has already been fixed by this PR: 
https://github.com/gnuradio/gnuradio/pull/797 . However, I would like to 
be able to use a vanilla GR 3.7 and the fix was applied to the next 
branch due to API change. Are there any known workarounds not requiring 
patching?


No, you'll have to use `next` or wait some more time until next is 
merged in master. Marcus is working on thatn (see PR 
https://github.com/gnuradio/gnuradio/pull/1809)


Best,
Bastian


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] A few questions regarding gr-ieeee802-11

[Tal Peer]

Hello everyone,

I've been playing around with GR and specifically gr-ieee802-11 lately, as
I intend to use it soon for a university lab. This tinkering might even
result in some code contributions later on (not promising anything
though...). At the moment I'm mainly interested in running simulations
using the module. I've read the relevant papers linked on wime-project.net
and went through the code, but some questions still remain open:

1. In the Sync Long block, the input is put through a matched filter
defined by the long training sequence in time domain. I'm probably
overseeing something here, but  I would expect this sequence to be the same
as the sequence given in table I-6 of the standard (well, a part of it at
least, since it repeats 2.5 times). Now, I understand the LONG vector is
generated using the create_long.R script and not knowing any R I tried to
reproduce this in MATLAB. However, after some experiments I figured that in
order to reproduce the same sequence I have to run in MATLAB (a is the
freq. domain sequence):

fliplr(fft(ifftshift(a)/sqrt(52)))

where from the R script I would actually expect (as we're transforming the
sequence from frequency to time domain and also conjugating it to create a
matched filter):

fliplr(conj(ifft(fftshift(a)/sqrt(52

I think I might be missing something here and would be glad if someone
could shed some light on this.

2. As seen in the provided examples, the (Random) Periodic Message Source
from gr-foo is useful for simulations. However, due to a bug in GR 3.7,
flowgraphs using it won't stop automatically. I'm aware that this has
already been fixed by this PR: https://github.com/gnuradio/gnuradio/pull/797
. However, I would like to be able to use a vanilla GR 3.7 and the fix was
applied to the next branch due to API change. Are there any known
workarounds not requiring patching?

That's it for now, more questions probably coming soon.

Cheers,
Tal
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Bug in fmdet_cf_imp.cc

[Eugene Grayver]

Hello,

There is a bug in the FM demod.  Unbelievably (almost), I reported a bug in the 
same line a couple of years ago.  At that time I also goofed (should have not 
retyped it).  The equation is STILL wrong!

Sdot = d_scl * (-S0+d_8*S1-d_8*S2+S4);

Should be

Sdot = d_scl * (-S0+d_8*S1-d_8*S3+S4);


[cid:image001.png@01D3FF1E.AB791FA0]

It is crazy that the basic FM demo works at all.


___
Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio not installing: Build Failed

[Curt Corum]

Derek,

Great!

It was also necessary to have


|-fext-numeric-literals |

in the mix as well for uhd and gnuradio to both build. Not sure if that
is covered implicitly?

Curt


On 06/08/2018 01:52 AM, Derek Kozel wrote:
> Hello Curt,
>
> The fix for this issue was merged into the GNU Radio master branch
> last night. Thank you for posting the PR and describing your solution
> here. The 3.8 release is going to raise the minimum version
> requirements of an appreciable number of dependencies in order to make
> sure that GNU Radio development can keep moving forward smoothly.
> C++11 will be mandatory on master at some time before that release
> occurs, but today isn't here quite yet.
>
> Thanks,
> Derek
>
> On Fri, Jun 8, 2018 at 2:11 AM, Curt Corum  > wrote:
>
> Mir and Jason,
>
> I've been working through something similar and have found a solution.
>
> Please see the github issue:
> https://github.com/gnuradio/pybombs/issues/502
>  and below.
>
> -Curt
>
>
> Dear pybombs team and community,
>
> Had issues with building gnuradio-default on relatively clean but
> up to date Ubuntu 16.04 LTS. Seems related to
> https://www.mail-archive.com/discuss-gnuradio@gnu.org/msg66739.html
> 
> https://www.mail-archive.com/discuss-gnuradio@gnu.org/msg66739.html
> 
> #424  #448
> 
>
> SNIP
>

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Freeing memory problem in GNURadio

[Gorur, Anisha - 0662 - MITLL]

Hello,
I've been having a strange problem with the gr-fec block, and I think it may be 
connected to other issues I'm having. I'm running a flowgraph on the E310 using 
the LDPC Encoder Definition (via Generator), LDPC Generator Matrix, and FEC 
Async Encoder blocks and it has been running fine for a few months. For another 
block, I needed to update the Volk library because I wanted a new kernel, but 
when I did so a couple of things started to break. 

I thought this was due to my update of GNURadio/Volk, but I have reinstalled 
the SDK as well as UHD and GNUradio from source (using these instructions: 
https://files.ettus.com/manual/page_usrp_e3x0.html) and I still get the same 
problems. I am using UHD version 3.9.2 (I need to for other compatibility 
issues, this has not given me trouble in the past) and GNURadio 3.7.11.1 (The 
version I was using when everything worked). My cross compiling also seems to 
be working fine, I get no errors in my cmake or make process. I am using the 
fpga files and SDK from here: 
http://files.ettus.com/e3xx_images/e3xx-release-4/ 

In the following gdb backtraces, I've built both GNURadio and my OOT module 
with -DCMAKE_BUILD_TYPE=Debug.  

Error 1:
When I kill a flowgraph with the LDPC Encoder in it, I get either a  segfault 
or an invalid pointer error when the program tries to call the  destructor of 
ldpc_gen_mtrx_encoder_impl.cc. (full backtrace in 
message_port_in_not_working.txt)

```
-- Loading FPGA image: 
/home/root/emb/usr/share/uhd/images/usrp_e3xx_fpga_idle_sg3.bit...[Thread 
0xa95ff460 (LWP 1241) exited]
 done
[Thread 0xb1546460 (LWP 1227) exited]
*** Error in `/usr/bin/python': munmap_chunk(): invalid pointer: 0xb6fa7d10 ***

Program received signal SIGABRT, Aborted.
0xb6d38894 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:55
55    return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(gdb) bt
#0  0xb6d38894 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:55
#1  0xb6d3c394 in __GI_abort () at abort.c:89
#2  0xb6d707b8 in __libc_message (do_abort=, fmt=0xb6e28a00 "*** 
Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175
#3  0xb6d7aa74 in malloc_printerr (action=3, str=0xb6e28a24 "munmap_chunk(): 
invalid pointer", ptr=) at malloc.c:4960
#4  0xb6d7ab94 in munmap_chunk (p=) at malloc.c:2817
#5  0xb3df81d8 in gsl_block_free (b=0xb6f9fda8 ) at 
/usr/src/debug/gsl/1.15-r0/gsl-1.15/block/init_source.c:78
#6  0xb3e47b40 in gsl_matrix_free (m=0x1d754) at 
/usr/src/debug/gsl/1.15-r0/gsl-1.15/matrix/init_source.c:189
#7  0xb3fbedc4 in gr::fec::code::ldpc_G_matrix_impl::~ldpc_G_matrix_impl 
(this=this@entry=0x7af6c0, __in_chrg=, __vtt_parm=) at 
/home/agorur/projects/emb/src/gnuradio/gr-fec/lib/ldpc_G_matrix_impl.cc:294
#8  0xb3fc0664 in ~ldpc_G_matrix_impl (this=0x7af6c0, __in_chrg=, __vtt_parm=) at 
/home/agorur/projects/emb/src/gnuradio/gr-fec/lib/ldpc_G_matrix_impl.cc:295
#9  checked_delete (x=0x7af6c0) at 
/home/agorur/projects/emb/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/boost/core/checked_delete.hpp:34
```

Error 2: I have my own message block, which has suddenly stopped working, the 
flowgraph does not recognize the input port (called pdus_in) and the backtrace 
traces back to a boost header file. (full backtrace in 
ldpc_destructor_free_error.txt)
```
-- Loading FPGA image: 
/home/root/emb/usr/share/uhd/images/usrp_e310_fpga_sg3.bit... done
-- Input frequency reference: 40 MHz
-- Detecting internal GPSDO [New Thread 0xb1546460 (LWP 1249)]
 found
-- Initializing core control...
-- Performing register loopback test... pass
-- Performing register loopback test... pass
-- Performing register loopback test... pass
-- Performing CODEC loopback test... pass
-- Performing CODEC loopback test... pass
-- Setting time source to internal
-- Asking for clock rate 10.24 MHz
-- Actually got clock rate 10.24 MHz
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
-- Setting time source to gpsdo
Could not find port: pdus_in in:
system
pdus_in
Program received signal SIGBUS, Bus error.
0xb64d24d8 in fetch_add (order=boost::memory_order_relaxed, v=1, storage=@0x6: 
) at 
/home/agorur/projects/emb/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/boost/atomic/detail/ops_gcc_atomic.hpp:100
100 
/home/agorur/projects/emb/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/boost/atomic/detail/ops_gcc_atomic.hpp:
 No such file or directory.
(gdb) bt
#0  0xb64d24d8 in fetch_add (order=boost::memory_order_relaxed, v=1, 
storage=@0x6: ) at 
/home/agorur/projects/emb/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/boost/atomic/detail/ops_gcc_atomic.hpp:100
#1  fetch_add (order=boost::memory_order_relaxed, v=1, this=0x6) at 
/home/agorur/projects/emb/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/boost/atomic/detail/atomic_template.hpp:115
#2  pmt::intrusive_ptr_add_ref (p=0x2) at 

[Discuss-gnuradio] QT throwing std::bad_alloc

[Tom McDermott]

I've had a problem that started about 4 months ago with Qt Gui throwing an
exception on startup.
I recently installed / rebuilt main-3.7 from git, to see if that bypassed
this issue, unfortunately not.
The problem occurs with QT GUI Frequency Sink. Disabling it prevents the
error.

GRC version 3.7.13.2Ubuntu 16.04
$ sysctl kernel.shmmax
kernel.shmmax = 2147483648

$ qmake --version
QMake version 2.01a
Using Qt version 4.8.7 in /usr/lib/x86_64-linux-gnu


Here is the trace:

gr::log :INFO: audio source - Audio sink arch: alsa
[New Thread 0x7fffa36c1700 (LWP 4563)]
[New Thread 0x7fffa2ec0700 (LWP 4564)]
[New Thread 0x7fffa26bf700 (LWP 4565)]
[New Thread 0x7fffa1ebe700 (LWP 4566)]
[New Thread 0x7fffa16bd700 (LWP 4567)]
[New Thread 0x7fffa0ebc700 (LWP 4568)]
[New Thread 0x7fff97ffe700 (LWP 4569)]
[New Thread 0x7fff977fd700 (LWP 4570)]
[New Thread 0x7fff96ffc700 (LWP 4571)]
[New Thread 0x7fff967fb700 (LWP 4572)]
[New Thread 0x7fff95ffa700 (LWP 4573)]
[New Thread 0x7fff957f9700 (LWP 4574)]
aU[Thread 0x7fffaabf0700 (LWP 4559) exited]
Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt. You must
reimplement QApplication::notify() and catch all exceptions there.

terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc

Thread 1 "python" received signal SIGABRT, Aborted.
0x77825428 in __GI_raise (sig=sig@entry=6)
at ../sysdeps/unix/sysv/linux/raise.c:54
54../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x77825428 in __GI_raise (sig=sig@entry=6)
at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x7782702a in __GI_abort () at abort.c:89
#2  0x74f1884d in __gnu_cxx::__verbose_terminate_handler() ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x74f166b6 in ?? () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x74f16701 in std::terminate() ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x74f16969 in __cxa_rethrow ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x753946ee in QEventLoop::exec (this=this@entry=0x7fffd7e0,
flags=...) at kernel/qeventloop.cpp:218
#7  0x7539a4b9 in QCoreApplication::exec ()
at kernel/qcoreapplication.cpp:1227
#8  0x72d5522c in QApplication::exec () at
kernel/qapplication.cpp:3828
#9  0x73df2aeb in meth_QApplication_exec_ (sipArgs=)
at sipQtGuipart9.cpp:38155
#10 0x004bc3fa in call_function (oparg=,
pp_stack=0x7fffd8f0) at ../Python/ceval.c:4350
#11 PyEval_EvalFrameEx () at ../Python/ceval.c:2987
#12 0x004b9ab6 in PyEval_EvalCodeEx () at ../Python/ceval.c:3582
#13 0x004c16e7 in fast_function (nk=,
na=, n=, pp_stack=0x7fffdaf0,
---Type  to continue, or q  to quit---func=___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio