Send Discuss-gnuradio mailing list submissions
to
address@hidden
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
address@hidden
You can reach the person managing the list at
address@hidden
When replying, please edit your Subject line so it is more
specific
than "Re: Contents of Discuss-gnuradio digest..."
Today's Topics:
1. Replacement for packet encoder/decoder (Damindra
Bandara)
2. Re: Block Thread question (Marcus M?ller)
3. Re: Block Thread question (Garver, Paul W)
4. Re: Fwd: Correlation Estimator in 3.7.10 (devin
kelly)
5. Re: Fwd: Correlation Estimator in 3.7.10 (Steven
Knudsen)
6. UHD/gnuradio on CentOS 7 install problems (Chad M.
Spooner)
7. Re: UHD/gnuradio on CentOS 7 install problems
(Marcus M?ller)
8. Re: UHD/gnuradio on CentOS 7 install problems
(Martin Braun)
----------------------------------------------------------------------
Message: 1
Date: Tue, 4 Oct 2016 12:40:10 -0400
From: Damindra Bandara <
address@hidden>
To:
address@hidden
Subject: [Discuss-gnuradio] Replacement for packet
encoder/decoder
Message-ID:
<
address@hidden>
Content-Type: text/plain; charset="utf-8"
Hi,
I have a flowgraph that uses packet encoder at the
transmitter end and a
decoder at the receiver end. I updated GNURadio to the
latest version and
saw that the packet encoder/decoder are marked as
deprecated. My current
work flows are as follows.
TX end: message source-->packet
encoder-->modulator-->USRP sink
RX end : USRP source --> synchronization blocks(for
phase modulation)-->
demodulator--> packet decoder--> message sink
Is there a replacement for packet encoder/decoder in the
latest version? I
appreciate if you could give me some information regarding
this.
Thank you,
Damindra
--
Damindra Savithri Bandara,
Ph.D. in Information Technology (Candidate)
George Mason University,
Fairfax,
Virginia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20161004/75f11fab/attachment.html>
------------------------------
Message: 2
Date: Tue, 4 Oct 2016 09:44:05 -0700
From: Marcus M?ller <
address@hidden>
To:
address@hidden
Subject: Re: [Discuss-gnuradio] Block Thread question
Message-ID: <
address@hidden>
Content-Type: text/plain; charset="windows-1252"
Hi Jake,
yes, that's true: The block_executer practically goes
through an endless
loop between handling input samples with (general_)work
and handling
messages with the registered message handler. The whole
point of that is
that you can send a message that would (logically) change
something in
the operation of the block, and it will never interfere
with the
operation of work ? thread-safety! (imagine, for example,
you changed
the number of taps of a FIR filter right in the middle of
that filter's
operation ? that would definitely lead to some unexpected
results).
Best regards,
Marcus
On 10/04/2016 08:09 AM, Gavin Jacobs wrote:
I am writing a block which takes a PDU input and
produces a stream
output. I used a source block template with zero stream
inputs, one
message input, and one stream output. I have implemented
a message
handler and I can see my messages are being received. I
need to pass
data from the PDU message handler to work(). I looked at
the code for
PDU_to_tagged_stream and it appears that they use a
private member
(d_curr_len) to communicate from the message handler to
work - which
implies that the message handler and work are on the
same thread. Is
this correct? i.e. can I use a plain FIFO queue from
message handler
to work, or do I need a thread safe queue?
Thanks,
Jake
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20161004/985cacb3/attachment.html>
------------------------------
Message: 3
Date: Tue, 4 Oct 2016 17:35:34 +0000
From: "Garver, Paul W" <
address@hidden>
To: Marcus M?ller <
address@hidden>
Cc: "
address@hidden"
<
address@hidden>
Subject: Re: [Discuss-gnuradio] Block Thread question
Message-ID: <
address@hidden>
Content-Type: text/plain; charset="windows-1252"
Does you block take the packet length as a parameter (vs.
reading from metadata)? I think this is a block which
should exist in the GR baseline, if your implementation is
general enough.
PWG
On Oct 4, 2016, at 12:44 PM, Marcus M?ller <
address@hidden<mailto:
address@hidden>>
wrote:
Hi Jake,
yes, that's true: The block_executer practically goes
through an endless loop between handling input samples
with (general_)work and handling messages with the
registered message handler. The whole point of that is
that you can send a message that would (logically) change
something in the operation of the block, and it will never
interfere with the operation of work ? thread-safety!
(imagine, for example, you changed the number of taps of a
FIR filter right in the middle of that filter's operation
? that would definitely lead to some unexpected results).
Best regards,
Marcus
On 10/04/2016 08:09 AM, Gavin Jacobs wrote:
I am writing a block which takes a PDU input and produces
a stream output. I used a source block template with zero
stream inputs, one message input, and one stream output. I
have implemented a message handler and I can see my
messages are being received. I need to pass data from the
PDU message handler to work(). I looked at the code for
PDU_to_tagged_stream and it appears that they use a
private member (d_curr_len) to communicate from the
message handler to work - which implies that the message
handler and work are on the same thread. Is this correct?
i.e. can I use a plain FIFO queue from message handler to
work, or do I need a thread safe queue?
Thanks,
Jake
_______________________________________________
Discuss-gnuradio mailing list
address@hidden<mailto:
address@hidden>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden<mailto:
address@hidden>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20161004/f3864ea7/attachment.html>
------------------------------
Message: 4
Date: Tue, 4 Oct 2016 15:31:20 -0400
From: devin kelly <
address@hidden>
To: Steven Knudsen <
address@hidden>
Cc: GNURadio Discussion List <
address@hidden>,
Knud
<
address@hidden>
Subject: Re: [Discuss-gnuradio] Fwd: Correlation Estimator
in 3.7.10
Message-ID:
<
address@hidden>
Content-Type: text/plain; charset="utf-8"
Steven,
I've had the exact same problem as you - my flowgraphs
from 3.7.9 worked
well but now I'm getting a lot of false detections from
this block.
Is this really how this block is supposed to perform? We
just have to use
trial and error to find the right threshold?
Thanks For Any Help,
Devin
On Tue, Sep 27, 2016 at 11:37 AM, Steven Knudsen <
address@hidden>
wrote:
Alright,
after some more thought I believe I understand what is
going on.
By looking at the cross-correlation power for the
current input samples,
the threshold can be calculated as a desired false alarm
rate. An
?arbitrary? threshold can be set independently of the
received signal power.
Unfortunately, for the test_corr_est.grc example, you
just can?t set the
threshold high enough to avoid false alarms. I tried the
CE block with up
to 0.999999 for the threshold and it was still a mess,
though much better.
That said, for my own application/flowgraph, setting the
CE block
threshold to 0.9999 appears to work. I can set as ?low?
as 0.999, but
that?s it.
This makes me wonder why bother to have a threshold
parameter at all?
Maybe just set the calculated d_pfa value to 10 or
something and be done
with it. Of course, we all hate magic numbers, and so
doing would introduce
a second number to the algorithm (the first is a
multiplier of 4 in the
peak thresholding logic).
Thanks for your patience?
Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
www.linkedin.com/in/knudstevenknudsen
*Von einem gewissen Punkt an gibt es keine R?ckkehr
mehr. Dieser Punkt ist
zu erreichen. - Franz Kafka*
Begin forwarded message:
*From: *Steven Knudsen <address@hidden>
*Subject: **Correlation Estimator in 3.7.10*
*Date: *September 27, 2016 at 07:40:17 MDT
*To: *GNURadio Discussion List <address@hidden>
*Cc: *Knud <address@hidden>
Hi All,
I am pretty confused with some of the changes to the
corr_est_cc_impl.cc
threshold detection algorithm.
Previously, in _set_threshold(), the zero-offset
autocorrelation of the
reference symbols was computed and scaled by the desired
relative threshold
when the correlation estimator is instantiated to
provide a fixed (constant
for the run) threshold (d_thresh). That makes sense to
me and appeared to
work pretty well.
Now, in _set_threshold(), a XXXX is calculated as d_pfa
= -logf(1.0f -
threshold) . In the work function, the detection
threshold is calculated
anew on each invocation as the mean value of the square
of the current
correlation of the reference symbols with the input
symbols, scaled by
d_pfa.
How can the threshold for detecting the peak of the
correlation against
the reference symbols be a function of the input
symbols? I know that using
an absolute threshold based on only the reference
symbols may be a problem
because you can?t know the magnitude of the received
input symbols, but I
think that?s why there is a block callback for
set_threshold().
The net result is that when one runs the correlation
estimator, a bunch of
peaks are output in the vicinity of the sync sequence in
the input stream.
The test_corr_est.grc example in gr-digital shows this
well.
I checked the commit history and the only relevant
comment is ?Works with
arbitrary scaling?. This suggests that the changes are
meant to include
in the threshold the effect of arbitrary input signal
power, which does
make some sense. Again, I thought that was why there was
a callback, but
even that is clunky and I could be wrong.
Anyway, all I know is that the correlation estimator
used to work really
well for me and is now, in my applications, broken
badly. Maybe I?m not
setting it up correctly, but AFAIK the block parameters
are the same.
Thanks for your consideration of this question,
steven
Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
www.linkedin.com/in/knudstevenknudsen
*All the wires are cut, my friendsLive beyond the
severed ends. Louis
MacNeice*
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20161004/fb475eec/attachment.html>
------------------------------
Message: 5
Date: Tue, 4 Oct 2016 14:23:24 -0600
From: Steven Knudsen <
address@hidden>
To: devin kelly <
address@hidden>
Cc: GNURadio Discussion List <
address@hidden>
Subject: Re: [Discuss-gnuradio] Fwd: Correlation Estimator
in 3.7.10
Message-ID: <
address@hidden>
Content-Type: text/plain; charset="utf-8"
Hey Dean,
For what it?s worth, I?ve resorted to two hacks.
1) where the sum of consecutive correlation mag squared
samples is compared to 4*detection, I?ve gone to
8*detection. With the block threshold set to 0.999999,
this results in threshold levels (compared to the peak
correlation value) of 32 to 78 %.
2) I added a variable to track the max cross-correlation
magnitude for samples that exceed the 8*detection
threshold. Then i compare those (peak) samples to that
max/4 and those that are above, I let pass.
I had to do the latter because I was seeing false
correlations at the very end of my TDMA packets. I think
they are due to the tx-to-rx transient I see with my
B200mini. My thought is that the transient is slow (looks
like a DC offset) and may create a false peak when part of
it is convolved with the reference sync sequence. Anyway,
implementing #2 made that problem go away.
The other thought I have for my particular application is
to disabled the Correlation Estimator (CE) when I know
there will be no sync sequence. Since I have a TDMA system
with a GPSDO/clock governing the slot scheme, I can
generate an ?enable? pulse from my MAC and use it to
control the CE block.
The big flaw with my approach in 1) and 2) is that I am
not accounting for variable receive power such as you?d
expect in a multi-radio TDMA system? first things first,
though, gotta see packets received reliably under Tx
constant power.
Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
www.linkedin.com/in/knudstevenknudsen
Der entscheidende Augenblick der menschlichen Entwicklung
ist immerw?hrend. Darum sind die revolution?ren geistigen
Bewegungen, welche alles Fr?here f?r nichtig erkl?ren, im
Recht, denn es ist noch nichts geschehen. - Franz Kafka
On Oct 4,
2016, at 13:31, devin kelly <address@hidden>
wrote:
Steven,
I've had the exact same problem as you - my flowgraphs
from 3.7.9 worked well but now I'm getting a lot of
false detections from this block.
Is this really how this block is supposed to perform?
We just have to use trial and error to find the right
threshold?
Thanks For Any Help,
Devin
On Tue, Sep 27, 2016 at 11:37 AM, Steven Knudsen <address@hidden
<mailto:address@hidden>>
wrote:
Alright, after some more thought I believe I understand
what is going on.
By looking at the cross-correlation power for the
current input samples, the threshold can be calculated
as a desired false alarm rate. An ?arbitrary? threshold
can be set independently of the received signal power.
Unfortunately, for the test_corr_est.grc example, you
just can?t set the threshold high enough to avoid false
alarms. I tried the CE block with up to 0.999999 for the
threshold and it was still a mess, though much better.
That said, for my own application/flowgraph, setting the
CE block threshold to 0.9999 appears to work. I can set
as ?low? as 0.999, but that?s it.
This makes me wonder why bother to have a threshold
parameter at all? Maybe just set the calculated d_pfa
value to 10 or something and be done with it. Of course,
we all hate magic numbers, and so doing would introduce
a second number to the algorithm (the first is a
multiplier of 4 in the peak thresholding logic).
Thanks for your patience?
Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca <http://techconficio.ca/>
www.linkedin.com/in/knudstevenknudsen
<http://www.linkedin.com/in/knudstevenknudsen>
Von einem gewissen Punkt an gibt es keine R?ckkehr mehr.
Dieser Punkt ist zu erreichen. - Franz Kafka
Begin
forwarded message:
From: Steven Knudsen <address@hidden
<mailto:address@hidden>>
Subject: Correlation Estimator in 3.7.10
Date: September 27, 2016 at 07:40:17 MDT
To: GNURadio Discussion List <address@hidden
<mailto:address@hidden>>
Cc: Knud <address@hidden
<mailto:address@hidden>>
Hi All,
I am pretty confused with some of the changes to the
corr_est_cc_impl.cc threshold detection algorithm.
Previously, in _set_threshold(), the zero-offset
autocorrelation of the reference symbols was computed
and scaled by the desired relative threshold when the
correlation estimator is instantiated to provide a
fixed (constant for the run) threshold (d_thresh).
That makes sense to me and appeared to work pretty
well.
Now, in _set_threshold(), a XXXX is calculated as
d_pfa = -logf(1.0f - threshold) . In the work
function, the detection threshold is calculated anew
on each invocation as the mean value of the square of
the current correlation of the reference symbols with
the input symbols, scaled by d_pfa.
How can the threshold for detecting the peak of the
correlation against the reference symbols be a
function of the input symbols? I know that using an
absolute threshold based on only the reference symbols
may be a problem because you can?t know the magnitude
of the received input symbols, but I think that?s why
there is a block callback for set_threshold().
The net result is that when one runs the correlation
estimator, a bunch of peaks are output in the vicinity
of the sync sequence in the input stream. The
test_corr_est.grc example in gr-digital shows this
well.
I checked the commit history and the only relevant
comment is ?Works with arbitrary scaling?. This
suggests that the changes are meant to include in the
threshold the effect of arbitrary input signal power,
which does make some sense. Again, I thought that was
why there was a callback, but even that is clunky and
I could be wrong.
Anyway, all I know is that the correlation estimator
used to work really well for me and is now, in my
applications, broken badly. Maybe I?m not setting it
up correctly, but AFAIK the block parameters are the
same.
Thanks for your consideration of this question,
steven
Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca <http://techconficio.ca/>
www.linkedin.com/in/knudstevenknudsen
<http://www.linkedin.com/in/knudstevenknudsen>
All the wires are cut, my friends
Live beyond the severed ends. Louis MacNeice
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
<mailto:address@hidden>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20161004/5a23c534/attachment.html>
------------------------------
Message: 6
Date: Tue, 04 Oct 2016 13:23:20 -0700
From: "Chad M. Spooner" <
address@hidden>
To:
address@hidden
Subject: [Discuss-gnuradio] UHD/gnuradio on CentOS 7
install problems
Message-ID: <
address@hidden>
Content-Type: text/plain; charset="us-ascii"
Forum:
I'm trying to get gnuradio/UHD up on a CentOS 7 machine.
I've made a lot
of progress, but have a problem I can't understand.
I'll provide details below, but the error message is
obtained during the
attempted installation of wxpython. It is a compiler
error. The first
error that appears is:
---------------------------------------------------------------------------
/usr/local/gnuradio/src/wxpython/bk-deps g++ -c -o
coredll_imagpng.o
-I./.pch/wxprec_coredll -D__WXGTK__ -DWXBUILDING
-I./src/tiff
-I./src/jpeg -DWXUSINGDLL -DWXMAKINGDLL_CORE
-DwxUSE_BASE=0 -fPIC -DPIC
-D_FILE_OFFSET_BITS=64 -D_LARGE_FILES
-I/usr/local/gnuradio/src/wxpython/lib/wx/include/gtk2-ansi-release-2.8
-I./include -pthread -I/usr/include/gtk-2.0
-I/usr/lib64/gtk-2.0/include
-I/usr/include/atk-1.0 -I/usr/include/cairo
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/pixman-1 -I/usr/include/freetype2
-I/usr/include/libpng15
-I/usr/include/libdrm -I/usr/include/harfbuzz -DWX_PRECOMP
-pthread
-Wall -Wundef -Wno-ctor-dtor-privacy -O2
-fno-strict-aliasing
./src/common/imagpng.cpp
./src/common/imagpng.cpp: In member function 'virtual bool
wxPNGHandler::LoadFile(wxImage*, wxInputStream&, bool,
int)':
./src/common/imagpng.cpp:532:30: error: 'voidp' was not
declared in this
scope
(voidp) NULL,
^
-------------------------------------------------------------------------------------------
Machine: HP Z Book G3 running CentOS 7, kernel
3.10.0-327.36.1.el7.x86_64 #1 SMP.
PyBOMBS: Version 2.2.0
Python: Version 3.5.2
pip: pip 8.1.2 from /usr/local/lib/python3.5/site-packages
(python 3.5)
gcc: gcc version 4.8.5 20150623 (Red Hat 4.8.5-4) (GCC)
Here is the command line I used to try to install gnuradio
and UHD:
pybombs prefix init /usr/local/gnuradio -a gnuradio -R
gnuradio-default
I've attached the full text log of what appeared on the
screen after I
issued that command.
(I've got UHD running under Ubuntu 16.04 and Fedora Core
24, but since
CentOS is residing on a very fast SSD and I need fast I/O,
I was hoping
to get UHD (at least) going on CentOS too.)
Thanks for any advice anybody might have.
Chad
--
Chad M. Spooner, PhD
NorthWest Research Associates
301 Webster Street
Monterey, CA 93940
address@hidden
cell: (831) 521 6743
office: (831) 582 4904
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20161004/b19a4ad4/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gnuradio_uhd_install_log.txt
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20161004/b19a4ad4/attachment.txt>
------------------------------
Message: 7
Date: Tue, 4 Oct 2016 13:56:41 -0700
From: Marcus M?ller <
address@hidden>
To:
address@hidden
Subject: Re: [Discuss-gnuradio] UHD/gnuradio on CentOS 7
install
problems
Message-ID: <
address@hidden>
Content-Type: text/plain; charset="windows-1252"
Hi Chad,
the question I'd ask here is:
Do you *really* need WxGUI support? It's going away with
GNU Radio 3.8,
and if you remove the Wx dependency from the GNU Radio
package, GNU
Radio will build just as well, but you'll only be
presented with the
actively maintained QtGUI.
Best regards,
Marcus
On 10/04/2016 01:23 PM, Chad M. Spooner wrote:
Forum:
I'm trying to get gnuradio/UHD up on a CentOS 7 machine.
I've made a
lot of progress, but have a problem I can't understand.
I'll provide details below, but the error message is
obtained during
the attempted installation of wxpython. It is a compiler
error. The
first error that appears is:
---------------------------------------------------------------------------
/usr/local/gnuradio/src/wxpython/bk-deps g++ -c -o
coredll_imagpng.o
-I./.pch/wxprec_coredll -D__WXGTK__ -DWXBUILDING
-I./src/tiff
-I./src/jpeg -DWXUSINGDLL -DWXMAKINGDLL_CORE
-DwxUSE_BASE=0 -fPIC
-DPIC -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES
-I/usr/local/gnuradio/src/wxpython/lib/wx/include/gtk2-ansi-release-2.8
-I./include -pthread -I/usr/include/gtk-2.0
-I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0
-I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0
-I/usr/include/pango-1.0 -I/usr/include/glib-2.0
-I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1
-I/usr/include/freetype2 -I/usr/include/libpng15
-I/usr/include/libdrm
-I/usr/include/harfbuzz -DWX_PRECOMP -pthread -Wall
-Wundef
-Wno-ctor-dtor-privacy -O2 -fno-strict-aliasing
./src/common/imagpng.cpp
./src/common/imagpng.cpp: In member function ?virtual
bool
wxPNGHandler::LoadFile(wxImage*, wxInputStream&,
bool, int)?:
./src/common/imagpng.cpp:532:30: error: ?voidp? was not
declared in
this scope
(voidp) NULL,
^
-------------------------------------------------------------------------------------------
Machine: HP Z Book G3 running CentOS 7,
kernel 3.10.0-327.36.1.el7.x86_64 #1 SMP.
PyBOMBS: Version 2.2.0
Python: Version 3.5.2
pip: pip 8.1.2 from
/usr/local/lib/python3.5/site-packages (python 3.5)
gcc: gcc version 4.8.5 20150623 (Red Hat 4.8.5-4) (GCC)
Here is the command line I used to try to install
gnuradio and UHD:
pybombs prefix init /usr/local/gnuradio -a gnuradio -R
gnuradio-default
I've attached the full text log of what appeared on the
screen after I
issued that command.
(I've got UHD running under Ubuntu 16.04 and Fedora Core
24, but since
CentOS is residing on a very fast SSD and I need fast
I/O, I was
hoping to get UHD (at least) going on CentOS too.)
Thanks for any advice anybody might have.
Chad
--
Chad M. Spooner, PhD
NorthWest Research Associates
301 Webster Street
Monterey, CA 93940
address@hidden
<mailto:address@hidden>
cell: (831) 521 6743
office: (831) 582 4904
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20161004/19dd5a6c/attachment.html>
------------------------------
Message: 8
Date: Tue, 4 Oct 2016 14:25:19 -0700
From: Martin Braun <
address@hidden>
To:
address@hidden
Subject: Re: [Discuss-gnuradio] UHD/gnuradio on CentOS 7
install
problems
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=windows-1252
PyBOMBS doesn't have an easy way of telling it that you
don't need WxGUI
if you're building from a prefix recipe (i.e., -R
gnuradio-default).
I'm not sure why WX doesn't compile on CentOS 7, but if it
fails, it'll
take down your PyBOMBS build. Since the whole point of
PyBOMBS is to
take all the installation pain away, this is definitely an
issue.
I've flagged wxpython as optional in gnuradio-default and
gnuradio-stable. If you run
$ pybombs recipes update
you should get the new versions and a failing WX won't
crash your build.
Cheers,
Martin
On 10/04/2016 01:56 PM, Marcus M?ller wrote:
Hi Chad,
the question I'd ask here is:
Do you *really* need WxGUI support? It's going away with
GNU Radio 3.8,
and if you remove the Wx dependency from the GNU Radio
package, GNU
Radio will build just as well, but you'll only be
presented with the
actively maintained QtGUI.
Best regards,
Marcus
On 10/04/2016 01:23 PM, Chad M. Spooner wrote:
Forum:
I'm trying to get gnuradio/UHD up on a CentOS 7
machine. I've made a
lot of progress, but have a problem I can't
understand.
I'll provide details below, but the error message is
obtained during
the attempted installation of wxpython. It is a
compiler error. The
first error that appears is:
---------------------------------------------------------------------------
/usr/local/gnuradio/src/wxpython/bk-deps g++ -c -o
coredll_imagpng.o
-I./.pch/wxprec_coredll -D__WXGTK__ -DWXBUILDING
-I./src/tiff
-I./src/jpeg -DWXUSINGDLL -DWXMAKINGDLL_CORE
-DwxUSE_BASE=0 -fPIC
-DPIC -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES
-I/usr/local/gnuradio/src/wxpython/lib/wx/include/gtk2-ansi-release-2.8
-I./include
-pthread -I/usr/include/gtk-2.0
-I/usr/lib64/gtk-2.0/include
-I/usr/include/atk-1.0 -I/usr/include/cairo
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/pixman-1 -I/usr/include/freetype2
-I/usr/include/libpng15 -I/usr/include/libdrm
-I/usr/include/harfbuzz
-DWX_PRECOMP -pthread -Wall -Wundef
-Wno-ctor-dtor-privacy -O2
-fno-strict-aliasing ./src/common/imagpng.cpp
./src/common/imagpng.cpp: In member function ?virtual
bool
wxPNGHandler::LoadFile(wxImage*, wxInputStream&,
bool, int)?:
./src/common/imagpng.cpp:532:30: error: ?voidp? was
not declared in
this scope
(voidp) NULL,
^
-------------------------------------------------------------------------------------------
Machine: HP Z Book G3 running CentOS 7,
kernel 3.10.0-327.36.1.el7.x86_64 #1 SMP.
PyBOMBS: Version 2.2.0
Python: Version 3.5.2
pip: pip 8.1.2 from
/usr/local/lib/python3.5/site-packages (python 3.5)
gcc: gcc version 4.8.5 20150623 (Red Hat 4.8.5-4)
(GCC)
Here is the command line I used to try to install
gnuradio and UHD:
pybombs prefix init /usr/local/gnuradio -a gnuradio -R
gnuradio-default
I've attached the full text log of what appeared on
the screen after I
issued that command.
(I've got UHD running under Ubuntu 16.04 and Fedora
Core 24, but since
CentOS is residing on a very fast SSD and I need fast
I/O, I was
hoping to get UHD (at least) going on CentOS too.)
Thanks for any advice anybody might have.
Chad
--
Chad M. Spooner, PhD
NorthWest Research Associates
301 Webster Street
Monterey, CA 93940
address@hidden
<mailto:address@hidden>
cell: (831) 521 6743
office: (831) 582 4904
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
------------------------------
Subject: Digest Footer
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
------------------------------
End of Discuss-gnuradio Digest, Vol 167, Issue 5
************************************************