I'm a grad student at Notre Dame working on software defined radio
projects. My current task is to get GNU Radio and the USRP hardware
working under MacOS X 10.4. I thought I'd write to see if anyone
ever got it to "work", and if so, what tricks were used beyond those
already in the Wiki.
Jon - Do I take it that you're compiling from source, not using Fink
or DarwinPorts (DP)? If that's the case, mucho respect for you ... I
tried that and gave up on wxPython - just never got the correct
configurations to make things work.
USRP should compile without issue once you've gotten
I'm working on gr-audio-osx (MacOS X 10.4 using "CoreAudio" or a
related framework), and have some questions. I did a quick search of
the email archive, but didn't come upon anything useful for this
question in the first few pages of results (lots of other interesting
stuff though). Shoul
I have an gr-audio-osx sink which works in the basic sense of working
- no frills -, let's call it v0.1 since there are still some changes
I need to make before it works well enough to be released into the
wild. In doing so, I've come up with some possible changes to the
audio sink & sink
On Nov 30, 2005, at 5:19 PM, Eric Blossom wrote:
OS/X question: does CoreAudio resample for you, or are you
restricted to
the rates that the card supports natively? As I recall, most macs
only support a couple of rates.
CoreAudio does everything necessary to convert inputs to appropriate
o
On Nov 30, 2005, at 6:20 PM, Eric Blossom wrote:
On Wed, Nov 30, 2005 at 05:41:42PM -0500, Michael Dickens wrote:
BTW> In examples/audio, it seems like the "dst" in "multi_...",
"dial_...", and "mono..." generate way too much data. I don't think
und", etc... Or could this maybe
be incorporated into the "device_name"? Hmmm... maybe that's an
option to reduce the number of API arguments.
On Nov 30, 2005, at 11:00 PM, Eric Blossom wrote:
On Wed, Nov 30, 2005 at 09:56:26PM -0500, Michael Dickens wrote:
My second implem
In implementing gr-audio-osx, I've figured out (after much debugging)
that 2 threads are conflicting (GR is 1 thread, CoreAudio is the
other), and thus I need a semaphore or equivalent ... needs to be
thread-safe. Does GR have a preference of what to use for this? Or
is it OS- and program
We use the omnithread abstraction.
Ah ... Found the class definition in ${prefix}/include/gnuradio/
omnithread.h ... I moved from OSX's semaphores to the omni_semaphore
class (very minor changes), and that seems to do the trick. Thanks!
- MLD
With the recent changes on Savannah
< http://savannah.gnu.org/forum/forum.php?forum_id=4168 >
GnuRadio's CVS Access
< http://comsec.com/wiki?CvsAccess >
needs to be updated. This page is locked, otherwise, I'd make the
changes myself.
The most obvious is:
" $ cvs -z3 -d:ext:[EMAIL PROTECTED
Eric is correct in how to fix FFTW v3.0.1 under MacOS X. The problem
is that the "getopt" stuff is already provided elsewhere, and thus
conflicts when creating the library. This will hopefully fix Jon's
issue. BTW> What MacOS X version are you running, and which GCC are
you using? Stran
Sorry for the delayed reply; just not enough time in the day.
1) On Dec 17, 2005, at 10:28 AM, Robert McGwier wrote:
I think the question was probably more than "what tools" but I
could be wrong.
No, I had gotten to the point where "what tools" was all I was
looking for. But your reply let
'gnuradio.i' is found in ${prefix}/include/gnuradio/swig/, and is
supposed to be installed by gnuradio-core (via "sudo make install" or
equivalent). You can copy it from gr-build/gnuradio-core/src/lib/
swig/gnuradio.i into that directory if necessary (they have the same
file contents), but
OTOH (with regard to compiling still working): trying to run (at
least some of the) examples in gnuradio-examples/python/usrp results in:
[snip]
import db_tv_rx
File "/usr/local/lib/python2.4/site-packages/gnuradio/
db_tv_rx.py", line 190, in ?
db_instantiator.add(usrp_dbid.TV_RX_REV
As Eric mentioned, the USB support for MacOS X isn't up to speed
yet. I have been playing around with both libusb's "darwin" and
USRP's "fusb_darwin" codes over the holidays, with no success (though
some changes I will eventually provide since they are either bug
fixes or augments for MacO
On Jan 1, 2006, at 5:51 PM, Eric Blossom wrote:
Please try updating, building and installing the usrp and gr-usrp
modules. Matt's added a couple of new daughterboard variants. The
constants are in usrp and are referenced in gr-usrp
Ah ... I did ./checkout, but it barfed on USRP and I assumed
On Jan 1, 2006, at 5:43 PM, Eric Blossom wrote:
I am almost certain that the problem is that you are not submitting
multiple asynchonous requests to the USB subsystem. This 4MB/sec
"limit" is what we are also seeing on NetBSD, which is also (at this
time) lacking a method to stream multiple bulk
On Jan 2, 2006, at 12:53 AM, Daniel O'Connor wrote:
Does OSX support aio (async IO)?
Yes, an has for a long time so it's pretty robust (if only one can
figure out how to use it). A newer addition is async & isochronous
low-latency transactions, generally for streaming media which require
Does GR have a preferred way to create a new thread? I don't know if
it will work for what I need, but it's worth a try. If it doesn't
work, then I have an email queued to Apple's USB list asking my next
question:
The problem is in doing the USB callback under OSX at the -
application- l
On Jan 6, 2006, at 9:33 AM, John Ackermann N8UR wrote:
In the meantime, anyone know what version of automake (and other
make tools) is required?
Last time I checked, automake version 1.8.6 or newer was required for
"USRP", and an older version for the others. The latest, 1.9.6,
works just
When checked out from CVS, and with the "correct" background
libraries and such, and the correct environment variables configured
correctly, GR compiles without change and with few warnings. Check
out Jon's instructions via < http://comsec.com/wiki?MacOsXTiger >. I
will be posting instruc
On Jan 6, 2006, at 7:24 PM, Eric Blossom wrote:
If you talking about creating a thread in C++, we use the omnithread
package. It's a thin C++ wrapper on top of posix threads. Docs in
gnuradio-core/doc/other/omnithread.pdf
Threading seems to work well enough that I won't pursue a MacOS X
kex
The primary issues right now are that (1) both the USRP and my
fusb_darwin codes copy LIBUSB internals to get the job done (mine is
very dependent right now, but I'll reduce that with re-programming
some things); and (2) some LIBUSB calls are made directly, while
others are through the USRP
[I sent a similar this out just under 1 week ago, and have received
no replies ... so I'm sending this updated message in hopes that
someone will share their thoughts on how to proceed. - MLD]
I've tried all the USB / general coding speed tweaks that I can think
of and easily find / work ou
On Jan 14, 2006, at 7:34 PM, Eric Blossom wrote:
On Mon, Jan 09, 2006 at 09:38:29PM -0500, Michael Dickens wrote:
Q: As USRP does not yet use the omnithread package (though it's
included in the config directory and just commented out of
configure.ac), and that package is part of the gnu
On Jan 14, 2006, at 6:10 PM, Eric Blossom wrote:
Generally speaking, reliable throughput on the USRP is dominated by
the OS's ability to deliver USB packets with small interpacket gaps.
[snip] The hardware (if properly implemented), should be
able to drive the USB at full speed. [snip]
Under Linu
Does gr-audio-[darwin|osx] exist in CVS yet (maybe under some other
permutation)?
No. I will release a first version "soon" ... probably by the end of
January. I had hoped to release it around "now", but that's not
coming to pass due to a number of factors, some of which are beyond
my co
Ryan - Your compile issue is that "string.h" isn't in the include
path (-I or otherwise) to get the prototype for the function
"memset". According to the SDCC Manual < http://sdcc.sourceforge.net/
doc/sdccman.html/node13.html >, -if- there is an issue then setting
"SDCC_INCLUDE" and/or "SDC
(1) You ended up sending ask_pkt.pyc, not ask_pkt.py ... the latter
would help in debugging!
Without knowing more:
(2) Your issue is that there is no function "asc_freq()" in the
"ask_demod" class.
On Feb 7, 2006, at 11:23 AM, [EMAIL PROTECTED] wrote:
File "/home/mrobitaille/GRworking/MRT
Hi Jason - Our hope is to get slides from Dr Mitola as well as
permission from Paul Tilghman / DARPA to release his slides. I have
queries into both of them, and am waiting to hear back from the former.
Maybe Tom can query Mitola specifically about this topic as well? No
promises, but these are our
Hi Jeon - It is quite possible that some presentations contain minor
typos or even errors. Research/development and presentation of it is
imperfect at best. Discussion such as this is the right thing to do! If
anyone catches minor typos or errors in any GRCon15 presentation (or,
for that matter, a
Hi Patrick - So what's happening is that with GRC, because it was
installed via MacPorts the MP version of Python is used. The terminal
only knows what you tell it via environment variables such as PYTHONPATH
(already suggested by Kevin Hofschröer) and PATH. In your case right
now, I'll bet that th
Hi Patrick - You're on the right track. We're just following what is written
(roughly) in < http://gnuradio.org/redmine/projects/gnuradio/wiki/MacInstall >.
Please also note that unless you play some tricks with the +quartz variant that
is available many GR dependencies, you'll have to install X
[off list]
Hi Patrick - Thanks for the feedback. I've heard of your issue before;
never experienced it myself. Do you mind if I ask you to do a few things
to help debug & maybe we can figure out a better way to keep GR / Python
/ MP happy? I not, that's fine too; just thought I'd ask.
1) If you w
My bad; let me really take this off list :)
On Tue, Sep 8, 2015, at 02:07 PM, Michael Dickens wrote:
> [off list]
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Hi Francisco - I'm not sure we can definitely say how many people helped
out; we sort of ebbed and flowed as necessary to make it work. There
were another 2-6 of us meeting weekly (and emailing regularly) for
organizational purposes; some more often than others. We had 15-20
volunteers to help with
Hi cdl - Which USRP are you using? USRP1, B200, B210? Might make a
difference ... - MLD
On Wed, Sep 9, 2015, at 12:22 PM, cdl wrote:
> i am using uhd model in gnuradio,usrp_sink and usrp_source to do a
> loopback sysrem and i connect the usrp tx and rx withRF feeder
> line,when i exe the grc ,i go
We're discussing what can be released & Tom will reply with that info.
It will not include email addresses, names, or affiliations; it will
probably be just # of registrations because we also can't accurately say
the # who attended any given day. Anyway, more from him once he gets
there. - MLD
On
Please reply on-list for the best assistance; not to me or any specific
responder personally.
OK; so you're using a B200, and you're getting USB errors. Have you
tried different cables? Have you tried different computers / different
OSs or different OS versions? Anything else beyond the error you
Hi Rama/Dave - I can't say -why- the error is happening, but the error
is because for some reason the llibusb1 library is not being included in
the linking. This might be because the libusb1 library has been updated
since the last time GNU Radio was built; or, it might be for other
reasons too; not
Hi CDL - As you also replied on the USRP list & this is a UHD and/or
Ettus Research issue, not a GR issue, we're moving the discussion to
just that email group & leaving this one. You'll still get support, just
there & not here. - MLD
On Thu, Sep 10, 2015, at 06:40 AM, cdl wrote:
> i am using one
What OS are you building on?
On Thu, Sep 10, 2015, at 02:18 PM, Richard Bell wrote:
> I wrote an OOT module in cpp using GNU Radio 3.7.8, it shows up in GRC
> but when I run it, I get the worst error known to mankind (in my
> opinion):
>
> AttributeError: 'module' object has no attribute 'my_block
Hi Richard - Glad you got the runtime part worked out for your OOT
block. CMake has its good and bad moments ...
As for the why the QA code fails, since you're on Linux do you need
to set the LD_LIBRARY_PATH somewhere? I know on OSX we have to "make
install" before doing "make test" because the li
Hi Rama/Dave - The benchmark examples run as standalone applications.
They do require Python, but they do not use GRC or any other GUI
interface.
Question: Are you running the OFDM or Digital/Narrowband benchmark? What
exact commands are you using for both Rx and Tx? What SDR hardware are
you usin
Hi Dave - I'm thinking that you are confusing "--samples-per-symbol" for
the sample rate. I think the option you're looking for is "-r". Look at
the "--help" for those examples when you get a chance. - MLD
On Thu, Sep 17, 2015, at 02:01 PM, Rama V wrote:
> Thank you very much Michael. I will follo
Hi Nemanja - SIP is used in Qwt and other PyQt related projects. It has
its own internal API, which must be compatible for all Python modules
being loaded (including SIP itself). So, what this error means is that
the Qwt module was built using a given SIP API (6.0 looks like), then
SIP was upgraded
Today (Wednesday, Sep 30), Apple released its latest OS for free
download: 10.11 "El Capitan". This new OS comes with Xcode 7.0.1, which
provides clang 7 (700.0.72) and (likely) llvm 3.7 -- both updates from
those provided in Xcode 6 or Xcode 5. With each new Xcode generation,
some APIs are depreca
Hi David - It looks from the 'brew install log that brew is using
"/usr/local/Cellar/python/2.7.10_2/bin/python", while you're trying to use
"/usr/local/bin/python". These may or not be the same install of Python; given
the PyThreadState_Get error you're getting I'd bet they are different versio
Hi Chandan - What procedure did you follow? And, how is GNU Radio
installed on your Mac? When you write that every command runs, do you
mean that you have QA code that works? We need a little more info before
we can really provide you assistance here. Feel free to email me
directly & we can report
Hi Chandan - It looks like you did everything correctly. Can you send me
a tarball archive of your OOT module to my email here & I'll help
diagnose off-list. We can report back what we find if it's useful. - MLD
On Sat, Oct 31, 2015, at 12:50 AM, chandan kumar wrote:
> To install gnuradio, I first
Hi Jeon - I maintain GNU Radio / Volk / UHD within MacPorts, and they
generally work on OS X 10.8 through 10.11; I know of folks using than on
10.6/7, and I believe they can be coerced into working on 10.5 (Intel or
PPC). There are issues here and there, such as that ControlPort doesn't
really work
Hi chandan - I have your code in hand and will look at it soon. I'll
email shortly with more info. - MLD
On Tue, Dec 29, 2015, at 03:57 PM, chandan kumar wrote:
> I have added a interpolator block in my out of tree module. The
> interpolation factor of the block is of integer type and single input
My advice is to just update the whole cmake directory. There have been
other changes in that directory that should be included in OOT modules
too. I know not all OOT modules use the latest, because I patch them in
MacPorts for the parts I need. - MLD
On Tue, Dec 29, 2015, at 04:43 PM, Philip Balis
On Tue, Dec 29, 2015, at 07:31 PM, Johnathan Corgan wrote:
> On Tue, Dec 29, 2015 at 4:10 PM, Michael Dickens
> wrote:
>
>> My advice is to just update the whole cmake directory. There
>> have been
>>
other changes in that directory that should be included in OOT mod
I believe that GR did not provide these files a while back, so we
included them in the OOT via gr-modtool. They've been there ever since.
That's my memory. - MLD
On Tue, Dec 29, 2015, at 07:47 PM, Johnathan Corgan wrote:
> On Tue, Dec 29, 2015 at 4:42 PM, Michael Dickens
> wrote
On Tue, Dec 29, 2015, at 08:30 PM, Johnathan Corgan wrote:
> On Tue, Dec 29, 2015 at 5:08 PM, Philip Balister wrote:
>> Dunno, but gr-newmod (or whatever it is called) in gnuradio
>> has a copy
>>
of the files. I had to fix the issue twice.
>
> This is good opportunity then to see what we can now
Hi shortwavedude - You're trying to configure an OOT module, yes? (GNU
Radio internally would not look for itself, so this is the logical
conclusion. Which OOT module are you trying to build?) That error means
that this OOT module is looking for GR 3.7.2 or newer, and that cmake
can't find GR insta
No problems. As I said, I don't use Ubuntu right now so I'm a bit out of
the loop on these matters. Keep playing around & learn all you can! -
MLD
If you look in <
https://github.com/kik/sdr-tv/blob/master/gr-ntsc/CMakeLists.txt >,
lines 89-94 read:
{{{
# Search for GNU Radio and its components an
Hi Mehdi - The first item looks correct; it's a default string that can
be overridden by the user mostly for the purpose of package managers.
I'm not sure if I understand the 2nd item. When I run GRC it looks fine.
Can you send me a screenshot off-list & I'll work with you there to see
what can be
gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
--
Michael Dickens, Mac O
Sorry about the gender mismatch, Michele; my bad.
You can disable graphics in a GRC flowgraph by going to the "Options"
block (which is usually in the top left), double click on it, then on
the "General Options" popup select "No GUI". Then, the flow graph will
have no GUI dependencies.
Hope this
Yeah; looks like GR installs using that version info by default. Even in
MacPorts. I'll look into getting that fixed in MacPorts.
BTW> How did you install GR / GRC? Ditto for Qt4 & other dependencies.
- MLD
On Fri, Jan 15, 2016, at 05:29 AM, MA wrote:
> Both commands return "v3.7.x-xxx-xunknown"
Hi micro7311 - GRC scripts are placed typically into
${prefix}/share/gnuradio/grc/blocks -- in your case, looks like
${prefix} == "/usr". Without having access to your OOT module or any
other info about it, the best advice I can give is to check to make sure
our OOT install ${prefix} matches that f
On Fri, Feb 12, 2016, at 08:32 AM, micro7311 wrote:
> Hi, thank for the detailed response to my question. I forgot to
> attach the OOT modules. They are attached here.
All works nicely for me, though admittedly I'm running on OS X & you're
not (or, looks like not). Here's a screenshot of one of
Hi chandan - Try setting the PYTHONPATH environment variable in your
shell to include the /path/to/your/module, and make sure that the
/path/to/FEC/module is also in the PYTHONPATH, if they were installed
into different directories. All of the GR modules need to be in the
PYTHONPATH somewhere in or
On 03/21/2016 01:50 PM, Thomas Wagner wrote:
> I will try to upgrade the installation on the Macbook to 3.9.1. It
> took me all night on Saturday to get in on the Macmini, I kept
> getting GnuRadio error messages on compile, I finally had to
> uninstall it and start over, then it worked.I
Hi Jim - Great to hear from another OS X GNU Radio user!
The issue is likely that MacPorts' 'python' expects its packages to be
installed into /opt/local somewhere, not /usr/local . I sure there's a
way to set various environment variables to find the installed files,
but it's easier to just inst
You're welcome; glad that works! - MLD
On Tue, Apr 26, 2016 at 6:08 AM, jim Schimpf wrote:
> Thanks to Michael Dickens . The tutorial
> problem in OS X I was having is fixed. Deleting the tutorial build
> directory, and then starting over using
> cmake -DCMAKE_INSTALL_
HI Franz - I'd guess that GNU Radio isn't installed, or not installed
into where CMake is installed & you're not telling CMake where to look.
FindGnuradio.cmake looks for GnuradioConfig.cmake, which is located in
some DIR/cmake/gnuradio directory. The DIR will be either PREFIX/lib or
PREFIX/share,
I think if you follow the install guide for Mac OS X, GR will work
almost out of the box. As stated, there are cases where some
dependencies fail to build or the like; just "clean" the failed
dependency, try to install it directly, and it usually works. Most
dependencies are a binary download now;
Hi Darin - If you want to use SDRplay, you -can- do that using MacPorts
via the gr-osmosdr port: with a patch that I can provide.
The SDRplay folks, at least in the recent past: (1) provide only
pre-combined binaries, not source code, which need to be tweaked to work
for most OS X installs includi
I'm replying right now off list to Mark's query. What he's asking is not
of interest to most users; mostly for advanced developers. - MLD
On Wed, Jul 6, 2016, at 10:02 AM, Mark Napier wrote:
> Hello,
>
> With help from Michael I've made up a patch file for the db_tvrx.cpp
> and dboard_iface.cpp.
What Sylvain wrote is correct: if you publish your GR OOT module, then
you have to choose GPLv3 or a compatible FOSS license. I believe that by
default the license is GPLv3, since that's what GR is. See also <
http://www.gnu.org/licenses/license-list.html > for a list of compatible
(and incompatibl
__
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
--
Michael Dickens, Mac OS X Programmer
Ettus Research Technical Support
Email: supp...@ettus.com
Web: http://www.ettus.com
__
I'm trying to work with the ZQM REQ / REP message blocks while learning
about ZMQ. From their overview guide < http://zguide.zeromq.org/page:all
>, they define various graphs where the interconnects are the ZMQ
connections.
Thus, for example, in Figure 4 "Publish-Subscribe", the PUB would be GR
si
On Thu, Jul 28, 2016, at 03:11 PM, Sylvain Munaut wrote:
> > But this model doesn't work for the REP / REQ in Figure 2
> > "Request-Reply". I would expect the ZMQ REQ to be a GR sink but instead
> > if is a source; likewise, I'd expect the ZMQ REP to be a GR source & it
> > is instead a sink.
> >
>
On Thu, Jul 28, 2016, at 06:44 PM, Johnathan Corgan wrote:
> The ZMQ REQ/REP dataflow has the receiving end REQuest data from the
> sending end when needed, which REPlies with a packet. It's a form of
> flow control.
>
> From the GNU Radio perspective, streams flow into GNU Radio sinks to
> exit t
Hi Francisco - Yes, I think having a generic ZMQ block would be awesome.
Do you have an OOT module or block that does what you listed: a generic
ZMQ block? If so, how do I gain access to it? This would save me lots of
time! Thanks! - MLD
On Thu, Jul 28, 2016, at 10:21 PM, Francisco Albani wrote:
>
Hi Andy - Thanks for your detailed thoughts on the subject matter.
I think we're all in general agreement that there are 2 ways to do REP /
REQ with respect to which is client and which is server. GR implements
one of those ways, but could easily provide the other, too. It's just
another way of lo
Apple released its latest OS earlier this week, now called "macOS" (was
Mac OS X): 10.12.0, codename "Sierra". The vast majority of projects
that built for 10.11 and prior continue to work with 10.12, including
Volk, UHD, and GNU Radio. In MacPorts, I committed changes to Qt4
(qt4-mac) to allow it
Hi Adam - We're still waiting to hear back from the videographers. We'll
make an announcement on various lists once the videos are in place.
Cheers! - MLD
On Sun, Oct 2, 2016, at 11:47 PM, Adam Bacon wrote:
> Does anyone know when the videos from GRCon16 are supposed to be posted?
___
On Fri, Oct 21, 2016, at 11:25 PM, w xd wrote:
> I have installed the gnuradio on my mac pc(mac os sierra).I have two
> questions:
Welcome to GR on Mac!
> 1.When I run some grc example,the grc will post a error.It
> said"missing xterm executable".How to solve it?
If you used the default 'port'
Hi Paul - You are correct that adding "DIGITAL" as you write should add
that component in for headers and library linking. Did you clean the
build directory after changing this setting? Sometimes CMake won't redo
the linkage internally, and one just has to "rm -rf" the whole build
directory and sta
The lib/ and swig/ libraries used inside cmake are generally the same.
I'll be very curious how this issue pans out! Cheers! - MLD
On Thu, Nov 17, 2016, at 08:13 AM, Garver, Paul W wrote:
> I’m thinking I should write a simple C++ harness to call the block.
> That way, I can isolate a SWIG proble
you are using some other Python, you'll
need to set all of the PYTHON variables accordingly.
Hope this is useful! - MLD
On Mon, Nov 21, 2016, at 08:13 AM, Michael Dickens wrote:
>
> -- Forwarded message --
> From: *vamsi krishna*
> Date: Sun, Nov 20, 2016 at 11:0
Hi Gilad - IIRC this error means that Python installs are being mixed
between linking and runtime. For example, linking against the macOS
provided Python and then trying to use MacPorts' Python for runtime
execution. If this statement doesn't help, email me off-list & we'll
work through your issue.
orts
> doesn't create a "python" symlink, so it can be fixed by either
> using "python2.7" (which exists in /opt/local/bin and will be used
> before the system's binary) or by creating a symlink with "ln -s
> /usr/local/bin/python2.7 /
Hi Vamsi - I'm glad that fixed the issue for you. The crash happens
because the OOT is being linked to a specific ABI (e.g., MacPorts Python
library), while the runtime is trying to use a different API (system
Python library). The libraries' ABIs are different enough to confuse
Apple's dynamic libr
Hi Greg - Good to hear from another OS X GR user! I think 1-3 in your
list are pretty accurate; I'll add for 3 that it's easy to use MacPorts
to do development with GR, either directly inside MP or via OOT modules.
I'll add 4: from source! I use a mix of 3 and 4, which with the proper
CMake setting
Hi Greg - what usually works is the following:
{{{
sudo port clean doxygen
sudo port install doxygen
sudo port clean gnuradio
sudo port install gnuradio
}}}
If that fails, email me off-list & I'll help debug. - MLD
> On Dec 6, 2016, at 7:08 AM, Gregory Ratcliff wrote:
>
> Just following instr
Hi Greg - What usually works is the following:
{{{
sudo port clean doxygen
sudo port install doxygen
sudo port clean gnuradio
sudo port install gnuradio
}}}
If that fails, email me off-list & I'll help debug. - MLD
On Tue, Dec 6, 2016, at 01:43 PM, Gregory Ratcliff wrote:
> Just follo
Hi Matthew - Hmm ... well, testing on 10.7 will be tricky for debugging
purposes. It looks like you installed GR via MacPorts ... yes? This
looks like the same issue as < https://trac.macports.org/ticket/53236[1]
>, yes? OK; I'm working on fixing this; hopefully this afternoon.
Cheers! - MLD
On
Hi Cinaed - Check out < https://brmlab.cz/user/jenda/rpi-gcc >. - MLD
On Mon, Feb 20, 2017, at 03:36 PM, Cinaed Simson wrote:
> Any know if the following bug has been resolved?
>
> It appears this bug has existed since the first pi was released.
>
> Anyone know if a patch exists?
>
> I did inst
According to nabble, your original post has yet to be authorized. I'll
append it for completion.
So you're running on an older OS X box (10.8), using the libc++ hack for
older systems. That should be OK. Most folks I know who use it do it
with 10.6 or 10.7, but it should work on 10.8 too.
If you
I don't know why your post didn't go through.
The gr-osmosdr port contents look correct.
Your script works for me on my OS X box (admittedly, 10.12 latest).
Let's take the discussion on-list, and I'll help you debug this & if
there's something relevant I'll reply back to the GR list. - MLD
I have a MacPorts ticket requesting that I enable CTRLPORT, which
requires Thrift, which was recently updated to 0.10.0 in MacPorts -- so
I thought it worth a try again to see if it works.
Thrift requires C++11 for building, which means that "gnuradio
+ctrlport" will also require C++11. Easy enoug
Thanks for the feedback. PR is
https://github.com/gnuradio/gnuradio/pull/1221 . - MLD
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
I recently had a MacPorts ticket to enable +ctrlport. After updating
thrift to 0.10.0, along with a patch to fix gr-fec's possible use of
c++11's 'constexpr', I got GR to build with ctrlport enabled. Ticket
fixed, since the issue was in MacPorts.
Running "make test" results in failures in the ctr
Can you send me (off list) a screen snapshot or the like so that I can
see what you mean by "fuzzy"? I see nothing out of the ordinary in GRC
when running, but then maybe I'm not looking at the correct text...
Cheers! - MLD
On Sun, Apr 2, 2017, at 10:12 AM, Dave NotTelling wrote:
> I just instal
Hi Vamsi - It looks like you're doing everything correctly for building
& installing your OOT & GR itself.
If I had to guess, I'd think that, somehow, the 2 argument to "map" is
being provided either directly or indirectly in the "top_block.py"
script & clearly doesn't support iteration & needs t
1 - 100 of 1256 matches
Mail list logo
