as the actual library file), or one of the
linked-to libraries is not correct.
CMake has settings to correct that, which I can pass on if this is the issue;
it's an easy fix to some CMakeLists.txt files.
Hope this helps! - MLD
--
Michael Dickens, Mac OS X Programmer
Ettus Research Technical Support
Hi Ulf - Your directory listings look OK. Ideally, you'd actually use
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages
as the Python files install location since that's the normal for MacPorts.
But, using /opt/local/lib/python2.7/site-packages is OK and
On Jan 14, 2014, at 1:24 AM, Bastian Bloessl bastian.bloe...@uibk.ac.at wrote:
...I guess you are talking about changing the RPATH. Can you please point me
to a module that does it right so that I can change it? I checked several but
didn't find the relevant parts.
Not RPATH; that's messed
Sure; if it's not in there already, it should be. I much prefer -all- binaries
(executables, libraries, shared objects, etc) to have correct linkage include
self-id -- because it's good coding practice as much as anything else. I say
go for it. One of these days I'll get around to trying out
On Jan 15, 2014, at 12:46 PM, Martin Braun martin.br...@ettus.com wrote:
OK, can you please make sure I didn't mess anything up here. It's a
pretty simple patch, but I know bugger-all about OSX :)
https://github.com/mbr0wn/gnuradio/commit/5743258c3329824761de2823a8b59fd91a992965
Just give
Hi Bastian - Your change (commit 340cda20) looks like it should do the trick
for the primary library. Thanks for getting that added, and so promptly! - MLD
On Jan 15, 2014, at 12:44 AM, Bastian Bloessl bastian.bloe...@uibk.ac.at
wrote:
I never heard about install_name_dir, but I just pushed a
I was playing around with gr-baz in MacPorts just now, and it requires the 3.6
API ... anyone know if this has been updated to the 3.7 API? Balint? I'm not
going to add it to MacPorts just for GR 3.6 ... - MLD
___
Discuss-gnuradio mailing list
I was playing around with gr-fcdproplus
https://github.com/dl1ksv/gr-fcdproplus in MacPorts just now, and it requires
Linux (e.g., uses pthread_barrier_t and clock_gettime) ... anyone know if
there is another version which is more OS compatible? - MLD
Hi Kai - gr-rds is now in MacPorts if you want to install it from there. That
said, if it works from you outside of MacPorts, that's great too! Mine works
nicely with a Jawbreaker, but not with my B210 because there are some issues
between gr-osmosdr and UHD that we're now working on
Awesome; I'll try it out shortly. - MLD
On Jan 20, 2014, at 6:52 AM, Volker Schroer dl1...@gmx.de wrote:
I just made some changes to CMakelist files on gr-fcdproplus on github to
hopefully run on OSX, now:
hidmac.c and some IOKIT libs should be used if osx is detected, and the xml
grc
Not quite yet. I'll send you a pull request shortly. - MLD
On Jan 20, 2014, at 8:31 AM, Michael Dickens michael.dick...@ettus.com wrote:
Awesome; I'll try it out shortly. - MLD
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https
Volker (dl1ksv) and I fixed the build issues with gr-fcdproplus on OSX in the
past couple of days, and this morning I pushed the gr-fcdproplus port to
MacPorts https://trac.macports.org/changeset/116194 ; I also changed the
gr-osmosdr port to by default include this new gr-fcdproplus port
On Jan 26, 2014, at 11:23 AM, Volker Schroer dl1...@gmx.de wrote:
In brief: Depending on the settings make test does not always test what
should test.
Hi Volker - If GNU Radio is already installed into the PREFIX provided to cmake
during configuration, then during make test some of the
On Feb 3, 2014, at 10:14 AM, Nemanja Savic vlasi...@gmail.com wrote:
at the moment I thought that the problem was solved, but actually something
strange is going on. I would only like to ask whether delay between two paths
can roll out somehow (i don't know if this verb exists). The point is
Hi Nemanja - Non-sync blocks -- ones that do not guarantee some number of
output items given some number of input items -- cannot be assumed to have
constant sample delay from input to output (or, in any other way; though they
may have this property). This property is irrespective of what the
it's done.
Thanks! - MLD
--
Michael Dickens, OSX Programmer
Ettus Research Technical Support
Email: supp...@ettus.com
Web: http://www.ettus.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss
difficult this would be for any other
audio option, but I generally like the idea.
What do others think? - MLD
--
Michael Dickens, OSX Programmer
Ettus Research Technical Support
Email: supp...@ettus.com
Web: http://www.ettus.com
___
Discuss-gnuradio
On Feb 10, 2014, at 10:05 AM, Philip Balister phi...@balister.org wrote:
Any updates?
Nope. Maybe folks are working on this in secret? TTBOMK, there was some
discussion and excitement directly after GrCon13, and then everyone found that
we had other things that required our attention and so
Hi Zhou - Can you post some links to relevant papers / research, for folks like
me to do a quick look at? I studied MIMO just a little bit, mostly from an IT
perspective, not a practical one. But, I've read through a lot of papers (on
many subjects) and would be interested in knowing more
Hi Zhou - I think it would be great to see how far GNU Radio can be pushed with
respect to MIMO processing. With advances in both algorithms and multi-core
CPU raw processing capabilities, the added computational requirements for MIMO
might be realizable at some reasonable level (IIRC, they
On Feb 20, 2014, at 10:58 PM, Bruce bruce...@yahoo.com wrote:
Where did you find that particular install?
Hi Bruce - Ed is talking about using MacPorts to install GNU Radio; see also
the various wiki pages related to these topics:
went smoothly without errors and installed
a working copy of 3.7.2.1 with only a few operational
issues.
Hats off to Michael Dickens for his superb job of supporting
GnuRadio on OSX!! :)
Michael,
I got the following when starting gnuradio-companion:
===
** (process
I just pushed the latest WIP for fixing gr-audio on OSX; I hope some
adventurous OSX users can test this branch out provide feedback! If you want
to help, but don't know how, ask me and I'll provide instructions. - MLD
https://github.com/michaelld/gnuradio/tree/fix_gr_audio_osx
Fixes that
I'll second what Moritz wrote: Since this pragma is non standard but widely
supported, let's stick with the header guards since they are guaranteed to
work even with very old C / C++ compilers ... if someone wants to -also- use
this pragma that's fine; having both should not hurt. I'd prefer
I know I could look to Google / do an internet search, but maybe asking here
would be better.What is/are the -seminal- paper/s on parallel log-map-siso
decoding?
I implemented the non-parallel version of the log-map algorithm -way- back in
2001 on whatever the portable Mac was at the time
Another update to https://github.com/michaelld/gnuradio/tree/fix_gr_audio_osx
:
+ the audio source should be working fully now; I've tested with both the
built-in mic and a FUNcube Dongle Pro (not Pro+) and device selection works and
sample rates are correct;
+ audio source devices can be
Hi Kevin - Thanks for the feedback and related info; it's nice to hear from
another GR on OSX user! I'll push changes to the sink either today or tomorrow
for testing. - MLD
On Feb 26, 2014, at 12:33 AM, Kevin Reid kpr...@switchb.org wrote:
For the audio source, flowgraph
submission; please keep them coming! The submission period
will close on 04 April 2014, and we will announce the selected presentations on
14 April 2014. Tom Rondeau and I will be leading the selection process.
Best Regards,
Michael Dickens
GNU Radio Conference 2014 Co-Organizer (one of a few)
[0
I just pushed the latest changes to my gr-audio OSX test branch:
https://github.com/michaelld/gnuradio/tree/fix_gr_audio_osx
fix gr-audio osx:
+ use GNU Radio preferences file to set default input and output audio device,
if provided;
+ use gr::logger for all non-debug messages;
+
I just pushed the latest, and, maybe, final, changes to my gr-audio OSX test
branch:
https://github.com/michaelld/gnuradio/tree/fix_gr_audio_osx
The latest changes move the osx_impl functions into gr::audio::osx, use them
correctly, and install the osx_impl.h header (with the other audio
To all GSoC'14 potential participants: The application period for GSoC'14 is
open (as of Monday, March 10). The deadline for getting your application in is
Friday, March 21 @ 19:00 UTC (3 PM/US/ET). I've added some read me links to
the GR Wiki GSoC Manifest page
Xcode 5.1 is for both OSX 10.8 and 10.9 only, so this note applies to both of
those OSX versions.
The new Xcode 5.1 breaks Boost compilation, which in turn breaks UHD and GNU
Radio compilation (in similar ways). Boost upstream already issued a patch to
fix this issue, and it is already
Hi Kunal - Following up from Martin's comments:
* You'll want to address some of the items listed on the GR GSoC Student wiki
page http://gnuradio.org/redmine/projects/gnuradio/wiki/GSoCStudentInfo --
for example:
+ Will GSoC be your only job, or will you have other things you -must- be
sudo port upgrade gnuradio
}}}
or, if you want to be thorough:
{{{
sudo port selfupdate
sudo port upgrade outdated
}}}
This update should work for both gnuradio (3.7.3) and gnuradio-devel (3.7.4 git
69dcaa75). Enjoy! - MLD
--
Michael Dickens, OSX Programmer
Ettus Research Technical Support
Hi Stefan - Nice proposal overall! Some items you'll want to address somewhere
(either in the Melange area or in your proposal document):
+ How long have you been on the GR discussion list? Do you participate
regularly?
+ Have you contributed any code back to GR or any other open-source
Hi Abhishek - Your proposal is coming along nicely! I'll 2nd (or, maybe 3rd by
now) encouraging you to get your proposal into Melange so that we can comment
on it there more. My up-front comment is that you probably want to state that
OpenAirInterface is wholly licensed under the GPLv2 ( and
We have a great selection of GSoC'14 proposals coming in! Here are a couple
quick reminders, primarily for GSoC students (but, everyone can benefit):
1) Please note that the deadline for submitting your proposal to Google Melange
is Friday, March 21, 19:00 UTC.
2) If you update your proposal
on
2014 April 14. Tom Rondeau and I will be leading the selection process.
Best Regards,
Michael Dickens
GNU Radio Conference 2014 Co-Organizer (one of a few)
[0] GRCon14 Location : AIA DAC Website
http://aiadac.com/
[1] GRCon14 Main Website
http://gnuradio.squarespace.com/gnu-radio-conference-2014
Hi Gayathri - I'll email you off-list with what to try to get the N210 working
again. - MLD
On Mar 26, 2014, at 8:08 PM, Gayathri Ramasubramanian grama...@vt.edu wrote:
Though I have burned the latest images of usrp_n210_fw.bin and
usrp_n210_fpga_r4.bin into usrp ,still it is not working. I
Hi Shane - With just the information provided, given that CMake is trying to
link against CppUnit means that that library was found somewhere. Hence,
chances are that CppUnit is being linked to libstdc++ while GNU Radio is trying
to use libc++ -- the different C++ runtime libraries tend to
Hi Ed - I'm glad to hear that GNU Radio 3.7.2.1 installed without issues using
MacPorts for you. 3.7.3 was released not long ago, and contains some nice fixes
-- especially for audio on OSX. You can
{{{
sudo port selfupdate
sudo port upgrade outdated
}}}
to get it (and, everything else that's
. We will announce the selected presentations on April 21.
Best Regards,
Michael Dickens
GNU Radio Conference 2014 Co-Organizer (one of a few)
* GRCon14 Call For Presentations
http://gnuradio.squarespace.com/grc2014-call-for-presentations/
___
Discuss
The audio sinks (all of them, to the best of my knowledge/understanding) do
nothing special when it comes to data channel synch. That's just not their job
(timing such as overflow or underrun might be, but that's a different issue
than being covered here). They should assume that incoming
Hi Ed - Are you asking whether you can reuse the same namespace and block name
with an OOT module? If so, then so long as you don't load the library
containing the GR-provided block(s), you can make it work -- it's a C++ issue
rather than anything else. That said, it would generally be better
% ctest -V -R python_message
UpdateCTestConfiguration from
:/opt/MacPorts/trunk/dports/science/gnuradio/work/build/DartConfiguration.tcl
UpdateCTestConfiguration from
:/opt/MacPorts/trunk/dports/science/gnuradio/work/build/DartConfiguration.tcl
Test project
In MacPorts, the header is installed as zmq.h, not zmq.hpp. I can easily
fix this if somebody else doesn't want to / if I need to, but I have a lot on
my queue right now. I'm just disabling ZMQ in the MacPorts install for now. -
MLD
{{{
:info:build In file included from
If I look through the tarball for zmq 3.2.4 or 4.0.4, I find only zmq.h, no
zmq.hpp. From the look of it, zmq is written as mixed C/C++, and the API
header is purely C (wrapped with extern C if included as C++). Hence, I
think the CMake Find file needs to check for both zmq.hpp and zmq.h as
*d_socket;
:info:build ^
}}}
So ... it seems like unless there's some standard way to get zmq.hpp then we
won't be using gr-zeromq on OSX. Any ideas? Can someone send me that file? -
MLD
On May 19, 2014, at 3:59 PM, Michael Dickens michael.dick...@ettus.com wrote:
If I look through
Yes, that's what the issue is: YA dependency! Thanks for your prompt feedback!
I'll look into creating a cppzmq port, since one does not currently exist.
We'll need to add CMake support for checking for this dependency, too. - MLD
On May 19, 2014, at 10:39 PM, Ben Rosenbloom
I won't repeat what has already been written by others, but I will agree with
them that my primary means of GR related help and discussion is this email
list, IRC, and personal emails. My Facebook account is not used for work
purposes, and I have no use for a work FB account; so, I won't be
I added a cppzmq port that installs this header, which depends on one of the
various zmq* ports (2.0, 2.2, 3.2, 4.0). All is happy now within MacPorts, but
the FindZeroMQ.cmake file needs to be updated to look for this header (it just
looks for zmq.h and libzmq).
-Sometimes- the test
Hi Pengyu - The way testing works right now under OSX (assuming you're using
OSX and MacPorts, yes?), you have to specify -all- of the dependency paths
correctly before calling GR_ADD_TEST. The test_howto is probably a C++
compiled executable, which CMake will know how to link correctly
wrote:
there's already a macports bug for that:
https://trac.macports.org/ticket/43445
and it seems that Michael Dickens (the GNU Radio Macports maintainer) has
proposed a solution.
Could you try that? (and maybe the port clean --all gnuradio; selfupate;
install gnuradio first)
On 25.05.2014
Over the weekend, I helped out a couple people trying out the gr-howto example
on OSX http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules .
The common are of issue -- which admittedly is primarily an OSX issue -- is
that the Python info which was used by GNU Radio's CMake
OK; good arguments. Hard-coding into OOT module == bad. Agreed.
Maybe something more along the lines of: When GR is installed, create a
${prefix}/etc/gnuradio/install.cfg file that contains what GR CMake found, in
a file that's easily loadable by CMake. Then in the gr-modtool OOT module
CMake 3.0.0 has lots of bug fixes from the last release (2.8.12), and it also
contains a number of policy changes. The primary ones that effect GNU Radio's
build system are in (1) using a name before it is declared (e.g.,
'gnuradio-runtime', which is used for 'test-gnuradio-pmt' before
(10.9) it´s crashing after about a minute.
For OS X I followed the build guide provided (installed using ports,
then uninstalled and compiled from source).
--
Michael Dickens, OSX Programmer
Ettus Research Technical Support
Email: supp...@ettus.com
Web: http://www.ettus.com
sense?
If you let me know what else to test, I'll try that too. Otherwise, without
actual functionality the basic GUI seems to work. - MLD
--
Michael Dickens, OSX Programmer
Ettus Research Technical Support
Email: supp...@ettus.com
Web: http://www.ettus.com
On Aug 3, 2014, at 12:00 AM, Stefan
)::thread_proxy ()
#11 0x7fff9940c772 in _pthread_start ()
#12 0x7fff993f91a1 in thread_start ()
}}}
--
Michael Dickens, OSX Programmer
Ettus Research Technical Support
Email: supp...@ettus.com
Web: http://www.ettus.com
On Aug 4, 2014, at 7:20 PM, Stefan Oltmanns stefan-oltma...@gmx.net wrote
might be stable at the same time as on OSX and Window would not be; it
can happen.
Good luck with your GR work! - MLD
--
Michael Dickens, OSX Programmer
Ettus Research Technical Support
Email: supp...@ettus.com
Web: http://www.ettus.com
On Aug 5, 2014, at 3:02 PM, Stefan Oltmanns stefan-oltma
created ticket #710 and will get to it soon.
If Stefan is using OSX 10.8 or 10.9 then he actually is using posix_memalign --
Apple added that function into 10.8+, and I've confirmed that GR uses it, too.
- MLD
--
Michael Dickens, OSX Programmer
Ettus Research Technical Support
Email: supp
with posix_memalign: Stable.
Thank you very much
--
Michael Dickens, OSX Programmer
Ettus Research Technical Support
Email: supp...@ettus.com
Web: http://www.ettus.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman
On Aug 6, 2014, at 6:50 PM, Stefan Oltmanns stefan-oltma...@gmx.net wrote:
yes, I have not modified my program at all:
I added a #error Broken allocation engine to volk_malloc.c at the
beginning of the other allocation engine. I tried to recompile, but
compiler stopped with my error message.
On Aug 6, 2014, at 7:08 PM, Michael Dickens michael.dick...@ettus.com wrote:
I will look into the volk_malloc you mention.
I just issued GR pull request 256 volk: add check for posix_memalign
https://github.com/gnuradio/gnuradio/pull/256 that fixes the use of
posix_memalign by checking
+portaudio+python27+qtgui+sdl+swig+uhd+wavelet+wxgui
(active)
Here is the output from ls
ls /opt/local/lib/python2.7/site-packages/
volk_modtool xcbgen
Specifically I am looking for the package read_complex_binary which can
help me read files dumped from grc.
--
Michael Dickens, OSX
Hi Sharath - Ah; OK. You are correct that the GNU Radio installer does not
install Octave files (in MacPorts or any other place; it's OS agnostic). But,
they are present in gr-utils/octave if you download the source (release or
git). You don't need to reinstall GNU Radio from source or
CMake 2.6,
2.8, and 3.0.
If you do testing, feel free to reply to the group or email me directly with
your successes or failures. Try touching headers (.h and .i) and sources to
see if rebuilding happens correctly.
Thanks in advance for any feedback on this change. - MLD
--
Michael Dickens, OSX
Hi Azza - This is a recent change in the way FindUHD works (by me). What
version of CMake are you using? - MLD
On Aug 28, 2014, at 12:37 PM, Azza Ben Mosbah azza.ben.mos...@gmail.com wrote:
I am trying to install gnuradio v3.7. It is not the first time I do this
installation, but it is the
OK; 2.6; let me see if I can fix it quickly. - MLD
On Aug 28, 2014, at 12:41 PM, Azza Ben Mosbah azza.ben.mos...@gmail.com wrote:
Thank you for this quick response.
cmake version 2.6-patch 4
___
Discuss-gnuradio mailing list
The best way to use the .cmake files installed by GNU Radio in an OOT module is
to do the
{{{
find_package(Gnuradio [...])
}}}
as close to first thing as possible. Once that's done, then all of the other
GR .cmake modules (including FindCppUnit.cmake) will become available when
using CMake =
Hi Dimitri - I'm not sure the GR cmake files are being installed in that
version of GR. On Linux by default, these files will be installed into
${prefix}/lib/cmake/gnuradio/, and there will be one called
GnuradioConfig.cmake. gr-baz does not provide this specific file, and if the
specific GR
After hearing from a few OSX users this afternoon at GRCon14 that they were
having issues getting gr-mac to build or function, I decided to get it into
MacPorts. Thus, after a little work and a couple patches, it is now in and
seemingly functional as of r125409
Ed and I talked off-list, but for those interested this type of error generally
means that the installed version of MacPorts is too old and needs updating. In
this specific case, configure.cxx_stdlib was added in the 2.3 release. Thus,
if the dports tree was updated but 'port' was not, then
Hi Stefan - Do you have an example program that I could do testing on? That
would help expedite any fix. Thanks! - MLD
On Sep 18, 2014, at 10:39 AM, Stefan Oltmanns stefan-oltma...@gmx.net wrote:
my C++ program is already working great, except one major bug on OS X:
I cannot stop the
Hi Stefan - Thanks for reporting back; no problems on any mistakes or bugs or
not being at GRCon14. It sounds like stop() and wait() work on OSX within GNU
Radio, and that the actual issue is when using a 3rd-party interface between
the hardware and GNU Radio. So, hopefully these other
Can somebody provide me with a program that I can use to test on OSX? I'm
happy to provide patches ... - MLD
On Sep 22, 2014, at 10:00 AM, Sylvain Munaut 246...@gmail.com wrote:
Well, it works on windows and linux according to the OP. (and since
osmocom_fft does a stop() wait(), I can
Ah; OK. Running osmocom_fft using a HackRF Jawbreaker and everything works OK;
I can do stop, run, and close without issues. Maybe this issue is specific
to some RTL device(s) rather than OSX? - MLD
On Sep 22, 2014, at 10:08 AM, Sylvain Munaut 246...@gmail.com wrote:
Well, as I said above,
A few points regarding gr-air-modes on OSX:
0) ldconfig does not exist on OSX. Apple's DYLD manager does the right
thing most of the time without having to be told that new libraries are
available. One can tweak the DYLD manager behavior during runtime via various
DYLD_* variables
That's great, Alan. Thanks for the feedback have fun with your GNU Radio /
RTL dongle setup. - MLD
On Sep 23, 2014, at 6:21 PM, Alan Woodward alankeithwoodw...@gmail.com wrote:
Many thanks for your help, the macports method has worked perfectly and I now
have a working gr-air-modes with
On Sep 25, 2014, at 10:22 AM, Stefan Oltmanns stefan-oltma...@gmx.net wrote:
Unfortunately I do not have any other hardware than two different RTL
devices (one with E4000 tuner and one with R820T).
I attached the most simple program to reproduce that error, it just
connects the OsmoSDR source
Mine outputs (in gdb):
{{{
gr-osmosdr v0.1.3-1-g4bb2fa4e (0.1.4git) gnuradio v3.7.x-xxx-xunknown
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace
[Reading symbols for shared libraries . done]
Using device #0 Realtek RTL2838UHIDIR SN: 0001
Found Rafael Micro R820T tuner
->
[Discuss-gnuradio] Mac OS X 10.10 Advice
discuss-gnuradio
-- Thread --
-- Date --
[Discuss-gnuradio] Mac OS X 10.10 Advice
Michael Dickens
Reply via em
Oh goody! I have a MacPorts ticket with this issue, and my AVX Mac is
currently unavailable for fixing this. Maybe somebody (Nathan? Tom?) can
figure out the correct fix? - MLD
On Oct 23, 2014, at 1:52 PM, Stefan Oltmanns stefan-oltma...@gmx.net wrote:
Adding const did not fix the problem,
, Michael Dickens via USRP-users
usrp-us...@lists.ettus.com wrote:
GNU Radio and UHD seem to generally work well with the recently released Mac
OS X 10.10. In my testing, everything in UHD works. And, everything in GNU
Radio works -except- for executing flow-graphs from with the GNU Radio
I just fixed this issue within MacPorts
https://trac.macports.org/changeset/127653 , which will be live by around
12:30 PM/US/Eastern. I ended up following Stephan’s lead and moving the
shuffle index values directly into the function call; nothing else made clang
happy. Given that these
requested, no matter what library name it came from.
All makes sense now, yes? Well, at least it’s fixed ;) - MLD
On Oct 30, 2014, at 9:24 AM, Michael Dickens michael.dick...@ettus.com wrote:
As pointed out elsewhere [1], you can work around the libxml2 issue by
running GRC while forcing MacPorts
Hi Alan - You’re welcome! Creating a binary distribution might be doable if I
don’t use MacPorts; otherwise, there are -tons- of dependencies that will have
to be dealt with and the resulting .app will be huge. I think the last time I
did this (IIRC, using qtmacdeploy) the .app was nearly 1
Hi Ed - The actual link command was not included in the output you provided, so
it’s difficult to say exactly where the issue lies. But, the basic cause is
that “libSDL.dylib” is not being included in the link command, and/or it does
not contain the various “SDL_*” symbols that are not being
Hi Michele - It looks like there are multiple GNU Radio installs being
caught in the execution: /usr/local/lib/ and /usr/lib/x86_64-linux-gnu/
:
{{{
Program received signal SIGSEGV, Segmentation fault.
0x76001d2f in pmt::string_to_symbol(std::string const) () from
/
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
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
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 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
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
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
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
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
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
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
1 - 100 of 1164 matches
Mail list logo
