Re: Gnuradio Update on ubuntu 20.04 lts

[Volker Schroer]

Sorry, I was wrong . cmake is not PPA related

> Am 19.07.2023 um 17:31 schrieb Marcus Müller :
> 
> Hi Volker,
> 
> I believe David is referring to the PPA installation, i.e.,
> 
> sudo add-apt-repository ppa:gnuradio/gnuradio-releases
> sudo apt-get update
> sudo apt-get install gnuradio python3-packaging
> 
> 
> But that's what confuses me: starting yesterday, that should have installed 
> GR 3.10.7.0 :-)
> 
> Anyways, huh, gotta check that package twice.
> 
> Best,
> Marcus
>> On 19.07.23 17:23, Volker Schroer wrote:
>> Did you run cmake with
>> -DENABLE_POSTINSTALL=ON ?
>> — Volker
>>>> Am 19.07.2023 um 17:16 schrieb David Martini :
>>> 
>>> 
>>> Hi Marcus
>>> 
>>> Thak you for answer
>>> I don't update the the Ubuntu. Ubuntu is 20.04 lts.
>>> Only gnuradio was update using the instruction on wiki ('InstallingGR' ) to 
>>> version v3 10.7.0
>>> Everything working ok but no icon is present. To lauch gnuradio we need to 
>>> open the terminal and lauch it.
>>> Not a big deal..but I would like to understand way.
>>> 
>>> Best Regards
>>> 
>>> David
>>> 
>>> 
>>> 
>>> 
>>> Il Mer 19 Lug 2023, 14:32 Marcus Müller >> <mailto:mmuel...@gnuradio.org>> ha scritto:
>>> 
>>>Hi David!
>>> 
>>>Thanks for reaching out; couldn't find time to answer you yesterday.
>>> 
>>>So, in best engineering manner, let's check a few assumptions with you:
>>> 
>>>- I'm interpreting your "routine update as "I updated Ubuntu 20.04 to 
>>> Ubuntu 23.04",
>>>because that's the only version of Ubuntu that I'm aware of that ships 
>>> GNU Radio 3.10.5.
>>> 
>>>- I'm interpreting your "icon of gnuradio" as the GNU Radio companion 
>>> launcher icon
>>>that
>>>you get (for example, if you're on Gnome desktop, by pressing the 
>>> "windows" key and
>>>starting to type gnuradio).
>>> 
>>>Are these assumptions correct?
>>>Which desktop are you using? If that's unclear, I think we could work 
>>> with a
>>>screenshot of
>>>where you expect the icon to be.
>>> 
>>>So, I just checked¹, and the Ubuntu 23.04 package still installs the
>>>gnuradio-grc.desktop
>>>file which *should* make any modern desktop environment list GNU Radio 
>>> companion in its
>>>launchable programs, hence my confusion.
>>>I compared the desktop files themselves, and they haven't changed.
>>> 
>>>Best,
>>>Marcus
>>> 
>>>——
>>>¹ that means I went to packages.ubuntu.com <http://packages.ubuntu.com>, 
>>> looked up
>>>the `gnuradio` package in both the
>>>version from Ubuntu 20.04 (focal) and the version from Ubuntu 23.04 
>>> (lunar), got the
>>>"list
>>>of files" for amd64 (bottom of the package page), and compared these 
>>> using `comm -3`.
>>> 
>>>>On 18.07.23 15:25, David Martini wrote:
>>>> Hi all
>>>>
>>>> After a routine update of ubuntu 20.04 (gnuradio was also in the list 
>>> of sw
>>>update) the
>>>> icon of gnuradio disappeared.
>>>> The gnuradio start properly from terminal.
>>>> The gnuradio is 3.10.5.
>>>> Any help?
>>>>
>>>> Thanks
>>>>
>>>> David Martini
>>>>
>>> 
> 

Re: Gnuradio Update on ubuntu 20.04 lts

[Volker Schroer]

Did you run cmake with -DENABLE_POSTINSTALL=ON ?— Volker Am 19.07.2023 um 17:16 schrieb David Martini :Hi MarcusThak you for answerI don't update the the Ubuntu. Ubuntu is 20.04 lts.Only gnuradio was update using the instruction on wiki ('InstallingGR' ) to version v3 10.7.0Everything working ok but no icon is present. To lauch gnuradio we need to open the terminal and lauch it.Not a big deal..but I would like to understand way.Best RegardsDavidIl Mer 19 Lug 2023, 14:32 Marcus Müller  ha scritto:Hi David!

Thanks for reaching out; couldn't find time to answer you yesterday.

So, in best engineering manner, let's check a few assumptions with you:

- I'm interpreting your "routine update as "I updated Ubuntu 20.04 to Ubuntu 23.04", 
because that's the only version of Ubuntu that I'm aware of that ships GNU Radio  3.10.5.

- I'm interpreting your "icon of gnuradio" as the GNU Radio companion launcher icon that 
you get (for example, if you're on Gnome desktop, by pressing the "windows" key and 
starting to type gnuradio).

Are these assumptions correct?
Which desktop are you using? If that's unclear, I think we could work with a screenshot of 
where you expect the icon to be.

So, I just checked¹, and the Ubuntu 23.04 package still installs the gnuradio-grc.desktop 
file which *should* make any modern desktop environment list GNU Radio companion in its 
launchable programs, hence my confusion.
I compared the desktop files themselves, and they haven't changed.

Best,
Marcus

——
¹ that means I went to packages.ubuntu.com, looked up the `gnuradio` package in both the 
version from Ubuntu 20.04 (focal) and the version from Ubuntu 23.04 (lunar), got the "list 
of files" for amd64 (bottom of the package page), and compared these using `comm -3`.

On 18.07.23 15:25, David Martini wrote:
> Hi all
> 
> After a routine update of ubuntu 20.04 (gnuradio was also in the list of sw update) the 
> icon of gnuradio disappeared.
> The gnuradio start properly from terminal.
> The gnuradio is 3.10.5.
> Any help?
> 
> Thanks
> 
> David Martini
> 

Re: Display text output within GNU Radio from an application

[Volker Schroer]

gr-display is an oot that is able to display text streams or text messages.— VolkerAm 09.07.2023 um 21:53 schrieb Elmore's :



Is there a way to produce a text display window in GNU Radio? I do not see 
anything in the listing of blocks.
 
I have an application that produces a stream of text for display. I would 
rather display it within GNU Radio rather than as console output.
 
The only reference I can find is to the following:
 https://github.com/dl1ksv/gr-display
 
Is this what I will need to use? I assume it produces an OOT module.
 
JimVirus-free.www.avg.com 

Logging question

[Volker Schroer]

Hi,

I'm trying to understand gnuradio's logging.
So I setup a simple flowgraph
signal_source -> throttle-> add const-> time_sink.

To enable debug logging I have to set

[log]
debug_file = stderr
debug_level = debug
log_file = stdout
log_level = debug

in ~/.gnuradio/config.conf

or in $CMAKE_INSTALL_PREFIX/etc/gnuradio/conf.d/gnuradio-runtime.conf

I have to set both debug_level and log_level to debug, to get a debug
log. What's the difference between log_level and debug_level? I can
redirect the output to a file, but only by setting log_file = {filename}.
Setting debug_file to a filename changes nothing.

To restrict the debug output to one block I tried to set the log_level
to info and called set_log_level('debug') for this block and verifying
this setting by log_level(). But it seems that this setting has no
influence.

What am I doing wrong ?

-- Volker

Re: File Meta Sink question

[Volker Schroer]

Have a look at

https://wiki.gnuradio.org/index.php/File_Meta_Sink

There you'll find an example with multiple entries.

I was able to get a little farther with using import pmt in the Import
block.   I am now having some new difficulty with the Extra Dict field
in the File Meta Sink block.    I'd like to add a few definitions to the
Extra Dictionary.

If I use:
pmt.dict_add(pmt.make_dict(),pmt.intern('FFT_size'),pmt.from_long(FFT_size))
to add in the FFT_size, that will run without error.   However, I'm not
sure how to add another entry.

If I try adding another entry,
pmt.dict_add(pmt.make_dict(),pmt.intern('FFT_size'),pmt.from_long(FFT_size)), 
pmt.dict_add(pmt.make_dict(),pmt.intern('freq'),pmt.from_long(freq))

I get an error about incompatible constructor arguments:
in __init__
     self.blocks_file_meta_sink_0 =
blocks.file_meta_sink(gr.sizeof_float*FFT_size, 'output.dat', samp_rate,
1, blocks.GR_FILE_FLOAT, False, 100,
pmt.dict_add(pmt.make_dict(),pmt.intern('FFT_size'),pmt.from_long(FFT_size)),pmt.dict_add(pmt.make_dict(),pmt.intern('freq'),pmt.from_long(freq)),
 False)
TypeError: __init__(): incompatible constructor arguments. The following
argument types are supported:
     1. gnuradio.blocks.blocks_python.file_meta_sink(itemsize: int,
filename: str, samp_rate: float = 1, relative_rate: float = 1, type:
gnuradio.blocks.blocks_python.gr_file_types =
, complex: bool = True,
max_segment_size: int = 100, extra_dict: pmt.pmt_python.pmt_base =
(), detached_header: bool = False)

Invoked with: 4096, 'output.dat', 1000, 1,
, False, 100, ((FFT_size . 1024)),
((freq . 10570)), False


If I try the entry this way:
pmt.dict_add(pmt.make_dict(),pmt.intern('FFT_size','freq'),pmt.from_long(FFT_size,freq))

I get an error in the block:
  Param - Extra Dict.(extra_dict):
Value
"pmt.dict_add(pmt.make_dict(),pmt.intern('FFT_size','freq'),pmt.from_long(FFT_size,freq))"
 cannot be evaluated:
intern(): incompatible function arguments. The following argument types
are supported:
    1. (s: str) -> pmt.pmt_python.pmt_base

I'm not sure how to add multiple entries to the dictionary, or if it's
possible to do so.    Thanks for any assistance!
Invoked with: 'FFT_size', 'freq'

Re: How to enable local OOT modules

[Volker Schroer]

Hi Ivan.

I forgot to mention:

Have a look at ~/.gnuradio/config.conf

There is a sectioo

[grc]

This section should contain something like

global_blocks_path = /usr/local/gnuradio/share/gnuradio/grc/blocks
local_blocks_path = /usr/local/oot3/share/gnuradio/grc/blocks

Instead of setting GRC_BLOCKS_PATH

you can set local_blocks_path which should be evaluated in both cases.

-- Volker



Hi Volker!
In order to see the local blocks in GRC, I also set $GRC_BLOCKS_PATH.
Based on your suggestions, at the moment I added the following variable
definitions in .bashrc:
export GNURADIO_OOT_LOCAL_PATH=$HOME/workspace/gnuradio-oot
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$GNURADIO_OOT_LOCAL_PATH/local/lib
export
PYTHONPATH=$PYTHONPATH:$GNURADIO_OOT_LOCAL_PATH/local/lib/python3.10/dist-packages
export
GRC_BLOCKS_PATH=$GRC_BLOCK_PATH:$GNURADIO_OOT_LOCAL_PATH/share/gnuradio/grc/blocks
It works like a charm if I launch gnuradio-companion from terminal.
The problem is that when I launch GRC from gnome shell, local blocks are
not found.
Why does launching GRC from gnome shell bypass $GRC_BLOCKS_PATH?
Thanks for help.
Ivan

Il 14.03.2023 18:01 Volker Schroer ha scritto:


Hello!
You have to set LD_LIBRARY_PATH and PYTHONPATH accordingly.

For example I install my oot's to /usr/local/oot and I set

echo $LD_LIBRARY_PATH
/usr/local/gnuradio/lib64:/usr/local/volk/lib64:/usr/local/libiio/lib64:/usr/local/libad9361/lib:/usr/local/oot/lib64

echo $PYTHONPATH
/usr/local/gnuradio/lib64/python3.11/site-packages/:/usr/local/oot/lib64/python3.11/site-packages/

-- Volker


Am 14.03.23 um 16:46 schriebkron...@tiscali.it  <mailto:kron...@tiscali.it>:

Hello guys! My aim is to setup a workstation with GNU Radio and a set
of system-wide OOTs installed (managed by the administrator) to be
used by all of the users, while still allowing the users to create
their own OOTs for local experiments and install them in
$HOME/local/. At the moment I installed GNU Radio on Ubuntu 22.04
using apt; I know I can specify to cmake
|-DCMAKE_INSTALL_PREFIX=$HOME/local.| How to get gnuradio aware with
respect to the OOT modules locally installed? Thanks for help! Ivan
VOUCHER CONNETTIVITÀ per P.IVA e PMI: internet a canone 0 per 48
mesi. ATTIVA ORA
https://casa.tiscali.it/promo/?u=https://promozioni.tiscali.it/voucher_business/ 
<https://casa.tiscali.it/promo/?u=https://promozioni.tiscali.it/voucher_business/> 
<https://casa.tiscali.it/promo/?u=https://promozioni.tiscali.it/voucher_business/?r=TS0A00025=link=tiscali_source=tiscali_medium=link_campaign=voucherbusiness_np=tiscali.link.footermail.voucherbusiness.btb
 
<https://casa.tiscali.it/promo/?u=https://promozioni.tiscali.it/voucher_business/?r=TS0A00025=link=tiscali_source=tiscali_medium=link_campaign=voucherbusiness_np=tiscali.link.footermail.voucherbusiness.btb>..>




VOUCHER CONNETTIVITÀ per P.IVA e PMI: internet a canone 0 per 48 mesi.
ATTIVA ORA
https://casa.tiscali.it/promo/?u=https://promozioni.tiscali.it/voucher_business/ 
<https://casa.tiscali.it/promo/?u=https://promozioni.tiscali.it/voucher_business/?r=TS0A00025=link=tiscali_source=tiscali_medium=link_campaign=voucherbusiness_np=tiscali.link.footermail.voucherbusiness.btb..>

Re: How to enable local OOT modules

[Volker Schroer]

Hello!
You have to set LD_LIBRARY_PATH and PYTHONPATH accordingly.

For example I install my oot's to /usr/local/oot and I set

echo $LD_LIBRARY_PATH
/usr/local/gnuradio/lib64:/usr/local/volk/lib64:/usr/local/libiio/lib64:/usr/local/libad9361/lib:/usr/local/oot/lib64

echo $PYTHONPATH
/usr/local/gnuradio/lib64/python3.11/site-packages/:/usr/local/oot/lib64/python3.11/site-packages/

-- Volker


Am 14.03.23 um 16:46 schrieb kron...@tiscali.it:

Hello guys!

My aim is to setup a workstation with GNU Radio and a set of system-wide
OOTs installed (managed by the administrator) to be used by all of the
users, while still allowing the users to create their own OOTs for local
experiments and install them in $HOME/local/.

At the moment I installed GNU Radio on Ubuntu 22.04 using apt; I know I
can specify to cmake |-DCMAKE_INSTALL_PREFIX=$HOME/local.|

How to get gnuradio aware with respect to the OOT modules locally installed?

Thanks for help!

Ivan




VOUCHER CONNETTIVITÀ per P.IVA e PMI: internet a canone 0 per 48 mesi.
ATTIVA ORA
https://casa.tiscali.it/promo/?u=https://promozioni.tiscali.it/voucher_business/ 

Re: File Meta Sink question

[Volker Schroer]

You have to enter
import pmt

not only pmt



I'm still having some trouble with this issue.    If I try to add a File
Meta Sink block, I get an error involving pmt.make_dict() that indicates
that pmt is not defined:
image.png
image.png


If I try to add an import block, I can't change the case of "Import",
and get an error message as shown
image.png


image.png

I'm having trouble finding any documentation to help with this.

Thanks!
-George


On Thu, Mar 9, 2023 at 11:06 AM Hassel, George mailto:ghas...@siena.edu>> wrote:

Hello,

I'm having some difficulty with saving metadata.   I'm trying to use
File Meta Sink as a block in gnuradio companion, and I get an error
message in the Extra Dict. filed that "Value "pmt.make_dict()"
cannot be evaluated: name 'pmt' is not defined.    I try to add in
an Import block that says Import pmt, and get an error that says
"Param - Import(imports): Bad import syntax: "pmt".

If I instead just use a python script with import pmt, I still get
errors involving the File Meta Sink blocks.

I tried to make sure that pmt was installed with pip3 install pmt,
but that causes an error with finding the paths for gnuradio.   I
resolved that by following the instructions at
https://wiki.gnuradio.org/index.php/ModuleNotFoundError
, but again
come back to the same errors involving pmt.

My Ubuntu version is 22.10
My gnuradio version is 3.10.3.0
My python3 version is 3.10.7

Thanks for any assistance you can provide!

-George Hassel

Re: File Meta Sink question

[Volker Schroer]

Hello,

I think your import statement should start with small letter i. Capital
letter I leads to the error message you described.

-- Volker
Am 09.03.23 um 17:06 schrieb Hassel, George:

Hello,

I'm having some difficulty with saving metadata.   I'm trying to use
File Meta Sink as a block in gnuradio companion, and I get an error
message in the Extra Dict. filed that "Value "pmt.make_dict()" cannot be
evaluated: name 'pmt' is not defined.    I try to add in an Import block
that says Import pmt, and get an error that says "Param -
Import(imports): Bad import syntax: "pmt".

If I instead just use a python script with import pmt, I still get
errors involving the File Meta Sink blocks.

I tried to make sure that pmt was installed with pip3 install pmt, but
that causes an error with finding the paths for gnuradio.   I resolved
that by following the instructions at
https://wiki.gnuradio.org/index.php/ModuleNotFoundError
, but again
come back to the same errors involving pmt.

My Ubuntu version is 22.10
My gnuradio version is 3.10.3.0
My python3 version is 3.10.7

Thanks for any assistance you can provide!

-George Hassel

Re: Qt widgets Improvement

[Volker Schroer]

Well Rohit , the starting point depends on your knowledge.

There are many qt-gui sinks, for instance

QT GUI sink, QT GUI frequency sink, QT GUI waterfall sink, etc.

The QT GUI sink contains an optional frequency sink , waterfall sink, etc.

But the code the sinks in the QT GUI sink differ from 'standalone'
sinks. From a maintainance point of view it would be great to have a
unified codebase for all those sinks.

But I think creating a unified codebase is hard work.

-- Volker


Thanks Volker  for this example it will be very helpful .

Btw which widget would be good to start with?

Thanks
Rohit

On Tue, Jan 31, 2023, 1:52 PM Volker Schroer mailto:dl1...@gmx.de>> wrote:

Hi Marcus,

thanks for the clarification.

Maybe this helps:

Qt Gui sink is an example how to use the designer together with
gnuradio. You'll find it in qt-gui/lib.

An example for an oot using the designer can be found in

github.com/dl1ksv/gr-display <http://github.com/dl1ksv/gr-display>

-- Volker
 > Hi Volker,
 >
 > I might have gotten my Qt jargon mixed up here :) Yeah I meant QT
 > Designer. Sorry for the confusion!
 >
 > Cheers,
 > Marcus
 >
 > On 30.01.23 17:29, Volker Schroer wrote:
 >> Hi,
 >>
 >> but I think in this case the qt-designer is the tool to to
design the
 >> widget. I'm curious how, to integrate qt-creator in the build
process.
 >>
 >> -- Volker
 >>
 >> Am 30.01.23 um 17:11 schrieb Marcus Müller:
 >>> Hi everyone!
 >>>
 >>> Sadly, the reply chain on this email thread got broken, so it's
probably
 >>> hard for you all to see, but:
 >>> This is about a specific GSoC proposal, which does not at all
imply that
 >>> you need Qt for every flowgraph.
 >>> Exactly as Rohit describes, this is about making it easier to
build a
 >>> GUI for GNU Radio flowgraphs *should you decide you want graphical
 >>> visualizations*.
 >>> And if you do so, gr-qtgui is based on Qt, anyways.
 >>>
 >>> Cheers,
 >>> Marcus
 >>>
 >>> On 30.01.23 17:02, Jim Melton wrote:
 >>>> I'd propose that nothing you do *requires* Qt. There are many
uses for
 >>>> GUI-less flowgraphs. Qt is a heavyweight framework; it should
not be
 >>>> required in order to build GRC flowgraphs.
 >>>>
 >>>> ---
 >>>> Jim Melton
 >>>>
 >>>>
 >>>> -Original Message-
 >>>> From: discuss-gnuradio-bounces+jim.melton=sncorp@gnu.org
<mailto:sncorp@gnu.org>
 >>>> mailto:sncorp@gnu.org>> On Behalf Of
 >>>> Marcus D. Leech
 >>>> Sent: Sunday, January 29, 2023 12:30
 >>>> To: discuss-gnuradio@gnu.org <mailto:discuss-gnuradio@gnu.org>
 >>>> Subject: [EXTERNAL] Re: Qt widgets Improvement
 >>>>
 >>>> On 29/01/2023 14:20, Rohit Bisht wrote:
 >>>>>
 >>>>> I'd like to start with "integrating gnu with qt creator"
because it
 >>>>> would make it easier to write code in the integrated qt
environment
 >>>>> and speed up build, run, and testing. I believe adjusting the
cmake
 >>>>> file and fixing paths to missing library files would be the
