On Jan 9, 2013, at 9:41 AM, Michael Dickens m...@alum.mit.edu wrote:
On Jan 8, 2013, at 4:35 PM, Johnathan Corgan johnat...@corganlabs.com wrote:
GNU Radio release 3.6.3 is available here:
For Mac OS X GNU Radio users: This morning (1/9) I updated the MacPorts'
install to this release
On Jan 9, 2013, at 4:33 PM, Alexandru Csete oz9...@gmail.com wrote:
Thanks for the detailed instructions.
I didn't have macports installed so I started from scratch. I installed
macports, then boost 1.51 according to your instructions. Then I try to
install uhd before gnuradio:
sudo
Hi Michael - Quite interesting. I wonder if the Boost folks know about this
issue; I doubt it was introduced by MacPorts since mostly they just replicate
the project's functionality. I had seen some issues recently, and had wondered
about them; I'll definitely check into this. Thanks! - MLD
After a bit of sleuthing, it turns out that this was a general Boost issue, not
just on OSX, discussed on their email list here
http://boost.2283326.n4.nabble.com/thread-thread-join-throws-in-1-52-0-td4638380.html
, in their tickets here https://svn.boost.org/trac/boost/ticket/7669 , and
Hi Tom - That's what I remembered, too, about Jenkins; and, what I had expected
about Gerrit. Give me another couple of months, and I'll be able to discuss
the use of them intelligently. Right now, I understand just the basics. And,
I'm not sure they make sense for GNU Radio given the size
I'm wondering whether the GR powers that be are thinking that GR has gotten
big enough to move to using Gerrit Git Review with Jenkins CI Server? I'm
now part of a project that's using it, and I also maintain (in MacPorts) the Qt
port and the Qt project uses this method too; so I'm learning
On Nov 22, 2012, at 11:57 AM, Josh Blum j...@ettus.com wrote:
Found another problem include: http://pastebin.com/FYvr5Sbs
Any dependency adding GRUEL_INCLUDE_DIRS to the include path might have
been causing ${Boost_INCLUDE_DIRS} to take precedence over local
directories. And who knows what
On Nov 22, 2012, at 9:53 AM, Tom Rondeau t...@trondeau.com wrote:
On Wed, Nov 21, 2012 at 1:35 PM, Josh Blum j...@ettus.com wrote:
That seems like the right idea to me, we already do this for
PYTHON_EXECUTABLE.
I would just do if(NOT DEFINED GR_PYTHON_DIR)
Otherwise, cmake might be kind
Hi Arturo - Can you load up the GRC example provided by GR:
gnuradio/examples/grc/simple/variable_config.grc ? This file works just fine
for me, no GL issues or anything, and it looks about the same as your figure
(or, maybe I'm doing something wrong?). I'm running from the latest GIT master
Hi Scott (and, anyone else trying this build using MacPorts): If you have log
files for any of these efforts, send them to me with the command line you used
that created them. That way I can try to make these ports even more robust;
and / or help you figure out what's going on with your
On Nov 26, 2012, at 5:30 PM, Arturo Rinaldi arty.n...@gmail.com wrote:
I smoothly installed the port version with
sudo port install gnuradio +docs +grc +python27 +qtgui +wxgui +uhd +volk
+wavelet +jack +portaudio +swig +sdl configure.compiler=llvm-gcc-4.2
performing a full installation.
On Nov 22, 2012, at 4:00 AM, Ian Buckley i...@ianbuckley.net wrote:
I have Xcode4.5 installed so I gave the configure.compiler=apple-gcc-4.2
idea a go.
Well, that was my bad: apple-gcc-4.2 is MacPorts' install of GCC 4.2 with
Apple modifications. Not generally what you want to be using.
Sorry Michael, you're totally right. I thought it was all ready to install
when you sent the email to the mailing list. Apologies again and keep up with
the great work :D.
No problems, and thanks! We all do the best we can, and sometimes we just
forget the small things. I certainly do :)
I just recently caught one of these order of include paths in
gr-uhd/swig. Its so easy to accidentally get it in the wrong order. I'd
like to take a look: Can you say what component is pulling in the
installed headers? Is it a specific component, swig module, etc?
Watching the debug output of
Hi Carles - Thanks for the report; I'm glad it works for you! If you installed
the gnuradio port using XCode 4.5 or newer (maybe even 4.4 or newer), then
Apple's Clang is the default compiler suite. IIRC, Volk and Clang do not play
nicely together yet; Volk (at least as of the 3.6.2 release)
I just updated the GNU Radio ports in MacPorts to the latest release (3.6.2),
GIT master (commit afea463f07), and GIT Next branch (commit c0b35b4ec7). By
using a single Portfile for all 3 versions, I should be able to maintain the
ports more easily and keep the more up to date as releases and
That would be my bad. I just checked in that file, so it will appear when you
do a selfupdate within 30 minutes from this email. Things will work a LOT
better when that file is available. :) - MLD
FIRST ERROR on Lion 10.7.5 and MacPorts 2.1.2, can't fetch teh patch file :
Error:
Running Mac OS X 10.8.2, XCode 4.5.1, Apple clang 4.1. On both the current
master and next, I get the same error when building. Compiling both the master
and next works fine using gcc (both apple gcc 4.2, and apple llvm gcc 4.2).
{{{
[ 5%] Building C object
On Nov 5, 2012, at 5:21 PM, Tom Rondeau t...@trondeau.com wrote:
I just tested that on my Linux machine and nothing seems to suffer for
it. I doubt that we require it. I've just posted this branch on my
github repo git://github.com/trondeau/gnuradio.git called
asm_for_clang.
This shouldn't
Turns out it's more than just making sure cmake checks for sincos(f) and
defines HAVE_SINCOS(F). I'll push a branch with fixes once I figure out how to
do that. - MLD
On Nov 1, 2012, at 1:44 AM, Josh Blum j...@joshknows.com wrote:
On 10/31/2012 06:20 PM, Michael Dickens wrote:
… nor sincosf
It turns out that gr-qtgui isn't compatible with the QWT 6 API. It works with
QWT 5.2.1 and 5.1.2; I don't know about 5.0.2 or earlier.
Does anyone know if there a (simple) way in CMake to check that the library is
-not- of a specific version? For example:
find_package(Qwt 6)
where the 6
On Nov 1, 2012, at 12:04 PM, Tom Rondeau t...@trondeau.com wrote:
gr-qtgui /should/ be compatible with QWT6. I've been running it on
QWT6 on my systems since 12.04 came out. If there are specific
problems, we can patch it.
If you look inside the code, there are quite a few places where
Hi Sebastian - Are all of the dependencies installed using MacPorts? Which
version of XCode are you using? Have you tried building from the GIT master to
see if that version works? Those are starting points; once I know more, we can
narrow down possible issues. - MLD
On Sep 11, 2012, at
. If you're still
having issues after Josh's latest, send me an email off-list and I'll try to
help you work it out. - MLD
On Sep 10, 2012, at 3:05 AM, Ben Reynwar b...@reynwar.net wrote:
On Mon, Aug 6, 2012 at 6:43 AM, Michael Dickens m...@alum.mit.edu wrote:
% make VERBOSE=on
[snip]
/opt/local
Hi Arturo - If you check the CMakeCache.txt file in the top level build
directory, I think you'll find that the PYTHON variables do not match up --
some are for 2.6 while others are for 2.7. Supply the desired values on the
cmake command line (cmake -DPYTHON_FOO=BAR ...), recheck the
Both UHD and GNU Radio compile and work for me on OSX 10.8.1 and Xcode 4.4.1,
with just a few -Ds on the cmake command line. I'm wondering if you've fully
installed XCode; I follow the list found at
https://trac.macports.org/wiki/ProblemHotlist . If you don't do all the right
steps, XCode
I'm running OSX 10.8.0, Xcode 4.4, latest updates; all background dependencies
are installed as both 32 and 64 bit, and includes orc. Please let me know
what tests I can run to get more/better info to help correct this issue. - MLD
% clang --version
Apple clang version 4.0
Looking at the CMakeCache.txt file, I don't see CMAKE_C_COMPILER_ID. I do see:
//CXX compiler.
CMAKE_CXX_COMPILER:FILEPATH=/usr/bin/c++
//C compiler.
CMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc
which result in:
% /usr/bin/c++ --version
Apple clang version 4.0
% /usr/bin/gcc --version
Hi Giulio - It looks like GNU Radio is trying to mix and match between Python
2.6 and 2.7. This, in general, is not advisable; try to coerce GNU Radio into
using one or the other. Fix that first, then see if there's still an issue.
If so, maybe someone with knowledge of the rtl2832_source
Hi George - I believe there are 2 possible solutions, though I've never used or
tested either myself. If you just want to verify that what you want to do
works, I think (1) should be quite straight forward.
1) This method will certainly work, but it's not very robust : Make your
custom_block2
On May 25, 2012, at 12:51 PM, Philip Balister wrote:
wxwidgets are not on the the e100, so no worries there. You will need to
disable the QT stuff though. I'm not certain what the variable is though.
-DENABLE_GR_QTGUI=ON/OFF
___
Discuss-gnuradio
Hi Steve - I'd like to say I have, but I haven't yet. I'm still using 10.6.8,
and have a long queue, probably a month or so, before I really get around to
GNU Radio on 10.7.X. The only thought I have is whether MacPorts was installed
into /opt/local or /usr/local ... if the former, then I'm
I just pulled the latest GIT master, cleaned out everything old, then the usual
cmake. Make errors out with:
[ 3%] Building C object volk/lib/CMakeFiles/volk.dir/volk_cpu.c.o
/var/tmp//ccrCnwC2.s:221:no such instruction: `xgetbv'
I'm running OSX 10.6.8, XCode 3.2.3, gcc 4.2.1. - MLD
expertise in assembly
language programming. Hopefully the VOLK-programmers-that-be can find a quick
fix. - MLD
On Apr 18, 2012, at 9:40 AM, Philip Balister wrote:
On 04/18/2012 09:28 AM, Michael Dickens wrote:
I just pulled the latest GIT master, cleaned out everything old, then the
usual cmake
[ 3%] Building C object volk/lib/CMakeFiles/volk.dir/volk_cpu.c.o
/opt/GNURadio/source/builds/jblum_gr/volk/lib/volk_cpu.c:51:43: error: missing
binary operator before token (
On Apr 18, 2012, at 12:44 PM, Josh Blum wrote:
On 04/18/2012 06:28 AM, Michael Dickens wrote:
I just pulled
On Apr 18, 2012, at 2:20 PM, Josh Blum wrote:
volk_work fix:
https://github.com/guruofquality/gnuradio/commit/578a4d858c3f765417b0d9560e5f8de29dde4e20
OK; I now see the commit you reference from your github account. I 'rm -rf'
the build directory, recreate it, do cmake, then make:
[ 3%]
Hi Barry - In order to help you out, we (the list) need the OS and build system
info. Although buried a bit, 3 clicks from the top-level wiki on gnuradio.org
is Mailing Lists :: Reporting Errors :: I've done everything above, and I
still have a question. How do I ask it? [1]. I encourage you
into this issue at
the end of this week unless someone else gets there first :) - MLD
On Apr 9, 2012, at 6:08 AM, Steven wrote:
On 9 Apr 2012, at 01:16, Michael Dickens wrote:
Does anyone have any pointers as to where I should be looking?
Hi Steven - First, the humor http://xkcd.com/138
Does anyone have any pointers as to where I should be looking?
Hi Steven - First, the humor http://xkcd.com/138/ .
Do ipcs -a to see how many shared memory attachments are in place. You might
see a lot, given that 'shmat' returns 'too many files open'. Here's the BASH
script I run, very
Mikko - It looks like you're using the GNU Autotools for building, yes? If so,
try using CMake instead; 'volk' in particular compiles must more robustly using
CMake. I don't know that I've ever gotten volk to compile using GNU Autotools,
but I've almost never had an issue when using CMake.
I found this post quite useful, interesting, and relevant for projects such as
GNU Radio.
http://www.softwarequalityconnection.com/2012/03/14-ways-to-contribute-to-open-source-without-being-a-programming-genius-or-a-rock-star/
The following post is more of a summary, specifically with
Nice job, RTL developers! - MLD
http://hardware.slashdot.org/story/12/03/31/1914217/software-defined-radio-for-11
Don't have $1500 to drop on a USRP? A Linux kernel developer has discovered
that a Realtek digital TV tuner chip has an undocumented mode that turns it
into a software-defined
Hi Rickard - I have about your setup, and it works well for me. I use MacPorts
for all of the background dependencies, then I install UHD, then GNU Radio,
both from GIT. I'm using Mac OS X 10.6.8 64-bit, XCode 3.2.3 (gcc 4.2.1), and
MacPorts' Python 2.7; I find that MacPorts' Python 2.6
As Martin wrote, the shortest answer is: no, or, well, not really or not
always. Under some circumstances this could be made work at least sometimes,
but I don't think you can guarantee it all of the time. For example, many of
the OFDM blocks always process exactly 1 packet's or FFT's worth
On Mar 22, 2012, at 9:55 AM, Arturo Rinaldi wrote:
I think i've sorted out the dependencies for building gnuradio on Lion 10.7.3
sudo port install boost icu cppunit fftw-3-single gawk \
readline gsl texinfo guile python27 py27-numpy py27-nose py27-distribute \
libsndfile portaudio
Hi Ben - Ditto Martin: great stuff! I think keep filling in the blanks is my
improvement recommendation :) -- some items contain This docstring is not
useful or the equivalent, or are just empty (e.g.,
gnuradio.optfir.band_pass). I'm guessing some items are like this because
the source code
Hi David - I'm glad you got JACK going. I don't use JACK myself, so I don't
know how jackd works. Maybe someone else on this this does? - MLD
On Mar 7, 2012, at 3:47 PM, David Kierzkowski wrote:
ok thanks for the reply
i finally made some progress and have jack support compiled in now.
If JACK was not found at configure time, it will not appear in the audio
registry at application initialization time (before main is executed). try
going back to 'configure' (or cmake) to see what it thinks is going on. - MLD
On Mar 6, 2012, at 10:19 AM, dave k wrote:
ok i jsut discovered
It looks like you have a mixed install, somehow, of MacPorts stuff; some older,
some newer. If you haven't done it recently, I'd recommend:
sudo port selfupdate
sudo port upgrade outdated
and, if that breaks, do:
sudo port clean outdated
sudo port -p upgrade outdated
and then report the
Hi Carles - That's great to hear! I take it that you don't have WX installed?
Using the QtGui really is nicer anyway :) But, having gnuradio-companion is
also nice ... maybe there is some other dependency that isn't getting met for
GRC? - MLD
On Mar 3, 2012, at 6:18 PM, Carles Fernandez
, Carles Fernandez wrote:
On Sun, Mar 4, 2012 at 12:22 AM, Michael Dickens m...@alum.mit.edu wrote:
Hi Carles - That's great to hear! I take it that you don't have WX
installed? Using the QtGui really is nicer anyway :) But, having
gnuradio-companion is also nice ... maybe there is some other
Hmm ... not sure what's going on. When you're in Python, can you do import
gtk successfully? That's what CMake is testing for, roughly. If it can't,
hopefully the error will shed some light as to what's going on. - MLD
On Mar 3, 2012, at 9:16 PM, Carles Fernandez wrote:
Well, actually I
On Mar 2, 2012, at 9:39 AM, Arturo Rinaldi wrote:
can i build the master git branch on macos X 10.7.3 with cmake ? have i to
satisfy the build pre-requisites with macports as usual ?
Hi Arturo - I believe that if you use MacPorts to install the background
dependencies -- just do sudo port
Hi Ben - I like the look of the generated HTML much more than that done by
Doxygen. That said, there is a serious deficiency ... maybe this is the
continuing down this path of which you speak: Is there any way for specific
blocks to get sphinx to generate actual arguments?
Hi Nazmul - If you use the GNU Radio GIT master and update it regularly, I
think that
GNU Radio Website, accessed February 2012. [Online]. Available:
http://www.gnuradio.org
is complete enough, since it refers to both the project in general as well as
the code. If you use a specific version
Hi Florian - Interesting observation about better reception when using larger
bandwidths. I tried it out, and yes indeed they do seem better at 1 MS/s
compared with 250 or 500 kS/s -- meaning that more packets are received
correctly at the higher rate than the lower rates. I didn't try 1
On Feb 21, 2012, at 9:44 AM, Tom Rondeau wrote:
It's because with the larger bandwidth, the subcarriers, too, have a larger
bandwidth. The coarse frequency correction is only set to look at so large an
offset based on a number of subcarriers (+/-5 or 10), so now with the same
frequency
On Feb 21, 2012, at 10:05 AM, Tom Rondeau wrote:
Are you seeing the 1 MHz offset when you use the uhd_siggen.py? Or is it just
with the OFDM transmitter?
I do see it with uhd_siggen.py. Didn't know about that utility; cool! - MLD
___
I've been playing with the gr-digital OFDM benchmark, Tx - Rx, and have an odd
issue that seems to be coming from within GNU Radio itself, not UHD. My setup
is: Mac OS X 10.6.8, latest UHD and GNU Radio from their respective GIT
masters, XCode 3.2.3 (gcc 4.2.1). I'm using 2 USRP1's, each
Given the discussion at the GNU Radio Conference about GSoC, what do our
fearless leaders say about giving it a try this year? Josh, with all his
amazing programming capabilities, can only do so much ;) - MLD
http://google-opensource.blogspot.com/2012/02/google-summer-of-code-2012-is-on.html
Is this for autotools or CMake? The CMake build (new master) works using -j2
for me (OSX 10.6.8, XCode 3.2.3; gcc 4.2.1); haven't tried the autotools build
because it has issues I've mostly transitioned to using CMake instead. - MLD
On Jan 20, 2012, at 10:40 AM, Tom Rondeau wrote:
I just
You can always do what William Plishker (et.al) did for their GPU work -- go to
http://gnuradio.org/redmine/projects/gnuradio/wiki/GRConf2011 and look for
GPGPU. They create a separate (but shared among the various process threads),
non-kernel memory buffer, and then place a pointer (or
Hi Ed - I build from their respective GIT masters, not from those specific
releases; but, yes, they seem to work for me. I use CMake for both, since (1)
GNU autotools is on the way out; and (2) it works better (e.g., I don't have to
disable Volk). - MLD
On Jan 11, 2012, at 2:25 PM, Ed
On Jan 5, 2012, at 6:32 PM, Arturo Rinaldi wrote:
could you list the dependencies to install trough macports to build gnuradio
from source on OS X Lion ? the gnuradio port of macports fails to build.
port rdeps gnuradio | sed -e 1d | awk '{ print $1 '} | sort | uniq | grep -v
gnuradio
GR builds on OSX just fine, with autotools or CMake. CMake is a bit easier
more of the components compile correctly using it. On OSX, the UDP stuff
compiles just fine, but I don't think it works correctly. I've never debugged
it further. Very possibly moving to Boost ASIO would solve that
On Dec 18, 2011, at 3:41 PM, Tom Rondeau wrote:
The differences, though, coming in the naming scheme and installation
method. Instead of having a gr_name.h file installed into
$prefix/include/gnuradio, it's just name.h that is installed into
$prefix/include/gnuradio/blocks. Likewise, the
http://europe.wirelessinnovation.org/mc/page.do?sitePageId=118803orgId=s2
SDR'12 WInnComm Europe will be in Brussels, Belgium, June 27-29, 2012.
It's a long ways to go, but Brussels is a great walking city worth the travel
if you can find a way to get there pay for it. They will look at
Last I checked, volk didn't compile on OSX yet -- but my knowledge is probably
a month old now, so things might have changed. I just compile with volk
disabled. Maybe Johnathan can comment more about volk working on OSX? - MLD
On Oct 31, 2011, at 12:02 PM, Dimitris Symeonidis wrote:
I'm
OK == false: when the RX packet's embedded CRC32 does not match that computed
using the RX'd payload data. In other words, if there are RX errors in the
RX'd packet's header, payload, or CRC32, then with high probability OK == false.
On Oct 9, 2011, at 10:06 AM, bharadwaj desikan wrote:
Application Process: Students wishing to apply should complete the form
supplied below. Applications must be completed by no later than 9 October
2011.
FYI: From the actual application form
https://sdf.memberclicks.net/index.php?option=com_mcview=mcmcid=form_105692
, it looks like they
On Sep 25, 2011, at 8:39 PM, Ben Reynwar wrote:
It wasn't that python2.5 didn't work, rather that macports didn't
attempt to install gnuradio for that version. Instead it installed
python2.6 and setup gnuradio for that. I've never messed about with
macports scripts so I don't know why that
If you use MacPorts under Mac OS X 10.5, .6, or .7, sudo port install
gnuradio should work as of this morning for installing all of the background
dependencies (and, version GR 3.3.0 from the tarball if that's good enough). I
had to fix SDCC 2.9 to work under 10.7, as well as tweak GNU Radio
On Sep 22, 2011, at 1:41 AM, Achilleas Anastasopoulos wrote:
[source] -- [block A] --[sink]
|___^
Just to clarify ... is your graph:
connect (source, A, sink)
connect (source, sink)
I don't know for certain why the loads are different, but I can make some
educated
Thank you, Tom, for organizing the conference. I certainly feel it was
successful, and look forward to next year's. Beyond the presentations -- which
it's great to see up already -- would it be possible to post demos, or links to
some repository containing the demos, that used GNU Radio /
On Sep 22, 2011, at 11:40 AM, Tom Rondeau wrote:
Thanks for the reminder. Forgot about this last night. They are now available
as a tarball.
Awesome; thanks.
My plan is to make these into hierarchical blocks that will be put into the
GNU Radio source code so that it's easy for people to
On Sep 22, 2011, at 1:00 PM, Nick Foster wrote:
Well, in answer to question 1, you don't need a throttle to avoid system
instability. You really use the throttle to keep your computer from becoming
entirely unresponsive when you have multiple threads with high priority
running
Unless Josh changed something recently, the cmake build (with volk disabled)
worked for me under 10.6.8, XCode 3.2.3, 64-bit. It looks like Ben is doing
this testing on 10.5.8, XCode 3.1.4 -- which by default will use 32-bit for
either PPC or Intel compiling, and, really, getting 64-bit was
Hi Ben - I believe that Volk (in general, not just the Python version) doesn't
play nicely with OSX (any version) yet. Use --disable-volk on the configure
command line to disable it, and everything else should work. - MLD
On Sep 10, 2011, at 5:24 PM, Ben Reynwar wrote:
Just tested the cmake
Use --disable-volk on the configure command line to disable it, and
everything else should work.
Right. CMake. Use what Josh said: -DENABLE_VOLK=OFF on the cmake command line.
I'm still in GNU autotools mode. - MLD
___
Discuss-gnuradio mailing
As a bit of history, I wrote the OSX audio interface back in Winter of 2005/6;
it was designed for OSX 10.4, and IIRC worked under 10.5 without changes. 10.6
introduced some small changes, which is where the GR_USE_OLD_AUDIO_UNIT came
from -- someone else did the work, and I helped test it.
As I've thought about what you wrote, Nick, the more I like it. As you say, it
won't work for every block -- but there are certain blocks that would benefit
from doing in-place computations, avoiding the extra 1 or 2 buffer copies per
call to work. And, the implementation needs to be
On Aug 30, 2011, at 9:34 AM, Tom Rondeau wrote:
On Mon, Aug 29, 2011 at 8:55 PM, Marcus D. Leech mle...@ripnet.com wrote:
One idea, which I credit to a conversation I had with Frank Brickle some
months ago, is the ability to synthesize a new block using a collection
of sub-blocks, and have
The DYLD_LIBRARY_PATH is not being set in the shell script when using CMake.
It is being set when using autotools (in the run_tests.sh file). Maybe this
makes a difference? - MLD
Take a look at
/opt/GNURadio/git/builds/cmake_next/gnuradio-core/src/python/gnuradio/gr/qa_agc_test.sh
and see
Testing on OSX 10.6.8, XCode 3.2.3 (gcc 4.2.1 with Apple tweaks), MacPorts
2.0.0 for all other dependencies. It looks like that configure' and 'build'
CMake logic is pretty good. I'd guess there's an issue with how 'Python' is
called during the 'test' stage.
From the top-level git directory,
On Aug 19, 2011, at 11:24 AM, Josh Blum wrote:
OK, make sure that if this was checked out from an old repository that
you git cleaned -dfx to remove any old in-tree generated headers. That
could have caused some of the problems you are seeing.
Can you send me
On Aug 19, 2011, at 3:27 PM, Josh Blum wrote:
Command: /bin/sh
/opt/GNURadio/git/builds/cmake_next/gnuradio-core/src/python/gnuradio/gr/qa_agc_test.sh
Directory:
/opt/GNURadio/git/builds/cmake_next/gnuradio-core/src/python/gnuradio/gr
qa_agc start time: Aug 19 09:41 EDT
Output:
Assuming you're using the thread-per-block scheduler, then you just need to
make sure any data dependencies are met so-as to not hang the scheduler --
which I think would be pretty hard to do. See also
gnuradio-core/src/lib/general/gr_throttle.cc. - MLD
On Jul 18, 2011, at 3:15 PM, Colby
Hi Ryan - I just did a clean uninstall, git pull, then reinstall of the current
master; I don't see this issue at all (e.g., the dial_tone.py example works
just fine -- though I don't know which audio interface is being used). I'm
running 10.6.8 on a MacBook Pro (early 2009 model), 64-bit
After disabling Jack and PortAudio, I see the same issue. What -were- you
thinking, Josh, when you integrated the audio components together? I think
you're secretly biased against OSX :) JK (really, I am just kidding)!
Tom Johnathan : Here's the patch code to fix this issue; it replicates
Great! Johnathan has already incorporated it into the various GIT branches, so
us OSX users should be good to go again. Thanks for reporting it; I wouldn't
have found that bug with my default setup. - MLD
On Jul 6, 2011, at 10:28 PM, Ryan Pape wrote:
Patch worked perfectly. Thanks for the
On Jul 5, 2011, at 10:50 PM, Colby Boyer wrote:
Not clear to me how to use them to effect non-uniformly-spaced channels.
Also, individual channels will have their own bandwidths.
See also: Polyphase Filter Banks For Unequal Channel Bandwidths And Arbitrary
Center Frequencies by fred harris
One should be able to pretty easily do a single buffer (map or not), or double
map buffer. Either way, one needs to check for wrap.
The former (single buffer), as Josh states, requires a memory copy every so
often (when wrap happens). There is a trade-off between buffer allocation size
and
If gnuradio-companion is installed by MacPorts (e.g.: sudo port install
gnuradio-companion, or sudo port install gnuradio), then Cheetah should also
be installed -- and with the correct Python version to work with GNU Radio.
One can see this via port installed | grep cheetah and then verify
2 comments:
1: Apple's GCC variant does not provide a fortran option (at all); maybe it can
be hacked on, but I don't know of a project that's done that. You're better
off getting the vanilla GCC compiling it with fortran enabled, or go with a
fortran-specific project instead.
2: IIRC numpy
On May 31, 2011, at 3:03 PM, Elvis Dowson wrote:
a. gcc-llvm-4.2 supplied with Xcode-4.0.2 package (paid version) appears to
build all the libraries, just like the standard gcc-4.0.1 from the older
Xcode-3.2.x series.
TTBOMK, and, really, this is kinda off list-topic by now:
Before XCode 4,
On May 28, 2011, at 11:26 AM, Alexander Chemeris wrote:
5) How well is GnuRadio suited for real-time operation?
In a general sense, yes, GNU Radio is well suited for real-time signal
processing of data streams. That said: Real time is only meaningful knowing
the performance criteria. What
Hi Alexander - I think Martin Tom covered that GNU Radio is quite capable of
being programmed for the basic receiver processing. You might need to play
around a bit with your DSP blocks, but otherwise I think GNU Radio's data
processing is up to the task.
On May 23, 2011, at 3:50 PM,
On May 17, 2011, at 5:39 PM, Tom Rondeau wrote:
What I'm now seeing, and this where the recent UHD apps comes in, is that
there we really have a lack of developers.
What it seems to come down to is a lack of initiative. We are all willing to
wait until someone else does something for us,
Just as a data point for comparison: Using MacPorts for all of the necessary
requirements; and the latest GIT masters of UHD and GNU Radio; I don't see
those check failures. I still get the socket connect: Connection refused on
that test, but that's expected. - MLD
On May 16, 2011, at 1:31
On May 16, 2011, at 3:35 PM, Elvis Dowson wrote:
I built the latest gnu radio-3.4.0 and for that, make check passed the
earlier test, but failed at the socket connection test that you mentioned.
However, when I run grc and run the dial tone example, audio doesn't work on
OS X with gnu
601 - 700 of 1164 matches
Mail list logo
