Re: Resampling radio data

[Mark Koenig]

Thanks for all of the suggestions.  I will look to try them out tomorrow.

Mark

Get Outlook for iOS<https://aka.ms/o0ukef>

From: Brian Padalino 
Sent: Tuesday, February 16, 2021 5:37:20 PM
To: Mark Koenig 
Cc: discuss-gnuradio@gnu.org 
Subject: Re: Resampling radio data

On Tue, Feb 16, 2021 at 5:21 PM Mark Koenig 
mailto:mark.koe...@iubelttechnologies.com>> 
wrote:
The BWs are 20mhz, 40mhz and 80Mhz respectively.  The host can range from a 
server with 48 cores(2.6Ghz), 256GB ram to a laptop with 8 cores(3.0Ghz), 64GB 
ram.

Have you tried using the blocks you asked about to see what happens with them?  
Jeff Long recommended running top to see if the processing threads for the 
resampling fall behind.  You can also check your memory growth to see if that 
happens.

You may be able to do a cheap/dirty resampling by taking the FFT at 23MHz, 
adding a few 0 bins to get it to 25MHz, then doing the IFFT.  You'll need to do 
some strange FFT sizes - maybe 4600 samples at the lower rate, and pad to 5000 
samples for the higher rate.  I don't think you'll need to filter, but I 
haven't gone through the exercise.  For cores like that, tho, it should be very 
fast to do an FFT followed by an IFFT with some zero's shoved into a vector, 
especially with so many cores.

Lastly, have you run fftw wisdom to get the fastest FFT performance?  That 
might be useful as well.

Let us know how your experimentation goes.  This sounds interesting.

Brian

Re: Resampling radio data

[Mark Koenig]

The BWs are 20mhz, 40mhz and 80Mhz respectively.  The host can range from a 
server with 48 cores(2.6Ghz), 256GB ram to a laptop with 8 cores(3.0Ghz), 64GB 
ram.

Get Outlook for iOS<https://aka.ms/o0ukef>

From: Brian Padalino 
Sent: Tuesday, February 16, 2021 5:17:32 PM
To: Mark Koenig 
Cc: discuss-gnuradio@gnu.org 
Subject: Re: Resampling radio data

On Tue, Feb 16, 2021 at 4:14 PM Mark Koenig 
mailto:mark.koe...@iubelttechnologies.com>> 
wrote:

Hello,



I am receiving data from a radio at 23Msps, and I would like to resample to a 
rate of 25Msps in which my software program can ingest it.  I am aware of the 
Fractional Resampler and the Rational Resampler.  Is one better than other, 
take less CPU cycles, etc.?  Is there a different block which would suit my 
needs more efficiently?  Should I instead look to implement the resampling 
within C++ as opposed to adding another block to my flowgraph?



I am going to do the above with the following rates:  46Msps -> 50Msps, 92Msps 
-> 100Msps.

How much of your bandwidth are you actually looking to keep intact?  How fast 
is your host CPU?

Brian

Resampling radio data

[Mark Koenig]

Hello,

I am receiving data from a radio at 23Msps, and I would like to resample to a 
rate of 25Msps in which my software program can ingest it.  I am aware of the 
Fractional Resampler and the Rational Resampler.  Is one better than other, 
take less CPU cycles, etc.?  Is there a different block which would suit my 
needs more efficiently?  Should I instead look to implement the resampling 
within C++ as opposed to adding another block to my flowgraph?

I am going to do the above with the following rates:  46Msps -> 50Msps, 92Msps 
-> 100Msps.

Thank you

Mark

Re: qt-gui problems with GNU 3.8

[Mark Koenig]

On more additional package, I noticed that does not currently exist the CentOS 
8 repo is ‘log4cpp’.  This package is required by GNU and how I am currently 
handling it is downloading the 
log4cpp-1.1.3.tar.gz file and manually installing the package.  This looks like 
it is working thus far.

Mark

On 11/19/19, 10:38 AM, "Müller, Marcus   (CEL)"  wrote:

That sounds like `moc` is misbehaving. Or CMake is and the Makefiles
aren't correctly regenerating all necessary files if subsets are
already there.

a) If you haven't, uninstall all potentially half-installed GNU Radios
(don't ask), purge your build folder and cmake; make -j8 again
b) If that doesn't solve it, we'll need to look at the paths: Do the
paths (starting with __ in your, I presume censored, email) look right?