way to go
 >>>>> (though I'll require more directions on that).
 >>>>>
 >>>>> Then "adding new widgets" followed by "improving them" .
 >>>> I guess it depends on what you think the dominant design doctrine
 >>>> should be  "gorgeous UI with the DSP as a kind of afterthought",
 >>>>     or "robust DSP with the UI as a kind of afterthought".   I
don't
 >>>> think that Qt designer is a particularly productive way to design
 >>>>     the DSP bits of a DSP application.
 >>>>
 >>>> The whole "form is more important than function" is a bit of
leftover
 >>>> brain-death promulgated by Steve Jobs, and it was as
 >>>>     wrong-headed then as it is now, IMHO.
 >>>>
 >>>>
 >>>>
 >>>>
 >>>> CONFIDENTIALITY NOTICE - SNC EMAIL: This email and any
attachments are
 >>>> confidential, may contain proprietary, protected, or export
controlled
 >>>> information, and are intended for the use of the intended
recipients
 >>>> only. Any review, reliance, distribution, disclosure, or
forwarding of
 >>>> this email and/or attachments outside of Sierra Nevada Corporation
 >>>> (SNC) without express written approval of the sender, except
to the
 >>>> extent required to further properly approved SNC business
purposes, is
 >>>> strictly prohibited. If you are not the intended recipient of this
 >>>> email, please notify the sender immediately, and delete all copies
 >>>> without reading, printing, or saving in any manner. --- Thank You.
 >>>
 >>
 >>

Re: Qt widgets Improvement

[Volker Schroer]

Hi Marcus,

thanks for the clarification.

Maybe this helps:

Qt Gui sink is an example how to use the designer together with
gnuradio. You'll find it in qt-gui/lib.

An example for an oot using the designer can be found in

github.com/dl1ksv/gr-display

-- Volker

Hi Volker,

I might have gotten my Qt jargon mixed up here :) Yeah I meant QT
Designer. Sorry for the confusion!

Cheers,
Marcus

On 30.01.23 17:29, Volker Schroer wrote:

Hi,

but I think in this case the qt-designer is the tool to to design the
widget. I'm curious how, to integrate qt-creator in the build process.

-- Volker

Am 30.01.23 um 17:11 schrieb Marcus Müller:

Hi everyone!

Sadly, the reply chain on this email thread got broken, so it's probably
hard for you all to see, but:
This is about a specific GSoC proposal, which does not at all imply that
you need Qt for every flowgraph.
Exactly as Rohit describes, this is about making it easier to build a
GUI for GNU Radio flowgraphs *should you decide you want graphical
visualizations*.
And if you do so, gr-qtgui is based on Qt, anyways.

Cheers,
Marcus

On 30.01.23 17:02, Jim Melton wrote:

I'd propose that nothing you do *requires* Qt. There are many uses for
GUI-less flowgraphs. Qt is a heavyweight framework; it should not be
required in order to build GRC flowgraphs.

---
Jim Melton


-Original Message-
From: discuss-gnuradio-bounces+jim.melton=sncorp@gnu.org
 On Behalf Of
Marcus D. Leech
Sent: Sunday, January 29, 2023 12:30
To: discuss-gnuradio@gnu.org
Subject: [EXTERNAL] Re: Qt widgets Improvement

On 29/01/2023 14:20, Rohit Bisht wrote:


