[Discuss-gnuradio] pre-emphasis filter not working
Hi, I was wondering if the issue is still in the lastest builds, I do not have to mathamatical knowledge to create this myself :( ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] AMD FX8150
Anyone on-list have any experience with the new AMD FX-series CPUs and Gnu Radio? In particular I'm considering replacing a Phenom II X6 1090T with a FX8150 (and new mobo, as it turns out). -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Passing numpy arrays into vector parameters
On Sat, Feb 18, 2012 at 2:29 AM, Burak TUYSUZ wrote: > > Hi all, > > I saw that there was a feature request 2 years ago. > http://gnuradio.org/redmine/issues/399 > Is there any progress on that or any idea how to do that? > Thank you > -Burak > > Burak, There hasn't been much work (or interest that I've seen) in making this work. There is this page: http://docs.scipy.org/doc/numpy/reference/swig.interface-file.html It has information about how to pass numpy arrays through Swig. From my reading of it, though, it doesn't seem to really be applicable to how things are defined in GNU Radio. If someone were to make a go at getting it to work generically with our blocks, I'd like to have a look. Any time I work with numpy/scipy arrays, I just pass them through by calling the tolist() method on the array. This returns a Python list that works correctly with GNU Radio blocks. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] www.gnuradio.org (and git) is down
www.gnuradio.org appears to be dead, as is the GIT server. Sigh. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] www.gnuradio.org (and git) is down
On Sat, Feb 18, 2012 at 11:59 AM, Marcus D. Leech wrote: > www.gnuradio.org appears to be dead, as is the GIT server. Sigh. > > -- > Marcus Leech > Principal Investigator > Shirleys Bay Radio Astronomy Consortium > http://www.sbrac.org It's working for me. No reset required. Try again. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ATSC decoding - Now Working!
Alright. If I get it working I will post my fixes. Which part is not working? Also, my research only deals with extracting the bit delay to the data sync frame. So, I will not really be doing much with atsc decoding past getting a bit stream what would include the sync frame. Which also brings up another question. In the general signal flow of decoding the atsc with gnuradio, when will the data sync frame be uncovered? At the moment, I run interp_short, xlate, and fpll. Those translate the signal to baseband and I think fpll demodulates. Do any of you guys happen to know what fpll actually outputs? Like what form is the data in? Because I don't have real over the air data to run through this I can't crack it open to make sense of it. Is it raw binary bit stream after that stage? Again, my intuition is that fpll outputs the raw bitstream and to find the data sync frame I will be able to just run a binary correlator with the pn_511 sequence. Any advice would be helpful. Thanks! Johnathan Corgan-2 wrote: > > On Fri, Feb 17, 2012 at 08:31, Tom Rondeau wrote: > >> Also, we might be able to host some data files on gnuradio.org. I need to >> look into how much space we have or can set aside for this, but it would >> be >> nice to have stuff like this easily accessible. > > We can easily conjure up an extra 10 or 20 GB for an example data file > volume. That's something like a dollar a month. > > Johnathan > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- View this message in context: http://old.nabble.com/Re%3A-Re%3A-ATSC-decoding---Now-Working%21-tp30073408p33348912.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] www.gnuradio.org (and git) is down
On Sat, 18 Feb 2012 12:09:46 -0500 Tom Rondeau wrote: > It's working for me. No reset required. Try again. If redirecting is not enabled in the browser, it may not get to gnuradio.org. It seems www.gnuradio.org goes there through redirection. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] www.gnuradio.org (and git) is down
On 02/18/2012 01:01 PM, John Coppens wrote: On Sat, 18 Feb 2012 12:09:46 -0500 Tom Rondeau wrote: It's working for me. No reset required. Try again. If redirecting is not enabled in the browser, it may not get to gnuradio.org. It seems www.gnuradio.org goes there through redirection. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio It seems to have been a transient, because 20 minutes after I posted, it was back again. My panic was clearly premature. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problem building gr-howto-write-a-block-cmake
Martin, yes i did sudo ldconfig, but the problem is still there. I noticed that cmake gives the following output for gr-howto-...-cmake -- Found SWIG: /usr/bin/swig (found version "2.0.4") -- Could NOT find PythonLibs (missing: PYTHON_LIBRARIES) -- Found PythonInterp: /usr/bin/python2.7 so it says it cannot find the PythonLibs. This is very weird since cmake on the gnuradio tree gives no problem: -- Configuring python-support support... -- Dependency PYTHONLIBS_FOUND = TRUE -- Dependency SWIG_FOUND = TRUE -- Dependency SWIG_VERSION_CHECK = TRUE -- Enabling python-support support. -- Override with -DENABLE_PYTHON=ON/OFF So, I am stuck at this point! I don't know what PyhtonLibs gr-howto tries to find and why there is a discrepancy between this and the gnuradio tree build. BTW, everything is on the master branch. Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] www.gnuradio.org (and git) is down
Tom, Am I correct in assuming you are running GR.org on AWS? I have noticed in my own use of AWS that they have occasional scheduled reboots of their hardware for upgrades, which naturally causes a reboot of your instance. These scheduled events are listed in the AWS console page. A scheduled maintenance reboot may have caused the short outage Marcus saw. On 02/18/2012 01:22 PM, Marcus D. Leech wrote: On 02/18/2012 01:01 PM, John Coppens wrote: On Sat, 18 Feb 2012 12:09:46 -0500 Tom Rondeau wrote: It's working for me. No reset required. Try again. If redirecting is not enabled in the browser, it may not get to gnuradio.org. It seems www.gnuradio.org goes there through redirection. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio It seems to have been a transient, because 20 minutes after I posted, it was back again. My panic was clearly premature. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] www.gnuradio.org (and git) is down
On Sat, Feb 18, 2012 at 10:56, Dan CaJacob wrote: > A scheduled maintenance reboot may have caused the short outage Marcus saw. We get an email on boot from the instance, so we know when these happen (it didn't.) My guess was it was a transient network connectivity issue for some routes into the AWS region. I have a once-per-minute continuous ping on the instance and didn't see anything unusual. We've recently been subject to a few (unsuccessful) TCP SYN flood attacks, which might have affected things, but not in the last couple days. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problem building gr-howto-write-a-block-cmake
On Thu, Feb 16, 2012 at 4:27 PM, Achilleas Anastasopoulos wrote: > I also noticed the following in the cmake ../ > > -- Found SWIG: /usr/bin/swig (found version "2.0.4") > -- Could NOT find PythonLibs (missing: PYTHON_LIBRARIES) > -- Found PythonInterp: /usr/bin/python2.7 > > > what is the significance of not founding the PythonLibs? > when i build gnuradio it says that it found them > > > -- Configuring python-support support... > -- Dependency PYTHONLIBS_FOUND = TRUE > -- Dependency SWIG_FOUND = TRUE > -- Dependency SWIG_VERSION_CHECK = TRUE > -- Enabling python-support support. > -- Override with -DENABLE_PYTHON=ON/OFF > > > > > Achilleas Achilleas, This is good information. I've gotten various reports on trouble with the use of SWIG 2.0.4 (specifically the .4 version). I didn't think it had become a default installation, but it seems like it is. I'll specifically take a look at it now, though. In the meantime, is there a way you can install Swig 1.3.x and use that, instead? I wonder if that might solve you problem. Tom On Thu, Feb 16, 2012 at 4:03 PM, Achilleas Anastasopoulos > wrote: > > yes i did that and get the same problem (the swig-related files are not > built). > > > > BTW, how can using git rm the entire directory gr-howto-cmake > > and download it from the trunk? > > > > thanks > > Achilleas > > > > > > > > On Thu, Feb 16, 2012 at 3:53 PM, Tom Rondeau wrote: > >> On Thu, Feb 16, 2012 at 11:57 AM, Achilleas Anastasopoulos > >> wrote: > >>> > >>> BTW, I forgot to say that I am building from the latest master branch > >>> and I have already built/installed the latest gnuradio from > >>> the master branch. > >>> > >>> Achilleas > >>> > >>> On Thu, Feb 16, 2012 at 11:49 AM, Achilleas Anastasopoulos > >>> wrote: > >>> > OK, I am having a problem building the howto module with CMake. > >>> > > >>> > Here is the output of all the steps: > >>> > > >>> > > >>> > [anastas@jefe build]$ cmake ../ > >>> > -- The CXX compiler identification is GNU > >>> > -- Check for working CXX compiler: /usr/lib64/ccache/c++ > >>> > -- Check for working CXX compiler: /usr/lib64/ccache/c++ -- works > >>> > -- Detecting CXX compiler ABI info > >>> > -- Detecting CXX compiler ABI info - done > >>> > -- Build type not specified: defaulting to release. > >>> > -- Boost version: 1.46.0 > >>> > -- checking for module 'gruel' > >>> > -- found gruel, version 3.5.2git > >>> > -- Found GRUEL: /usr/local/lib64/libgruel.so > >>> > -- checking for module 'gnuradio-core' > >>> > -- found gnuradio-core, version 3.5.2git > >>> > -- Found GNURADIO_CORE: /usr/local/lib64/libgnuradio-core.so > >>> > -- Boost version: 1.46.0 > >>> > -- Found the following Boost libraries: > >>> > -- unit_test_framework > >>> > -- Found SWIG: /usr/bin/swig (found version "2.0.4") > >>> > -- Could NOT find PythonLibs (missing: PYTHON_LIBRARIES) > >>> > -- Found PythonInterp: /usr/bin/python2.7 > >>> > -- Found Doxygen: /usr/bin/doxygen > >>> > -- Configuring done > >>> > -- Generating done > >>> > -- Build files have been written to: > >>> > > >>> > > /n/harrisville/x/anastas/gnuradio_trunk/gr-howto-write-a-block-cmake/build > >>> > > >>> > > >>> > Then > >>> > > >>> > > >>> > > >>> > [anastas@jefe build]$ make > >>> > [ 12%] Building CXX object > >>> > lib/CMakeFiles/gnuradio-howto.dir/howto_square_ff.cc.o > >>> > [ 25%] Building CXX object > >>> > lib/CMakeFiles/gnuradio-howto.dir/howto_square2_ff.cc.o > >>> > [ 37%] Building CXX object > >>> > lib/CMakeFiles/gnuradio-howto.dir/howto_demod_filterbank_ccvc.cc.o > >>> > Linking CXX shared library libgnuradio-howto.so > >>> > [ 37%] Built target gnuradio-howto > >>> > [ 50%] Building CXX object > >>> > lib/CMakeFiles/qa_howto_square2_ff.dir/qa_howto_square2_ff.cc.o > >>> > Linking CXX executable qa_howto_square2_ff > >>> > [ 50%] Built target qa_howto_square2_ff > >>> > [ 62%] Building CXX object > >>> > lib/CMakeFiles/qa_howto_square_ff.dir/qa_howto_square_ff.cc.o > >>> > Linking CXX executable qa_howto_square_ff > >>> > [ 62%] Built target qa_howto_square_ff > >>> > [ 62%] Generating __init__.pyc > >>> > [ 62%] Generating __init__.pyo > >>> > [ 87%] Built target pygen_python_6b399 > >>> > [ 87%] Shebangin howto_square.py > >>> > [100%] Built target pygen_apps_19307 > >>> > > >>> > > >>> > Then > >>> > > >>> > > >>> > [anastas@jefe build]$ sudo make install > >>> > Built target gnuradio-howto > >>> > Built target qa_howto_square2_ff > >>> > Built target qa_howto_square_ff > >>> > Built target pygen_python_6b399 > >>> > Built target pygen_apps_19307 > >>> > Install the project... > >>> > -- Install configuration: "Release" > >>> > -- Installing: /usr/local/include/howto/howto_api.h > >>> > -- Installing: /usr/local/include/howto/howto_square_ff.h > >>> > -- Installing: /usr/local/include/howto/howto_square2_ff.h > >>> > -- Installing: /usr/local/lib64/libgnuradio-howto.so > >>> > -- Removed runtime path from "/usr/local/lib64/libgnuradio-howto.so" > >>> > -- Installing: > >>>
Re: [Discuss-gnuradio] Using volk in Mac: test report
On Fri, Feb 17, 2012 at 6:04 PM, Nowlan, Sean wrote: > Don’t know how helpful these are, but here you go. > > ** ** > > Sean > Sean, It looks like a couple of functions are failing from the stdout: volk_32fc_s32f_magnitude_16i_a: fail on arch orc volk_32fc_x2_multiply_32fc_a: fail on arch orc These are both the Orc implementations of the functions, which seem to work fine on my Intel processors. I don't have access to an OSX box or an E100, so I can't really test this out. The files you sent me don't (appear to) tell me what the real problem is. We'll need some other brave soul out there who can dig into these issues on the platforms for us. Thanks, Tom > *From:* trond...@trondeau.com [mailto:trond...@trondeau.com] *On Behalf > Of *Tom Rondeau > *Sent:* Friday, February 17, 2012 5:25 PM > *To:* Nowlan, Sean > *Cc:* Nick Foster; discuss-gnuradio@gnu.org > > *Subject:* Re: [Discuss-gnuradio] Using volk in Mac: test report > > ** ** > > On Fri, Feb 17, 2012 at 5:11 PM, Nowlan, Sean > wrote: > > I built Tom’s safe_align branch on E100 and ran volk_profile. It > segfaulted on “RUN_VOLK_TESTS:volk_32fc_s32fc_multiply_32fc_a. I’ll get a > stack trace for you. > > > > Sean > > ** ** > > Really interesting that it's the same block. Hopefully, it's a single, > simple fix. I'll look into it when you can get me the stack trace. > > ** ** > > Thanks for reporting! > > Tom > > ** ** > > > > > > *From:* discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org[mailto: > discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] *On Behalf > Of *Tom Rondeau > *Sent:* Friday, February 17, 2012 2:33 PM > *To:* Nick Foster > *Cc:* discuss-gnuradio@gnu.org > *Subject:* Re: [Discuss-gnuradio] Using volk in Mac: test report > > > > On Fri, Feb 17, 2012 at 2:30 PM, Nick Foster wrote: > > On Fri, Feb 17, 2012 at 11:20 AM, Carles Fernandez < > carles.fernan...@gmail.com> wrote: > > Thanks for the inputs! > > We are interested in determining the best architecture at instantation > time. What would be the best strategy? We though about running the > same operations several times for each architecture, measure the > results and use the fastest one for the processing blocks. Would this > be the right approach? > > > > Carles, > > > > Run volk_profile. It does exactly what you said, and writes the results to > ~/.volk/volk_config. Volk reads this file when it is involked (sorry) to > determine which particular function to execute. So all you do is run > volk_profile once on any given machine, and it's optimized. > > > > --n > > > > Carles, > > This is discussed on the webpage: > > http://gnuradio.org/redmine/projects/gnuradio/wiki/volk > > > > We'll be updating this as things progress with Volk, but the profiler info > is there already. > > > > Tom > > > > ** ** > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Anyone have an opinion on what existing block is closest to the attached so that I can start writing my own?
Attached is a C implementation of a block I wish was in Gnu Radio.
Anyone done anything similar-enough as a block
in Gnu Radio that would make a decent starting point?
It's basically a block that takes a fixed-size vector input, and a list
of "descriptors" that describe output channels that need to be carved out of
the input vector (a list of start:end which are simply offsets into
the vector). It's intended to be used after a FFT+complex-to-MAG block to
process the resulting vector and select sub-bands and turn them into
power-estimate channels. I see nothing in Gnu Radio that does this,
other than things like the FFT channelizer, PFB channelizer, etc.
Neither of those is efficient in this case, because the channels are of
non-uniform distribution and width, and if the target is simply power
estimation, that part has already basically been done by the
FFT+complex-to-MAG stage.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
/*
* A specialzed vector de-mux for estimating power within defined sub-bands of
a vector that
* is the output of an FFT+complex-to-MAG
*
* It takes in a fixed-size float vector, and a list of descriptors describing
the sub-bands that are to
* be added together to form an output channel. The output is a number of
channels (one per descriptor).
*
* Consider the following example:
*
* Input vector:
*^^ ^^^
* CH 0 CH 1CH 2(etc)
*
* For simple multi-channel power estimation this is significantly more
efficient than many other techniques
* that might be used. Channel-width resolution is based purely on the
resolution of the FFT+complex-to-MAG
* that feeds this specialized demux. Resolutions of a few hundred Hz with
25MHz input bandwidths appear to
* be feasible with this technique. For uniformly-spaced channels with
relatively-coarse resolution, a PFB
* channel bank might be better.
*
* This "rides" on the fact that the Gnu Radio FFT implementation is very
efficient, due to its use of
* FFTW, which provides several overlapping techniques to improve performance
including:
*
*o an optimizer
*o aggressive use of SSEx/3DNow! instruction sets
*o multi-threaded FFT calculations (useful for very large FFTs, which are
required for fine resolution)
*
* In many situations, the total number of post-FFT ops you need to do is quite
modest compared to the FFT,
* since you may be ignoring the vast majority of the input vector. In the
application domain of interest
* (multi-channel power estimation for ionospheric measurements), probably
98% of the input vector isn't
* touched. But the channels of interest are:
*
* o not evenly spaced
* o not of uniform bandwidth
* o between 1 and perhaps 10 sub-band "collections" (output channels)
might be of interest
*
* invector - input vector of size 'vecsize'
* vec_begins - list of sub-channel start points (offsets from beginning of
input vector)
* vec_ends - list of sub-channel end points (offsets from beginning of
input vector)
* nchan - number of output channels (or "collections of sub-bands from
input")
* outchans - the output channels
*
*/
int
vector_power_estimator_ff (float invector[], int vecsize, int vec_begins[], int
vec_ends[], int nchan, float outchans[])
{
int i, j;
/*
* For each output channel descriptor
*/
for (i = 0; i < nchan; i++)
{
/*
* Accumulate an output channel from sub-bands in the input
*/
outchans[i] = 0.0;
for (j = vec_begins[i]; j < vec_ends[i]; j++)
{
if (j < vecsize)
{
/*
* Opportunity for volk-ifying here
*/
outchans[i] += invector[j];
}
}
}
return nchan;
}
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problem building gr-howto-write-a-block-cmake
On 02/16/2012 01:27 PM, Achilleas Anastasopoulos wrote: > I also noticed the following in the cmake ../ > > -- Found SWIG: /usr/bin/swig (found version "2.0.4") > -- Could NOT find PythonLibs (missing: PYTHON_LIBRARIES) > -- Found PythonInterp: /usr/bin/python2.7 > > > what is the significance of not founding the PythonLibs? > when i build gnuradio it says that it found them > > I think the main build system is a little smarter about setting PYTHON_EXECUTABLE before calling into the pythonlibs module. Try this little diff for the gr-howto: http://pastebin.com/18ytGnkE -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problem building gr-howto-write-a-block-cmake
I installed swig 1.3.40 and i have the same problem! is there any other way i can check if the required PyhtonLibs are indeed available in my system? The fact that gnuradio trunk builds without a problem makes me go crazy... thanks Achilleas On Sat, Feb 18, 2012 at 3:40 PM, Tom Rondeau wrote: > On Thu, Feb 16, 2012 at 4:27 PM, Achilleas Anastasopoulos > wrote: >> >> I also noticed the following in the cmake ../ >> >> -- Found SWIG: /usr/bin/swig (found version "2.0.4") >> -- Could NOT find PythonLibs (missing: PYTHON_LIBRARIES) >> -- Found PythonInterp: /usr/bin/python2.7 >> >> >> what is the significance of not founding the PythonLibs? >> when i build gnuradio it says that it found them >> >> >> -- Configuring python-support support... >> -- Dependency PYTHONLIBS_FOUND = TRUE >> -- Dependency SWIG_FOUND = TRUE >> -- Dependency SWIG_VERSION_CHECK = TRUE >> -- Enabling python-support support. >> -- Override with -DENABLE_PYTHON=ON/OFF >> >> >> >> >> Achilleas > > > Achilleas, > This is good information. I've gotten various reports on trouble with the > use of SWIG 2.0.4 (specifically the .4 version). I didn't think it had > become a default installation, but it seems like it is. I'll specifically > take a look at it now, though. > > In the meantime, is there a way you can install Swig 1.3.x and use that, > instead? I wonder if that might solve you problem. > > Tom > > > >> On Thu, Feb 16, 2012 at 4:03 PM, Achilleas Anastasopoulos >> wrote: >> > yes i did that and get the same problem (the swig-related files are not >> > built). >> > >> > BTW, how can using git rm the entire directory gr-howto-cmake >> > and download it from the trunk? >> > >> > thanks >> > Achilleas >> > >> > >> > >> > On Thu, Feb 16, 2012 at 3:53 PM, Tom Rondeau wrote: >> >> On Thu, Feb 16, 2012 at 11:57 AM, Achilleas Anastasopoulos >> >> wrote: >> >>> >> >>> BTW, I forgot to say that I am building from the latest master branch >> >>> and I have already built/installed the latest gnuradio from >> >>> the master branch. >> >>> >> >>> Achilleas >> >>> >> >>> On Thu, Feb 16, 2012 at 11:49 AM, Achilleas Anastasopoulos >> >>> wrote: >> >>> > OK, I am having a problem building the howto module with CMake. >> >>> > >> >>> > Here is the output of all the steps: >> >>> > >> >>> > >> >>> > [anastas@jefe build]$ cmake ../ >> >>> > -- The CXX compiler identification is GNU >> >>> > -- Check for working CXX compiler: /usr/lib64/ccache/c++ >> >>> > -- Check for working CXX compiler: /usr/lib64/ccache/c++ -- works >> >>> > -- Detecting CXX compiler ABI info >> >>> > -- Detecting CXX compiler ABI info - done >> >>> > -- Build type not specified: defaulting to release. >> >>> > -- Boost version: 1.46.0 >> >>> > -- checking for module 'gruel' >> >>> > -- found gruel, version 3.5.2git >> >>> > -- Found GRUEL: /usr/local/lib64/libgruel.so >> >>> > -- checking for module 'gnuradio-core' >> >>> > -- found gnuradio-core, version 3.5.2git >> >>> > -- Found GNURADIO_CORE: /usr/local/lib64/libgnuradio-core.so >> >>> > -- Boost version: 1.46.0 >> >>> > -- Found the following Boost libraries: >> >>> > -- unit_test_framework >> >>> > -- Found SWIG: /usr/bin/swig (found version "2.0.4") >> >>> > -- Could NOT find PythonLibs (missing: PYTHON_LIBRARIES) >> >>> > -- Found PythonInterp: /usr/bin/python2.7 >> >>> > -- Found Doxygen: /usr/bin/doxygen >> >>> > -- Configuring done >> >>> > -- Generating done >> >>> > -- Build files have been written to: >> >>> > >> >>> > >> >>> > /n/harrisville/x/anastas/gnuradio_trunk/gr-howto-write-a-block-cmake/build >> >>> > >> >>> > >> >>> > Then >> >>> > >> >>> > >> >>> > >> >>> > [anastas@jefe build]$ make >> >>> > [ 12%] Building CXX object >> >>> > lib/CMakeFiles/gnuradio-howto.dir/howto_square_ff.cc.o >> >>> > [ 25%] Building CXX object >> >>> > lib/CMakeFiles/gnuradio-howto.dir/howto_square2_ff.cc.o >> >>> > [ 37%] Building CXX object >> >>> > lib/CMakeFiles/gnuradio-howto.dir/howto_demod_filterbank_ccvc.cc.o >> >>> > Linking CXX shared library libgnuradio-howto.so >> >>> > [ 37%] Built target gnuradio-howto >> >>> > [ 50%] Building CXX object >> >>> > lib/CMakeFiles/qa_howto_square2_ff.dir/qa_howto_square2_ff.cc.o >> >>> > Linking CXX executable qa_howto_square2_ff >> >>> > [ 50%] Built target qa_howto_square2_ff >> >>> > [ 62%] Building CXX object >> >>> > lib/CMakeFiles/qa_howto_square_ff.dir/qa_howto_square_ff.cc.o >> >>> > Linking CXX executable qa_howto_square_ff >> >>> > [ 62%] Built target qa_howto_square_ff >> >>> > [ 62%] Generating __init__.pyc >> >>> > [ 62%] Generating __init__.pyo >> >>> > [ 87%] Built target pygen_python_6b399 >> >>> > [ 87%] Shebangin howto_square.py >> >>> > [100%] Built target pygen_apps_19307 >> >>> > >> >>> > >> >>> > Then >> >>> > >> >>> > >> >>> > [anastas@jefe build]$ sudo make install >> >>> > Built target gnuradio-howto >> >>> > Built target qa_howto_square2_ff >> >>> > Built target qa_howto_square_ff >> >>> > Built target pygen_python_6b399 >>
Re: [Discuss-gnuradio] problem building gr-howto-write-a-block-cmake
On 02/18/2012 04:25 PM, Achilleas Anastasopoulos wrote: > I installed swig 1.3.40 and i have the same problem! > > is there any other way i can check if the required PyhtonLibs > are indeed available in my system? > The fact that gnuradio trunk builds without a problem makes me go crazy... > Its not a swig problem, swig 2.0.4 is fine. Did you try my patch? http://pastebin.com/18ytGnkE > thanks > Achilleas > > > On Sat, Feb 18, 2012 at 3:40 PM, Tom Rondeau wrote: >> On Thu, Feb 16, 2012 at 4:27 PM, Achilleas Anastasopoulos >> wrote: >>> >>> I also noticed the following in the cmake ../ >>> >>> -- Found SWIG: /usr/bin/swig (found version "2.0.4") >>> -- Could NOT find PythonLibs (missing: PYTHON_LIBRARIES) >>> -- Found PythonInterp: /usr/bin/python2.7 >>> >>> >>> what is the significance of not founding the PythonLibs? >>> when i build gnuradio it says that it found them >>> >>> >>> -- Configuring python-support support... >>> -- Dependency PYTHONLIBS_FOUND = TRUE >>> -- Dependency SWIG_FOUND = TRUE >>> -- Dependency SWIG_VERSION_CHECK = TRUE >>> -- Enabling python-support support. >>> -- Override with -DENABLE_PYTHON=ON/OFF >>> >>> >>> >>> >>> Achilleas >> >> >> Achilleas, >> This is good information. I've gotten various reports on trouble with the >> use of SWIG 2.0.4 (specifically the .4 version). I didn't think it had >> become a default installation, but it seems like it is. I'll specifically >> take a look at it now, though. >> >> In the meantime, is there a way you can install Swig 1.3.x and use that, >> instead? I wonder if that might solve you problem. >> >> Tom >> >> >> >>> On Thu, Feb 16, 2012 at 4:03 PM, Achilleas Anastasopoulos >>> wrote: yes i did that and get the same problem (the swig-related files are not built). BTW, how can using git rm the entire directory gr-howto-cmake and download it from the trunk? thanks Achilleas On Thu, Feb 16, 2012 at 3:53 PM, Tom Rondeau wrote: > On Thu, Feb 16, 2012 at 11:57 AM, Achilleas Anastasopoulos > wrote: >> >> BTW, I forgot to say that I am building from the latest master branch >> and I have already built/installed the latest gnuradio from >> the master branch. >> >> Achilleas >> >> On Thu, Feb 16, 2012 at 11:49 AM, Achilleas Anastasopoulos >> wrote: >>> OK, I am having a problem building the howto module with CMake. >>> >>> Here is the output of all the steps: >>> >>> >>> [anastas@jefe build]$ cmake ../ >>> -- The CXX compiler identification is GNU >>> -- Check for working CXX compiler: /usr/lib64/ccache/c++ >>> -- Check for working CXX compiler: /usr/lib64/ccache/c++ -- works >>> -- Detecting CXX compiler ABI info >>> -- Detecting CXX compiler ABI info - done >>> -- Build type not specified: defaulting to release. >>> -- Boost version: 1.46.0 >>> -- checking for module 'gruel' >>> -- found gruel, version 3.5.2git >>> -- Found GRUEL: /usr/local/lib64/libgruel.so >>> -- checking for module 'gnuradio-core' >>> -- found gnuradio-core, version 3.5.2git >>> -- Found GNURADIO_CORE: /usr/local/lib64/libgnuradio-core.so >>> -- Boost version: 1.46.0 >>> -- Found the following Boost libraries: >>> -- unit_test_framework >>> -- Found SWIG: /usr/bin/swig (found version "2.0.4") >>> -- Could NOT find PythonLibs (missing: PYTHON_LIBRARIES) >>> -- Found PythonInterp: /usr/bin/python2.7 >>> -- Found Doxygen: /usr/bin/doxygen >>> -- Configuring done >>> -- Generating done >>> -- Build files have been written to: >>> >>> >>> /n/harrisville/x/anastas/gnuradio_trunk/gr-howto-write-a-block-cmake/build >>> >>> >>> Then >>> >>> >>> >>> [anastas@jefe build]$ make >>> [ 12%] Building CXX object >>> lib/CMakeFiles/gnuradio-howto.dir/howto_square_ff.cc.o >>> [ 25%] Building CXX object >>> lib/CMakeFiles/gnuradio-howto.dir/howto_square2_ff.cc.o >>> [ 37%] Building CXX object >>> lib/CMakeFiles/gnuradio-howto.dir/howto_demod_filterbank_ccvc.cc.o >>> Linking CXX shared library libgnuradio-howto.so >>> [ 37%] Built target gnuradio-howto >>> [ 50%] Building CXX object >>> lib/CMakeFiles/qa_howto_square2_ff.dir/qa_howto_square2_ff.cc.o >>> Linking CXX executable qa_howto_square2_ff >>> [ 50%] Built target qa_howto_square2_ff >>> [ 62%] Building CXX object >>> lib/CMakeFiles/qa_howto_square_ff.dir/qa_howto_square_ff.cc.o >>> Linking CXX executable qa_howto_square_ff >>> [ 62%] Built target qa_howto_square_ff >>> [ 62%] Generating __init__.pyc >>> [ 62%] Generating __init__.pyo >>> [ 87%] Built target pygen_python_6b399 >>> [ 87%] Shebangin howto_square.py >>> [100%] Built target pygen_apps_19307 >>> >>> >>> Then >>> >>> >>> [anastas@jefe build]$ sudo make install >>> Bu
Re: [Discuss-gnuradio] Using volk in Mac: test report
On Sat, Feb 18, 2012 at 1:05 PM, Tom Rondeau wrote: > On Fri, Feb 17, 2012 at 6:04 PM, Nowlan, Sean > wrote: > >> Don’t know how helpful these are, but here you go. >> >> ** ** >> >> Sean >> > > Sean, > It looks like a couple of functions are failing from the stdout: > > volk_32fc_s32f_magnitude_16i_a: fail on arch orc > volk_32fc_x2_multiply_32fc_a: fail on arch orc > > These are both the Orc implementations of the functions, which seem to > work fine on my Intel processors. I don't have access to an OSX box or an > E100, so I can't really test this out. The files you sent me don't (appear > to) tell me what the real problem is. > > We'll need some other brave soul out there who can dig into these issues > on the platforms for us. > Those are functions I wrote, so they're my problem. =) I'll hack on it this week. What's strange is I absolutely validated them on Orc before committing them... Sean, what version of Orc are you running on your E100? --n > > Thanks, > Tom > > > > >> *From:* trond...@trondeau.com [mailto:trond...@trondeau.com] *On Behalf >> Of *Tom Rondeau >> *Sent:* Friday, February 17, 2012 5:25 PM >> *To:* Nowlan, Sean >> *Cc:* Nick Foster; discuss-gnuradio@gnu.org >> >> *Subject:* Re: [Discuss-gnuradio] Using volk in Mac: test report >> >> ** ** >> >> On Fri, Feb 17, 2012 at 5:11 PM, Nowlan, Sean < >> sean.now...@gtri.gatech.edu> wrote: >> >> I built Tom’s safe_align branch on E100 and ran volk_profile. It >> segfaulted on “RUN_VOLK_TESTS:volk_32fc_s32fc_multiply_32fc_a. I’ll get a >> stack trace for you. >> >> >> >> Sean >> >> ** ** >> >> Really interesting that it's the same block. Hopefully, it's a single, >> simple fix. I'll look into it when you can get me the stack trace. >> >> ** ** >> >> Thanks for reporting! >> >> Tom >> >> ** ** >> >> >> >> >> >> *From:* discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org[mailto: >> discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] *On Behalf >> Of *Tom Rondeau >> *Sent:* Friday, February 17, 2012 2:33 PM >> *To:* Nick Foster >> *Cc:* discuss-gnuradio@gnu.org >> *Subject:* Re: [Discuss-gnuradio] Using volk in Mac: test report >> >> >> >> On Fri, Feb 17, 2012 at 2:30 PM, Nick Foster wrote: >> >> On Fri, Feb 17, 2012 at 11:20 AM, Carles Fernandez < >> carles.fernan...@gmail.com> wrote: >> >> Thanks for the inputs! >> >> We are interested in determining the best architecture at instantation >> time. What would be the best strategy? We though about running the >> same operations several times for each architecture, measure the >> results and use the fastest one for the processing blocks. Would this >> be the right approach? >> >> >> >> Carles, >> >> >> >> Run volk_profile. It does exactly what you said, and writes the results >> to ~/.volk/volk_config. Volk reads this file when it is involked (sorry) to >> determine which particular function to execute. So all you do is run >> volk_profile once on any given machine, and it's optimized. >> >> >> >> --n >> >> >> >> Carles, >> >> This is discussed on the webpage: >> >> http://gnuradio.org/redmine/projects/gnuradio/wiki/volk >> >> >> >> We'll be updating this as things progress with Volk, but the profiler >> info is there already. >> >> >> >> Tom >> >> >> >> ** ** >> > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
