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