I'd like to start with "integrating gnu with qt creator" because it
would make it easier to write code in the integrated qt environment
and speed up build, run, and testing. I believe adjusting the cmake
file and fixing paths to missing library files would be the way to go
(though I'll require more directions on that).

Then "adding new widgets" followed by "improving them" .

I guess it depends on what you think the dominant design doctrine
should be  "gorgeous UI with the DSP as a kind of afterthought",
    or "robust DSP with the UI as a kind of afterthought".   I don't
think that Qt designer is a particularly productive way to design
    the DSP bits of a DSP application.

The whole "form is more important than function" is a bit of leftover
brain-death promulgated by Steve Jobs, and it was as
    wrong-headed then as it is now, IMHO.




CONFIDENTIALITY NOTICE - SNC EMAIL: This email and any attachments are
confidential, may contain proprietary, protected, or export controlled
information, and are intended for the use of the intended recipients
only. Any review, reliance, distribution, disclosure, or forwarding of
this email and/or attachments outside of Sierra Nevada Corporation
(SNC) without express written approval of the sender, except to the
extent required to further properly approved SNC business purposes, is
strictly prohibited. If you are not the intended recipient of this
email, please notify the sender immediately, and delete all copies
without reading, printing, or saving in any manner. --- Thank You.

Re: Qt widgets Improvement

[Volker Schroer]

Hi,

but I think in this case the qt-designer is the tool to to design the
widget. I'm curious how, to integrate qt-creator in the build process.

-- Volker

Am 30.01.23 um 17:11 schrieb Marcus Müller:

Hi everyone!

Sadly, the reply chain on this email thread got broken, so it's probably
hard for you all to see, but:
This is about a specific GSoC proposal, which does not at all imply that
you need Qt for every flowgraph.
Exactly as Rohit describes, this is about making it easier to build a
GUI for GNU Radio flowgraphs *should you decide you want graphical
visualizations*.
And if you do so, gr-qtgui is based on Qt, anyways.

Cheers,
Marcus

On 30.01.23 17:02, Jim Melton wrote:

I'd propose that nothing you do *requires* Qt. There are many uses for
GUI-less flowgraphs. Qt is a heavyweight framework; it should not be
required in order to build GRC flowgraphs.

---
Jim Melton


-Original Message-
From: discuss-gnuradio-bounces+jim.melton=sncorp@gnu.org
 On Behalf Of
Marcus D. Leech
Sent: Sunday, January 29, 2023 12:30
To: discuss-gnuradio@gnu.org
Subject: [EXTERNAL] Re: Qt widgets Improvement

On 29/01/2023 14:20, Rohit Bisht wrote:


I'd like to start with "integrating gnu with qt creator" because it
would make it easier to write code in the integrated qt environment
and speed up build, run, and testing. I believe adjusting the cmake
file and fixing paths to missing library files would be the way to go
(though I'll require more directions on that).

Then "adding new widgets" followed by "improving them" .

I guess it depends on what you think the dominant design doctrine
should be  "gorgeous UI with the DSP as a kind of afterthought",
    or "robust DSP with the UI as a kind of afterthought".   I don't
think that Qt designer is a particularly productive way to design
    the DSP bits of a DSP application.

The whole "form is more important than function" is a bit of leftover
brain-death promulgated by Steve Jobs, and it was as
    wrong-headed then as it is now, IMHO.




CONFIDENTIALITY NOTICE - SNC EMAIL: This email and any attachments are
confidential, may contain proprietary, protected, or export controlled
information, and are intended for the use of the intended recipients
only. Any review, reliance, distribution, disclosure, or forwarding of
this email and/or attachments outside of Sierra Nevada Corporation
(SNC) without express written approval of the sender, except to the
extent required to further properly approved SNC business purposes, is
strictly prohibited. If you are not the intended recipient of this
email, please notify the sender immediately, and delete all copies
without reading, printing, or saving in any manner. --- Thank You.

Re: Tutorial on Hier Block and Parameters

[Volker Schroer]

I think, the PYTHONPATH should not start with :
and it is not required that the PYTHONPATH contains the location of your
grc files.
~/.grc_gnuradio is not a file but a directory. If this diretocry does
not exist, just create it.

Copy your generated *.yml and *.py from your working directory to
~/.grc_gnuradio


What's the output of grc when you start it?

On my system it looks like:

grc
<<< Welcome to GNU Radio Companion v3.10.0.0-22-g7712360d >>>

Block paths:
/home/schroer/.grc_gnuradio
/usr/local/gnuradio/share/gnuradio/grc/blocks

The second path points to the gnuradio blocks and depends on your
installation., probably
/usr/share/gnuradio/grc/blocks/

If grc references your .grc_gnuradio directory , you should find your
created blocks in grc.

If the reference is missing have a look at
~/.gnuradio/config.conf

There should be a section like

[grc]
canvas_default_size = 1280, 1024
canvas_font_size = 8
default_flow_graph =
enabled_components =
testing-support;python-support;man-pages;gnuradio-runtime;gr-ctrlport;gnuradio-companion;gr-blocks;gr-fec;gr-fft;gr-filter;gr-analog;gr-digital;gr-dtv;gr-audio;*
alsa;* oss;gr-channels;gr-pdu;gr-iio;*
libad9361;gr-qtgui;gr-trellis;gr-utils;gr_modtool;gr_blocktool;gr-vocoder;gr-network
global_blocks_path = /usr/local/gnuradio/share/gnuradio/grc/blocks
local_blocks_path =
xterm_executable = /usr/bin/xterm

Here you can specify your local_blocks_path


I hope this helps.

-- Volker


The output is

echo $PYTHONPATH
:/home/grctut/the folder where I am saving working grc files.
However, I am able to use GRC for other purposes normally. I notice that
GRC blocks (.yaml files) are in /usr/share/gnuradio/grc/blocks/ folder.
Also there is no .grc_gnuradio file in my home directory. However, there
is a .gnuradio folder with a prefs folder and config.conf and grc.conf
files. prefs folder has a vmcircbuf_default_factory file.



--

Message: 3
Date: Sat, 12 Feb 2022 12:07:37 +0100
From: Volker Schroer mailto:dl1...@gmx.de>>
To: discuss-gnuradio@gnu.org <mailto:discuss-gnuradio@gnu.org>
Subject: Re: Tutorial on Hier Block and Parameters
Message-ID: mailto:a21da2e7-fea7-ecce-9de3-4b1567795...@gmx.de>>
Content-Type: text/plain; charset=UTF-8; format=flowed

Yes, that the generated hier block files go to the working directory of
~/.grc_gnuradio is a known bug.

See:
https://github.com/gnuradio/gnuradio/pull/5547
<https://github.com/gnuradio/gnuradio/pull/5547>

What is the result of

echo $PYTHONPATH


-- Volker
 > Hi,
 > I am facing a problem  using the tutorial. My installation is from
 > repository.
 > I am using GRC3.10.1.1(Python3.8.10) on OS Ubuntu 20.04.3LTS.
 > When I generate the flow graph, output files are going to the working
 > directory and not .grc_gnuradio as mentioned in tutorial. Probably
 > because of this, they are not appearing in the block tree of GRC.
Also,
 > I get these messages on the terminal.
 > Warning: vocoder_codec2_decode_ps - option_attributes are for enums
 > only, ignoring
 >  >>> Warning: vocoder_codec2_encode_sp - option_attributes are
for enums
 > only, ignoring
 > May not be relevant, but I observe whenever I open the terminal, the
 > following line appears before the command prompt.
 > PYTHONPATH: command not found
 > Please help me in configuring GRC properly. Or do i have to install
 > gnuradio in home directory instead of system installation?
 >
 > --
 > Best Regards,
 > vsrk sarma

--
Best Regards,
vsrk sarma

Re: Tutorial on Hier Block and Parameters

[Volker Schroer]

Yes, that the generated hier block files go to the working directory of
~/.grc_gnuradio is a known bug.

See:
https://github.com/gnuradio/gnuradio/pull/5547

What is the result of

echo $PYTHONPATH


-- Volker

Hi,
I am facing a problem  using the tutorial. My installation is from
repository.
I am using GRC3.10.1.1(Python3.8.10) on OS Ubuntu 20.04.3LTS.
When I generate the flow graph, output files are going to the working
directory and not .grc_gnuradio as mentioned in tutorial. Probably
because of this, they are not appearing in the block tree of GRC. Also,
I get these messages on the terminal.
Warning: vocoder_codec2_decode_ps - option_attributes are for enums
only, ignoring
 >>> Warning: vocoder_codec2_encode_sp - option_attributes are for enums
only, ignoring
May not be relevant, but I observe whenever I open the terminal, the
following line appears before the command prompt.
PYTHONPATH: command not found
Please help me in configuring GRC properly. Or do i have to install
gnuradio in home directory instead of system installation?

--
Best Regards,
vsrk sarma

Re: FFT size in QT GUI Freq.Sink

[Volker Schroer]

You have to set the spectrum width to half in the gui frequency sink block.


The fftsize should be 32 256 512 1024 2048 4096 .
In the example you mentioned, the fftsize is set to 2048.

-- Volker

I was learning about the sampling rate by looking into the
tutorial provided in the GNURadio wiki
URL: https://wiki.gnuradio.org/index.php/Sample_Rate_Tutorial


When I was trying to replicate the flowgraph in my 3.8.2.0 version of
GNURadio. I got an FFT size error message:

     return _qtgui_swig.freq_sink_f_make(fftsize, wintype, fc, bw, name,
nconnections, parent)
RuntimeError: freq_sink: FFT size must be > 16 and < 16384.

Then I tried to increase the FFT size to 17 and then the flowgraph was
executed but the flowgraph was not the same as shown in the example.

Attaching the flowgraph for the reference

My question is whether I have built the flowgraph in the wrong manner or
is it with the GNURadio 3.8 issue??

Regards
Ярослав

Re: FFT size in QT GUI Freq.Sink

[Volker Schroer]

The fftsize should be 32 256 512 1024 2048 4096 .
In the example you mentioned, the fftsize is set to 2048.

-- Volker

I was learning about the sampling rate by looking into the
tutorial provided in the GNURadio wiki
URL: https://wiki.gnuradio.org/index.php/Sample_Rate_Tutorial


When I was trying to replicate the flowgraph in my 3.8.2.0 version of
GNURadio. I got an FFT size error message:

     return _qtgui_swig.freq_sink_f_make(fftsize, wintype, fc, bw, name,
nconnections, parent)
RuntimeError: freq_sink: FFT size must be > 16 and < 16384.

Then I tried to increase the FFT size to 17 and then the flowgraph was
executed but the flowgraph was not the same as shown in the example.

Attaching the flowgraph for the reference

My question is whether I have built the flowgraph in the wrong manner or
is it with the GNURadio 3.8 issue??

Regards
Ярослав

Re: Error when opening flowgraph unless a specific unused block is enabled

[Volker Schroer]

It's an error in grc. The block 'Modulate vector' is not proper
evaluated. Just open and close the block 'Modulate vector' in the
property editor then you get the error message :


Value "digital.modulate_vector_bc(mod.to_basic_block(), data, taps)"
cannot be evaluated:
'NoneType' object has no attribute 'to_basic_block'


I think there is an error in the digital_modulate_vector.block.yml
definition.
Probably line 16 in this file

value: ${ digital.modulate_vector_bc(mod.to_basic_block(), data, taps) }

should be removed.

-- Volker
Am 20.09.21 um 21:54 schrieb Jameson Collins:

I am trying  to make my own version of packet_rx.grc.  I copied the
flowgraph and began modifying it.  I found that at some point  I started
getting this error when I open the flowgraph:

ERROR:gnuradio.grc.core.FlowGraph:Failed to evaluate variable block
modulated_sync_word
Traceback (most recent call last):
   File
"/home/user/git/toolbox/conda/miniforge3/envs/gnuradio/lib/python3.8/site-packages/gnuradio/grc/core/FlowGraph.py",
line 268, in renew_namespace
     value = eval(variable_block.value, namespace, variable_block.namespace)
   File "", line 1, in 
AttributeError: 'NoneType' object has no attribute 'to_basic_block'
ERROR:gnuradio.grc.core.FlowGraph:Failed to evaluate variable block
modulated_sync_word
Traceback (most recent call last):
   File
"/home/user/git/toolbox/conda/miniforge3/envs/gnuradio/lib/python3.8/site-packages/gnuradio/grc/core/FlowGraph.py",
line 268, in renew_namespace
     value = eval(variable_block.value, namespace, variable_block.namespace)
   File "", line 1, in 
AttributeError: 'NoneType' object has no attribute 'to_basic_block'

I traced the problem back to whether or not the preamble variables are
enabled in the flowgraph.  However, it doesn't matter whether these
variables are actually used anywhere.  They simply need to exist
otherwise this error occurs.

Please see the attached grc file.  It has the minimum number of blocks
to reproduce the error.  If the 3 disabled blocks are instead enabled
then the error will not occur.

Re: Regarding the error in creating an OOT module in GR3.9

[Volker Schroer]

I think you have a version mix. gnuradio 3.9 uses std::shared_ptr but
you boost::shared_ptr which is 3.8
 So you need a version of gr-packetizer that supports 3.9.

-- Volker

Am 09.08.21 um 11:42 schrieb Yash Agrawal 18410 via GNU Radio, the Free
& Open-Source Toolkit for Software Radio:

Hello everyone,
  am currently working on the project "'Implementation of a packet
encoder/decoder pair in the GNU radio framework'".I am getting some
serious errors while running the project on the above mentioned
environment shown as:
merlin@merlin:~/chchc/gnuradioproject-master/gr-packetizer/build$ make
Scanning dependencies of target gnuradio-packetizer
[  3%] Building CXX object
lib/CMakeFiles/gnuradio-packetizer.dir/preamble_header_payload_demux_impl.cc.o
/home/merlin/chchc/gnuradioproject-master/gr-packetizer/lib/preamble_header_payload_demux_impl.cc:
In static member function ‘static
gr::packetizer::preamble_header_payload_demux::sptr
gr::packetizer::preamble_header_payload_demux::make(int, int, int, const
string&, const string&, bool, size_t, const string&, double, const
std::vector >&, size_t, int, int)’:
/home/merlin/chchc/gnuradioproject-master/gr-packetizer/lib/preamble_header_payload_demux_impl.cc:90:9:
error: could not convert ‘gnuradio::get_initial_sptr(T*) [with T =
gr::packetizer::preamble_header_payload_demux_impl]()’ from
‘std::shared_ptr’ to
‘gr::packetizer::preamble_header_payload_demux::sptr {aka
boost::shared_ptr}’
        return gnuradio::get_initial_sptr
               ~~
          (new preamble_header_payload_demux_impl(
          ^~~~
            header_len,
            ~~~
            items_per_symbol,
            ~
            guard_interval,
            ~~~
            length_tag_key,
            ~~~
            trigger_tag_key,
            
            output_symbols,
            ~~~
            itemsize,
            ~
            timing_tag_key,
            ~~~
            samp_rate,
            ~~
            special_tags,
            ~
            header_padding,
            ~~~
            preamble_len,
            ~
            header_len_divider
            ~~
          ));
          ~~
lib/CMakeFiles/gnuradio-packetizer.dir/build.make:62: recipe for target
'lib/CMakeFiles/gnuradio-packetizer.dir/preamble_header_payload_demux_impl.cc.o'
failed
make[2]: ***
[lib/CMakeFiles/gnuradio-packetizer.dir/preamble_header_payload_demux_impl.cc.o]
Error 1
CMakeFiles/Makefile2:174: recipe for target
'lib/CMakeFiles/gnuradio-packetizer.dir/all' failed
make[1]: *** [lib/CMakeFiles/gnuradio-packetizer.dir/all] Error 2
Makefile:140: recipe for target 'all' failed
make: *** [all] Error 2

My current working environment is gnuradio 3.9 on ubuntu 18.04. Hence
any leads will be thankful.
-/ Thanks and Regards/
/Yash Agrawal/
/Electrical Engineering and Computer Sciences Department
/
/18410/

Re: GNU Radio (Companion) bug

[Volker Schroer]

As 'm just working on the feature/gr-iio branch, I used this branch for
testing your grc file.
But I think this does not concern grc.


I can load your flowgraph and make changes to your sampe_rate_chooser
block. Everything works fine. If I disable your dvbtx block and
enable OFDM symbol I can generate your flowgraph.

But if run this flowgraph I get

AttributeError: module 'osmosdr' has no attribute 'ALL_MBOARDS'

but this may depend on my Osmocom implementation.

-- Volker



Am 03.05.21 um 21:07 schrieb Ralf Gorholt:

Dear all,

I have spent several hours before my PC trying to get my new OOT block
running, but in vain. Now I have got the impression that one of my
problems is due to a bug in GNU Radio (Companion). I have attached a
working graph (using Qt GUI) to this email. I am not used to report bugs
but in the wiki I have read that I should send an email to this list.

The problem is, that in certain cases when I change the value of a
parameter in a combo box, GRC displays a message telling me that ports
are disconnected although they are not.

This behaviour can easily reproduced. In GRC, load the attached flow
graph and open the properties window of a block that has a combo box.
Then, change a parameter and click the "Apply" button. The value in the
block changes. Then change the value back. As soon as you select the
item in the combo box, a message is displayed telling you that the ports
are not connected and no more changes are accepted, even when you click
on "Apply".

I have verified this with GNU Radio version 3.8.2.0 on Linux (Python
3.8.5) and 3.8.0.0 on Windows (Python 2.7.10). GNU Radio 3.9 (checked on
Windows) does not show this behaviour but if I remember correctly, not
everything has been ported to version 3.9 yet and for this reason I
would like to keep version 3.8. Would it be possible to fix this bug
also in version 3.8?

Thank you very much for your help.

Kind regards,

Ralf

Re: GNU Radio sink question

[Volker Schroer]

Try to add

flags: throttle

in your corresponding grc file

Am 08.04.21 um 12:23 schrieb jean-michel.fri...@femto-st.fr:

I have just completed gr-rpitx a GNU Radio sink block for emitting
from Raspberry Pi's GPIO output thanks to F5OEO's librpitx
(https://github.com/jmfriedt/gr-rpitx) and the dataflow is well scheduled
as shown with the short movie
https://github.com/jmfriedt/gr-rpitx/tree/main/examples/gr-rpitx_demo.mp4

However in this implementation, GNU Radio Companion complains that I have
not included a Throttle block since it does not know that the sink is clocked
by hardware. How can I tell GNU Radio that the stream data rate will be defined
by this hardware sink ?

Thanks, JM

Re: Calling work function slower in v3.8 than v3.7

[Volker Schroer]

I found this piece of code, that may help.
It's taken from
https://github.com/dl1ksv/gr-iio/blob/gr3.9/lib/device_sink_impl.cc
which is a fork of analogdevicesinc/gr-iio


lines 163 ff

/*
 * The private constructor
 */
device_source_impl::device_source_impl(struct iio_context *ctx,
bool destroy_ctx, const std::string ,
const std::vector ,
const std::string _phy,
const std::vector ,
unsigned int buffer_size, unsigned int decimation)
  : gr::sync_block("device_source",
  gr::io_signature::make(0, 0, 0),
  gr::io_signature::make(1, -1, sizeof(short))),
port_id(pmt::mp("msg")),
timeout(100),
ctx(ctx), buf(NULL),
buffer_size(buffer_size),
decimation(decimation),
destroy_ctx(destroy_ctx)


and lines 336

if (!fast_enough) {
message_port_pub(port_id, pmt::mp("timeout"));
/* GNU Radio won't call our block anytime soon if the
 * work() function returns 0; it can take up to 500ms
 * before it gets called again. To avoid that, we make
 * this block send itself a dummy message on its input
 * system message port, so that the scheduler calls us
 * again promptly. */
pmt::pmt_t payload = pmt::from_long(0);
pmt::pmt_t msg = pmt::cons(pmt::mp("done"), payload);
post(pmt::mp("system"), msg);
return 0;


-- Volker



Am 07.04.21 um 21:34 schrieb Jeff S:

I am having an issue with a custom OOT module which is acting as a burst 
source.  It receives an asynchronous message in one thread, and then puts data 
into the stream using another thread.  This worked fine using GR v3.7, but with 
v3.8, not so much.

I believe my problem may have to do with how the scheduler operates now, in that in 
v3.7, the ::work() function was called very quickly ( at a rate of < 1 ms per 
call), no mater what data is being sent into the stream.  With version 3.8, when no 
data is being sent into the stream, I am getting a fairly constant 250 ms calls to 
::work().  This causes a significant delay for when data is received to when it can 
get transmitted (when I'm looking for a <= 4 ms response).

I've search a bit in the archives, but haven't found quite what I'm looking 
for.  Is there a way to signal the scheduler asynchronously to make a call to 
::work(), or to make the scheduler call work at a faster rate?

Thanks.
Jeff

Re: Version info

[Volker Schroer]

Thanks for the info.
I see the wrong version info depends on git describe which depends on a
correct tagging.

As every branch has it's own version info, why don't we use

git rev-parse --short HEAD instead of git describe to get the commit hash ?

So we would be independent of missing tags.

-- Volker



I filed an issue for this.

https://github.com/gnuradio/gnuradio/issues/4059

Ron

On 1/15/21 08:58, Jeff Long wrote:

The v3.8.0.0 part is incorrect, but commit be21c299 shows you built a
recent master. There is no 3.9 or 3.10 tag yet, so everything shows up
as 3.8.

On Fri, Jan 15, 2021 at 11:46 AM Volker Schroer mailto:dl1...@gmx.de>> wrote:

Hi,
I just build a fresh version of gnuradio from latest git master
branch.
After running cmake I get:

Building for version: v3.8.0.0-891-gc4b33434 / 3.10.0git

and after building I get

gnuradio-config-info -v
v3.8.0.0-879-gbe21c299

What does v3.8 means at that point. I'd expected at least 3.9 or
even 3.10.

Is this an error or do I understand somehing wrong ?

-- Thanks

Volker

Version info

[Volker Schroer]

Hi,
I just build a fresh version of gnuradio from latest git master branch.
After running cmake I get:

Building for version: v3.8.0.0-891-gc4b33434 / 3.10.0git

and after building I get

gnuradio-config-info -v
v3.8.0.0-879-gbe21c299

What does v3.8 means at that point. I'd expected at least 3.9 or even 3.10.

Is this an error or do I understand somehing wrong ?

-- Thanks

Volker

clang formating

[Volker Schroer]

Hi,

I just made a pr and got the message that the pr formatting check
failed. But looking at the output I don't understand, what's wrong.

Even more I'd like to know how I can do the formatting check locally.
The coding guide in the wiki is empty.

Thanks in advance

-- Volker

Re: Latency Manager from GRCON2019

[Volker Schroer]

Hello !
Meanwhile gnuradio does not use swig but pybind.
If your OOT requires swig you have to go back to 3.8

-- Volker, dl1ksv

Am 06.11.20 um 22:31 schrieb Fabien PELLET:

Hello,

I'm trying to compile the project OOT of latency manager of Matt ETTUS
from he presents at the GRCON2019.

For that I built from source GNURadio to get 3.9 version successfully
but I can't compile the project provided here :
https://github.com/dkozel/gr-workinprogress.

The CMAKE fails and tell that it can't find GRSwig. I'm on Ubuntu 20.04.

Thanks for any help or suggestions.

Best regards,

Fabien PELLET, F4CTZ.

Re: Custom Qt GUI Sink Block

[Volker Schroer]

Hi Jerrid,

have a look at

https://github.com/dl1ksv/gr-display

and there at display_text_msg.

Perhaps, you can use this module directly or adjust to your needs.

-- Volker


Hey All,

Currently I am trying to test some code I have in an embedded python
block and verify that a string variable is changing given the correct
situations. However, I have not found an easy way to display this string
message to the GUI while my gnuradio flowgraph is running. So what I
would like to do is create a Qt GUI message sink block, that operates
identically to the number sink block, but instead of taking a float
value as an input it takes a pmt as an input. Does anyone know how to do
this using an embedded python block? I have never quite understood
creating OOT modules and coding custom blocks using C++, so being able
to make a Qt GUI block using python would be much easier for me if it is
possible.

Best Regards,

Jerrid

Re: Porting gr-osmosdr to gr-3.9 without swig.

[Volker Schroer]

Hi Chris,

I started gr-osmosdr some month ago, but I had to interrupt due to other
coding needs.

What gr-osmosdr repository did you start with ?
I forked
https://github.com/argilo/gr-osmosdr.git

which had some preparations for 3.9, but at that time gr3.9 still used swig.

First I ported successfully some of my oot modules to 3.9 the way
described in the porting guide.

But for more complex modules I tried another way.

I removed the swig part and looked at my ported modules, how to add the
pybind part.

At the moment I'm at the point af generating the bindings.

-- Volker

Re: Amateur Radio G3RUH AX.25 2FSK

[Volker Schroer]


The master branch is for gr3.9, but there is a gnuradio 3.8 branch

Another good starting point for ax.25 could be wb2osz/direwolf on github.
— Volker



>> Am 12.08.2020 um 06:31 schrieb Yugal Joshi :
> 
> Hello Jeff
> Thanks for replying 
> 
> From what I learned in last two days in GNU Radio, it looks like gr-25 is an 
> OOT module.
> gr-25 works with GR 3.9 and pybinds and I am using GR 3.8.1.0.
> 
> Also I want to implement G3RUH  2FSK AX25 using the core modules of GRC or 
> programming  new OOTs so that I can improve my learning curve. 
> 
> Any help would be appreciated from the community.
> 
> Thanks and Regards
> 
> Yugal Joshi 
> 
> 
>> On Wed, 12 Aug 2020, 4:45 am Jeff Long,  wrote:
>> Have you already take a look at this?
>> https://github.com/dl1ksv/gr-ax25
>> 
>>> On Tue, Aug 11, 2020 at 4:13 PM Yugal Joshi  
>>> wrote:
>>> Hello all 
>>> I am new to the GNU Radio community.
>>> I am starting an effort to implement a receiver using GNU Radio for the 
>>> amateur radio whose transmitter operates in G3RUH mode with 2-FSK 
>>> modulation and AX25 data format.
>>> I designed the project to learn GNU Radio as well as to contribute 
>>> something to the SmallSat Community of my institution Indian Institute of 
>>> Space Science and Technology (IIST).
>>> 
>>> Is anyone else working on the same configurations ?
>>> 
>>> Anyone who can guide me through the procedural steps I should take to 
>>> design this receiver(G3RUH mode with 2-FSK and AX25 data format)?
>>> 
>>> As a background information : 
>>> The AX.25 protocol is a standard for encoding the data that includes a 
>>> message header,station callsign, destination callsign, message and a simple 
>>> CRC-16.
>>> The system is widely used for position reporting of the amateur stations
>>> 
>>> Looking for a directive path to move ahead and a positive response.
>>> 
>>> Thanks and Regards
>>> -- 
>>> Yugal Joshi 
>>> B. Tech. Electronics and Communication Engineering
>>> Indian Institute of Space Science and Technology (IIST)
>>> Thiruvananthapuram
>>> Kerala
>>> India  - 695547

Re: Porting oot modules to gr 3.9 and pybind ***solved

[Volker Schroer]

Finally I found the solution.

You have to call

py::module::import("gnuradio.qtgui.qtgui_python");

inside the PYBIND11_MODULE macro

-- Volker

Re: Porting oot modules to gr 3.9 and pybind

[Volker Schroer]

Meanwhile I came a bit further.

In qtgui there is a binding definition for QWidget. If I put the same
definition into my gr-display bindings, the error disappears. But now I
can't use my module together with the qtgui.

I can't import display together with qtgui as the secon import fails with

from .qtgui_python import *
ImportError: generic_type: type "QWidget" is already registered!

So how can I reuse the binding definition from gnuradio/qtgui inside my
oot module.

Any hints are appreciated.

-- Volker

Re: Porting oot modules to gr 3.9 and pybind

[Volker Schroer]

Am 03.07.20 um 22:52 schrieb Josh:

Try putting an extra None for parent parameter as the last arg in those
instantiations. Take a look at the flow graph generation for any of the
qt GUI widgets. For some reason pybind doesn’t like the last default param.



That did not help. Only removing the parent parameter helps.
I compared to the qtgui blocks and found out that

parent: gnuradio.qtgui.qtgui_python.QWidget = 0


although parent is declared as QWidget*, as I do.
But in my case

parent: QWidget  = 0

I'm curious where this replacement happens.

-- Volker


On Fri, Jul 3, 2020 at 11:14 AM Volker Schroer mailto:dl1...@gmx.de>> wrote:

Yes,
__PIC__ is required, and ENABLE_PYTHON, too.

With hardcoded  include directories to add_include in
   bindtool/core/generator.py I'm able to generate the bindings and
build
the module.

But trying to run the blocks fails with typeError.

For instance

    File

"/home/schroer/gnuradiocomponents/gr-display.orig/python/qa_display_text_msg.py",
line 30, in test_instance
      instance = text_msg('TestString')
TypeError: __init__(): incompatible constructor arguments. The following
argument types are supported:
      1. display.display_python.text_msg(label: str, parent: QWidget
= 0)

Invoked with: 'TestString'

Or

Traceback (most recent call last):
    File
"/home/schroer/gnuradiocomponents/gr-display.orig/python/qa_show_image.py",
line 32, in test_instance
      instance = show_image(imagewidth ,
TypeError: __init__(): incompatible constructor arguments. The following
argument types are supported:
      1. display.display_python.show_image(imagewidth: int, imageheight:
int, parent: QWidget = 0)

Invoked with: 1024, 512, None


What am I doing wrong, or what is missing ?

The only difference I can see to my working gr-funcube is the use of a
QWidget as parameter.

Any hints ?

-- Volker

 > In parseheader_generic.py, there is fpic defined, but I think it
might
 > need the __PIC__
 >
 >              generator_path, generator_name =
utils.find_xml_generator()
 >              xml_generator_config =
parser.xml_generator_configuration_t(
 >                  xml_generator_path=generator_path,
 >                  xml_generator=generator_name,
 >                  include_paths=self.include_paths,
 >                  compiler='gcc',
 >                  undefine_symbols=['__PIE__'],
 >
 > #define_symbols=['BOOST_ATOMIC_DETAIL_EXTRA_BACKEND_GENERIC',
'__PIC__'],
 >
 > define_symbols=['BOOST_ATOMIC_DETAIL_EXTRA_BACKEND_GENERIC'],
 >                  cflags='-std=c++11 -fPIC')
 >
 > On Wed, Jul 1, 2020 at 11:38 AM Volker Schroer mailto:dl1...@gmx.de>
 > <mailto:dl1...@gmx.de <mailto:dl1...@gmx.de>>> wrote:
 >
 >     Josh,
 >
 >     meanwhile I found the add_include parameter
 >     in bindtool/core/generator.py and hardcoded there the qt
includes.
 >
 >     That leads to
 >
 >     INFO Parsing source file
 >
  
"/home/schroer/gnuradiocomponents/gr-display.orig/include/display/display_text_msg.h"
 >     ...
 >     In file included from
 >
  
/home/schroer/gnuradiocomponents/gr-display.orig/include/display/display_text_msg.h:33:
 >     In file included from
 >     /usr/include/x86_64-linux-gnu/qt5/QtWidgets/qapplication.h:43:
 >     In file included from
 >     /usr/include/x86_64-linux-gnu/qt5/QtWidgets/qtwidgetsglobal.h:43:
 >     In file included from
 >     /usr/include/x86_64-linux-gnu/qt5/QtGui/qtguiglobal.h:43:
 >     /usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h:1187:4:
error: "You
 >     must build your code with position
 >             independent code if Qt was built with
-reduce-relocations. "
 >          "Compile your code with -fPIC
 >             (-fPIE is not enough)."
 >     #  error "You must build your code with position independent
code if Qt
 >     was built with -reduce-rel...
 >          ^
 >     1 error generated.
 >     Error occurred while running CASTXML:  status:1
 >
 >
 >     So I think , some compiler flags are needed, too.
 >
 >     I'm going to find out how to come across.
 >
 >     In the long run the bind tool will need an additional
include-directory
 >     parameter.
 >
 >     -- Volker
 >
 >
 >     Am 01.07.20 um 17:02 schrieb Josh:
 >      > Volker,
 >      >
 >      > Glad that the first one worked.  I had to do a little bit of
  

Re: Porting oot modules to gr 3.9 and pybind

[Volker Schroer]

Yes,
__PIC__ is required, and ENABLE_PYTHON, too.

With hardcoded  include directories to add_include in
 bindtool/core/generator.py I'm able to generate the bindings and build
the module.

But trying to run the blocks fails with typeError.

For instance

  File
"/home/schroer/gnuradiocomponents/gr-display.orig/python/qa_display_text_msg.py",
line 30, in test_instance
instance = text_msg('TestString')
TypeError: __init__(): incompatible constructor arguments. The following
argument types are supported:
1. display.display_python.text_msg(label: str, parent: QWidget = 0)

Invoked with: 'TestString'

Or

Traceback (most recent call last):
  File
"/home/schroer/gnuradiocomponents/gr-display.orig/python/qa_show_image.py",
line 32, in test_instance
instance = show_image(imagewidth ,
TypeError: __init__(): incompatible constructor arguments. The following
argument types are supported:
1. display.display_python.show_image(imagewidth: int, imageheight:
int, parent: QWidget = 0)

Invoked with: 1024, 512, None


What am I doing wrong, or what is missing ?

The only difference I can see to my working gr-funcube is the use of a
QWidget as parameter.

Any hints ?

-- Volker


In parseheader_generic.py, there is fpic defined, but I think it might
need the __PIC__

             generator_path, generator_name = utils.find_xml_generator()
             xml_generator_config = parser.xml_generator_configuration_t(
                 xml_generator_path=generator_path,
                 xml_generator=generator_name,
                 include_paths=self.include_paths,
                 compiler='gcc',
                 undefine_symbols=['__PIE__'],

#define_symbols=['BOOST_ATOMIC_DETAIL_EXTRA_BACKEND_GENERIC', '__PIC__'],

define_symbols=['BOOST_ATOMIC_DETAIL_EXTRA_BACKEND_GENERIC'],
                 cflags='-std=c++11 -fPIC')

On Wed, Jul 1, 2020 at 11:38 AM Volker Schroer mailto:dl1...@gmx.de>> wrote:

Josh,

meanwhile I found the add_include parameter
in bindtool/core/generator.py and hardcoded there the qt includes.

That leads to

INFO Parsing source file

"/home/schroer/gnuradiocomponents/gr-display.orig/include/display/display_text_msg.h"
...
In file included from

/home/schroer/gnuradiocomponents/gr-display.orig/include/display/display_text_msg.h:33:
In file included from
/usr/include/x86_64-linux-gnu/qt5/QtWidgets/qapplication.h:43:
In file included from
/usr/include/x86_64-linux-gnu/qt5/QtWidgets/qtwidgetsglobal.h:43:
In file included from
/usr/include/x86_64-linux-gnu/qt5/QtGui/qtguiglobal.h:43:
/usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h:1187:4: error: "You
must build your code with position
        independent code if Qt was built with -reduce-relocations. "
     "Compile your code with -fPIC
        (-fPIE is not enough)."
#  error "You must build your code with position independent code if Qt
was built with -reduce-rel...
     ^
1 error generated.
Error occurred while running CASTXML:  status:1


So I think , some compiler flags are needed, too.

I'm going to find out how to come across.

In the long run the bind tool will need an additional include-directory
parameter.

-- Volker


Am 01.07.20 um 17:02 schrieb Josh:
 > Volker,
 >
 > Glad that the first one worked.  I had to do a little bit of
gymnastics
 > to get the gr-qtgui files binded in-tree.  If you look at the
notes in
 > gr-utils/bindtool/scripts/bind_gr_module.py, QTGUI required
passing as
 > args the include directories to the QT installation.  This is because
 > pygccxml does some sort of sandboxed compile of the target header
file.
 > So gr_modtool bind will need to have those arguments or some other
 > script to get around it.  I can take a look at this, but there
might be
 > a workaround for getting the bindings generated now.
 >
 > Josh
 >
 >
 >
 >
 >
 >
 > On Wed, Jul 1, 2020 at 5:50 AM Volker Schroer mailto:dl1...@gmx.de>
 > <mailto:dl1...@gmx.de <mailto:dl1...@gmx.de>>> wrote:
 >
 >     Hi,
 >
 >     I'm just started to port some of my oot modules to gr 3.9 and
pybind. I
 >     followed
 >
https://wiki.gnuradio.org/index.php/GNU_Radio_3.9_OOT_Module_Porting_Guide
 >
 >     and it worked flawless for my first module gr-funcube.
 >
 >     Now I'm trying to port gr-display , which requires qt5 to be
built.
 >     When I run
 >
 >     gr_modtool bind display_text_msg
 >
 >     I get:
 >     GNU Radio module name identified: display
 >     INFO Parsing source file
 >
  
"/home/schroer/gnuradiocompone

Porting oot modules to gr 3.9 and pybind

[Volker Schroer]

Hi,

I'm just started to port some of my oot modules to gr 3.9 and pybind. I
followed
https://wiki.gnuradio.org/index.php/GNU_Radio_3.9_OOT_Module_Porting_Guide

and it worked flawless for my first module gr-funcube.

Now I'm trying to port gr-display , which requires qt5 to be built.
When I run

gr_modtool bind display_text_msg

I get:
GNU Radio module name identified: display
INFO Parsing source file
"/home/schroer/gnuradiocomponents/gr-display.orig/include/display/display_text_msg.h"
...
/home/schroer/gnuradiocomponents/gr-display.orig/include/display/display_text_msg.h:33:10:
fatal error:
  'qapplication.h' file not found
#include 
 ^~~~
1 error generated.
Error occurred while running CASTXML:  status:1


How can I come across this error ?

-- Volker

Background colour settings of grc variable editor

[Volker Schroer]

Hello list,

using grc / gnuradio on Ubuntu (19.10 and 20.04)  gives unreadable value
entries in the variable editor or in the parameter editor if the
parameter type is raw.
In such a case the background colur of the value entry is black and the
text colour is black, too. See attached screenshot.

Trying the same on a gentoo box everythings works fine.

So I suppose, it's first a problem of the linux distro, not of gnuradio.

But I could not find out wherefrom grc takes the settings of the value
entry in the variable / parameter editor.

Any hints would be appreciated

-- Volker

Re: GR3.8 RTL-SDR: Errors in swig?

[Volker Schroer]

Hi,

does

dmesg

give some hints why the kernel driver was detached ?

I had to blacklist

dvb_usb_rtl28xxu

module to get my dongle running.


Then the output looks like

gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.9.0.0-git
built-in source types: file rtl rtl_tcp rfspace redpitaya
Using device #0 Generic RTL2832U SN: 153705700
Found Rafael Micro R820T tuner
[R82XX] PLL not locked!
[R82XX] PLL not locked!
Allocating 15 zero-copy buffers


-- Volker
Am 02.05.20 um 19:32 schrieb Michael Hartje:

Dear List,

after upgrade to GR 3.8 (opensuse Thumbleweed) I tried the first simple
receiver:

RTL-SDR-Block ---> null-Block (checked it with osmosdr-block, -- same error)

When I start the program

hartje@nb-wrkn:~/Dokumente/afu/grc> python3 FM_RTL38n.py
CPU Features: SSE2+ SSE4.1+ AVX+ FMA+
Using avx for xtrxdsp_iq16_sc32
Using avx for xtrxdsp_iq8_ic16
Using avx for xtrxdsp_iq16_ic16i
Using avx for xtrxdsp_iq8_ic8i
Using avx for xtrxdsp_sc32i_iq16
Using avx for xtrxdsp_iq8_sc32
Using avx for xtrxdsp_iq8_sc32i
Using avx for xtrxdsp_iq16_sc32i
Using avx for xtrxdsp_sc32_iq16
Using avx for xtrxdsp_ic16i_iq16
linux; GNU C++ version 9.2.1 20200128 [revision
83f65674e78d97d27537361de1a9d74067ff228d]; Boost_107100;
UHD_003.009.007-0-unknown

gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.8.0.0
built-in source types: file osmosdr rtl rtl_tcp uhd miri sdrplay hackrf
bladerf rfspace airspy airspyhf soapy redpitaya freesrp xtrx
Using device #0 Realtek RTL2838UHIDIR SN: 0001
Detached kernel driver
Found Rafael Micro R820T tuner
[R82XX] PLL not locked!
[R82XX] PLL not locked!
Traceback (most recent call last):
   File "FM_RTL38n.py", line 148, in 
     main()
   File "FM_RTL38n.py", line 126, in main
     tb.start()
   File "/usr/lib64/python3.8/site-packages/gnuradio/gr/top_block.py",
line 111, in start
     top_block_start_unlocked(self._impl, max_noutput_items)
   File "/usr/lib64/python3.8/site-packages/gnuradio/gr/runtime_swig.py",
line 4832, in top_block_start_unlocked
     return _runtime_swig.top_block_start_unlocked(r, max_noutput_items)
RuntimeError: list contains invalid format!
Reattached kernel driver
hartje@nb-wrkn:~/Dokumente/afu/grc>

my swig version 4.0.1-2.1

Please have a look on the last lines... -- any help will be welcome.

Re: Weird Python Sinks Crash with GNU Radio 3.8.1

[Volker Schroer]

Tested on Ubuntu 19.10 with python 3.7.5

Crashing.

Backtrace gives

Thread 3 "my_null_sink4" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe8939700 (LWP 7033)]
0x7265bed1 in gr::py_feval_ll::calleval(long) () from
/usr/local/gnuradio/lib/python3/dist-packages/gnuradio/gr/_runtime_swig.so
(gdb) bt
#0  0x7265bed1 in gr::py_feval_ll::calleval(long) () from
/usr/local/gnuradio/lib/python3/dist-packages/gnuradio/gr/_runtime_swig.so
#1  0x76caf2ea in gr::block_gateway_impl::work(int,
std::vector >&,
std::vector >&) ()
   from /usr/local/gnuradio/lib/libgnuradio-runtime.so.3.9.0
#2  0x76caf423 in gr::block_gateway_impl::general_work(int,
std::vector >&, std::vector >&, std::vector >&)
() from /usr/local/gnuradio/lib/libgnuradio-runtime.so.3.9.0
#3  0x76cad1a3 in gr::block_executor::run_one_iteration() ()
from /usr/local/gnuradio/lib/libgnuradio-runtime.so.3.9.0
#4  0x76d03093 in
gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr,
boost::shared_ptr, int) () from
/usr/local/gnuradio/lib/libgnuradio-runtime.so.3.9.0
#5  0x76cf498e in
boost::detail::function::void_function_obj_invoker0,
void>::invoke(boost::detail::function::function_buffer&) ()
   from /usr/local/gnuradio/lib/libgnuradio-runtime.so.3.9.0
#6  0x76d105c6 in
boost::detail::thread_data >::run() () from
/usr/local/gnuradio/lib/libgnuradio-runtime.so.3.9.0
#7  0x771f61b5 in ?? () from
/usr/lib/x86_64-linux-gnu/libboost_thread.so.1.67.0
#8  0x77d9c669 in start_thread (arg=) at
pthread_create.c:479
#9  0x77ed8323 in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95


By the way: trying the gnuradio version with pybind instead of swig
crashes too.

-- Volker

Re: Qt GUI Chooser initial selection

[Volker Schroer]

I think, it should be possible to take the qtgui_chooser.block.yml file
from the master branch. This sould work, as there is no code affected.

Volker

Am 12.04.20 um 14:56 schrieb Chris Vine:

Ah, OK.  This did not find its way into gnuradio-3.8.1.0.  Presumably it
will apply OK to that version however?  (If so I suggest it is applied
to the 3.8 branch also.)

Chris


On Sun, 12 Apr 2020 11:48:56 +0200
Volker Schroer  wrote:

Hi !
This was fixed with #2778

See also:

https://github.com/gnuradio/gnuradio/pull/2778/files/ef5ca9fe51dc45c0332e41db36f822f145f6116a


-- Volker
Am 11.04.20 um 14:45 schrieb Chris Vine:

Hi,

On porting a gnuradio-companion flow graph from gnuradio-3.7 to
gnuradio-3.8, I noticed that there no longer seems to be a way of
setting the initial (default) selection for the Qt GUI Chooser widget.
The initial selection seems now always to be the first one in the list.

The widget is therefore no longer suitable for presenting a selection
of numeric values to the user in numerical order where you don't want
the initial default to be the highest (or lowest) value.

Is there some way around this or some other widget that is now intended
to be used for this purpose?

Chris

Question on OOT- Modules installation path

[Volker Schroer]

Hi,

I'm trying to expand the gr-osmosdr oot module using the funcube ( fcd,
fcdproplus ) modules. While gr-fcd formerly was a part of gnuradio and
disappeard in 3.8, fcdproplus was always a oot module.

In gnuradio >=3.8 oot modules provide gnuradio-{oot-name}Config.cmake
and some others.

Now I came across that using gr_modtool these files will be installed to
${GNURADIO_INSTALL_PREFIX}/lib/cmake/"Module name",
while some other oot's like gr-iqbal or gr-osmosdr put these files to


${GNURADIO_INSTALL_PREFIX}/lib/cmake/gnuradio.

This path has consequences how to find these modules later.

So my question:
What is the recommended path for these files.


Thanks in advance
-- Volker

Re: Qt GUI Chooser initial selection

[Volker Schroer]

Hi !
This was fixed with #2778

See also:

https://github.com/gnuradio/gnuradio/pull/2778/files/ef5ca9fe51dc45c0332e41db36f822f145f6116a


-- Volker
Am 11.04.20 um 14:45 schrieb Chris Vine:

Hi,

On porting a gnuradio-companion flow graph from gnuradio-3.7 to
gnuradio-3.8, I noticed that there no longer seems to be a way of
setting the initial (default) selection for the Qt GUI Chooser widget.
The initial selection seems now always to be the first one in the list.

The widget is therefore no longer suitable for presenting a selection
of numeric values to the user in numerical order where you don't want
the initial default to be the highest (or lowest) value.

Is there some way around this or some other widget that is now intended
to be used for this purpose?

Chris

Re: AM demodulation

[Volker Schroer]

Hi Barry,
I have similar problem receiving and demodulating an rtty signal.
At the moment I do it in two steps:

First: set the fcdpp to the desired band, apply a lp with downsampling
to 48 Khz ( for rtty i even downsample to 8Khz) and add a
spectrumdisplay and this stage. Here you get a get reading of the
frequency and you can downmix it to baseband.

-- Volker

Am 26.10.19 um 21:00 schrieb Barry Duggan:

Hi,

I've been working on a gnuradio AM broadcast receiver, and have found
that the tuning is very critical to obtaining clear audio. My flowgraph
can be seen at https://wiki.gnuradio.org/index.php/File:FunCube_AM.png.
Are there any alternate demodulation methods which are not so sensitive
to exact tuning?

Thanks,

Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 204, Issue 6

[Volker Schroer]

Hi,

I just tried a very simple example:

file source(in ) -> File sink (/dev/stdout )

As long as I feed a few characters to the fifo, nothing happens on the
flowgraph side.

Finishing the cat command by ctrl-d or ctrl-c leads to

attachthread[thread-per-block[0]: ]: fread error

But if I write a lot of characters to the fifo
For instance the COPYING file of gnuradio I get a lot of output, but not
the whole file.


The gnuradio scheduler does not process the input byte by byte, but it
collects the input and distributes it to the different blocks.

So you must provide enough input before you see some output.

-- Volker

Am 08.10.19 um 08:07 schrieb ali mokdad:

Dear all

Moreover,

as I mentioned before no data is transmitted in the following case
1- $ mkfifo in
2-: $ cat > in
3- gnuradio : file source (in)  --> stream to tagged stream --> throttle -->
tagged stream to pdu --> message debug
till I press ctrl c, where in file source repeat in no.

if repeat is yes then I have the following error
[/build/gnuradio-BBYmSv/gnuradio-3.7.11/gr-blocks/lib/file_source_impl.cc]
fseek failed

can anyone inform me what is the problem?

Best regards

On Tue, Oct 8, 2019 at 8:00 AM ali mokdad mailto:aa.mokdad...@gmail.com>> wrote:

Dear

thx for your reply

even by using stdbuf  the problem remains the same
$ stdbuf -i 0 -o 0 cat > in

I think the problem must be solved from gnuradio because if I run
two terminals in
first terminal: $ cat > in
second terminal: $ cat in
then whatever I write in the first terminal is sent to the second
terminal after pressing enter.

while
if instead of the second terminal I used gnuradio with the following
flowgraph
in gnuradio : file source (in)  --> stream to tagged stream -->
throttle -->
tagged stream to pdu --> message debug

the data are not sent till I press ctrl c.

thanks again for your help, but my problem is not solved if there is
any one can help me

Best regards




Virus-free. www.avast.com





<#m_6056736687892377648_m_1211741247935538308_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Mon, Oct 7, 2019 at 7:06 PM mailto:discuss-gnuradio-requ...@gnu.org>> wrote:

Send Discuss-gnuradio mailing list submissions to
discuss-gnuradio@gnu.org 

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
or, via email, send a message with subject or body 'help' to
discuss-gnuradio-requ...@gnu.org


You can reach the person managing the list at
discuss-gnuradio-ow...@gnu.org


When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."


Today's Topics:

    1. fifo / file source (ali mokdad)
    2. Re: fifo / file source (Müller)
    3. Re: fifo / file source (ali mokdad)
    4. Re: fifo / file source (N. Benes)


--

Message: 1
Date: Mon, 7 Oct 2019 13:41:47 +0300
From: ali mokdad mailto:aa.mokdad...@gmail.com>>
To: discuss-gnuradio@gnu.org 
Subject: [Discuss-gnuradio] fifo / file source
Message-ID:

mailto:cacn2bhndhnwhkddjfojnm1pgps%2bnrhdudm7zyeaa6abptke...@mail.gmail.com>>
Content-Type: text/plain; charset="utf-8"

Dear all

I tested the following

1- in terminal, I created a fifo file by: mkfifo in
2- in terminal, I run: cat > in
3- in gnuradio i run : file source (in)  --> stream to tagged
stream -->
tagged stream to pdu --> message debug
4- in terminal, I write and press enter nothing is sent, only if
I press
ctrl c the all the data written in the terminal are sent to the
message
debug.

How can I solve this problem?
-- next part --
An HTML attachment was scrubbed...
URL:



--

Message: 2
Date: Mon, 7 Oct 2019 11:11:52 +
From: Müller, Marcus (CEL) mailto:muel...@kit.edu>>
To: "discuss-gnuradio@gnu.org "
mailto:discuss-gnuradio@gnu.org>>,
         "aa.mokdad...@gmail.com
" mailto:aa.mokdad...@gmail.com>>
Subject: Re: 

Re: [Discuss-gnuradio] Errors trying to build gr-radioteletype for version 3.8

[Volker Schroer]

Hi following the discussion I just published a fork of gr-radioteletype
building against gnuradio maint-3.8 and gnuradio master.

See

https://github.com/dl1ksv/gr-radioteletype

-- Volker

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

Re: [Discuss-gnuradio] gnuradio.conf file

[Volker Schroer]

Hi,
on linux  there seems to be no gnuradio.conf ( 3.8 , 3.9). But in
CMAKE_INSTALL_PREFIX//etc/gnuradio/conf.d/
there exists grc.conf.

This file contains

# This file contains system wide configuration data for GNU Radio.
# You may override any setting on a per-user basis by editing
# ~/.gnuradio/config.conf

[grc]
global_blocks_path = /usr/local/gnuradio-volker/share/gnuradio/grc/blocks
local_blocks_path =
default_flow_graph =
xterm_executable = /usr/bin/xterm
canvas_font_size = 8
canvas_default_size = 1280, 1024

In
~/.gnuradio there exists grc.conf containing user specific infos of grc
like used flowgraphs etc.


Am 21.08.19 um 15:33 schrieb Michael Dickens:

Hi Barry - The file "gnuradio.conf" resides in "~/.gnuradio/". In my setup, I put the "[grc]"and "xterm" 
lines in the file "config.conf" in the same directory ... not sure if this is correct ... maybe I could combine them into a single 
"*.conf"? Anyway ... the entry (after "[grc]") should be something like:
{{{
xterm_executable = /opt/local/bin/xterm
}}}
I just specifies which "xterm" executable to use. GRC should be able to find a default "xterm" 
assuming it's in a standard system path. On my computer I have the system "xterm" as well as one compiled 
from source, so I actually use the above line to set the specific "xterm" for GRC to use. Hope this is 
useful! - MLD

On Wed, Aug 21, 2019, at 8:23 AM, Barry Duggan wrote:

Hi,

I just finished a clean start build of the maint-3.8 branch. When I
executed a gnuradio-companion flowgraph, it said I was missing the xterm
executable, and to specify it in gnuradio.conf as

[grc]
xterm_executable

My problem is that there doesn't seem to be an existing gnuradio.conf
file, and I don't know where to put it. I have '~/gnuradio',
'~/.gnuradio', and '~/.gnuradio/prefs' as possible candidates.
Interestingly, it seems to run OK without it!

I am using Raspbian Buster on a Raspberry Pi 3B+.

Side note: The GRC version is 3.9.0.0.git!

Thanks for your help.
--
Barry Duggan KV4FV

___
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] Trying to build gr-fcdproplus for GR 3.8

