[Discuss-gnuradio] connect/disconnect blocks in hierarchical block depending on a variable

2019-10-21 Thread Thabet GHARBI 
Hello,

I'm writing a hierarchical block in C++, in which I instantiate 3 custom
(hier)blocks.
I want to start Block1 only, and depending on the value of one of its
attributes (which changes during processing), disconnect it, and connect
either block2 or block3,

1- What's the simplest way to do this?
2- In case we use "message passing", is it possible to interpret the
message at hierarchical block level?

Thanks in advance.

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

Re: [Discuss-gnuradio] connect/disconnect blocks in hierarchical block depending on a variable

2019-10-21 Thread CEL 
Hello!

Re: 1

That's not how GNU Radio should be used, and thus, it's impossible to
do that, architecturally. Connecting blocks pretty much has non-
deterministic behaviour w.r.t. to buffer state, and also, without the
block connected, your flow graph probably wouldn't be properly
connected and couldn't even start!

Instead, have a block (not a hier block) that outputs items according
to some state. Often, it's easy to transport state transitions as
stream tags.

Re: 2

Hier blocks shouldn't be involved in signal processing. So, although
it's generally possible to make a hier block a message acceptor, it's
rarely a good idea.

Best regards,
Marcus


On Mon, 2019-10-21 at 10:52 +0200, Thabet GHARBI wrote:
> Hello,
> 
> I'm writing a hierarchical block in C++, in which I instantiate 3 custom 
> (hier)blocks.
> I want to start Block1 only, and depending on the value of one of its 
> attributes (which changes during processing), disconnect it, and connect 
> either block2 or block3,
> 
> 1- What's the simplest way to do this?
> 2- In case we use "message passing", is it possible to interpret the message 
> at hierarchical block level?
> 
> Thanks in advance.
>  
> Best Regards,
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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

[Discuss-gnuradio] Error compiling gr-qtgui/lib

2019-10-21 Thread Gisle Vanem 

Hello list.

I have some errors while compiling 'gr-qtgui' using MSVC
and/or clang-cl. From clang-cl:
  TimeRasterDisplayPlot.cc(199,30):  error: allocating an object of abstract 
class type 'TimeRasterData'
  d_data.push_back(new TimeRasterData(d_rows, d_cols));
 ^
  f:/Qt/Qwt/src\qwt_raster_data.h(100,25):  note: unimplemented pure virtual 
method 'interval' in 'TimeRasterData'
  virtual QwtInterval interval( Qt::Axis ) const = 0;
^
  TimeRasterDisplayPlot.cc(374,20):  error: no member named 'setInterval' in 
'TimeRasterData'
  d_data[i]->setInterval(Qt::ZAxis, QwtInterval(minIntensity, 
maxIntensity));
~  ^

The error on 'setInterval' is in other files too.

I suspect I'm using the wrong Qwt library.
This is the one I'm using:
   svn://svn.code.sf.net/p/qwt/code/trunk/qwt

ver. 6.1.4 Or are we supposed to use another (older) one?

--
--gv

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

Re: [Discuss-gnuradio] Error compiling gr-qtgui/lib

2019-10-21 Thread Michael Dickens 
Hi Gisle - Which version of GR are you trying to build? GR37
uses qwt52+qt4, while GR38 uses qwt6+qt5 ... I'm guessing Qwt 6.1.4 should
work, though I don't think I've tried it out yet. - MLD

On Mon, Oct 21, 2019 at 9:40 AM Gisle Vanem  wrote:

> Hello list.
>
> I have some errors while compiling 'gr-qtgui' using MSVC
> and/or clang-cl. From clang-cl:
>TimeRasterDisplayPlot.cc(199,30):  error: allocating an object of
> abstract class type 'TimeRasterData'
>d_data.push_back(new TimeRasterData(d_rows, d_cols));
>   ^
>f:/Qt/Qwt/src\qwt_raster_data.h(100,25):  note: unimplemented pure
> virtual method 'interval' in 'TimeRasterData'
>virtual QwtInterval interval( Qt::Axis ) const = 0;
>  ^
>TimeRasterDisplayPlot.cc(374,20):  error: no member named 'setInterval'
> in 'TimeRasterData'
>d_data[i]->setInterval(Qt::ZAxis, QwtInterval(minIntensity,
> maxIntensity));
>  ~  ^
>
> The error on 'setInterval' is in other files too.
>
> I suspect I'm using the wrong Qwt library.
> This is the one I'm using:
> svn://svn.code.sf.net/p/qwt/code/trunk/qwt
>
> ver. 6.1.4 Or are we supposed to use another (older) one?
>
> --
> --gv
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNU 3.8 OOT module problem