Best regards,
Marcus

On Tue, 2019-11-19 at 15:31 +0000, Mark Koenig wrote:
> Marcus,
> 
> Here is some feedback regarding using the rpms you helped me create.
> 
> I can run ‘cmake’ with no errors, but running ‘make’ I see the errors 
below with respect to the qt-gui package.  Any advice on how to fix this 
problem?
> 
> Thank you
> 
> Mark
> 
> #38 2179. [ 79%] Generating 
__/include/gnuradio/qtgui/moc_spectrumdisplayform.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 79%] Generating __/include/gnuradio/qtgui/moc_displayform.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 79%] Generating 
__/include/gnuradio/qtgui/moc_timedisplayform.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 79%] Generating 
__/include/gnuradio/qtgui/moc_timecontrolpanel.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 79%] Generating 
__/include/gnuradio/qtgui/moc_timerasterdisplayform.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 79%] Generating 
__/include/gnuradio/qtgui/moc_freqdisplayform.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 79%] Generating 
__/include/gnuradio/qtgui/moc_freqcontrolpanel.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 79%] Generating 
__/include/gnuradio/qtgui/moc_constellationdisplayform.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 80%] Generating 
__/include/gnuradio/qtgui/moc_waterfalldisplayform.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 80%] Generating 
__/include/gnuradio/qtgui/moc_histogramdisplayform.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 80%] Generating 
__/include/gnuradio/qtgui/moc_numberdisplayform.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 80%] Generating 
__/include/gnuradio/qtgui/moc_vectordisplayform.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 80%] Generating __/include/gnuradio/qtgui/moc_form_menus.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 80%] Generating __/include/gnuradio/qtgui/moc_DisplayPlot.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 80%] Generating 
__/include/gnuradio/qtgui/moc_FrequencyDisplayPlot.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 80%] Generating 
__/include/gnuradio/qtgui/moc_TimeDomainDisplayPlot.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 80%] Generating 
__/include/gnuradio/qtgui/moc_TimeRasterDisplayPlot.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 80%] Generating 
__/include/gnuradio/qtgui/moc_WaterfallDisplayPlot.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 80%] Generating 
__/include/gnuradio/qtgui/moc_ConstellationDisplayPlot.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 81%] Generating 
__/include/gnuradio/qtgui/moc_HistogramDisplayPlot.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 81%] Generating 
__/include/gnuradio/qtgui/moc_VectorD

Re: qt-gui problems with GNU 3.8

[Mark Koenig]

So, I opened the docker contained and I did what you suggested (cleaning up 
make and removing the build directory) then successfully rebuilt the gnuradio 
package with the qt-gui module.

What’s odd is that if I try and do this automatically with a dockerfile, using 
the docker build command, I get the qt-gui failures. 

Any thoughts why?

Mark

On 11/19/19, 10:38 AM, "Müller, Marcus   (CEL)"  wrote:

That sounds like `moc` is misbehaving. Or CMake is and the Makefiles
aren't correctly regenerating all necessary files if subsets are
already there.

a) If you haven't, uninstall all potentially half-installed GNU Radios
(don't ask), purge your build folder and cmake; make -j8 again
b) If that doesn't solve it, we'll need to look at the paths: Do the
paths (starting with __ in your, I presume censored, email) look right?

Best regards,
Marcus