[Volker Schroer]

Hi Barry,

did you try

apt-get install lib-hidapiusb0



Hi Volker,

I installed libhidapi-dev and the build works. However, I could not
locate lib-hidapiusb0. Where is it? Is it needed?

My flowgraph compiles, but I haven't installed the udev rules yet, so it
doesn't find the dongle.

Thanks



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

Re: [Discuss-gnuradio] Trying to build gr-fcdproplus for GR 3.8

[Volker Schroer]

Hi,

there was an error in the cmake script. As in the summary noted, the
bundled hidapi should be used.
Just fixed it in the git repositry. This should compile .
But I'd prefer, to use the latest hidapi.
You have to install something like libhidapi-dev and lib-hidapiusb0.

I'm not familiar with pip, But I think you installed the python bindings
of hidapi that are not used.

I hope, it works.

Am 16.08.19 um 03:31 schrieb Barry Duggan:

Hi,

I'm trying to build gr-fcdproplus for GR 3.8

since 'libusb-1.0' was missing, I did:
    "sudo apt-get install libusb-1.0"

to load hidapi, I did 'sudo pip3 install hidapi'

the cmake summary is:
--  Build Summary =
-- Building gr-fcdproplus  : .. for Linux
-- Building for gnuradio   : 3.8.0.0
-- Using CMAKE Module path :
/home/pi/gr-fcdproplus/cmake/Modules;/usr/local/lib/cmake/gnuradio
-- CMake Modules Dir   : lib/cmake
-- fcdproplus INCLUDES : include/fcdproplus
-- Using install prefix    : /usr/local
-- Installing grc files to : /usr/local/share/gnuradio/grc/blocks
-- Bundled hidapi is used
-- 
-- Configuring done
-- Generating done
-- Build files have been written to: /home/pi/gr-fcdproplus/build

the make produced (second try):
pi@raspberrypi:~/gr-fcdproplus/build $ make -j3
[ 11%] Built target _fcdproplus_swig_doc_tag
[ 23%] Built target pygen_python_34b56
[ 29%] Building CXX object
lib/CMakeFiles/gnuradio-fcdproplus.dir/fcdpp_control_impl.cc.o
[ 41%] Building CXX object
lib/CMakeFiles/gnuradio-fcdproplus.dir/fcd_control_impl.cc.o
[ 41%] Building CXX object
lib/CMakeFiles/gnuradio-fcdproplus.dir/fcd_impl.cc.o
In file included from /home/pi/gr-fcdproplus/lib/fcd_control_impl.cc:26:
/home/pi/gr-fcdproplus/lib/fcd_control_impl.h:29:10: fatal error:
hidapi.h: No such file or directory
  #include "hidapi.h"
   ^~
compilation terminated.
make[2]: *** [lib/CMakeFiles/gnuradio-fcdproplus.dir/build.make:89:
lib/CMakeFiles/gnuradio-fcdproplus.dir/fcd_control_impl.cc.o] Error 1
make[2]: *** Waiting for unfinished jobs
In file included from /home/pi/gr-fcdproplus/lib/fcdpp_control_impl.cc:23:
/home/pi/gr-fcdproplus/lib/fcdpp_control_impl.h:29:10: fatal error:
hidapi.h: No such file or directory
  #include "hidapi.h"
   ^~
compilation terminated.
[ 47%] Built target doxygen_target
make[2]: *** [lib/CMakeFiles/gnuradio-fcdproplus.dir/build.make:76:
lib/CMakeFiles/gnuradio-fcdproplus.dir/fcdpp_control_impl.cc.o] Error 1
[ 58%] Built target fcdproplus_swig_swig_doc
[ 64%] Built target fcdproplus_swig_swig_compilation
make[1]: *** [CMakeFiles/Makefile2:141:
lib/CMakeFiles/gnuradio-fcdproplus.dir/all] Error 2
make: *** [Makefile:130: all] Error 2

What do I need to do to resolve the missing "hidapi.h"? I found a HIDAPI
package on Git. Is is better / different?

Thanks for your help.



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

Re: [Discuss-gnuradio] Problem building gr-display

[Volker Schroer]

Now the gr-display master branch builds against gnuradio 3.8.0.0-rc2


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

Re: [Discuss-gnuradio] Problem building gr-display

[Volker Schroer]

Sorry I forgot: This is a outdated version as it was setup before
gnuradio switched to modern cmake. I have to publish my latest
gr-display version, but first I want to test it against the latest gnuradio.



Am 25.07.19 um 13:56 schrieb Ron Economos:

That OOT is just not up to date with GNU Radio 3.8. It needs to be
redone with the current gr_modtool.

Ron

On 7/25/19 04:36, Barry Duggan wrote:

Hi Chris,

Thank you for that. I'm still a newbie with git.

That process worked as far as cloning, but I am still getting the same
error:

"""
CMake Error at CMakeLists.txt:102 (message):
  GnuRadio Runtime required to compile display
"""

from CMakeLists.txt:
find_package(Gnuradio "3.8" REQUIRED PATHS ${CMAKE_INSTALL_PREFIX}
${GNURADIO_MODULE_DIRECTORY})

So I still don't know the correct path for GNURADIO_MODULE_DIRECTORY.

Thanks,
---
Barry Duggan


On 2019-07-25 02:48, Palmer, Chris wrote:

Barry,

Try this:

git clone https://github.com/dl1ksv/gr-display.git
cd gr-display
git checkout gnuradio3.8

-cp

From: Discuss-gnuradio
 on behalf
of Barry Duggan 
Sent: Wednesday, July 24, 2019 3:47 PM
To: Volker Schroer
Cc: Discuss Gnuradio
Subject: Re: [Discuss-gnuradio] Problem building gr-display

Hi Volker,

1) What specific URL should I use? I tried:

git clone https://github.com/dl1ksv/gr-display/tree/gnuradio3.8
Cloning into 'gnuradio3.8'...
fatal: repository
'https://github.com/dl1ksv/gr-display/tree/gnuradio3.8/' not found

and also:

git clone
https://github.com/dl1ksv/gr-display/tree/gnuradio3.8/gr-display

2) Does the cmake command need to define GNURADIO_MODULE_DIRECTORY? If
so, what is the path?

Thanks,
--
Barry Duggan KV4FV

On Wed, 24 Jul 2019 16:30:02 +0200, Volker Schroer wrote:

On github in gr-display exists a gnuradio3.8 branch. Try this one.
Now that gnuradio switched to 3.8 I should switch the master branch to
3.8, too.

___
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] Problem building gr-display

[Volker Schroer]

On github in gr-display exists a gnuradio3.8 branch. Try this one.
Now that gnuradio switched to 3.8 I should switch the master branch to
3.8, too.


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

Re: [Discuss-gnuradio] converting xml block files to new yaml yml block files

[Volker Schroer]

I found this script usefull, to convert xml to yaml files.

https://gist.github.com/haakov/4228ff6a14486641add538483093e86b



Am 23.05.19 um 22:01 schrieb Michael Dickens:

Check out < https://github.com/igorauad/gr-osmosdr/tree/gr3.8 > and < 
https://github.com/mvaenskae/gr-osmosdr/tree/gr3.8 >. Both of these folks have been 
trying to get gr-osmosdr working with GR3.8 fully; maybe one or both of them have converted 
yml scipts? - MLD

On Thu, May 23, 2019, at 3:11 PM, Steven Barbo wrote:

Hello.
Am using gnuradio 3.8 git (python 3.7.3) and have compiled gr-osmosdr to work 
with that.
Having some issue translating from osmosdr_source.xml to 
osmosdr_source_block.yml, the new yaml format
Anyone tackled this?

--
If something is requisite, how can it possibly be, prerequisite?

vanitas vanitatum omnia vanitas
later, steve
http://umn.edu/~barbo
___
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] free(): invalid pointer for AM demod block at Gnuradio 3.7.13.5

[Volker Schroer]

You have set passband frequency to 0 ! So your passband reaches from 0
to 0. That make no sense. Probably a parameter check should be
introduced to the demod block Further  you should add a throttle block
after your source.

Same problem can be found in 3.8.


Am 14.05.19 um 15:02 schrieb Ignatius Rivaldi:

I'm running Arch Linux with Gnu Radio 3.7.13.5 and
Python 2.7.16 (default, Mar 11 2019, 18:59:25)
[GCC 8.2.1 20181127] on linux2

and if I try to use AM demod block with anything the flowgraph crashes
with this:


Warning: This flow graph may not have flow control: no audio or RF hardware blocks 
found. Add a Misc->Throttle block to your flow graph to avoid CPU congestion.