2019-10-21 Thread Mark Koenig 
Hello,

I have a number of OOT tree modules I am porting over to GNU 3.8, and all but 
one module seem to be going well.  I am able to build and install all of the 
modules without errors, but when I try to call one of them, I get the error 
below.  I believe I have modified CMakeLists.txt properly.

could not find/open output driver: libwfcontrol_output_radiotap_pcap.so!
/opt/truearrow/6.3/lib/libwfcontrol_output_pcap.so: undefined symbol: 
_ZTI13output_driver
thread[thread-per-block[10]: ]: 
could not find driver

Does anyone have any suggestions on how to properly troubleshoot this problem?  
Or point me where to look to remedy the issue?  I have tried using “c++filt”, 
but it only returns “typeinfo for output_driver”.


Thank you very much

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

Re: [Discuss-gnuradio] Error compiling gr-qtgui/lib

2019-10-21 Thread Gisle Vanem 

Michael Dickens wrote:

Hi Gisle - Which version of GR are you trying to build? GR37 uses qwt52+qt4, while GR38 uses qwt6+qt5 ... I'm guessing 
Qwt 6.1.4 should work, though I don't think I've tried it out yet. - MLD


I use the 'master' at https://github.com/gnuradio/gnuradio.git
Should be v3.8, no?

But just switching to 'https://github.com/osakared/qwt.git'
compiles fine. Although it fails at the link stage and the
latest commit is 2,5 year old!

I just don't get this package mess!

--
--gv

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

Re: [Discuss-gnuradio] Error compiling gr-qtgui/lib

2019-10-21 Thread Michael Dickens 
Yes: GR GIT master == GR38, which will require qwt6+qt5 of some
combination. I'm using Qwt 6.1.4 right now with Qt5 5.12.5. Works nicely. -
MLD

On Mon, Oct 21, 2019 at 10:30 AM Gisle Vanem  wrote:

> Michael Dickens wrote:
>
> > Hi Gisle - Which version of GR are you trying to build? GR37
> uses qwt52+qt4, while GR38 uses qwt6+qt5 ... I'm guessing
> > Qwt 6.1.4 should work, though I don't think I've tried it out yet. - MLD
>
> I use the 'master' at https://github.com/gnuradio/gnuradio.git
> Should be v3.8, no?
>
> But just switching to 'https://github.com/osakared/qwt.git'
> compiles fine. Although it fails at the link stage and the
> latest commit is 2,5 year old!
>
> I just don't get this package mess!
>
> --
> --gv
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Error compiling gr-qtgui/lib

2019-10-21 Thread Geof Nieboer 
The Qwt/Qt linkage is indeed a problem, as when compiling one must be
very careful to link the right version of Qwt to the right version of
Qt or else all hell breaks loose.

GR3.7 needs Qwt5 linked to Qt4
GR3.8 needs Qwt6 linked to Qt5

If you are building 3.7 on windows, I'd recommend just using the
installers here: http://www.gcndevelopment.com/gnuradio, which will
bring down all your dependencies in a self-contained fashion.  For 3.8
the build scripts will do it, but I haven't released an installer as
I've been waiting for gr-osmosdr and couple OOTs to be converted.

Geof