On Tue, 2019-11-19 at 15:31 +0000, Mark Koenig wrote:
> Marcus,
> 
> Here is some feedback regarding using the rpms you helped me create.
> 
> I can run ‘cmake’ with no errors, but running ‘make’ I see the errors 
below with respect to the qt-gui package.  Any advice on how to fix this 
problem?
> 
> Thank you
> 
> Mark
> 
> #38 2179. [ 79%] Generating 
__/include/gnuradio/qtgui/moc_spectrumdisplayform.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 79%] Generating __/include/gnuradio/qtgui/moc_displayform.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 79%] Generating 
__/include/gnuradio/qtgui/moc_timedisplayform.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 79%] Generating 
__/include/gnuradio/qtgui/moc_timecontrolpanel.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 79%] Generating 
__/include/gnuradio/qtgui/moc_timerasterdisplayform.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 79%] Generating 
__/include/gnuradio/qtgui/moc_freqdisplayform.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 79%] Generating 
__/include/gnuradio/qtgui/moc_freqcontrolpanel.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 79%] Generating 
__/include/gnuradio/qtgui/moc_constellationdisplayform.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 80%] Generating 
__/include/gnuradio/qtgui/moc_waterfalldisplayform.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 80%] Generating 
__/include/gnuradio/qtgui/moc_histogramdisplayform.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 80%] Generating 
__/include/gnuradio/qtgui/moc_numberdisplayform.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 80%] Generating 
__/include/gnuradio/qtgui/moc_vectordisplayform.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 80%] Generating __/include/gnuradio/qtgui/moc_form_menus.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 80%] Generating __/include/gnuradio/qtgui/moc_DisplayPlot.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 80%] Generating 
__/include/gnuradio/qtgui/moc_FrequencyDisplayPlot.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 80%] Generating 
__/include/gnuradio/qtgui/moc_TimeDomainDisplayPlot.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 80%] Generating 
__/include/gnuradio/qtgui/moc_TimeRasterDisplayPlot.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 80%] Generating 
__/include/gnuradio/qtgui/moc_WaterfallDisplayPlot.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 80%] Generating 
__/include/gnuradio/qtgui/moc_ConstellationDisplayPlot.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 81%] Generating 
__/include/gnuradio/qtgui/moc_HistogramDisplayPlot.cpp
> #38 2179. standard input:0: Note: No relevant classes found. No output 
generated.
> #38 2179. [ 81%] Gene

Re: qt-gui problems with GNU 3.8

[Mark Koenig]

ce "podman" by "docker" below) container

marcus@workstation> podman run -it --rm centos:8)

This is a very rough rundown of what I just did in a fresh CentOS 8
container:

[root@hash /]# dnf check-update; dnf install -y epel-release
[root@hash /]# dnf update -y
[root@hash /]# dnf install -y make rpm-build qt5-qt*-devel rpmdevtools
ccache
[root@hash /]# adduser mockbuild
[root@hash /]# cd
[root@hash ~]# curl -o qwt-6.1.3-11.fc31.src.rpm 

https://ftp-stud.hs-esslingen.de/pub/fedora/linux/releases/31/Everything/source/tree/Packages/q/qwt-6.1.3-11.fc31.src.rpm
[root@hash ~]# rpm -i qwt-6.1.3-11.fc31.src.rpm

I had to hunt down a lot of qt4 lines in the qwt.spec and remove them
before this builds on CentOS 8. I have just attached a diff for a
successfully building Qwt6 on the Bug that Vasil mentioned [2], so we
can try that one; continue with

[root@hash ~]# cd rpmbuild/SPECS
[root@hash SPECS]# rm qwt.spec
[root@hash SPECS]# curl -o qwt.spec 
https://bugzilla.redhat.com/attachment.cgi?id=1636615
[root@hash SPECS]# rpmbuild -bs qwt.spec
[root@hash SPECS]# cd ../SRPMS
[root@hash SRPMS]# rpmbuild -rb *.src.rpm
… wit …

This should, if the build succeeds (mine is still running), give you
qwt6-qt5 packages. Install these! 

[root@hash SRPMS]# cd ../RPMS/
[root@hash RPMS]# ls */*
noarch/qwt-doc-6.1.3-11.el8.noarch.rpm
x86_64/qwt-qt5-6.1.3-11.el8.x86_64.rpm
x86_64/qwt-qt5-devel-6.1.3-11.el8.x86_64.rpm
x86_64/qwt-debugsource-6.1.3-11.el8.x86_64.rpm
x86_64/qwt-qt5-debuginfo-6.1.3-11.el8.x86_64.rpm
[root@hash RPMS]# cd x86_64
[root@hash x86_64]# dnf install -y *

Try to build GNU Radio now!


Best regards,
Marcus

On Fri, 2019-11-15 at 21:46 +0200, Vasil Velichkov wrote:
> Hi Mark,
    > 
> On 15/11/2019 21.19, Mark Koenig wrote:
> > I am trying to build gnuradio branch maint-3.8 and I am having trouble 
getting qt-gui to enabled.  I am currently using the new distro CentOS 8, and I 
cannot find any ‘qwt’ packages.  Has anyone got gnuradio to build on CentOS 8 
yet?  I am very close to having all the modules I desire to be built and 
enabled.
> > 
> > Any help would be greatly appreciated.
> 
> The qwt package is usually available from the EPEL repositories[1] but 
there are still no package for epel8, see [2]
> 
> [1] https://fedoraproject.org/wiki/EPEL
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1751172
> 
> Regards,
> Vasil
> 