Executing: /usr/bin/python2 -u /home/feanor/Development/SDR/top_block.py

free(): invalid pointer


Done


This is just a AM demod block with null sink and null source attached
to it, reproduction flowgraph is attached to this email


___
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] Testers needed: Updated CMake syntax

[Volker Schroer]

Hi,
I tried [1] on Ubuntu 18.10 and it build without problems.
Starting to build some of mine OOT's I found, that FindUSB.cmake is 
missing. I think this was used to build gr-fcd which is not part of 
gnuradio 3.8.

But that's no problem.
Will the new cmake be part of gnuradio-3.8 ?

I'll keep on testing some more OOT's

-- Volker



Hi all,

in the last weeks I have been pursuing the quest of reworking the
current CMake build tooling in GNU Radio to use "modern CMake" syntax.
This work has mainly completed and now is the time to fix bugs you
encounter.

The work on the updated CMake can be found here
[0]/[1] and should compile just fine using the cmake & make/ninja
commands you are used to.
Support for static libraries might be still broken, but static linking
can be enabled using `-DBUILD_SHARED_LIBS=OFF` on the command line. No
shared library will be built using that flag.

Linking Out-of-Tree modules should be way easier using the new syntax
(but still old modules have to be updated). Mainly the `find_package`
call now follows the convention of specifying components in the
function call e.g. `find_package(Gnuradio COMPONENTS fft audio)`. After
the correct components are specified on in the `find_package` call the
corresponding build targets are available in your CMake project.  e.g.
you can `target_link_libraries(foo gnuradio::gnuradio-fft)`. Several
core build targets are always available (gnuradio::gnuradio-runtime,
gnuradio::gnuradio-pmt).

Instead of linking to all GNU Radio libraries in the
`target_link_libraries` call in `lib/CMakeLists.txt` now only the
targets needed should be linked with. An example for changes needed in
a OOT can be found at [2].
Mostly removing almost everything from `cmake/Modules` and removing a
lot of manual dependency finding from your own `CMakeLists.txt` is a
good step forward.
Necessary changes to `gr_modtool` have been incorporated to work with
the new CMake syntax.

If you encounter bugs or have suggestions for further improvements do
not hesitate to contact me through the pull request [0] or email. I'll
help with build problems updating your OOT as well.

Cheers
Andrej

[0] https://github.com/gnuradio/gnuradio/pull/2230
[1] https://github.com/noc0lour/gnuradio/tree/update_cmake
[2] https://github.com/noc0lour/gr-grnet/tree/3.8


___
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] Transistion from gnuradio 3.7 to 3.8

[Volker Schroer]

Two questions:


- I'm just preparing some oot modules for gnuradio 3.8. Does a tool 
exist for migrating xml files to yml files or have I to do this 
manually, which could be time consuming in some cases ?


- In 3.7 there exists gr-fcd. Although it's not on the list of 
depreciated modules there is no gr-fcd in next ( the upcoming 3.8 ). Is 
there no need for gr-fcd anymore ? Otherwise should it become part of 
3.8 again, or should it move to oot - modules ? In this case I could put 
it to gr-fcdproplus which is quite similar.


-- Volker




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

Re: [Discuss-gnuradio] Help needed with message ports [success]

[Volker Schroer]

Just to report the solution, as it me be usefull for others.

My block was an hier2 block. Hier2 blocks can't handle messages 
directly, they only can serve as a proxy.


So I added a gr::block with no inputs and outputs ( yes, this is 
possible, I did not know before ) that could handle the message.


From my hier2 block I routed the message to my new block and everything 
works fine.


The details can be seen on github

https://github.com/dl1ksv/gr-fcdproplus/tree/gnuradio3.8

Many thanks to MLD, who pointed me into the right direction.

-- Volker



Am 20.07.2018 um 12:28 schrieb Volker Schroer:

Hi,

I'm trying to add an message port to my  working oot module fcdproplus 
to be able to control the frequency by an message from a qtgui sink.


I used the analog signal source as guide and implemented a message sink 
in the grc description, registered the in port, and defined  a handler 
function like described in the tutorial.


I can run my example of a simple fm receiver as before, but when I 
connect the message out port of a qtgui sink to my message in port of my 
oot block,


I get the following error message:


./FMRadio.py
INFO: Audio source arch: alsa
Funcube Dongle Pro+ found as: plughw:3,0
Dongle sucessfully initialized
Result of Action :+
FCDAPP 20.03
  Lna gain enabled
  Mixer gain enabled
If gain set to: 10
Set Frequency to: 94.3 KHz, corrected to: 94300 Khz
INFO: Audio sink arch: alsa
Traceback (most recent call last):
   File "./FMRadio.py", line 277, in 
     main()
   File "./FMRadio.py", line 266, in main
     tb.start()
   File 
"/usr/local/gnuradio/lib64/python2.7/site-packages/gnuradio/gr/top_block.py", 
line 109, in start

     top_block_start_unlocked(self._impl, max_noutput_items)
   File 
"/usr/local/gnuradio/lib64/python2.7/site-packages/gnuradio/gr/runtime_swig.py", 
line 5678, in top_block_start_unlocked

     return _runtime_swig.top_block_start_unlocked(r, max_noutput_items)
RuntimeError: fcdproplus(3): insufficient connected output ports (1 
needed, 0 connected)


These are the connections:


    ##
     # Connections
     ##
     self.msg_connect((self.qtgui_sink_x_0, 'freq'), 
(self.fcdproplus_fcdproplus_0, 'freq'))
     self.connect((self.analog_fm_demod_cf_0, 0), 
(self.audio_sink_0, 0))
     self.connect((self.analog_fm_demod_cf_0, 0), 
(self.audio_sink_0, 1))
     self.connect((self.fcdproplus_fcdproplus_0, 0), 
(self.low_pass_filter_0, 0))
     self.connect((self.fcdproplus_fcdproplus_0, 0), 
(self.qtgui_sink_x_0, 0))
     self.connect((self.low_pass_filter_0, 0), 
(self.analog_fm_demod_cf_0, 0))


If I remove the line

self.msg_connect((self.qtgui_sink_x_0, 'freq'), 
(self.fcdproplus_fcdproplus_0, 'freq'))



from my python script he error message disappears.

What am I doing wrong?


Any help is appreciated.

-- Volker


___
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] Deprecated valve block

[Volker Schroer]

Hi !

In gnuradio 3.7 the valve block is marked as deprecated and there is 
missing in 3.8.


But  is there a suitable replacement for this block ?

Thanks

-- Volker


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

Re: [Discuss-gnuradio] Help needed with message ports

[Volker Schroer]

Hi Michael,

thank you for your reply. Yes your clarification is correct.

The block I'm trying is of type hier2_block. Meanwhile I found an older post

https://lists.gnu.org/archive/html/discuss-gnuradio/2015-10/msg8.html

 describing the same problem. But the gnuradio code has been modified 
since then, but it seems that the proposal in this post has been 
incorporated.



I tested with the current git/master and git/next. The problems are the 
same.


I think it depends on the hier2 block, as I can setup a simple flowgraph 
with a signal source ( this is of type sync block ) that works.


Now I'm trying to understand the code of 
hier_block2_detail::msg_connect. But at the moment this is hard stuff 
for me.

I'll report if I get a solution.

-- Volker




Am 21.07.2018 um 16:23 schrieb Michael Dickens:

Hi Volker - Just to clarify:

You've added an -optional- input async message port to a block that currently does just 
streaming. If you -do not- try to connect to this new port, then everything works as desired 
& as before. If you -do- try to connect to the port then you get the runtime error 
"insufficient connected output ports (1 needed, 0 connected)". Yes?

"Once upon a time" ... there was, and as it turns out still is (just tried using 
the current GIT master of GR), a bug in the code that handles connections for mixed streams 
and -input- async messages, which results in the runtime error you're encountering. I can 
provide a very simplified OOT that shows this error; I tried to track it down once but got 
sidetracked & never figured it out. Maybe I'll give it a go again this coming week ... 
or, maybe you can?

Sorry for the bad news! - MLD

On Fri, Jul 20, 2018, at 6:28 AM, Volker Schroer wrote:

Hi,

I'm trying to add an message port to my  working oot module fcdproplus
to be able to control the frequency by an message from a qtgui sink.

I used the analog signal source as guide and implemented a message sink
in the grc description, registered the in port, and defined  a handler
function like described in the tutorial.

I can run my example of a simple fm receiver as before, but when I
connect the message out port of a qtgui sink to my message in port of my
oot block,

I get the following error message:


./FMRadio.py
INFO: Audio source arch: alsa
Funcube Dongle Pro+ found as: plughw:3,0
Dongle sucessfully initialized
Result of Action :+
FCDAPP 20.03
   Lna gain enabled
   Mixer gain enabled
If gain set to: 10
Set Frequency to: 94.3 KHz, corrected to: 94300 Khz
INFO: Audio sink arch: alsa
Traceback (most recent call last):
    File "./FMRadio.py", line 277, in 
      main()
    File "./FMRadio.py", line 266, in main
      tb.start()
    File
"/usr/local/gnuradio/lib64/python2.7/site-packages/gnuradio/gr/
top_block.py",
line 109, in start
      top_block_start_unlocked(self._impl, max_noutput_items)
    File
"/usr/local/gnuradio/lib64/python2.7/site-packages/gnuradio/gr/
runtime_swig.py",
line 5678, in top_block_start_unlocked
      return _runtime_swig.top_block_start_unlocked(r, max_noutput_items)
RuntimeError: fcdproplus(3): insufficient connected output ports (1
needed, 0 connected)

These are the connections:


     ##
      # Connections
      ##
      self.msg_connect((self.qtgui_sink_x_0, 'freq'),
(self.fcdproplus_fcdproplus_0, 'freq'))
      self.connect((self.analog_fm_demod_cf_0, 0),
(self.audio_sink_0, 0))
      self.connect((self.analog_fm_demod_cf_0, 0),
(self.audio_sink_0, 1))
      self.connect((self.fcdproplus_fcdproplus_0, 0),
(self.low_pass_filter_0, 0))
      self.connect((self.fcdproplus_fcdproplus_0, 0),
(self.qtgui_sink_x_0, 0))
      self.connect((self.low_pass_filter_0, 0),
(self.analog_fm_demod_cf_0, 0))

If I remove the line

self.msg_connect((self.qtgui_sink_x_0, 'freq'),
(self.fcdproplus_fcdproplus_0, 'freq'))


from my python script he error message disappears.

What am I doing wrong?


Any help is appreciated.

-- Volker


___
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] Help needed with message ports

[Volker Schroer]

Hi,

I'm trying to add an message port to my  working oot module fcdproplus 
to be able to control the frequency by an message from a qtgui sink.


I used the analog signal source as guide and implemented a message sink 
in the grc description, registered the in port, and defined  a handler 
function like described in the tutorial.


I can run my example of a simple fm receiver as before, but when I 
connect the message out port of a qtgui sink to my message in port of my 
oot block,


I get the following error message:


./FMRadio.py
INFO: Audio source arch: alsa
Funcube Dongle Pro+ found as: plughw:3,0
Dongle sucessfully initialized
Result of Action :+
FCDAPP 20.03
 Lna gain enabled
 Mixer gain enabled
If gain set to: 10
Set Frequency to: 94.3 KHz, corrected to: 94300 Khz
INFO: Audio sink arch: alsa
Traceback (most recent call last):
  File "./FMRadio.py", line 277, in 
    main()
  File "./FMRadio.py", line 266, in main
    tb.start()
  File 
"/usr/local/gnuradio/lib64/python2.7/site-packages/gnuradio/gr/top_block.py", 
line 109, in start

    top_block_start_unlocked(self._impl, max_noutput_items)
  File 
"/usr/local/gnuradio/lib64/python2.7/site-packages/gnuradio/gr/runtime_swig.py", 
line 5678, in top_block_start_unlocked

    return _runtime_swig.top_block_start_unlocked(r, max_noutput_items)
RuntimeError: fcdproplus(3): insufficient connected output ports (1 
needed, 0 connected)


These are the connections:


   ##
    # Connections
    ##
    self.msg_connect((self.qtgui_sink_x_0, 'freq'), 
(self.fcdproplus_fcdproplus_0, 'freq'))
    self.connect((self.analog_fm_demod_cf_0, 0), 
(self.audio_sink_0, 0))
    self.connect((self.analog_fm_demod_cf_0, 0), 
(self.audio_sink_0, 1))
    self.connect((self.fcdproplus_fcdproplus_0, 0), 
(self.low_pass_filter_0, 0))
    self.connect((self.fcdproplus_fcdproplus_0, 0), 
(self.qtgui_sink_x_0, 0))
    self.connect((self.low_pass_filter_0, 0), 
(self.analog_fm_demod_cf_0, 0))


If I remove the line

self.msg_connect((self.qtgui_sink_x_0, 'freq'), 
(self.fcdproplus_fcdproplus_0, 'freq'))



from my python script he error message disappears.

What am I doing wrong?


Any help is appreciated.

-- Volker


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

[Discuss-gnuradio] Next branch, yaml

[Volker Schroer]

Hi all !

I just succeeded to build gnuradio next on gentoo and ubuntu 18.04.

make test reports some errors I'll look for later.

In a next step I tried to move my oot modules to next and found that 
module description has changed from xml to yaml.


May be I missed some posts.

Is there a description of the new structure available ?

-- Volker


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

Re: [Discuss-gnuradio] oot modules in grc

[Volker Schroer]

Ron,
many thanks for your hints. They are very usefull for me.

But just a question to the gnuradio developers:

Wouldn't it be appropriate to have some predefined categories.
Otherwise I expect an uncontrolled growth on categories.

But at the moment I know, how to proceed.

Thanks again

-- Volker


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

[Discuss-gnuradio] oot modules in grc

[Volker Schroer]

For some times oot modules are sorted into a subtree (no module 
specified ). On 'mouse over' the developers are asked to update their 
xml - files with module names.


If I look into the gnuradio xml files the module name always seems to be 
[core].


Are there recommendations for oot- modules or should it always be [OOT] ?

I found nothing about this in the tutorials.

Any hints are welcome.
Thanks
-- Volker

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

Re: [Discuss-gnuradio] Simplest example with qt does nog work which debian testing/buster

[Volker Schroer]

Sorry if this post appears twice, but my mail provider had problems so 
I'm not sure if this post was really sent.


Hello,
the line

self.restoreGeometry(self.settings.value("geometry").toByteArray()

is correct.

But gnuradio uses QT4, so  PyQt4 is required.

Volker

Am 17.01.2018 um 11:21 schrieb s.achte...@rug.nl:

    Hello list (second attempt),

Starting with gnuradio on Debian testing/buster and trying a flowgraph 
with only

a "wav file source" and an "audio sink".

With option "WX gui" it just works, but with option "QT gui" there is the
following error:

  File "/home/sietse/top_block.py", line 55, in __init__
     self.restoreGeometry(self.settings.value("geometry").toByteArray())
AttributeError: 'QByteArray' object has no attribute 'toByteArray'

If I remove that line everything works ok!
PyQt5 is being used.

What am I doing wrong?

   Thanks in advance,
     Sietse


___
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] Simplest example with qt does nog work which debian testing/buster

[Volker Schroer]

Hello,
the line

self.restoreGeometry(self.settings.value("geometry").toByteArray()

is correct.

But gnuradio uses QT4, so  PyQt4 is required.

Volker

Am 17.01.2018 um 11:21 schrieb s.achte...@rug.nl:

    Hello list (second attempt),

Starting with gnuradio on Debian testing/buster and trying a flowgraph 
with only

a "wav file source" and an "audio sink".

With option "WX gui" it just works, but with option "QT gui" there is the
following error:

  File "/home/sietse/top_block.py", line 55, in __init__
     self.restoreGeometry(self.settings.value("geometry").toByteArray())
AttributeError: 'QByteArray' object has no attribute 'toByteArray'

If I remove that line everything works ok!
PyQt5 is being used.

What am I doing wrong?

   Thanks in advance,
     Sietse


___
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] Strange behaviour while importing oot module

[Volker Schroer]

Hi,
I just wrote a new oot module rshfiq with gnuradio v3.7.9.1-145-g5e383b0b

I get problems to load my module.
Testing directly with python, I get:


 $ python
