So, I just tried building UHD through pybombs, which had its strangenesses, but worked out.
Which also means that you should be able to install it from source manually without pybombs. I'm currently doing a pybombs --prefix /home/gruser/prefix install gnuradio, after having removed apache-thrift from /home/gruser/.pybombs/recipes/gr-recipes/gnuradio.lwr; I'll report back. Best regards, Marcus On 07.10.2016 18:09, Marcus Müller wrote: > > Hi Chad > >> Is it the consensus of the group is that UHD/gnuradio is not installable >> on CentOS 7? > No. It should be. In fact, I've built it once, but that was a while > back, but I don't remember UHD giving me much trouble. > > I'll try again later today, please stand by. > > Best regards, > Marcus > > On 07.10.2016 17:53, Chad Spooner wrote: >> All I really need in the short term is UHD on CentOS 7. >> >> Is it the consensus of the group is that UHD/gnuradio is not installable >> on CentOS 7? I haven't seen any suggestions about the python-zmq >> problem below. >> >> Chad >> >> >> On Wed, 2016-10-05 at 10:34 -0700, Chad M. Spooner wrote: >>> >>> Martin, Marcus: Thanks for the helpful replies. >>> >>> All: I think I messed up on subscribing to the mail list by >>> selecting Digest, and I've tried to undo that. For now, I have to >>> reply to the Digest I got this morning. >>> >>> I updated the recipes as suggested, and did a new installation. The >>> first error was that somehow QT 4 was not in my (root's) path, QT >>> 3.3 was, so I fixed that. (The symptom was that 'qmake' was not >>> found by the installer.) >>> >>> Then I did another install and got to the point where the installer >>> wants to install python-zmq: >>> >>> checking whether g++ supports C++11 features with -std=c++11... yes >>> ./configure: line 17775: syntax error near unexpected token `QT,' >>> ./configure: line 17775: ` PKG_CHECK_MODULES(QT, QtCore >= 4.3, >>> QtNetwork >= 4.3, have_qt=yes, have_qt=no)' >>> PyBOMBS.Packager.source - ERROR - Configuration failed after running >>> at least twice. >>> PyBOMBS.Packager.source - ERROR - Problem occurred while building >>> package apache-thrift: >>> Configuration failed >>> PyBOMBS.PackageManager - WARNING - Optional package apache-thrift >>> failed to install. >>> PyBOMBS.install_manager - INFO - Installation successful. >>> PyBOMBS.install_manager - INFO - Installing package: liblog4cpp >>> 00549 kB / 00549 kB (100%) >>> Configuring: (100%) >>> [====================================================================================] >>> Building: (100%) >>> [====================================================================================] >>> Installing: (100%) >>> [====================================================================================] >>> PyBOMBS.install_manager - INFO - Installation successful. >>> PyBOMBS.install_manager - INFO - Installing package: zeromq >>> 02084 kB / 02084 kB (100%) >>> Configuring: (100%) >>> [====================================================================================] >>> Building: (100%) >>> [====================================================================================] >>> Installing: (100%) >>> [====================================================================================] >>> PyBOMBS.install_manager - INFO - Installation successful. >>> PyBOMBS.install_manager - INFO - Installing package: python-zmq >>> PyBOMBS.Packager.source - WARNING - Cannot find a source URI for >>> package python-zmq >>> PyBOMBS.install_manager - ERROR - Error installing package >>> python-zmq. Aborting. >>> >>> Chad >>> >>> On 2016-10-05 09:00, discuss-gnuradio-requ...@gnu.org wrote: >>> >>>> Send Discuss-gnuradio mailing list submissions to >>>> discuss-gnuradio@gnu.org <mailto: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 >>>> <mailto:discuss-gnuradio-requ...@gnu.org> >>>> >>>> You can reach the person managing the list at >>>> discuss-gnuradio-ow...@gnu.org >>>> <mailto: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. 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 <damindra.band...@gmail.com >>>> <mailto:damindra.band...@gmail.com>> >>>> To: discuss-gnuradio@gnu.org <mailto:discuss-gnuradio@gnu.org> >>>> Subject: [Discuss-gnuradio] Replacement for packet encoder/decoder >>>> Message-ID: >>>> <CANpceN-aihkrnJuFMbwr9a2J9XyA=b-kyhsm28ouocdxux5...@mail.gmail.com >>>> <mailto:CANpceN-aihkrnJuFMbwr9a2J9XyA=b-kyhsm28ouocdxux5...@mail.gmail.com>> >>>> 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 <marcus.muel...@ettus.com >>>> <mailto:marcus.muel...@ettus.com>> >>>> To: discuss-gnuradio@gnu.org <mailto:discuss-gnuradio@gnu.org> >>>> Subject: Re: [Discuss-gnuradio] Block Thread question >>>> Message-ID: <8518d7c5-bb52-b44a-df51-eed2e8068...@ettus.com >>>> <mailto:8518d7c5-bb52-b44a-df51-eed2e8068...@ettus.com>> >>>> 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 >>>>> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> >>>>> 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" <garv...@gatech.edu <mailto:garv...@gatech.edu>> >>>> To: Marcus M?ller <marcus.muel...@ettus.com >>>> <mailto:marcus.muel...@ettus.com>> >>>> Cc: "discuss-gnuradio@gnu.org <mailto:discuss-gnuradio@gnu.org>" >>>> <discuss-gnuradio@gnu.org <mailto:discuss-gnuradio@gnu.org>> >>>> Subject: Re: [Discuss-gnuradio] Block Thread question >>>> Message-ID: <9707d576-16c7-427d-9ac9-205776100...@gatech.edu >>>> <mailto:9707d576-16c7-427d-9ac9-205776100...@gatech.edu>> >>>> 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 >>>> <marcus.muel...@ettus.com >>>> <mailto:marcus.muel...@ettus.com><mailto:marcus.muel...@ettus.com >>>> <mailto:marcus.muel...@ettus.com>>> 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 >>>> Discuss-gnuradio@gnu.org >>>> <mailto:Discuss-gnuradio@gnu.org><mailto:Discuss-gnuradio@gnu.org >>>> <mailto:Discuss-gnuradio@gnu.org>> >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>> >>>> >>>> _______________________________________________ >>>> Discuss-gnuradio mailing list >>>> Discuss-gnuradio@gnu.org >>>> <mailto:Discuss-gnuradio@gnu.org><mailto:Discuss-gnuradio@gnu.org >>>> <mailto:Discuss-gnuradio@gnu.org>> >>>> 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 <dwwke...@gmail.com <mailto:dwwke...@gmail.com>> >>>> To: Steven Knudsen <ee.k...@gmail.com <mailto:ee.k...@gmail.com>> >>>> Cc: GNURadio Discussion List <discuss-gnuradio@gnu.org >>>> <mailto:discuss-gnuradio@gnu.org>>, Knud >>>> <k...@ieee.org <mailto:k...@ieee.org>> >>>> Subject: Re: [Discuss-gnuradio] Fwd: Correlation Estimator in 3.7.10 >>>> Message-ID: >>>> <caanlyuywhz6ydbfpprfb_zhez6awapecsr9aqfkdxg_dr69...@mail.gmail.com >>>> <mailto:caanlyuywhz6ydbfpprfb_zhez6awapecsr9aqfkdxg_dr69...@mail.gmail.com>> >>>> 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 <ee.k...@gmail.com >>>> <mailto:ee.k...@gmail.com>> 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 >>>>> <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 <ee.k...@gmail.com <mailto:ee.k...@gmail.com>> >>>>> *Subject: **Correlation Estimator in 3.7.10* >>>>> *Date: *September 27, 2016 at 07:40:17 MDT >>>>> *To: *GNURadio Discussion List <discuss-gnuradio@gnu.org >>>>> <mailto:discuss-gnuradio@gnu.org>> >>>>> *Cc: *Knud <k...@ieee.org <mailto:k...@ieee.org>> >>>>> >>>>> 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 >>>>> <http://www.linkedin.com/in/knudstevenknudsen> >>>>> >>>>> >>>>> *All the wires are cut, my friendsLive beyond the severed ends. Louis >>>>> MacNeice* >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Discuss-gnuradio mailing list >>>>> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> >>>>> 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 <ee.k...@gmail.com <mailto:ee.k...@gmail.com>> >>>> To: devin kelly <dwwke...@gmail.com <mailto:dwwke...@gmail.com>> >>>> Cc: GNURadio Discussion List <discuss-gnuradio@gnu.org >>>> <mailto:discuss-gnuradio@gnu.org>> >>>> Subject: Re: [Discuss-gnuradio] Fwd: Correlation Estimator in 3.7.10 >>>> Message-ID: <2b4339a2-c07b-42ef-835c-b6c874446...@gmail.com >>>> <mailto:2b4339a2-c07b-42ef-835c-b6c874446...@gmail.com>> >>>> 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 >>>> <http://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 <dwwke...@gmail.com >>>>> <mailto:dwwke...@gmail.com>> 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 >>>>> <ee.k...@gmail.com <mailto:ee.k...@gmail.com> >>>>> <mailto:ee.k...@gmail.com <mailto:ee.k...@gmail.com>>> 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> >>>>> <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 <ee.k...@gmail.com >>>>>> <mailto:ee.k...@gmail.com> <mailto:ee.k...@gmail.com >>>>>> <mailto:ee.k...@gmail.com>>> >>>>>> Subject: Correlation Estimator in 3.7.10 >>>>>> Date: September 27, 2016 at 07:40:17 MDT >>>>>> To: GNURadio Discussion List <discuss-gnuradio@gnu.org >>>>>> <mailto:discuss-gnuradio@gnu.org> >>>>>> <mailto:discuss-gnuradio@gnu.org <mailto:discuss-gnuradio@gnu.org>>> >>>>>> Cc: Knud <k...@ieee.org <mailto:k...@ieee.org> <mailto:k...@ieee.org >>>>>> <mailto:k...@ieee.org>>> >>>>>> >>>>>> 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> >>>>>> <http://www.linkedin.com/in/knudstevenknudsen> >>>>>> >>>>>> All the wires are cut, my friends >>>>>> Live beyond the severed ends. Louis MacNeice >>>>> >>>>> >>>>> _______________________________________________ >>>>> Discuss-gnuradio mailing list >>>>> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> >>>>> <mailto:Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>> >>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> >>>>> >>>> >>>> -------------- 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" <cmspoo...@nwra.com >>>> <mailto:cmspoo...@nwra.com>> >>>> To: discuss-gnuradio@gnu.org <mailto:discuss-gnuradio@gnu.org> >>>> Subject: [Discuss-gnuradio] UHD/gnuradio on CentOS 7 install problems >>>> Message-ID: <6d5eae41623e096d2aab488dfe857...@nwra.com >>>> <mailto:6d5eae41623e096d2aab488dfe857...@nwra.com>> >>>> 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 >>>> cmspoo...@nwra.com <mailto:cmspoo...@nwra.com> >>>> 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 <marcus.muel...@ettus.com >>>> <mailto:marcus.muel...@ettus.com>> >>>> To: discuss-gnuradio@gnu.org <mailto:discuss-gnuradio@gnu.org> >>>> Subject: Re: [Discuss-gnuradio] UHD/gnuradio on CentOS 7 install >>>> problems >>>> Message-ID: <d732bd83-d095-ef55-f32d-239799f4a...@ettus.com >>>> <mailto:d732bd83-d095-ef55-f32d-239799f4a...@ettus.com>> >>>> 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 >>>>> cmspoo...@nwra.com <mailto:cmspoo...@nwra.com> >>>>> <mailto:cmspoo...@nwra.com <mailto:cmspoo...@nwra.com>> >>>>> cell: (831) 521 6743 >>>>> office: (831) 582 4904 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Discuss-gnuradio mailing list >>>>> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> >>>>> 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 <martin.br...@ettus.com >>>> <mailto:martin.br...@ettus.com>> >>>> To: discuss-gnuradio@gnu.org <mailto:discuss-gnuradio@gnu.org> >>>> Subject: Re: [Discuss-gnuradio] UHD/gnuradio on CentOS 7 install >>>> problems >>>> Message-ID: <e5b13b32-0d30-e584-226e-167a29d87...@ettus.com >>>> <mailto:e5b13b32-0d30-e584-226e-167a29d87...@ettus.com>> >>>> 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 >>>>>> cmspoo...@nwra.com <mailto:cmspoo...@nwra.com> >>>>>> <mailto:cmspoo...@nwra.com <mailto:cmspoo...@nwra.com>> >>>>>> cell: (831) 521 6743 >>>>>> office: (831) 582 4904 >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Discuss-gnuradio mailing list >>>>>> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> >>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Discuss-gnuradio mailing list >>>>> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> >>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>> >>>> >>>> >>>> >>>> ------------------------------ >>>> >>>> Subject: Digest Footer >>>> >>>> _______________________________________________ >>>> Discuss-gnuradio mailing list >>>> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>> >>>> >>>> ------------------------------ >>>> >>>> End of Discuss-gnuradio Digest, Vol 167, Issue 5 >>>> ************************************************ >>> -- >>> Chad M. Spooner, PhD >>> NorthWest Research Associates >>> 301 Webster Street >>> Monterey, CA 93940 >>> cmspoo...@nwra.com <mailto:cmspoo...@nwra.com> >>> cell: (831) 521 6743 >>> office: (831) 582 4904 >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> -- >> Chad M. Spooner >> NorthWest Research Associates >> 301 Webster Street >> Monterey, CA 93940 >> cmspoo...@nwra.com >> 831 582 4904 >> >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