Re: qt-gui problems with GNU 3.8

[Mark Koenig]

Thanks!  I will look into this and see if it works for me.

Mark

On 11/15/19, 3:50 PM, "Müller, Marcus   (CEL)"  wrote:

Ah, it's the same old blues; need to have qt(4)-devel packaged for qwt.

(What I've tried is: Run Fedora as host, and have a podman (or docker,
as if I care, replace "podman" by "docker" below) container

marcus@workstation> podman run -it --rm centos:8)

This is a very rough rundown of what I just did in a fresh CentOS 8
container:

[root@hash /]# dnf check-update; dnf install -y epel-release
[root@hash /]# dnf update -y
[root@hash /]# dnf install -y make rpm-build qt5-qt*-devel rpmdevtools
ccache
[root@hash /]# adduser mockbuild
[root@hash /]# cd
[root@hash ~]# curl -o qwt-6.1.3-11.fc31.src.rpm 

https://ftp-stud.hs-esslingen.de/pub/fedora/linux/releases/31/Everything/source/tree/Packages/q/qwt-6.1.3-11.fc31.src.rpm
[root@hash ~]# rpm -i qwt-6.1.3-11.fc31.src.rpm

I had to hunt down a lot of qt4 lines in the qwt.spec and remove them
before this builds on CentOS 8. I have just attached a diff for a
successfully building Qwt6 on the Bug that Vasil mentioned [2], so we
can try that one; continue with

[root@hash ~]# cd rpmbuild/SPECS
[root@hash SPECS]# rm qwt.spec
[root@hash SPECS]# curl -o qwt.spec 
https://bugzilla.redhat.com/attachment.cgi?id=1636615
[root@hash SPECS]# rpmbuild -bs qwt.spec
[root@hash SPECS]# cd ../SRPMS
[root@hash SRPMS]# rpmbuild -rb *.src.rpm
… wit …

This should, if the build succeeds (mine is still running), give you
qwt6-qt5 packages. Install these! 

[root@hash SRPMS]# cd ../RPMS/
[root@hash RPMS]# ls */*
noarch/qwt-doc-6.1.3-11.el8.noarch.rpm
x86_64/qwt-qt5-6.1.3-11.el8.x86_64.rpm
x86_64/qwt-qt5-devel-6.1.3-11.el8.x86_64.rpm
x86_64/qwt-debugsource-6.1.3-11.el8.x86_64.rpm
x86_64/qwt-qt5-debuginfo-6.1.3-11.el8.x86_64.rpm
[root@hash RPMS]# cd x86_64
[root@hash x86_64]# dnf install -y *

Try to build GNU Radio now!


Best regards,
Marcus

On Fri, 2019-11-15 at 21:46 +0200, Vasil Velichkov wrote:
> Hi Mark,
    > 
> On 15/11/2019 21.19, Mark Koenig wrote:
> > I am trying to build gnuradio branch maint-3.8 and I am having trouble 
getting qt-gui to enabled.  I am currently using the new distro CentOS 8, and I 
cannot find any ‘qwt’ packages.  Has anyone got gnuradio to build on CentOS 8 
yet?  I am very close to having all the modules I desire to be built and 
enabled.
> > 
> > Any help would be greatly appreciated.
> 
> The qwt package is usually available from the EPEL repositories[1] but 
there are still no package for epel8, see [2]
> 
> [1] https://fedoraproject.org/wiki/EPEL
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1751172
> 
> Regards,
> Vasil
> 

qt-gui problems with GNU 3.8

[Mark Koenig]

I am trying to build gnuradio branch maint-3.8 and I am having trouble getting 
qt-gui to enabled.  I am currently using the new distro CentOS 8, and I cannot 
find any ‘qwt’ packages.  Has anyone got gnuradio to build on CentOS 8 yet?  I 
am very close to having all the modules I desire to be built and enabled.

Any help would be greatly appreciated.

Mark

Here is the cmake error output for qt-gui.