Python 2.7.13 (default, Mar 30 2017, 12:47:27)
[GCC 5.4.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import rshfiq
>>> a=rshfiq.rshfiq()
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'module' object has no attribute 'rshfiq'
>>>

First I thought that I made a program error, but by chance I found out 
that calling my module this way works:


$ python
Python 2.7.13 (default, Mar 30 2017, 12:47:27)
[GCC 5.4.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import fcdproplus
>>> import rshfiq
>>> a=rshfiq.rshfiq()
Traceback (most recent call last):
  File "", line 1, in 
  File 
"/usr/local/gnuradio/lib64/python2.7/site-packages/rshfiq/rshfiq_swig.py", 
line 134, in make

return _rshfiq_swig.rshfiq_make(*args, **kwargs)
TypeError: Required argument 'audio_device_name' (pos 1) not found
>>>

which is correct.

So I looked into the __init__.py file of my module.
The relevant part is

# import swig generated symbols into the rshfiq namespace
try:
  # this might fail if the module is python-only
  from rshfiq_swig import *
except ImportError:
  pass


As in older modules the try  except is missing, I modified this to

from rshfiq_swig import *

Then I get the following resutls:

$ python
Python 2.7.13 (default, Mar 30 2017, 12:47:27)
[GCC 5.4.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import rshfiq
Traceback (most recent call last):
  File "", line 1, in 
  File 
"/usr/local/gnuradio/lib64/python2.7/site-packages/rshfiq/__init__.py", 
line 33, in 

from rshfiq_swig import *
  File 
"/usr/local/gnuradio/lib64/python2.7/site-packages/rshfiq/rshfiq_swig.py", 
line 17, in 

_rshfiq_swig = swig_import_helper()
  File 
"/usr/local/gnuradio/lib64/python2.7/site-packages/rshfiq/rshfiq_swig.py", 
line 16, in swig_import_helper

return importlib.import_module('_rshfiq_swig')
  File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in 
import_module

__import__(name)
ImportError: No module named _rshfiq_swig
>>>

and

$ python
Python 2.7.13 (default, Mar 30 2017, 12:47:27)
[GCC 5.4.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import fcdproplus
>>> import rshfiq
>>> a=rshfiq.rshfiq()
Traceback (most recent call last):
  File "", line 1, in 
  File 
"/usr/local/gnuradio/lib64/python2.7/site-packages/rshfiq/rshfiq_swig.py", 
line 134, in make

return _rshfiq_swig.rshfiq_make(*args, **kwargs)
TypeError: Required argument 'audio_device_name' (pos 1) not found
>>>

Any ideas ? I think I made a mistake, but I have no further ideas how to 
find.


Thanks in advance

-- Volker





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

Re: [Discuss-gnuradio] GNU Radio Companion - ALSA

[Volker Schroer]

Hi Robin,
I think that the PI audio hardware is stereo.
So set in your audio sink the number of inputs to to and than connect 
the second input channel to the same port of the preceding port the 
first channel is connected to.


-- Volker

Am 19.02.2017 um 17:17 schrieb Robin A. Jensen:

Hello Volker

My audiosink is in mono. 1 input.
If I put in a 2. Rationel Sampler and gonnect it's input to WBFM Revicer
and then put Rat. Samp. 2 to a second input on audio sink, i'll get:
RuntimeError: audio_alsa_sink
don't know another way to make WBFM into 2 channel?

Best regards
Robin.


Den 19-02-2017 kl. 17:05 skrev Volker Schroer:

Hi Robin,
that means , you got the correct device name, but your selected
topology is wrong. That happens for example if you provide one input
to a stereo device.

-- Volker

Am 19.02.2017 um 16:52 schrieb Robin A. Jensen:

Hello Volker

It will still create error:
RuntimeError: check topology failed on audio_alsasink(8) using
ninputs=1, noutputs=0

Best regards
Robin.


Den 19-02-2017 kl. 16:44 skrev Volker Schroer:

Robin,
try to use hw:0 or plughw:0 as device string.

The hardware device must be written in lowercase.

If I user uppercase I get the same error as you reported.

ALSA lib
/var/tmp/portage/media-libs/alsa-lib-1.1.2/work/alsa-lib-1.1.2/src/pcm/pcm.c:2450:(snd_pcm_open_noupdate)

Unknown PCM HW:2,0
ERROR: [HW:2,0]: Datei oder Verzeichnis nicht gefunden

If in lowercase:

audio_alsa_sink[hw:2,0]: using S32_LE

-- Volker


Am 19.02.2017 um 16:15 schrieb Robin A. Jensen:

Yes of course.
Here we go:

aplay -L

null
Discard all samples (playback) or generate zero samples (capture)

pulse
PulseAudio Sound Server
sysdefault:CARD=ALSA
bcm2835 ALSA, bcm2835 ALSA
Default Audio Device

dmix:CARD=ALSA,DEV=0
bcm2835 ALSA, bcm2835 ALSA
Direct sample mixing device

dmix:CARD=ALSA,DEV=1
bcm2835 ALSA, bcm2835 IEC958/HDMI
Direct sample mixing device

dsnoop:CARD=ALSA,DEV=0
bcm2835 ALSA, bcm2835 ALSA
Direct sample snooping device

dsnoop:CARD=ALSA,DEV=1
bcm2835 ALSA, bcm2835 IEC958/HDMI
Direct sample snooping device

hw:CARD=ALSA,DEV=0
bcm2835 ALSA, bcm2835 ALSA
Direct hardware device without any conversions

hw:CARD=ALSA,DEV=1
bcm2835 ALSA, bcm2835 IEC958/HDMI
Direct hardware device without any conversions

plughw:CARD=ALSA,DEV=0
bcm2835 ALSA, bcm2835 ALSA
Hardware device with all software conversions

plughw:CARD=ALSA,DEV=1
bcm2835 ALSA, bcm2835 IEC958/HDMI
Hardware device with all software conversions

If i use @: speaker-test -f 800 -t sinus -r 48000 -c 1-s 1
I'll get a fine sinus tone.
So there are sound through the system.

Best regards
Robin.


Den 19-02-2017 kl. 15:48 skrev Marcus Müller:

You're right, we should tackle this more systematically.

My problem is that I don't have a RPi3 to play around with at hand,
so I
have to trust you on the "HW:0,0"; it's not a very typical string,
through, as most alsa device names are lowercase. Could you share the
output of "aplay -L" with us?

Best regards,
Marcus

On 19.02.2017 15:16, Robin A. Jensen wrote:

Hello Marcus.

Thanks for your reply and your welcomming to the community.

I've made the changes as suggested.
Also i've made a setup on a Windows 10 machine, to ensure the script
runs.
With the changes the sound is much better! :-)

But when i run the same setup on RPi 3 / Jessie-distro i've end up
with the same result, no matter what I do with the Audio sink.
I'm using Gnu Radio Companion 3.7.5
The error code is still:

ALSA libpcm.c2239:)snd_pcm_open_noupdate) Unknown PCM HW:0,0 <-- 10
times this line
gr::log :ERROR: audio_alsa_sink0 - [HW:0,0]: No such file or
directory.
File "/home/pi/radio/top_block.py", line133, in 
  tb= top_block()
File "/home/pi/radio/top_block.py", line82, in __init__
self.audio_sink_0 = audio.sink(48000, "HW:0,0", True)
File
"/usr/lib/python2.7/dist-packages/gnuradio/audio/audio_swig.py",
line 195, in make
return _ausio_swig.sink_make(*args, **kwargs)
RuntimeError: audio_alsa_sink

I know is alwayes is eassy to blame the software, but could it be a
bug?
As i said. i've tried with all the suggested lines from
documentation
of the block.

Best regards
Robin.

Den 18-02-2017 kl. 18:17 skrev Marcus Müller:

Hi Robin,

first of all: Welcome to the GNU Radio community!


On 02/18/2017 05:29 PM, Robin A. Jensen wrote:

Hello all of you.

I've just recieved my RTL-SDR dongle and is all new to this
sdr-stuff,
so please bear over with me, if i'm at the wrong place.
I'm using GNU Radio Companion on a RPi 3 and no mather what i'll
do, i
can't get the sound to work.
If a'im using rtl_fm and aplay, i'll get sound but it won't set
on the
radiostation.

aha, so that's good, the sound system as it does work.
You'll probably want to use "aplay -L" to find the possible ALSA
device
names that you can use in the GNU Radio Audio sink.

I'll take on that later.
I've crea

Re: [Discuss-gnuradio] GNU Radio Companion - ALSA

[Volker Schroer]

Hi Robin,
that means , you got the correct device name, but your selected topology 
is wrong. That happens for example if you provide one input to a stereo 
device.


-- Volker

Am 19.02.2017 um 16:52 schrieb Robin A. Jensen:

Hello Volker

It will still create error:
RuntimeError: check topology failed on audio_alsasink(8) using
ninputs=1, noutputs=0

Best regards
Robin.


Den 19-02-2017 kl. 16:44 skrev Volker Schroer:

Robin,
try to use hw:0 or plughw:0 as device string.

The hardware device must be written in lowercase.

If I user uppercase I get the same error as you reported.

ALSA lib
/var/tmp/portage/media-libs/alsa-lib-1.1.2/work/alsa-lib-1.1.2/src/pcm/pcm.c:2450:(snd_pcm_open_noupdate)
Unknown PCM HW:2,0
ERROR: [HW:2,0]: Datei oder Verzeichnis nicht gefunden

If in lowercase:

audio_alsa_sink[hw:2,0]: using S32_LE

-- Volker


Am 19.02.2017 um 16:15 schrieb Robin A. Jensen:

Yes of course.
Here we go:

aplay -L

null
Discard all samples (playback) or generate zero samples (capture)

pulse
PulseAudio Sound Server
sysdefault:CARD=ALSA
bcm2835 ALSA, bcm2835 ALSA
Default Audio Device

dmix:CARD=ALSA,DEV=0
bcm2835 ALSA, bcm2835 ALSA
Direct sample mixing device

dmix:CARD=ALSA,DEV=1
bcm2835 ALSA, bcm2835 IEC958/HDMI
Direct sample mixing device

dsnoop:CARD=ALSA,DEV=0
bcm2835 ALSA, bcm2835 ALSA
Direct sample snooping device

dsnoop:CARD=ALSA,DEV=1
bcm2835 ALSA, bcm2835 IEC958/HDMI
Direct sample snooping device

hw:CARD=ALSA,DEV=0
bcm2835 ALSA, bcm2835 ALSA
Direct hardware device without any conversions

hw:CARD=ALSA,DEV=1
bcm2835 ALSA, bcm2835 IEC958/HDMI
Direct hardware device without any conversions

plughw:CARD=ALSA,DEV=0
bcm2835 ALSA, bcm2835 ALSA
Hardware device with all software conversions

plughw:CARD=ALSA,DEV=1
bcm2835 ALSA, bcm2835 IEC958/HDMI
Hardware device with all software conversions

If i use @: speaker-test -f 800 -t sinus -r 48000 -c 1-s 1
I'll get a fine sinus tone.
So there are sound through the system.

Best regards
Robin.


Den 19-02-2017 kl. 15:48 skrev Marcus Müller:

You're right, we should tackle this more systematically.

My problem is that I don't have a RPi3 to play around with at hand,
so I
have to trust you on the "HW:0,0"; it's not a very typical string,
through, as most alsa device names are lowercase. Could you share the
output of "aplay -L" with us?

Best regards,
Marcus

On 19.02.2017 15:16, Robin A. Jensen wrote:

Hello Marcus.

Thanks for your reply and your welcomming to the community.

I've made the changes as suggested.
Also i've made a setup on a Windows 10 machine, to ensure the script
runs.
With the changes the sound is much better! :-)

But when i run the same setup on RPi 3 / Jessie-distro i've end up
with the same result, no matter what I do with the Audio sink.
I'm using Gnu Radio Companion 3.7.5
The error code is still:

ALSA libpcm.c2239:)snd_pcm_open_noupdate) Unknown PCM HW:0,0 <-- 10
times this line
gr::log :ERROR: audio_alsa_sink0 - [HW:0,0]: No such file or
directory.
File "/home/pi/radio/top_block.py", line133, in 
  tb= top_block()
File "/home/pi/radio/top_block.py", line82, in __init__
self.audio_sink_0 = audio.sink(48000, "HW:0,0", True)
File "/usr/lib/python2.7/dist-packages/gnuradio/audio/audio_swig.py",
line 195, in make
return _ausio_swig.sink_make(*args, **kwargs)
RuntimeError: audio_alsa_sink

I know is alwayes is eassy to blame the software, but could it be a
bug?
As i said. i've tried with all the suggested lines from documentation
of the block.

Best regards
Robin.

Den 18-02-2017 kl. 18:17 skrev Marcus Müller:

Hi Robin,

first of all: Welcome to the GNU Radio community!


On 02/18/2017 05:29 PM, Robin A. Jensen wrote:

Hello all of you.

I've just recieved my RTL-SDR dongle and is all new to this
sdr-stuff,
so please bear over with me, if i'm at the wrong place.
I'm using GNU Radio Companion on a RPi 3 and no mather what i'll
do, i
can't get the sound to work.
If a'im using rtl_fm and aplay, i'll get sound but it won't set
on the
radiostation.

aha, so that's good, the sound system as it does work.
You'll probably want to use "aplay -L" to find the possible ALSA
device
names that you can use in the GNU Radio Audio sink.

I'll take on that later.
I've createt a small FM Reciever in GNU Radio companion and
everytime
i'll execute the script i'll get an error:

RuntimeError.audio.alsa.sink

Hm, I've never seen a GNU Radio error being printed like this; but
that
might just be me. However, I can't reproduce this error printing
shape
as hard as I try.

I've been all over the internet to find a solution but with no luck.
So now i'm have a hope that this mailling list can help me?


My suspicion is that your audio device doesn't like the sampling rate
your trying to use, or you need to specify a device name (or
both). Can
you make things work on the PC you use to design these flow gr

Re: [Discuss-gnuradio] GNU Radio Companion - ALSA

[Volker Schroer]

Robin,
try to use hw:0 or plughw:0 as device string.

The hardware device must be written in lowercase.

If I user uppercase I get the same error as you reported.

ALSA lib 
/var/tmp/portage/media-libs/alsa-lib-1.1.2/work/alsa-lib-1.1.2/src/pcm/pcm.c:2450:(snd_pcm_open_noupdate) 
Unknown PCM HW:2,0

ERROR: [HW:2,0]: Datei oder Verzeichnis nicht gefunden

If in lowercase:

audio_alsa_sink[hw:2,0]: using S32_LE

-- Volker


Am 19.02.2017 um 16:15 schrieb Robin A. Jensen:

Yes of course.
Here we go:

aplay -L

null
Discard all samples (playback) or generate zero samples (capture)

pulse
PulseAudio Sound Server
sysdefault:CARD=ALSA
bcm2835 ALSA, bcm2835 ALSA
Default Audio Device

dmix:CARD=ALSA,DEV=0
bcm2835 ALSA, bcm2835 ALSA
Direct sample mixing device

dmix:CARD=ALSA,DEV=1
bcm2835 ALSA, bcm2835 IEC958/HDMI
Direct sample mixing device

dsnoop:CARD=ALSA,DEV=0
bcm2835 ALSA, bcm2835 ALSA
Direct sample snooping device

dsnoop:CARD=ALSA,DEV=1
bcm2835 ALSA, bcm2835 IEC958/HDMI
Direct sample snooping device

hw:CARD=ALSA,DEV=0
bcm2835 ALSA, bcm2835 ALSA
Direct hardware device without any conversions

hw:CARD=ALSA,DEV=1
bcm2835 ALSA, bcm2835 IEC958/HDMI
Direct hardware device without any conversions

plughw:CARD=ALSA,DEV=0
bcm2835 ALSA, bcm2835 ALSA
Hardware device with all software conversions

plughw:CARD=ALSA,DEV=1
bcm2835 ALSA, bcm2835 IEC958/HDMI
Hardware device with all software conversions

If i use @: speaker-test -f 800 -t sinus -r 48000 -c 1-s 1
I'll get a fine sinus tone.
So there are sound through the system.

Best regards
Robin.


Den 19-02-2017 kl. 15:48 skrev Marcus Müller:

You're right, we should tackle this more systematically.

My problem is that I don't have a RPi3 to play around with at hand, so I
have to trust you on the "HW:0,0"; it's not a very typical string,
through, as most alsa device names are lowercase. Could you share the
output of "aplay -L" with us?

Best regards,
Marcus

On 19.02.2017 15:16, Robin A. Jensen wrote:

Hello Marcus.

Thanks for your reply and your welcomming to the community.

I've made the changes as suggested.
Also i've made a setup on a Windows 10 machine, to ensure the script
runs.
With the changes the sound is much better! :-)

But when i run the same setup on RPi 3 / Jessie-distro i've end up
with the same result, no matter what I do with the Audio sink.
I'm using Gnu Radio Companion 3.7.5
The error code is still:

ALSA libpcm.c2239:)snd_pcm_open_noupdate) Unknown PCM HW:0,0 <-- 10
times this line
gr::log :ERROR: audio_alsa_sink0 - [HW:0,0]: No such file or directory.
File "/home/pi/radio/top_block.py", line133, in 
  tb= top_block()
File "/home/pi/radio/top_block.py", line82, in __init__
self.audio_sink_0 = audio.sink(48000, "HW:0,0", True)
File "/usr/lib/python2.7/dist-packages/gnuradio/audio/audio_swig.py",
line 195, in make
return _ausio_swig.sink_make(*args, **kwargs)
RuntimeError: audio_alsa_sink

I know is alwayes is eassy to blame the software, but could it be a bug?
As i said. i've tried with all the suggested lines from documentation
of the block.

Best regards
Robin.

Den 18-02-2017 kl. 18:17 skrev Marcus Müller:

Hi Robin,

first of all: Welcome to the GNU Radio community!


On 02/18/2017 05:29 PM, Robin A. Jensen wrote:

Hello all of you.

I've just recieved my RTL-SDR dongle and is all new to this sdr-stuff,
so please bear over with me, if i'm at the wrong place.
I'm using GNU Radio Companion on a RPi 3 and no mather what i'll do, i
can't get the sound to work.
If a'im using rtl_fm and aplay, i'll get sound but it won't set on the
radiostation.

aha, so that's good, the sound system as it does work.
You'll probably want to use "aplay -L" to find the possible ALSA device
names that you can use in the GNU Radio Audio sink.

I'll take on that later.
I've createt a small FM Reciever in GNU Radio companion and everytime
i'll execute the script i'll get an error:

RuntimeError.audio.alsa.sink

Hm, I've never seen a GNU Radio error being printed like this; but that
might just be me. However, I can't reproduce this error printing shape
as hard as I try.

I've been all over the internet to find a solution but with no luck.
So now i'm have a hope that this mailling list can help me?


My suspicion is that your audio device doesn't like the sampling rate
your trying to use, or you need to specify a device name (or both). Can
you make things work on the PC you use to design these flow graphs?

I'd start with a signal source (sampling rate == the sampling rate that
you set in your Audio sink), configured to produce a "float" output
sine
of 1 kHz, directly connected to an Audio sink. If that works, move on.





What I say about the flow graph in the following has, as far as I can
tell, nothing to do with the error you're getting. Still, there's
mistakes in the flow graph that would make it impossible to

[Discuss-gnuradio] OOT- Modules version numbering scheme

[Volker Schroer]

Are there recommendations how OOT- module versions should be numbered ?
gr_modtool provides no version numbering.

Should there be a relation to the minimium required gnuradio version ?

I'curious if GrVersion and GR_LIBRARY_FOO should be used?

Thanks in advance
-- Volker




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

[Discuss-gnuradio] qa_polar_encoder

[Volker Schroer]

Hi,

I'm just trying the next-qt5 branch from github. Building from scratch 
works fine.

But
make test
hangs on qa_polar_encoder.

After more than 6 hours of waiting I stopped the process.
LastTest.log.tmp shows no errors. All 92 tests before passed without errors.
Any suggestions ?

Thanks in advance.
-- Volker


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

Re: [Discuss-gnuradio] OOT module authors, please update your cmake

[Volker Schroer]

Why not to use the cmake modules of gnuradio directly if building OOT's ?
If I'm right they are in ${INSTALL_PREFIX}/lib/cmake/gnuradio.

And put cmake files only nedded by the oot module into the local oot 
cmake directory.


-- Volker

Am 29.12.2015 um 22:43 schrieb Philip Balister:

Per this commit in gnuradio:

https://github.com/gnuradio/gnuradio/commit/dec480ab3f0809677ba3ef2a3a64d402d742b5ec

This commit fixes the cmake in new OOT's, but existing ones need to do
this by hand.

Thanks,

Philip

___
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] gr-display

[Volker Schroer]

First, if you run the generated top_block.py you see

Traceback (most recent call last):
  File "./top_block.py", line 99, in 
tb = top_block()
  File "./top_block.py", line 71, in __init__
self.tab_grid_layout_0.addWidget(self._show_text_0_win, 1000,110)
  File 
"/usr/local/gnuradio/lib64/python2.7/site-packages/gnuradio/gr/hier_block2.py", 
line 93, in __getattr__

return getattr(self._impl, name)
AttributeError: 'top_block_sptr' object has no attribute 'tab_grid_layout_0'

So remove remove the entry in the gui hint of gr_display.

Second, characters that can be displayed are in the range of 32 to 128 
and not between 0 and 2.


Third, you try to generate 1000 * 32000 each second. That's to much to 
display.


Set repeat of in you random source and min and max appropriate and 
you'll see the generated values will be displayed.


-- Volker

Am 05.11.2015 um 14:00 schrieb chai E:

hello all
i am using
https://github.com/gnss-sdr/gnss-sdr[text_sink],
but there is nothing show when i use text_sink
this is my grc file,
is there some one who konw how to use this demo

another question ,i want to test the example of DTV in gnuradio ,but
there is only transmitter,where i can  got a demo of DTV-dvbs2 receicer
based on gnuradio,

thank you


--Ekko


___
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] Decoding NOAA satellite

[Volker Schroer]

If you want to decode the apt pictures, you can do this by the means of
gnuradio.

I use a fcdpro+  but it should be possible to use an dongle , too.

To display the decoded image I use
https://github.com/dl1ksv/gr-display

-- Volker

Am 23.10.2015 um 09:03 schrieb alfred noble:

Hi everyone I have RTL2832u and recently I've decoded the data from
NOAA satellite successfully , but I used two windows apps , one SDR#
and the other WXtoImg , now I want to write an app myself that
decodes the data received from the NOAA satellite.I want to know if
any one here has done this before and give me some pieces of advise.
Is it possible to write a program based on C# to receive and decode
the data from NOAA satellite ?

best regards Alfred


___ 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] ControlPort 3.7.8rc1

[Volker Schroer]

There is a directory
gnuradio-runtime/python/gnuradio/ctrlport


where you in controlport related stuff.

- - Volker

Am 04.08.2015 um 10:09 schrieb Jeon:

Dear Bob,

A few months ago, I've asked a similar question 
(http://lists.gnu.org/archive/html/discuss-gnuradio/2015-06/msg00197.html)


and Tom gave me his paper in SIGCOMM.

Inspecting GNU Radio Applications with ControlPort and Performance 
Counters

Thomas Rondeau, Tim O’Shea, and Nathan Goergen

You can get one in http://conferences.sigcomm.org/sigcomm/2013/srif.php

It does not fully describe how it can be used, though, through this 
you can get a hint.


Regards,
Jeon.

2015-08-04 16:36 GMT+09:00 bob wole bnw...@gmail.com 
mailto:bnw...@gmail.com:


Ubuntu 14.04 64-bit

I just installed frest gnuradio 3.7.8rc1 with control port
enabled. I fetched gnuradio using

git clone --recursive https://github.com/gnuradio/gnuradio.git


 Gnuradio enabled component shows

* gr-ctrlport
* * thrift

However, I do not see any *gr-ctrlport directory *inside the
gnuradio directory. Where is the source code for control port?
Also there are no examples for using control port.

--
Bob

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org mailto: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] cannot import name GNURadio when launching perf-monitorx and ctrlport-monitor

[Volker Schroer]

The same error happens in the 3.7.8 release candidate.

-- Volker



I am trying to measure performance of my OOT module with performance 
counter and control port.


When I execute a command line `gr-perf-monitorx` or 
`gr-ctrlport-monitor`, an error below occurred:


File 
/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/GrDataPlotter.py, 
line 26, in module

from gnuradio.ctrlport import GNURadio
ImportError: cannot import name GNURadio

Could anyone give me a hint for this?

For detail information, I've installed GNU Radio with `build-gnuradio` 
script. The last commit of cloned git repository in my PC is 
`d5cea6e4(https://gnuradio.org/redmine/projects/gnuradio/repository/revisions/d5cea6e44e29db6b62fabe2b1e5ec16e91b41e68)` 
https://gnuradio.org/redmine/projects/gnuradio/repository/revisions/d5cea6e44e29db6b62fabe2b1e5ec16e91b41e68%29%60 
in Jun 22 2015. I can't remember exactly, but I think this commit was 
used to install the GNU Radio.


Regards,
Jeon.


___
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] gnuradio and android

[Volker Schroer]

Tom,

thank you for your comments.

I agree to your objection that android is java based. But I think most 
of the gnuradio users  ( not developers ) are  not willing (or not able 
) to code in java. gnuradio is python based at least to glue blocks 
together.


So my conclusion would be : either support python on android or to 
generate java code from grc.
But I'm unsure which of the many approaches of python for android will 
win, if any.


Nevertheless both would require gnuradio based on qt5.

I just ported some other qt4 based projects to qt5 and it wasn't really 
a great problem.

So I'd try contribute to migrate gnuradio to qt5.

But some questions: Do you intend to use PyQt4 ( which should support 
qt5, too) or do you plan PyQt5 ? And which would be the best gnuradio 
repository to start from ?


-- Volker


 Am 23.07.2015 um 15:43 schrieb Tom Rondeau:
On Wed, Jul 22, 2015 at 4:47 PM, Volker Schroer dl1...@gmx.de 
mailto:dl1...@gmx.de wrote:


Hi!
I watched the development of gnuradio for android. But I'm not
very familiar with java, so I searched for a way to run gnuradio
python scripts without or with little modifications on android.

I detected the python_for_android project and wrote some recipes
to run gnuradio on android.

For those who are interested , see:
https://github.com/dl1ksv/python-for-android

At the moment I'm able to run things like

dial_tone or an fm receiver using the rtl dongle.

But there are a lot of things missing,  in particular a gui,
support of fcd(pro+), etc.

So my question: Where to go from here: Introducing kivy to
gnuradio for building gui's , or migrating qt5 ( a way I'd prefer )
Or is this only a nice finger exercise and of no special interest ?

Comments are welcome

-- Volker


Volker,

This is awesome that you're working on this and sharing your progress. 
Two things.