On 10/21/19, Michael Dickens  wrote:
> Hi Gisle - Which version of GR are you trying to build? GR37
> uses qwt52+qt4, while GR38 uses qwt6+qt5 ... I'm guessing Qwt 6.1.4 should
> work, though I don't think I've tried it out yet. - MLD
>
> On Mon, Oct 21, 2019 at 9:40 AM Gisle Vanem  wrote:
>
>> Hello list.
>>
>> I have some errors while compiling 'gr-qtgui' using MSVC
>> and/or clang-cl. From clang-cl:
>>TimeRasterDisplayPlot.cc(199,30):  error: allocating an object of
>> abstract class type 'TimeRasterData'
>>d_data.push_back(new TimeRasterData(d_rows, d_cols));
>>   ^
>>f:/Qt/Qwt/src\qwt_raster_data.h(100,25):  note: unimplemented pure
>> virtual method 'interval' in 'TimeRasterData'
>>virtual QwtInterval interval( Qt::Axis ) const = 0;
>>  ^
>>TimeRasterDisplayPlot.cc(374,20):  error: no member named
>> 'setInterval'
>> in 'TimeRasterData'
>>d_data[i]->setInterval(Qt::ZAxis, QwtInterval(minIntensity,
>> maxIntensity));
>>  ~  ^
>>
>> The error on 'setInterval' is in other files too.
>>
>> I suspect I'm using the wrong Qwt library.
>> This is the one I'm using:
>> svn://svn.code.sf.net/p/qwt/code/trunk/qwt
>>
>> ver. 6.1.4 Or are we supposed to use another (older) one?
>>
>> --
>> --gv
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
> --
> Michael Dickens
> Ettus Research Technical Support
> Email: supp...@ettus.com
> Web: https://ettus.com/
>


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

Re: [Discuss-gnuradio] Error compiling gr-qtgui/lib

2019-10-21 Thread Geof Nieboer 
Ah I forgot to mention, I had to build a patch for Qwt6, my scripts
retrieve that file and patch qwt6.

The URL for the patched files is:
https://www.gcndevelopment.com/gnuradio/downloads/sources/qwt6_patch.7z

I don't recall off the top of my head what the changes were, and can't
verify from this computer, sorry.  But give them a shot.

Geof



On 10/21/19, Geof Nieboer  wrote:
> The Qwt/Qt linkage is indeed a problem, as when compiling one must be
> very careful to link the right version of Qwt to the right version of
> Qt or else all hell breaks loose.
>
> GR3.7 needs Qwt5 linked to Qt4
> GR3.8 needs Qwt6 linked to Qt5
>
> If you are building 3.7 on windows, I'd recommend just using the
> installers here: http://www.gcndevelopment.com/gnuradio, which will
> bring down all your dependencies in a self-contained fashion.  For 3.8
> the build scripts will do it, but I haven't released an installer as
> I've been waiting for gr-osmosdr and couple OOTs to be converted.
>
> Geof
>
> On 10/21/19, Michael Dickens  wrote:
>> Hi Gisle - Which version of GR are you trying to build? GR37
>> uses qwt52+qt4, while GR38 uses qwt6+qt5 ... I'm guessing Qwt 6.1.4
>> should
>> work, though I don't think I've tried it out yet. - MLD
>>
>> On Mon, Oct 21, 2019 at 9:40 AM Gisle Vanem 
>> wrote:
>>
>>> Hello list.
>>>
>>> I have some errors while compiling 'gr-qtgui' using MSVC
>>> and/or clang-cl. From clang-cl:
>>>TimeRasterDisplayPlot.cc(199,30):  error: allocating an object of
>>> abstract class type 'TimeRasterData'
>>>d_data.push_back(new TimeRasterData(d_rows, d_cols));
>>>   ^
>>>f:/Qt/Qwt/src\qwt_raster_data.h(100,25):  note: unimplemented pure
>>> virtual method 'interval' in 'TimeRasterData'
>>>virtual QwtInterval interval( Qt::Axis ) const = 0;
>>>  ^
>>>TimeRasterDisplayPlot.cc(374,20):  error: no member named
>>> 'setInterval'
>>> in 'TimeRasterData'
>>>d_data[i]->setInterval(Qt::ZAxis, QwtInterval(minIntensity,
>>> maxIntensity));
>>>  ~  ^
>>>
>>> The error on 'setInterval' is in other files too.
>>>
>>> I suspect I'm using the wrong Qwt library.
>>> This is the one I'm using:
>>> svn://svn.code.sf.net/p/qwt/code/trunk/qwt
>>>
>>> ver. 6.1.4 Or are we supposed to use another (older) one?
>>>
>>> --
>>> --gv
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>>
>> --
>> Michael Dickens
>> Ettus Research Technical Support
>> Email: supp...@ettus.com
>> Web: https://ettus.com/
>>
>


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

Re: [Discuss-gnuradio] GNU 3.8 OOT module problem

2019-10-21 Thread CEL 
This looks like a runtime shared library loader problem.
Make sure that libwfcontrol_output_radiotap_pcap.so is in a path that
your system looks in (environment variable LD_LIBRARY_PATH, plus
whatever your system is configured to).