-- Python checking for PyQt5 - found
-- Checking for module 'Qt5Qwt6'
--   Package 'Qt5Qwt6', required by 'virtual:world', not found
-- 
-- Configuring gr-qtgui support...
--   Dependency Boost_FOUND = 1
--   Dependency QT_FOUND = 1
--   Dependency QWT_FOUND = FALSE
--   Dependency ENABLE_VOLK = TRUE
--   Dependency ENABLE_GNURADIO_RUNTIME = ON
--   Dependency ENABLE_GR_FFT = ON
--   Dependency ENABLE_GR_FILTER = ON
--   Dependency PYTHONLIBS_FOUND = TRUE
--   Dependency PYQT5_FOUND = TRUE
--   Disabling gr-qtgui support.
--   Override with -DENABLE_GR_QTGUI=ON/OFF

Here are my final modules enabled ad disabled.

-- # Gnuradio enabled components 
-- ##
--   * python-support
--   * testing-support
--   * doxygen
--   * gnuradio-runtime
--   * gr-ctrlport
--   * * thrift
--   * gnuradio-companion
--   * gr-blocks
--   * gr-fec
--   * gr-fft
--   * gr-filter
--   * gr-analog
--   * gr-digital
--   * gr-dtv
--   * gr-audio
--   * * oss
--   * gr-channels
--   * gr-trellis
--   * gr-uhd
--   * gr-utils
--   * gr_modtool
--   * gr-vocoder
--   * gr-wavelet
-- 
-- ##
-- # Gnuradio disabled components
-- ##
--   * sphinx
--   * gr-qtgui
--   * gr-video-sdl
--   * gr-zeromq
-- 


 

[Discuss-gnuradio] GNU 3.8 OOT module problem

[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 with gnuradio 3.8 and python 3

[Mark Koenig]

Michael,

On line 37, I see the following text.

set(ENABLE_PYTHON ON CACHE BOOL “Enable Python & Swig”)

So it looks like it is enabled.

I added ‘include(GrPython)’ to my CMakeLists.txt file and now it is pulling the 
wrong python interpreter.  I want to use Python 3.

#9 2.642 -- Found PythonInterp: /usr/bin/python (found version "2.7.15")
#9 2.652 -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found 
suitable exact version "2.7.15+")
#9 2.688 -- Found SWIG: /usr/bin/swig3.0 (found version "3.0.12")
#9 2.693 -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found 
version "2.7.15+")

Further down my dockerfile output I am seeing the following, which I believe is 
because CMake is using the wrong python interpreter.

-- Checking for module 'thrift'
#9 3.454 --   Found thrift, version 0.10.0
#9 3.553 -- Python checking for Thrift - not found
#9 3.555 -- Could NOT find THRIFT (missing: PYTHON_THRIFT_FOUND THRIFT_FOUND)
#9 3.561 CMake Warning at CMakeLists.txt:24 (find_package):
#9 3.561   Found package configuration file:
#9 3.561
#9 3.561 /opt/truearrow/6.3/lib/cmake/gnuradio/GnuradioConfig.cmake
#9 3.561
#9 3.561   but it set Gnuradio_FOUND to FALSE so package "Gnuradio" is 
considered to
#9 3.561   be NOT FOUND.  Reason given by package:
#9 3.561
#9 3.561   The following imported targets are referenced, but are missing:
#9 3.561   gnuradio::gnuradio-runtime


Any help would be greatly appreciated.

From: Michael Dickens 
Date: Monday, September 16, 2019 at 5:21 PM
To: Mark Koenig 
Cc: "discuss-gnuradio@gnu.org" 
Subject: Re: [Discuss-gnuradio] Error with gnuradio 3.8 and python 3

Hi Mark - Interesting issue. Is SWIG/Python -not- enabled in your GR install? 
Following the code, that could cause the error you're seeing. If you look 
through the file "/opt/truearrow/6.3/lib/cmake/gnuradio/GnuradioConfig.cmake", 
line 37 will show whether ENABLE_PYTHON is enabled or not. - MLD

On Mon, Sep 16, 2019 at 2:57 PM Mark Koenig 
mailto:mark.koe...@iubelttechnologies.com>> 
wrote:
Hello,

I am trying to build a module and I keep seeing the error below during cmake.  
Any deas?