First, I think the QT5 way is where you'd want to go. We will be 
migrating there, anyways, likely for the 3.8 release. Having done some 
work recently on the gr_filter_design tool in QT4/5, it's not a huge 
amount of work to go between them. We'll likely do this work off the 
next branch for the next API version release. Anything you can 
contribute to this effort would be great.


As to Python, I'm skeptical how fruitful this path really is. If it's 
just for your own stuff, that's one thing, but Android is Java, love 
it or hate it. Trying to work too far away from their structure of 
work is dangerous, since they can decide at any moment to just kill 
certain efforts -- I'm a little afraid of this myself with our 
reliance on the NDK, even.


I'm in the boat of learning Java myself to work in this world. Easier 
that than trying to force other modes of operation onto this beast.


Tom


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

[Discuss-gnuradio] gnuradio and android

[Volker Schroer]

Hi!
I watched the development of gnuradio for android. But I'm not very 
familiar with java, so I searched for a way to run gnuradio python 
scripts without or with little modifications on android.


I detected the python_for_android project and wrote some recipes to run 
gnuradio on android.


For those who are interested , see:
https://github.com/dl1ksv/python-for-android

At the moment I'm able to run things like

dial_tone or an fm receiver using the rtl dongle.

But there are a lot of things missing,  in particular a gui, support of 
fcd(pro+), etc.


So my question: Where to go from here: Introducing kivy to gnuradio for 
building gui's , or migrating qt5 ( a way I'd prefer )

Or is this only a nice finger exercise and of no special interest ?

Comments are welcome

-- Volker



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

[Discuss-gnuradio] Cmake question

[Volker Schroer]

I need to modify the SONAME of some gnuradio libs.

In the gnuradio/volk/CMakeList.txt there is an entry

set_target_properties(volk PROPERTIES SOVERSION ${LIBVER})

that sets the SONAME. But how is this done for other libs like 
gnuradio-runtime or gnuradio-pmt.

I did not identfy the statements doing this.

Thanks in advance

-- Volker



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

Re: [Discuss-gnuradio] Numpy question

[Volker Schroer]

That's right, but the problem is pmt. Is it really required for gnuradio 
to run ?

Am 06.07.2015 um 22:03 schrieb Michael Dickens:

A quick look at the source reveals NumPy is used extensively in GNU
Radio, but it is checked for by the gr-wxgui and grc modules only. So,
most of GNU Radio can install properly even if NumPy is not installed or
working. - MLD

On Mon, Jul 6, 2015, at 03:43 PM, Volker Schroer wrote:

That means,there is a bug in cmake. If numpy is required , then gnuradio
should not build if numpy is not found.
But if I remember well, in earlier days of gnuradio pmt was not required.

Am 06.07.2015 um 18:27 schrieb Martin Braun:

On 06.07.2015 08:54, Volker Schroer wrote:
   

I'm trying to build gnuradio for a system without numpy.

Numpy should probably be a hard requirement -- Python blocks won't work
properly without it, even disregarding this specific module.


How can I come around this problem without installing numpy ?

Unless you want to disable Python support entirely, you can't.

___
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] Numpy question

[Volker Schroer]

To be more specific:
Is pmt_to_python.py required as that's the place wher numpy is called.

But if this is required gnuradio should not compile without numpy.

Am 06.07.2015 um 22:09 schrieb Michael Dickens:

Yes, pmt is required for gnuradio-runtime, which in turn is required for
anything gnuradio. - MLD

On Mon, Jul 6, 2015, at 04:08 PM, Volker Schroer wrote:

That's right, but the problem is pmt. Is it really required for gnuradio  to 
run ?

___
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] Cmake question

[Volker Schroer]

Michael, thank you for the quick response.
My question was a bit misleading. I don't want  to modify the library 
name but the version number.

In the volk directory I found the correspondent entry

set_target_properties(volk PROPERTIES SOVERSION ${LIBVER})


in the gnuradio-runtime/lib/CMakeFile.txt

Which command sets the version number to 0.0.0

--Volker


Hi Volker - Actually, the command you quote just sets the -version- of
the library, not the name. The name is set by default as the target
name, though one can change the name to something else via a similar
set_target_properties command. Hope this helps! - MLD

On Mon, Jul 6, 2015, at 07:01 AM, Volker Schroer wrote:

I need to modify the SONAME of some gnuradio libs.

In the gnuradio/volk/CMakeList.txt there is an entry

set_target_properties(volk PROPERTIES SOVERSION ${LIBVER})

that sets the SONAME. But how is this done for other libs like
gnuradio-runtime or gnuradio-pmt.
I did not identfy the statements doing this.

___
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] Numpy question

[Volker Schroer]

That means,there is a bug in cmake. If numpy is required , then gnuradio 
should not build if numpy is not found.

But if I remember well, in earlier days of gnuradio pmt was not required.

-- Volker


Am 06.07.2015 um 18:27 schrieb Martin Braun:

On 06.07.2015 08:54, Volker Schroer wrote:
  

I'm trying to build gnuradio for a system without numpy.

Numpy should probably be a hard requirement -- Python blocks won't work
properly without it, even disregarding this specific module.


How can I come around this problem without installing numpy ?

Unless you want to disable Python support entirely, you can't.

Cheers,
Martin

___
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] Cmake question

[Volker Schroer]

Now I got it.
In GrMiscutils.cmake the SOVERSION is set.

Thanks to all.

-- Volker


Am 06.07.2015 um 17:41 schrieb Volker Schroer:

Michael, thank you for the quick response.
My question was a bit misleading. I don't want  to modify the library 
name but the version number.

In the volk directory I found the correspondent entry

set_target_properties(volk PROPERTIES SOVERSION ${LIBVER})


in the gnuradio-runtime/lib/CMakeFile.txt

Which command sets the version number to 0.0.0

--Volker


Hi Volker - Actually, the command you quote just sets the -version- of
the library, not the name. The name is set by default as the target
name, though one can change the name to something else via a similar
set_target_properties command. Hope this helps! - MLD

On Mon, Jul 6, 2015, at 07:01 AM, Volker Schroer wrote:

I need to modify the SONAME of some gnuradio libs.

In the gnuradio/volk/CMakeList.txt there is an entry

set_target_properties(volk PROPERTIES SOVERSION ${LIBVER})

that sets the SONAME. But how is this done for other libs like
gnuradio-runtime or gnuradio-pmt.
I did not identfy the statements doing this.

___
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] Numpy question

[Volker Schroer]

I'm trying to build gnuradio for a system without numpy.

cmake reports correctly

--
-- Python checking for pygtk = 2.10.0
-- Python checking for pygtk = 2.10.0 - not found
--
-- Python checking for numpy
-- Python checking for numpy - not found
--
-- Configuring gnuradio-companion support...


make reports
Linking CXX shared library libgnuradio-pmt-3.7.8git.so

and the library exists in the install directory.

But running an example leads to

pmt_to_python.py, line 22, in module
 ImportError: No module named numpy

How can I come around this problem without installing numpy ?

-- Volker

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

[Discuss-gnuradio] gnuradio and qt

[Volker Schroer]

Support for qt4 will end at the end of this year. I think this is not a 
real problem at the moment, but are there plans to migrate to qt5 ?


Thanks

-- Volker

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

Re: [Discuss-gnuradio] FCDproplus: FunCumb Dongle V2.0 soundcard found but not controlpart

[Volker Schroer]

gr-fcdproplus does not need controlport.

You'll find the udev rules in the readme.

If this does not help, post the error message.


-- Volker


Am 05.05.2015 um 05:30 schrieb Gregory W. Ratcliff:

There were a few threads a while back where this problem was discussed.
It seemed the issue was never debugged, just disappeared after a clean 
install.


About as clean as I know to make it:

Running Ubuntu 14.04 LTS from wiped clean (as of 5/4/2015), 64 bit desktop
Downloaded and installed today's Pybombs
Installed osmocom, rtl and gr-fcdproplu

RTL and osmocom work fine.

Completed with a Pybombs update

Rumors else indicate this is a UDEV permissions issue.

Ideas?

Greg
nz8r








___
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] gr-display-master install (was Re: Writing text to a QT GUI Window)

[Volker Schroer]

If you install gnuradio without a CMAKE_INSTALL_PREFIX it goes to 
/usr/local containing many subdirectories.
But in some use cases it may be necessary to install into a different 
directory.

On your system the CMAKE_INSTALL_PREFIX is /usr/local

Am 20.04.2015 um 16:45 schrieb Murphy, John:

In the gr-display-master README file under 2. Installation when it states...
$cmake -DCMAKE_INSTALL_PREFIX=where gnuradio is installed ../

What is meant by where gnuradio is installed?
gnuradio gets installed across many directories, to which does this refer?

Sorry for the noob question, I never had to use -DCMAKE_INSTALL_PREFIX
before just using gr_modtool for my own blocks, even copying between
systems.

On my system, when I sudo make install my own modules, it puts stuff in...
/usr/local/lib/cmake/MYMODULE
/usr/local/include/MYMODULE
/usr/local/lib64
/usr/local/lib64/python2.7/site-packages/MYMODULE
usr/local/include/MYMODULE/MYMODULE/swig
/usr/local/share/gnuradio/blocks

gr-display sounds like a great idea, and I am eager to try it out.

John Murphy
jmur...@comsonics.com

On Sat, Apr 18, 2015 at 12:00 PM,  discuss-gnuradio-requ...@gnu.org wrote:

   12. Re: Writing text to a QT Gui Window (Volker Schroer)
Message: 12
Date: Sat, 18 Apr 2015 12:46:50 +0200
From: Volker Schroer dl1...@gmx.de
Subject: Re: [Discuss-gnuradio] Writing text to a QT Gui Window
Have a look at
https://github.com/dl1ksv/gr-display
Am 18.04.2015 um 12:04 schrieb Mike Willis:

I am wondering how I might write stuff to a gui window from my OOT
blocks rather than to the console. I don?t see anything in the
standard blocks ? a gui text sink for example. I assume I will need to
write something but am short on examples of gui output

___
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] Writing text to a QT Gui Window

[Volker Schroer]

Have a look at

https://github.com/dl1ksv/gr-display

-- Volker

Am 18.04.2015 um 12:04 schrieb Mike Willis:


I am wondering how I might write stuff to a gui window from my OOT 
blocks rather than to the console. I don’t see anything in the 
standard blocks – a gui text sink for example. I assume I will need to 
write something but am short on examples of gui output


Mike



___
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] QTGUI Issue

[Volker Schroer]

Are you sure that you have only qwt5 on your system ?

I had such effects when there was qwt5 and qwt6 on my system.

-- Volker



Am 27.01.2015 um 18:05 schrieb Richard Bell:

*Another update: *I've managed to get the libqwt.so files isolated to
the pybombs install directories:

/[tsvcis@tsvtester lib]$ sudo find / -name '*libqwt.so.5*'
/home/tsvcis/Documents/pybombs/src/qwt5/lib/libqwt.so.5.2.0
/home/tsvcis/Documents/pybombs/src/qwt5/lib/libqwt.so.5.2
/home/tsvcis/Documents/pybombs/src/qwt5/lib/libqwt.so.5
/home/tsvcis/Documents/target/lib/libqwt.so.5.2.0
/home/tsvcis/Documents/target/lib/libqwt.so.5.2
/home/tsvcis/Documents/target/lib/libqwt.so.5/

but after all of this, I'm in the same boat as when we started. I get
the following undefined symbol error when trying to use a QT block in grc:
/
ImportError:
/home/tsvcis/Documents/target/lib64/libgnuradio-qtgui-3.7.7git.so.0.0.0:
undefined symbol: _ZN7QwtPlot16staticMetaObjectE/

I could use some more debug help as I'm out of ideas. I've made sure the
only rpms installed related to qt are the base installs of qt3 and qt4
that comes with my CentOS 6.6 distro. All the other qt related things,
qwt, qwt-devel, pyqwt and pyqwt-devel, are installed by pybombs from
source.

One not obvious effect I've found is that if I try and import qtgui, I
get the following error:

/[tsvcis@tsvtester lib]$ python
Python 2.6.6 (r266:84292, Jan 22 2014, 09:42:36)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux2
Type help, copyright, credits or license for more information.
  import gnuradio
  from gnuradio import qtgui
Segmentation fault (core dumped)
[tsvcis@tsvtester lib]$ /

However, if I import wxgui first, and then try to import qtgui, I get
the symbol error I normally see in grc:

/[tsvcis@tsvtester lib]$ python
Python 2.6.6 (r266:84292, Jan 22 2014, 09:42:36)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux2
Type help, copyright, credits or license for more information.
  import gnuradio
  from gnuradio import wxgui
  from gnuradio import qtgui
Traceback (most recent call last):
   File stdin, line 1, in module
   File
/home/tsvcis/Documents/target/lib64/python2.6/site-packages/gnuradio/qtgui/__init__.py,
line 34, in module
 from qtgui_swig import *
   File
/home/tsvcis/Documents/target/lib64/python2.6/site-packages/gnuradio/qtgui/qtgui_swig.py,
line 26, in module
 _qtgui_swig = swig_import_helper()
   File
/home/tsvcis/Documents/target/lib64/python2.6/site-packages/gnuradio/qtgui/qtgui_swig.py,
line 22, in swig_import_helper
 _mod = imp.load_module('_qtgui_swig', fp, pathname, description)
ImportError:
/home/tsvcis/Documents/target/lib64/libgnuradio-qtgui-3.7.7git.so.0.0.0:
undefined symbol: _ZN7QwtPlot16staticMetaObjectE
  /

I'm only mentioning it in the chance it reveals something to someone.

Appreciate the help,
Rich

On Mon, Jan 26, 2015 at 5:47 PM, Richard Bell richard.be...@gmail.com
mailto:richard.be...@gmail.com wrote:

*Latest update:* After uninstalling all the qwt and pyqwt that were
installed by yum, I tried a clean pybombs install, with everything
installed from source, and it completed.

Further debug commands now look like this:
/
[tsvcis@tsvtester ~]$ ldd
/home/tsvcis/Documents/target/lib64/libgnuradio-qtgui-3.7.7git.so.0.0.0
| grep qwt
*libqwt.so.5 = /home/tsvcis/Documents/target/lib/libqwt.so.5
(0x7f414c468000)*/

Searching for libqwt.so.5 revelas:

/[tsvcis@tsvtester ~]$ sudo find / -name 'libqwt.so.5*'
[sudo] password for tsvcis:
/home/tsvcis/Documents/pybombs/src/qwt5/lib/libqwt.so.5.2.0
/home/tsvcis/Documents/pybombs/src/qwt5/lib/libqwt.so.5.2
*/home/tsvcis/Documents/pybombs/src/qwt5/lib/libqwt.so.5*
/home/tsvcis/Documents/target/lib/libqwt.so.5.2.0
/home/tsvcis/Documents/target/lib/libqwt.so.5.2
*/home/tsvcis/Documents/target/lib/libqwt.so.5*
*/usr/lib64/libqwt.so.5*/

The major difference between now and before is the absence of
libqwt.so.5.1.1 files in /usr/lib64.

When I try to import qtgui, I get am still not able to.

/ import gnuradio
  from gnuradio import qtgui
Segmentation fault (core dumped)
[tsvcis@tsvtester ~]$ /

When I start grc and try to run a flowgraph with a qt widget I get
the following error:

ImportError:
/home/tsvcis/Documents/target/lib64/libgnuradio-qtgui-3.7.7git.so.0.0.0:
undefined symbol: _ZN7QwtPlot16staticMetaObjectE

Executing the following has no effect:
/export
LD_PRELOAD=/home/tsvcis/Documents/pybombs/src/qwt5/lib/libqwt.so.5/

And executing the following:
/export LD_PRELOAD=/usr/lib64/libqwt.so.5/

leads to the following error when I start the python interpreter:
[tsvcis@tsvtester build]$ export LD_PRELOAD=/usr/lib64/libqwt.so.5
[tsvcis@tsvtester build]$ echo $LD_PRELOAD
/usr/lib64/libqwt.so.5
[tsvcis@tsvtester build]$ python
ERROR: ld.so: object '/usr/lib64/libqwt.so.5' from LD_PRELOAD cannot
be preloaded: ignored.

Re: [Discuss-gnuradio] FunCube Dongle pro +

[Volker Schroer]

udev_enumerate_new is called from  the  latest hidapi code.

Some distros provide a hidapi package. So the actual fcdproplus tries to 
detect if an hidapi package is installed. Otherwise it uses the hidapi 
code provided with fcdproplus, which uses udev_enumerate_new.


So it would be interesting waht cmake has reported.

Near the end of the cmake output you see something like this ( in the 
case that the hidapi package is installed):


GNURADIO_PMT_FOUND = TRUE
-- checking for module 'alsa'
--   found alsa, version 1.0.28
-- Found ALSA 1.0.28
-- checking for module 'libusb-1.0'
--   found libusb-1.0, version 1.0.19
-- Found libusb-1.0: /usr/include/libusb-1.0, /usr/lib64/libusb-1.0.so
-- Found Doxygen: /usr/bin/doxygen (found version 1.8.5)
-- System Hidapi Lib /usr/lib64/libhidapi-libusb.so is used
-- Audio LIBS: /usr/local/gnuradio-orig/lib/libgnuradio-audio.so

As Marcus already proposed, it might be helpfull to see the output of

ldd lib/libgnuradio-fcdproplus.so

inside the build directory

and additionally from the gnuradio install directory.

I think udev_enumerate_new is provided from newer versions of libudev.

If you want to use a hidapi version without udev_enumerate_new
just checkout the with_hidapi release.

-- Volker




Am 01.11.2014 um 01:39 schrieb Marcus Müller:

Tracing this down; Daniel, could you share what
pkg-config --static --libs libsub-1.0
says?
in your build directory, can you do a
ldd lib/libgnuradio-fcdproplus.so


Greetings, and good night (forgot the time)
Marcus

On 11/01/2014 01:04 AM, Marcus Müller wrote:

Oh indeed, good point!
Sylvain: you're right.
How gr-fcdproplus ends up being able to compile and link is still a
mystery to me. I was expecting a horrible symbol export forwarding
hack involving libusb, but no:

$nm -D /lib64/libusb-1.so
 U udev_device_get_action
 U udev_device_get_devnode
 U udev_device_get_sysname
 U udev_device_new_from_syspath
 U udev_device_unref
 U udev_enumerate_add_match_subsystem
 U udev_enumerate_get_list_entry
 U udev_enumerate_new
...



gives me all of the udev symbols as undefined, which obviously is
correct, because they should be dynamically loaded from libusb:
$ldd /lib64/libusb-1.0.so

libusb-1.0.so|grep udev
linux-vdso.so.1 =  (0x7fff6b7fc000)
libudev.so.1 (0x0038b660)
...

Trying to build this now, but I'm currently on a machine where I
haven't even installed GR yet :/ this might take a second.

Greetings,
Marcus


On 11/01/2014 12:43 AM, Sylvain Munaut wrote:

What I find strange is that the symbol error is found at runtime and
not at link-time. That suggest either there is two libudev and the one
used for runtime is different than the one found for link-time, or
that this library was copied over from another system.

Cheers,

Sylvain



___
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] Best way to output decoded data to user

[Volker Schroer]

On github
https://github.com/dl1ksv/gr-display
there is an qt based simple oot module gr-display that can be used to 
display character streams either in an text window or as png picture.

I use this to display ax.25 packets images from weather satellites.

-- Volker

Am 15.04.2014 23:36, schrieb madengr:

Martin Braun-2 wrote

Generally: Don't use a message queue. Also, I recommend not adding any
WX widgets, unless you hate QT, because we're trying to move away from
them.

The message passing interface might be a better choice, but the idea in
general is very good.

Martin


Is there a reason not to use the message queue; maybe it is being
deprecated?  I'm experimenting with it now to pass FFT vectors out of the
flow into my python script to search for a frequency and tune demodulator,
and I can poll the queue every 10ms with no issues.  Should I be using
another method?  I don't want to write a block just yet.

Thanks,
Lou
KD4HSO



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Best-way-to-output-decoded-data-to-user-tp47578p47611.html
Sent from the GnuRadio mailing list archive at Nabble.com.

___
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] GIT checkout of Gnu Radio failed!

[Volker Schroer]

The config file ist located in .git ( hidden directory) not in ./git

-- Volker


Am 27.03.2014 21:25, schrieb Sara Chérif:

I tried this command but I got this output :
sara@ubuntu:~/gnuradio$ git clone --progress
https://github.com/gnuradio/gnuradio.git.
Cloning into 'gnuradio.git.'...
fatal: https://github.com/gnuradio/gnuradio.git./info/refs not found:
did you run git update-server-info on the server?
I searched for the problem , I found in this link that i have to change
in ./git/config
http://stackoverflow.com/questions/9343189/did-you-run-git-update-server-info-error-on-a-github-repository
but I didn't find this file ,, where can i find it (sorry i am new to
Ubuntu )

Then I found in the file named  build-gnuradio  this line
git clone --progress http://git.gnuradio.org/git/gnuradio.git $LOGDEV 21
and i changed it to:
git clone --progress https://github.com/gnuradio/gnuradio.git $LOGDEV 21
as you said

But I have the same output!!
Fetching Gnu Radio via GIT...Cloning into 'gnuradio'...
error: Unable to get pack file
http://gnuradio.org/git/gnuradio.git/objects/pack/pack-4efcc5d853d522a5d355d67387c7f37121663227.pack
transfer closed with 17230768 bytes remaining to read
error: Unable to find 6d7dd3f7609d9ec26acefdf040be0e8bb77a222c under
http://gnuradio.org/git/gnuradio.git
Cannot obtain needed object 6d7dd3f7609d9ec26acefdf040be0e8bb77a222c
while processing commit 85ae8fc1e6b7397eb6dc774e2e4eaf8049265b13.
error: Fetch failed.
Could not find gnuradio/gnuradio-{core,runtime} after GIT checkout
GIT checkout of Gnu Radio failed!
Send success/fail info to sbrac.org?Y http://sbrac.org?Y



