Hi Chad, So, I've went ahead and built a refreshed uhd RPM for CentOS 7. I really haven't had a chance to test it (and it's getting all kinds of late around here), but if you'd like to try yourself:
https://gist.github.com/133daf964cdf947587bc6bcd303b85aa The binary file you're looking for is probably uhd-3.10.0.0-5.el7.centos.x86_64.rpm ; things are still uploading, so please have another couple of minutes patience; the -devel package, as usual, contains the headers etc. Best regards, Marcus On 07.10.2016 20:16, Marcus Müller wrote: > > 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, [email protected] wrote: >>>> >>>>> Send Discuss-gnuradio mailing list submissions to >>>>> [email protected] <mailto:[email protected]> >>>>> >>>>> 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 >>>>> [email protected] >>>>> <mailto:[email protected]> >>>>> >>>>> You can reach the person managing the list at >>>>> [email protected] >>>>> <mailto:[email protected]> >>>>> >>>>> 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 <[email protected] >>>>> <mailto:[email protected]>> >>>>> To: [email protected] <mailto:[email protected]> >>>>> 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 <[email protected] >>>>> <mailto:[email protected]>> >>>>> To: [email protected] <mailto:[email protected]> >>>>> Subject: Re: [Discuss-gnuradio] Block Thread question >>>>> Message-ID: <[email protected] >>>>> <mailto:[email protected]>> >>>>> 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 >>>>>> [email protected] <mailto:[email protected]> >>>>>> 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" <[email protected] >>>>> <mailto:[email protected]>> >>>>> To: Marcus M?ller <[email protected] >>>>> <mailto:[email protected]>> >>>>> Cc: "[email protected] <mailto:[email protected]>" >>>>> <[email protected] <mailto:[email protected]>> >>>>> Subject: Re: [Discuss-gnuradio] Block Thread question >>>>> Message-ID: <[email protected] >>>>> <mailto:[email protected]>> >>>>> 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 >>>>> <[email protected] >>>>> <mailto:[email protected]><mailto:[email protected] >>>>> <mailto:[email protected]>>> 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 >>>>> [email protected] >>>>> <mailto:[email protected]><mailto:[email protected] >>>>> <mailto:[email protected]>> >>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>> >>>>> >>>>> _______________________________________________ >>>>> Discuss-gnuradio mailing list >>>>> [email protected] >>>>> <mailto:[email protected]><mailto:[email protected] >>>>> <mailto:[email protected]>> >>>>> 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 <[email protected] <mailto:[email protected]>> >>>>> To: Steven Knudsen <[email protected] <mailto:[email protected]>> >>>>> Cc: GNURadio Discussion List <[email protected] >>>>> <mailto:[email protected]>>, Knud >>>>> <[email protected] <mailto:[email protected]>> >>>>> 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 >>>>> <[email protected] <mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>> >>>>>> *Subject: **Correlation Estimator in 3.7.10* >>>>>> *Date: *September 27, 2016 at 07:40:17 MDT >>>>>> *To: *GNURadio Discussion List <[email protected] >>>>>> <mailto:[email protected]>> >>>>>> *Cc: *Knud <[email protected] <mailto:[email protected]>> >>>>>> >>>>>> 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 >>>>>> [email protected] <mailto:[email protected]> >>>>>> 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 <[email protected] <mailto:[email protected]>> >>>>> To: devin kelly <[email protected] <mailto:[email protected]>> >>>>> Cc: GNURadio Discussion List <[email protected] >>>>> <mailto:[email protected]>> >>>>> Subject: Re: [Discuss-gnuradio] Fwd: Correlation Estimator in 3.7.10 >>>>> Message-ID: <[email protected] >>>>> <mailto:[email protected]>> >>>>> 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 <[email protected] >>>>>> <mailto:[email protected]>> 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 >>>>>> <[email protected] <mailto:[email protected]> >>>>>> <mailto:[email protected] <mailto:[email protected]>>> 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 <[email protected] >>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>> <mailto:[email protected]>>> >>>>>>> Subject: Correlation Estimator in 3.7.10 >>>>>>> Date: September 27, 2016 at 07:40:17 MDT >>>>>>> To: GNURadio Discussion List <[email protected] >>>>>>> <mailto:[email protected]> >>>>>>> <mailto:[email protected] <mailto:[email protected]>>> >>>>>>> Cc: Knud <[email protected] <mailto:[email protected]> >>>>>>> <mailto:[email protected] <mailto:[email protected]>>> >>>>>>> >>>>>>> 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 >>>>>> [email protected] <mailto:[email protected]> >>>>>> <mailto:[email protected] <mailto:[email protected]>> >>>>>> 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" <[email protected] >>>>> <mailto:[email protected]>> >>>>> To: [email protected] <mailto:[email protected]> >>>>> Subject: [Discuss-gnuradio] UHD/gnuradio on CentOS 7 install problems >>>>> Message-ID: <[email protected] >>>>> <mailto:[email protected]>> >>>>> 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 >>>>> [email protected] <mailto:[email protected]> >>>>> 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 <[email protected] >>>>> <mailto:[email protected]>> >>>>> To: [email protected] <mailto:[email protected]> >>>>> Subject: Re: [Discuss-gnuradio] UHD/gnuradio on CentOS 7 install >>>>> problems >>>>> Message-ID: <[email protected] >>>>> <mailto:[email protected]>> >>>>> 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 >>>>>> [email protected] <mailto:[email protected]> >>>>>> <mailto:[email protected] <mailto:[email protected]>> >>>>>> cell: (831) 521 6743 >>>>>> office: (831) 582 4904 >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Discuss-gnuradio mailing list >>>>>> [email protected] <mailto:[email protected]> >>>>>> 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 <[email protected] >>>>> <mailto:[email protected]>> >>>>> To: [email protected] <mailto:[email protected]> >>>>> Subject: Re: [Discuss-gnuradio] UHD/gnuradio on CentOS 7 install >>>>> problems >>>>> Message-ID: <[email protected] >>>>> <mailto:[email protected]>> >>>>> 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 >>>>>>> [email protected] <mailto:[email protected]> >>>>>>> <mailto:[email protected] <mailto:[email protected]>> >>>>>>> cell: (831) 521 6743 >>>>>>> office: (831) 582 4904 >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Discuss-gnuradio mailing list >>>>>>> [email protected] <mailto:[email protected]> >>>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Discuss-gnuradio mailing list >>>>>> [email protected] <mailto:[email protected]> >>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------ >>>>> >>>>> Subject: Digest Footer >>>>> >>>>> _______________________________________________ >>>>> Discuss-gnuradio mailing list >>>>> [email protected] <mailto:[email protected]> >>>>> 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 >>>> [email protected] <mailto:[email protected]> >>>> cell: (831) 521 6743 >>>> office: (831) 582 4904 >>>> _______________________________________________ >>>> Discuss-gnuradio mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> -- >>> Chad M. Spooner >>> NorthWest Research Associates >>> 301 Webster Street >>> Monterey, CA 93940 >>> [email protected] >>> 831 582 4904 >>> >>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> [email protected] >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
