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
************************************************