2014-03-27 20:35 GMT+02:00 Tom Rondeau t...@trondeau.com
mailto:t...@trondeau.com:

On Thu, Mar 27, 2014 at 11:21 AM, Sara Chérif
saracheri...@gmail.com mailto:saracheri...@gmail.com wrote:
  I am installing GNU Radio from this link :
 

http://blogs.bu.edu/mhirsch/2012/07/installing-gnu-radio-in-ubuntu-12-04-x64/comment-page-1/
  but I got this output in terminal :

We're getting various reports of problems with git over http access to
gnuradio.org http://gnuradio.org. We think it's something going on
with our hosting
platform.

You can change that line in the build script from
http://git.gnuradio.org/git/gnuradio.git to
https://github.com/gnuradio/gnuradio.git.

Tom



  This script will fetch Gnu Radio version 3.7/maint from the
repositories,
  along with compatible
  extras.
  Is this OK?Y
  Fetching various packages (Gnu Radio, UHD, gr-osmosdr, gr-iqbal, etc)
  via the Internet
  === THIS MAY TAKE QUITE SOME TIME =
  Fetching Gnu Radio via GIT...Cloning into 'gnuradio'...
  error: Unable to get pack file
 

http://gnuradio.org/git/gnuradio.git/objects/pack/pack-4efcc5d853d522a5d355d67387c7f37121663227.pack
  transfer closed with 20430353 bytes remaining to read
  error: Unable to find 6d7dd3f7609d9ec26acefdf040be0e8bb77a222c under
  http://gnuradio.org/git/gnuradio.git
  Cannot obtain needed object 6d7dd3f7609d9ec26acefdf040be0e8bb77a222c
  while processing commit 85ae8fc1e6b7397eb6dc774e2e4eaf8049265b13.
  error: Fetch failed.
  Could not find gnuradio/gnuradio-{core,runtime} after GIT checkout
  GIT checkout of Gnu Radio failed!
  Send success/fail info to sbrac.org?Y http://sbrac.org?Y
 
  then I tried git clone --verbose  --progress
  http://gnuradio.org/git/gnuradio.git and i got the same output ,
what can i
  do ? ..thanks  in advance:)
 
  sara@ubuntu:~/gnuradio$ git clone --verbose
  http://gnuradio.org/git/gnuradio.git
  Cloning into 'gnuradio'...
  error: Unable to get pack file
 

http://gnuradio.org/git/gnuradio.git/objects/pack/pack-4efcc5d853d522a5d355d67387c7f37121663227.pack
  transfer closed with 21869664 bytes remaining to read
  error: Unable to find 6d7dd3f7609d9ec26acefdf040be0e8bb77a222c under
  http://gnuradio.org/git/gnuradio.git
  Cannot obtain needed object 6d7dd3f7609d9ec26acefdf040be0e8bb77a222c
  while processing commit 85ae8fc1e6b7397eb6dc774e2e4eaf8049265b13.
  error: Fetch failed.
 
  sara@ubuntu:~/gnuradio$ git clone --progress
  http://gnuradio.org/git/gnuradio.git
  Cloning into 'gnuradio'...
  error: Unable to get pack file
 

http://gnuradio.org/git/gnuradio.git/objects/pack/pack-4efcc5d853d522a5d355d67387c7f37121663227.pack
  transfer closed with 21283224 bytes remaining to read
  error: Unable to find 6d7dd3f7609d9ec26acefdf040be0e8bb77a222c under
  http://gnuradio.org/git/gnuradio.git
  Cannot obtain needed object 6d7dd3f7609d9ec26acefdf040be0e8bb77a222c
  while processing commit 85ae8fc1e6b7397eb6dc774e2e4eaf8049265b13.
  error: Fetch failed.
 
 
 
  ___
  Discuss-gnuradio mailing list
  Discuss-gnuradio@gnu.org 

Re: [Discuss-gnuradio] Problem running FCD demo

[Volker Schroer]

Have a look at your dmesg log. You probably see a  not enough 
bandwidth message. Are you using an usb 2 or an usb 3 port ?


-- Volker



Am 19.03.2014 03:57, schrieb Mike Harpe:

I am trying to run the FCD nfm demo with the proplus module. This is
using 3.7.3. Everything compiled and loaded fine. I am very tired and
going to bed.

I would really appreciate someone looking at this. Thanks in advance.

Executing: /home/mike/fcd_nfm_rx.py

Using Volk machine: avx_64_mmx_orc
Funcube Dongle Pro+ found as: plughw:1,0
Dongle sucessfully initialized
Result of Action :+
FCDAPP 20.03
  Lna gain enabled
  Mixer gain disabled
If gain set to: 0
Set Frequency to: 1.62475e+08 Hz, corrected to: 162475008 Hz
len(audio_taps) = 463
audio_alsa_source[plughw:1,0]: snd_pcm_hw_params failed: Input/output error
Traceback (most recent call last):
   File /home/mike/fcd_nfm_rx.py, line 405, in module
 tb.Start(True)
   File
/usr/local/lib/python2.7/dist-packages/grc_gnuradio/wxgui/top_block_gui.py,
line 73, in Start
 self.start()
   File
/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py, line
104, in start
 top_block_start_unlocked(self._tb, max_noutput_items)
   File
/usr/local/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py,
line 4629, in top_block_start_unlocked
 return _runtime_swig.top_block_start_unlocked(*args, **kwargs)
RuntimeError: check topology failed on audio_alsa_source(12) using
ninputs=0, noutputs=2

  Done



___
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] Throttle question

[Volker Schroer]

For testing purposes I use
vector source (byte ) - vector to stream - throttle - [blocks to test]
In the vector source repeat is set to yes and the sample rate is set 
to 1024 ( and in the throttle block , too ).


I would expect that the throttle delivers 1024 samples every second. But 
I see that the throttle delivers 32768 bytes about every 32 seconds. ( 
Which is on average 1024 samples per second ).
Is this the expected behavior or should the samples be delivered  every 
second ?


-- Volker


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

Re: [Discuss-gnuradio] Throttle question

[Volker Schroer]

Thanks for the tips.

Setting the Max Output bufferin the throttle block did the trick.
Yes, the vector to stream block can be avoided. The default vector 
length is 1 in grc.


Now testing works much smoother.

Good to know.

-- Volker


Am 16.03.2014 18:00, schrieb Marcus Müller:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Volker,

yes, that is expected behaviour. Most probably ;)
For explanation: Since GNU Radio itself always passes around multiple
items at once (so your work doesn't get called), all throttle can do is
limit the average rate, unless it would consume one input item at a
time, stall work as long as necessary and then output that one item.
For higher sample rates (where the flow graph is nearly CPU-limited),
which is the original use case of throttle (stopping GNU Radio from
completely clogging the CPU) this would imply a considerable overhead.

What you can try is call the public
gr::block::set_max_noutput_items(int) method on your throttle block
*prior* to starting the flow graph. This should tell the scheduler to
call the throttle's work function with smaller numbers of input
samples (also, it reduces the output buffer size if that is feasible
for the downstream block).
Also, try smaller values for the max_output_buffer size of the vector
source, maybe (that could be even accessible in the GNU Radio
companion block property dialog).

one more question in that context: why the vector to stream? the
vector source can output single samples, too. Just set the vector
length to 1.

Greetings,
Marcus

On 16.03.2014 17:35, Volker Schroer wrote:

For testing purposes I use vector source (byte ) - vector to
stream - throttle - [blocks to test] In the vector source
repeat is set to yes and the sample rate is set to 1024 ( and
in the throttle block , too ).

I would expect that the throttle delivers 1024 samples every
second. But I see that the throttle delivers 32768 bytes about
every 32 seconds. ( Which is on average 1024 samples per second ).
Is this the expected behavior or should the samples be delivered
every second ?

-- Volker


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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTJdimAAoJEBQ6EdjyzlHtheAH/iv6UnTFsr0z+BftZO535iDu
kKZa4ik0wnYMv83byngbqX9RClzCATeTxSKgav9EwKIF66jAwH3l5Ojb+wv9SA4C
4gSttXCktHwCU7lcSPaAQMQzJIKOEJUlHPgd67iGxMVuu67RPDZoFyQiWSHaRaV1
kwhk4KgZs/Ku+ORvaMNJk3caTs9OUJkBvbqxvr1DCWZyHXS/CDh3is7XJMONcLRR
d0XzELkMic9MdbkT/ljnjujlPaMtlw+VM3SvU8Cfvm/lLif9KsLE0PdjF4yWbFpZ
Ct+RoD1/HZMUhceBZL804ty7xlNrt73B7jZgT9ZmgzxkEqoyw54UeoXnrIZeIjg=
=+VI7
-END PGP SIGNATURE-

___
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] how to enable doc of gr-trellis

[Volker Schroer]

The README in gr-trellis says:

The doc directory is not built by default.  This is to avoid spurious
build problems on systems that don't have xmlto installed.  If you
have xmlto and its dependencies installed, you can build the html
version of the gr-trellis article by cd'ing to doc and invoking make.


And it worked for me.

-- Volker



Am 23.02.2014 15:54, schrieb Tiankun Hu:

Hi experts,
I found a doc gr-trellis/doc/gr-trellis.xml, is there anyone know how
to build it to gr-trellis.html?
I found cmake option ENABLE_DOXYGEN default is ON, but I did not find
this doc in my doc path /usr/local/share/doc/gnuradio-3.7.3git/html/

Thanks
Tiankun


___
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] Issue with gr-funcubedongleproplus

[Volker Schroer]

The first part looks o.k. I don't know anything about MTP devices, but 
after some googeling I suppose there is an udev misconfiguration.


Please look, if there exists a rule file for MTP devices that is 
triggered by the funcube dongle.


-- Volker



Am 16.02.2014 16:21, schrieb Mike Harpe:

This is what I see in /var/log/messages when I plug it in.

Feb 16 10:19:56 debianvm kernel: [  485.160978] usb 2-2.2: new
full-speed USB device number 6 using uhci_hcd
Feb 16 10:19:56 debianvm kernel: [  485.432177] usb 2-2.2: New USB
device found, idVendor=04d8, idProduct=fb31
Feb 16 10:19:56 debianvm kernel: [  485.432180] usb 2-2.2: New USB
device strings: Mfr=1, Product=2, SerialNumber=0
Feb 16 10:19:56 debianvm kernel: [  485.432181] usb 2-2.2: Product:
FUNcube Dongle V2.0
Feb 16 10:19:56 debianvm kernel: [  485.432182] usb 2-2.2: Manufacturer:
Hanlincrest Ltd.
Feb 16 10:19:56 debianvm kernel: [  485.487344] 6:1:1: cannot get freq
at ep 0x81
Feb 16 10:19:56 debianvm kernel: [  485.532651] generic-usb
0003:04D8:FB31.0003: hiddev0,hidraw1: USB HID v1.11 Device [Hanlincrest
Ltd.  FUNcube Dongle V2.0  ] on usb-:02:00.0-2.2/input2
Feb 16 10:19:56 debianvm mtp-probe: checking bus 2, device 6:
/sys/devices/pci:00/:00:11.0/:02:00.0/usb2/2-2/2-2.2
Feb 16 10:19:56 debianvm mtp-probe: bus: 2, device: 6 was not an MTP device

Thanks for looking at this.

Mike Harpe


On Sun, Feb 16, 2014 at 1:31 AM, Volker Schroer dl1...@gmx.de
mailto:dl1...@gmx.de wrote:

What do you see in your message log, when you connect the dongle to
your computer ?

-- Volker


Am 15.02.2014 21:30, schrieb Mike Harpe:

Hello! I've gotten GNU Radio 3.7.2.1 compiled and running. I have a
FunCube Dongle Pro Plus V2 that I received in the last week.

My environment is Debian wheezy running a generic kernel.

I am getting the following when I try to run the narrowband FM
example.
It has to do with the control part of the dongle. I tried the udev
change with no success. I am new to working with devices in udev
so I'm
sure that's the problem.

Here's what I get...

Showing: /home/mike/fcd_nfm_rx.grc

Generating: /home/mike/fcd_nfm_rx.py

Executing: /home/mike/fcd_nfm_rx.py

Using Volk machine: avx_64_mmx_orc
Funcube Dongle Pro+ found as: plughw:1,0
Traceback (most recent call last):
File /home/mike/fcd_nfm_rx.py, line 405, in module
  tb = fcd_nfm_rx()
File /home/mike/fcd_nfm_rx.py, line 257, in __init__
  self.fcdproplus_fcdproplus_0 = fcdproplus.fcdproplus(,1)
File

/usr/local/lib/python2.7/__dist-packages/fcdproplus/__fcdproplus_swig.py,
line 103, in make
  return _fcdproplus_swig.fcdproplus___make(device_name, unit)
RuntimeError: FunCube Dongle  V2.0 soundcard found but not
controlpart.

Any help is appreciated.

Thank you!

Michael Harpe, N4PLE
Sellersburg, IN


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



_
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio
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] Issue with gr-funcubedongleproplus

[Volker Schroer]

What do you see in your message log, when you connect the dongle to your 
computer ?


-- Volker


Am 15.02.2014 21:30, schrieb Mike Harpe:

Hello! I've gotten GNU Radio 3.7.2.1 compiled and running. I have a
FunCube Dongle Pro Plus V2 that I received in the last week.

My environment is Debian wheezy running a generic kernel.

I am getting the following when I try to run the narrowband FM example.
It has to do with the control part of the dongle. I tried the udev
change with no success. I am new to working with devices in udev so I'm
sure that's the problem.

Here's what I get...

Showing: /home/mike/fcd_nfm_rx.grc

Generating: /home/mike/fcd_nfm_rx.py

Executing: /home/mike/fcd_nfm_rx.py

Using Volk machine: avx_64_mmx_orc
Funcube Dongle Pro+ found as: plughw:1,0
Traceback (most recent call last):
   File /home/mike/fcd_nfm_rx.py, line 405, in module
 tb = fcd_nfm_rx()
   File /home/mike/fcd_nfm_rx.py, line 257, in __init__
 self.fcdproplus_fcdproplus_0 = fcdproplus.fcdproplus(,1)
   File
/usr/local/lib/python2.7/dist-packages/fcdproplus/fcdproplus_swig.py,
line 103, in make
 return _fcdproplus_swig.fcdproplus_make(device_name, unit)
RuntimeError: FunCube Dongle  V2.0 soundcard found but not controlpart.

Any help is appreciated.

Thank you!

Michael Harpe, N4PLE
Sellersburg, IN


___
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] funcube pro +

[Volker Schroer]

The funcube pro+ works flawless on my usb 2.0 port. It seems that the 
bandwidth problem arises from the usb controller hardware.


I use an ASROCK motherboard with SB7x0/SB8x0/SB9x0 controller in use 
with the ohci /ehci kernel drivers. This controller works very well for me.


The Inc. EJ168 USB 3.0 Host Controller instead does not work. It claims 
to have not enough bandwith but for both Funcube devices the ( pro and 
the pro+).


-- Volker



Am 12.02.2014 11:09, schrieb Alexandru Csete:

On Wed, Feb 12, 2014 at 10:51 AM, Nemanja Savic vlasi...@gmail.com wrote:

Hi all guys,

I am about to buy funcube dongle pro +, and wanted to ask if somebody of u
use it without any problems?


Very few people use it on linux without problems. If you have a USB 1
port it will probably work, otherwise you will likely get the
insufficient bandwidth bug.

https://github.com/csete/gqrx/issues/91

There are however no problems with the original Funcube Dongle Pro
(the one without shortwaves and only 96 kHz bandwidth).

Alex

___
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] funcube pro +

[Volker Schroer]

If you run linux on your laptop try

lspci -k

and look for USB. Then you can find the controller type.

USB 3 supports higher speed than USB 2 and should offer more bandwidth. 
But on my desktop system the dongle only runs on the USB 2 port not on 
the USB 3 port. The same happens with the funcube pro that requires 
lower bandwidth than the pro +. On my notebook there exists only an USB3 
controller Intel 8 Series/C2200 and it works flawless.


--Volker


Am 12.02.2014 14:22, schrieb Nemanja Savic:

Well, I have dell laptop but have no clue which usb controller it has.
Now I am not sure whether I should by one or not. Anyway, should newer
versions of usb have higher speed and thus bandwidth.


On Wed, Feb 12, 2014 at 1:49 PM, Volker Schroer dl1...@gmx.de
mailto:dl1...@gmx.de wrote:

The funcube pro+ works flawless on my usb 2.0 port. It seems that
the bandwidth problem arises from the usb controller hardware.

I use an ASROCK motherboard with SB7x0/SB8x0/SB9x0 controller in use
with the ohci /ehci kernel drivers. This controller works very well
for me.

The Inc. EJ168 USB 3.0 Host Controller instead does not work. It
claims to have not enough bandwith but for both Funcube devices the
( pro and the pro+).

-- Volker



Am 12.02.2014 11:09, schrieb Alexandru Csete:

On Wed, Feb 12, 2014 at 10:51 AM, Nemanja Savic
vlasi...@gmail.com mailto:vlasi...@gmail.com wrote:

Hi all guys,

I am about to buy funcube dongle pro +, and wanted to ask if
somebody of u
use it without any problems?


Very few people use it on linux without problems. If you have a
USB 1
port it will probably work, otherwise you will likely get the
insufficient bandwidth bug.

https://github.com/csete/gqrx/__issues/91
https://github.com/csete/gqrx/issues/91

There are however no problems with the original Funcube Dongle Pro
(the one without shortwaves and only 96 kHz bandwidth).

Alex

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



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




--
Nemanja Savić



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

Re: [Discuss-gnuradio] gr-audio: add query device names?

[Volker Schroer]

Hi Volker,

The idea is to enumerate using library calls, which is the right way to do this.

Alex


Hi Alex,

Yes, I know, but sometimes this does not help. Here is a list of my 
devices from aplay -l:


Karte 0: SB [HDA ATI SB], Gerät 0: ID 892 Analog [ID 892 Analog]
  Sub-Geräte: 0/1
  Sub-Gerät #0: subdevice #0
Karte 0: SB [HDA ATI SB], Gerät 1: ID 892 Digital [ID 892 Digital]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
Karte 1: M44 [M Audio Delta 44], Gerät 0: ICE1712 multi [ICE1712 multi]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
Karte 2: Loopback [Loopback], Gerät 0: Loopback PCM [Loopback PCM]
  Sub-Geräte: 7/8
  Sub-Gerät #0: subdevice #0
  Sub-Gerät #1: subdevice #1
  Sub-Gerät #2: subdevice #2
  Sub-Gerät #3: subdevice #3
  Sub-Gerät #4: subdevice #4
  Sub-Gerät #5: subdevice #5
  Sub-Gerät #6: subdevice #6
  Sub-Gerät #7: subdevice #7
Karte 2: Loopback [Loopback], Gerät 1: Loopback PCM [Loopback PCM]
  Sub-Geräte: 8/8
  Sub-Gerät #0: subdevice #0
  Sub-Gerät #1: subdevice #1
  Sub-Gerät #2: subdevice #2
  Sub-Gerät #3: subdevice #3
  Sub-Gerät #4: subdevice #4
  Sub-Gerät #5: subdevice #5
  Sub-Gerät #6: subdevice #6
  Sub-Gerät #7: subdevice #7
Karte 4: HDMI [HDA ATI HDMI], Gerät 3: HDMI 0 [HDMI 0]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0


But to use the Delta card I have to use plughw:1 as device or some other 
plugin defined in my personal .asoundrc .


-- Volker




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

Re: [Discuss-gnuradio] gr-audio: add query device names?

[Volker Schroer]

There may a problem with alsa and linux.
You can find all available cards in the file /proc/asound/cards.

But in some cases you can't use a card directly.
For instance the Delta M44 offers 10 channels, but in many use cases you 
only work with 2 channels. So you have to use plugins.


Of course, you could list the available hardware.

-- Volker



Am 05.02.2014 17:43, schrieb Michael Dickens:

It's all well and good to send in an audio device name to the gr-audio 
sink/source, and then see if that device name matches anything / works / is 
found.  In my fixes to gr-audio-osx, if the audio device was specified but not 
found, the code will print out a list of available device names and use the 
default device.

This got me thinking: Why not change the gr-audio API to include a method that 
returns all known device names (output ones for sink and input ones for 
source)?  I can easily do it on OSX native, and Alex Csete has a means for 
doing it on PortAudio; I have no idea how difficult this would be for any other 
audio option, but I generally like the idea.

What do others think? - MLD
--
Michael Dickens, OSX Programmer
Ettus Research Technical Support
Email: supp...@ettus.com
Web: http://www.ettus.com


___
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] Some thoughts on out of tree modules and cmake files

[Volker Schroer]

Hi,

at the moment each out of tree module has it's one cmake/Modules path, 
containing some cmake macros, mainly copied from some gnuradio source tree.


As gnuradio development proceeds, cmake modules may be updated. It's not 
always necessary but perhaps good practice to keep the out of tree cmake 
modules in sync.


As the number of oot- modules raises that means a lot of work.

As each oot module needs a gnuradio installation , why not to install 
the complete cmake path together with gnuradio and reference these 
modules in the oot CMakeLists.txt. As far as I can see only only two 
lines in the main CMakeLists.txt file are effected.


The oot modules source would always use updated cmake files and if you 
need macros not provided by gnuradio you can still keep them with your 
module.


-- Volker



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