Best regards,
Marcus

On Mon, 2019-10-21 at 14:20 +, Mark Koenig wrote:
> Hello,
>  
> I have a number of OOT tree modules I am porting over to GNU 3.8, and all but 
> one module seem to be going well.  I am able to build and install all of the 
> modules without errors, but when I try to call one of them, I get the error 
> below.  I believe I have modified CMakeLists.txt properly.
>  
> could not find/open output driver: libwfcontrol_output_radiotap_pcap.so!
> /opt/truearrow/6.3/lib/libwfcontrol_output_pcap.so: undefined symbol: 
> _ZTI13output_driver
> thread[thread-per-block[10]: ]: 
> could not find driver
>  
> Does anyone have any suggestions on how to properly troubleshoot this 
> problem?  Or point me where to look to remedy the issue?  I have tried using 
> “c++filt”, but it only returns “typeinfo for output_driver”.
>  
>  
> Thank you very much
>  
> Mark
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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

Re: [Discuss-gnuradio] GNU 3.8 OOT module problem

2019-10-21 Thread Vasil Velichkov 
Hi Mark,

On 21/10/2019 17.20, Mark Koenig wrote:
> Hello,
> 
> I have a number of OOT tree modules I am porting over to GNU 3.8, and all but 
> one module seem to be going well.  I am able to build and install all of the 
> modules without errors, but when I try to call one of them, I get the error 
> below.  I believe I have modified CMakeLists.txt properly.
> 
> could not find/open output driver: libwfcontrol_output_radiotap_pcap.so!
> /opt/truearrow/6.3/lib/libwfcontrol_output_pcap.so: undefined symbol: 
> _ZTI13output_driver
> thread[thread-per-block[10]: ]: 
> could not find driver
> 
> Does anyone have any suggestions on how to properly troubleshoot this 
> problem?  Or point me where to look to remedy the issue?  I have tried using 
> “c++filt”, but it only returns “typeinfo for output_driver”.

Most probably the output_driver class is missing implementation of one or more 
pure virtual functions or it's missing its virtual destructor. See all the 
answers of the following SO question - 
https://stackoverflow.com/questions/307352/g-undefined-reference-to-typeinfo

Regards,
Vasil

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

Re: [Discuss-gnuradio] Run time error of gr-ieee802-11 after grc upgrade (UHD?)

2019-10-21 Thread Carlos Velazquez 
Yup! That was the issue.  Thanks for he quick reply!

Carlos

On Oct 20, 2019, at 8:11 PM, Michael Dickens 
mailto:michael.dick...@ettus.com>> wrote:

Hi Carlos - The issue is with the USRP source block. If you open up its options 
in GRC, under the tab "FE Corrections", there are 2 entries (IQ Balance and DC 
Offset), both of which are probably double quotes ("") ... these should be 
Python booleans, so True or False depending on if you want to use the option or 
not. Hopefully changing them to True or False will take care of your issue. - 
MLD

On Sun, Oct 20, 2019 at 6:00 PM Carlos Velazquez 
mailto:cvel...@hotmail.com>> wrote:
I am running macOS 10.14.6 and grc 3.7.13.5.  After troubleshooting the missing 
variable error in gr-ieee802 after a macport update, I now have the following 
error:

Traceback (most recent call last):
  File “~/Documents/Research/gr-ieee802-11/examples/wifi_rx.py", line 380, in 

main()
  File “~/Documents/Research/gr-ieee802-11/examples/wifi_rx.py", line 368, in 
main
tb = top_block_cls()
  File “~/Documents/Research/gr-ieee802-11/examples/wifi_rx.py", line 152, in 
__init__
self.uhd_usrp_source_0.set_auto_dc_offset("", 0)
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/uhd/uhd_swig.py",
 line 3582, in set_auto_dc_offset
return _uhd_swig.usrp_source_sptr_set_auto_dc_offset(self, enb, chan)
TypeError: in method 'usrp_source_sptr_set_auto_dc_offset', argument 2 of type 
'bool'

The loopback block runs fine. It seems UHD may have changed? Anyone having the 
problem? I tried to upgrade gr to 3.8 but macports is only fetching 3.7

v/r,

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


--
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/

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