#9 3.713 -- Found VOLK: Volk::volk
#9 3.729 -- Checking for module 'thrift'
#9 3.761 --   Found thrift, version 0.10.0
#9 3.840 CMake Error at 
/opt/truearrow/6.3/lib/cmake/gnuradio/FindTHRIFT.cmake:68 
(GR_PYTHON_CHECK_MODULE):
#9 3.840   Unknown CMake command "GR_PYTHON_CHECK_MODULE".
#9 3.840 Call Stack (most recent call first):
#9 3.840   /usr/share/cmake-3.10/Modules/CMakeFindDependencyMacro.cmake:48 
(find_package)
#9 3.840   
/opt/truearrow/6.3/lib/cmake/gnuradio/gnuradio-runtimeConfig.cmake:24 
(find_dependency)
#9 3.840   /opt/truearrow/6.3/lib/cmake/gnuradio/GnuradioConfig.cmake:45 
(include)
#9 3.840   CMakeLists.txt:23 (find_package)
#9 3.840
#9 3.840
#9 3.842 -- Configuring incomplete, errors occurred!
#9 3.842 See also "/workspaces/ta/gr-vrt/Release/CMakeFiles/CMakeOutput.log".
#9 3.842 See also "/workspaces/ta/gr-vrt/Release/CMakeFiles/CMakeError.log".
#9 3.849 [ Build gr-vrt (Release) FAILED with error code 1 ]


Thank you

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


--
Michael Dickens, Mac OS X Programmer

Ettus Research Technical Support

Email: supp...@ettus.com<mailto: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] Error with gnuradio 3.8 and python 3

[Mark Koenig]

Hello,

I am trying to build a module and I keep seeing the error below during cmake.  
Any deas?

#9 3.713 -- Found VOLK: Volk::volk
#9 3.729 -- Checking for module 'thrift'
#9 3.761 --   Found thrift, version 0.10.0
#9 3.840 CMake Error at 
/opt/truearrow/6.3/lib/cmake/gnuradio/FindTHRIFT.cmake:68 
(GR_PYTHON_CHECK_MODULE):
#9 3.840   Unknown CMake command "GR_PYTHON_CHECK_MODULE".
#9 3.840 Call Stack (most recent call first):
#9 3.840   /usr/share/cmake-3.10/Modules/CMakeFindDependencyMacro.cmake:48 
(find_package)
#9 3.840   
/opt/truearrow/6.3/lib/cmake/gnuradio/gnuradio-runtimeConfig.cmake:24 
(find_dependency)
#9 3.840   /opt/truearrow/6.3/lib/cmake/gnuradio/GnuradioConfig.cmake:45 
(include)
#9 3.840   CMakeLists.txt:23 (find_package)
#9 3.840
#9 3.840
#9 3.842 -- Configuring incomplete, errors occurred!
#9 3.842 See also "/workspaces/ta/gr-vrt/Release/CMakeFiles/CMakeOutput.log".
#9 3.842 See also "/workspaces/ta/gr-vrt/Release/CMakeFiles/CMakeError.log".
#9 3.849 [ Build gr-vrt (Release) FAILED with error code 1 ]


Thank you

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

Re: [Discuss-gnuradio] Control Port Thrift Issues

[Mark Koenig]

Marcus,

I am using CentOS 7.2, Thrift 0.9.2 and GNU 3.7.11.

Mark

On 9/15/17, 12:02 PM, "Discuss-gnuradio on behalf of 
discuss-gnuradio-requ...@gnu.org" 
<discuss-gnuradio-bounces+mark.koenig=iubelttechnologies@gnu.org on behalf 
of 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. Re: Control Port Thrift Issues (Marcus M?ller)
   2. Tonight: Cyberspectrum Software Defined Radio Meetup (San
  Diego, Thu Sept 14th, 6:30PM PT) (Balint Seeber)
   3. Re: Time sinks out of sync after adding and removing noise in
  simple FSK simulation (James Wanga)
   4. Re: Recent change in destructor behavior? (Dmitry Kramarev)


--

Message: 1
Date: Thu, 14 Sep 2017 19:31:36 +0200
From: Marcus M?ller <marcus.muel...@ettus.com>
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Control Port Thrift Issues
Message-ID: <25f98175-1668-5048-eff8-ce4460f1d...@ettus.com>
Content-Type: text/plain; charset=windows-1252

OK, so we'll tackle this headon :)

So, we'll need to talk about the specific GNU Radio version you're
compiling, the exact-as-possible thrift version. Maybe also the
OS/distro version.

Admittedly, I'm at GRCon right now, and it might be minimally
non-trivial to just set up a container/VM to reproduce, but maybe
looking at the code alone suffices!

Best regards,

Marcus

    On 09/14/2017 02:17 PM, Mark Koenig wrote:
> Hi Marcus,
>
> I do believe I need control ports active.  I am using GNUradio as the 
framework for some code that I believe uses control ports.
>
> Mark
>
>
> On 9/14/17, 3:10 AM, "Discuss-gnuradio on behalf of 
discuss-gnuradio-requ...@gnu.org" 
<discuss-gnuradio-bounces+mark.koenig=iubelttechnologies@gnu.org on behalf 
of 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. How to create uhd's time_spec_t from Python (Piotr Krysik)
>2. Re: Control Port Thrift Issues (Marcus M?ller)
>3. Re: How to create uhd's time_spec_t from Python (Marcus M?ller)
>4. Re: Synchronisation (John Shields)
>5. [SOCIS '17] GRC C++ Output: Week 7 (H?kon V?gsether)
>6. Time sinks out of sync after adding and removing noise in
>   simple FSK simulation (James Wanga)
> 
> 
> --
> 
> Message: 1
> Date: Wed, 13 Sep 2017 19:08:36 +0200
> From: Piotr Krysik <per...@o2.pl>
> To: GNURadio Discussion List <discuss-gnuradio@gnu.org>
> Subject: [Discuss-gnuradio] How to create uhd's time_spec_t from
>   Python
> Message-ID: <7edcc791-5aa7-908a-58ae-3e306580c...@o2.pl>
> Content-Type: text/plain; charset=utf-8
> 
> Hi All,
> 
> time_spec_t is a class representing time in UHD. It uses time_t (long
> int) for representing full seconds and double for parts of a second.
> This format of time is usable to tell USRPs when to do certain tasks. 
It
> is also very usable for operations on time without loosing precision.
> 
> In c++ time_spec_t can be constructed from time represented by a 
double
> (not precise if number of full seconds is large)

Re: [Discuss-gnuradio] Control Port Thrift Issues

[Mark Koenig]

Hi Marcus,

I do believe I need control ports active.  I am using GNUradio as the framework 
for some code that I believe uses control ports.

Mark


On 9/14/17, 3:10 AM, "Discuss-gnuradio on behalf of 
discuss-gnuradio-requ...@gnu.org" 
<discuss-gnuradio-bounces+mark.koenig=iubelttechnologies@gnu.org on behalf 
of 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. How to create uhd's time_spec_t from Python (Piotr Krysik)
   2. Re: Control Port Thrift Issues (Marcus M?ller)
   3. Re: How to create uhd's time_spec_t from Python (Marcus M?ller)
   4. Re: Synchronisation (John Shields)
   5. [SOCIS '17] GRC C++ Output: Week 7 (H?kon V?gsether)
   6. Time sinks out of sync after adding and removing noise in
  simple FSK simulation (James Wanga)


--

Message: 1
Date: Wed, 13 Sep 2017 19:08:36 +0200
From: Piotr Krysik <per...@o2.pl>
To: GNURadio Discussion List <discuss-gnuradio@gnu.org>
Subject: [Discuss-gnuradio] How to create uhd's time_spec_t from
Python
Message-ID: <7edcc791-5aa7-908a-58ae-3e306580c...@o2.pl>
Content-Type: text/plain; charset=utf-8

Hi All,

time_spec_t is a class representing time in UHD. It uses time_t (long
int) for representing full seconds and double for parts of a second.
This format of time is usable to tell USRPs when to do certain tasks. It
is also very usable for operations on time without loosing precision.

In c++ time_spec_t can be constructed from time represented by a double
(not precise if number of full seconds is large) or from time_t and
double. Both constructors are exposed by SWIG in Python.

When I construct time_spec from double everything is fine:

>>> from gnuradio import uhd
>>> uhd.time_spec(10)

But when I construct from int and float I get an error:

>>> uhd.time_spec(10,0.1)
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line
1576, in __init__
this = _uhd_swig.new_time_spec_t(*args)
NotImplementedError: Wrong number or type of arguments for overloaded
function 'new_time_spec_t'.
  Possible C/C++ prototypes are:
uhd::time_spec_t::time_spec_t(double)
uhd::time_spec_t::time_spec_t(time_t,double)
uhd::time_spec_t::time_spec_t(time_t,long,double)

Somehow Python's integer is not recognized as compatible with time_t
parameter in the second constructor
(uhd::time_spec_t::time_spec_t(time_t,double) ).

My question:
Is there a way to use time_spec_t's constructor
uhd::time_spec_t::time_spec_t(time_t,double) from Python interface
exposed by GNU Radio? In my opinion there should be, otherwise why to
expose it through SWIG.

--
Best Regards,
Piotr Krysik




--

Message: 2
Date: Wed, 13 Sep 2017 19:54:47 +0200
From: Marcus M?ller <marcus.muel...@ettus.com>
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Control Port Thrift Issues
Message-ID: <26b13e91-3b19-c721-4f0c-ae6c16856...@ettus.com>
Content-Type: text/plain; charset="windows-1252"

Hi Mark,

We can look at that in-depth, but in spirit of keeping this as
time-effective as possible for you: Do you *need* controlport (it's a
system to remotely access statistics and specifics knobs and levers in
GNU Radio)? Many (most) users don't really.

Best regards,

Marcus


On 09/13/2017 04:41 PM, Mark Koenig wrote:
>
> I am seeing an error during ?Make? and it has to do with the
> controlport and thrift?.not sure what is going on.  Any help would be
> appreciated.
>
>  
>
> Thanks
>
>  
>
> Mark
>
>  
>
>  
>
> After running ?Make? I see the following error:
>
>  
>
> [ 11%] Building CXX object
> 
gnuradio-runtime/lib/CMakeFiles/gnuradio-runtime.dir/controlport/thrift/rpcserver_booter_thrift.cc.o
>
   

[Discuss-gnuradio] Control Port Thrift Issues

[Mark Koenig]

I am seeing an error during “Make” and it has to do with the controlport and 
thrift….not sure what is going on.  Any help would be appreciated.

Thanks

Mark


After running “Make” I see the following error:

[ 11%] Building CXX object 
gnuradio-runtime/lib/CMakeFiles/gnuradio-runtime.dir/controlport/thrift/rpcserver_booter_thrift.cc.o
/usr/local/truearrow_6_0_0_0/deploypkg/target/src/gnuradio/gnuradio-runtime/lib/controlport/thrift/rpcserver_booter_thrift.cc:
 In member function ‘bool thrift_application_base::application_started()’:
/usr/local/truearrow_6_0_0_0/deploypkg/target/src/gnuradio/gnuradio-runtime/lib/controlport/thrift/rpcserver_booter_thrift.cc:117:78:
 error: ‘class apache::thrift::transport::TServerSocket’ has no member named 
‘getPort’
   int used_port = 
((apache::thrift::transport::TServerSocket*)thetransport)->getPort();
  ^
make[2]: *** 
[gnuradio-runtime/lib/CMakeFiles/gnuradio-runtime.dir/controlport/thrift/rpcserver_booter_thrift.cc.o]
 Error 1
make[1]: *** [gnuradio-runtime/lib/CMakeFiles/gnuradio-runtime.dir/all] Error 2
make: *** [all] Error 2

I don’t get any errors during cmake, my ouput is below.

-- ##
-- # Gnuradio enabled components
-- ##
--   * python-support
--   * testing-support
--   * volk
--   * doxygen
--   * sphinx
--   * gnuradio-runtime
--   * gr-ctrlport
--   * * thrift
--   * gr-blocks
--   * gnuradio-companion
--   * gr-fec
--   * gr-fft
--   * gr-filter
--   * gr-analog
--   * gr-digital
--   * gr-dtv
--   * gr-atsc
--   * gr-audio
--   * * alsa
--   * * oss
--   * gr-channels
--   * gr-noaa
--   * gr-pager
--   * gr-qtgui
--   * gr-trellis
--   * gr-uhd
--   * gr-utils
--   * gr-video-sdl
--   * gr-vocoder
--   * gr-fcd
--   * gr-wavelet
--   * gr-wxgui
--   * gr-zeromq
--
-- ##
-- # Gnuradio disabled components
-- ##
--   * gr-comedi
--
-- Using install prefix: /usr/local/truearrow_6_0_0_0/deploypkg/target
-- Building for version: 3.7.10.1 / 3.7.10.1
-- Configuring done
-- Generating done
-- Build files have been written to: 
/usr/local/truearrow_6_0_0_0/deploypkg/target/src/gnuradio/build

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