With only a small amount of hacking / patching, I’ve gotten GNU Radio
mostly running on MacOS X 10.5 “Leopard”. The WX Scopes don’t work
yet, but the various other WX Widgets look OK and seem to work; I
will continue looking into the Scope’s issue. Using “nogui” scripts,
I can verify that USRP ↔ USB transport works, and FM reception was
just fine. I will write an “install guide” sooner or later on this
topic, likely once the install of the background libraries /
includes / applications becomes more reliable / stable.
A few points:
-
10.5 includes XCode 3.0, which uses “i686-apple-darwin9-gcc-4.0.1
(GCC) 4.0.1 (Apple Inc. build 5465)”. 10.4 includes XCode 2.4, which
uses “i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc.
build 5367)”. Really too bad Apple hasn’t updated to at least 4.1 if
not 4.2. Ah well; every little bit of progress counts!
-
SDCC 2.7.0 as compiled by Apple’s GCC doesn’t work properly for the
purposes of GNU Radio’s needs for either 10.4 or 10.5 on Intel-Mac’s
only; these work just fine on PPC-Macs at least on 10.4. SDCC 2.4
for Intel-Mac provided by the link on the MacInstall page does work
on both 10.4 and 10.5 for Intel OSX.
-
10.5 includes Python 2.5.1 by default; 10.4 included Python 2.3.5.
I’ve created patches for specific MacPorts Portfiles to allow for
installation using the built-in Python instead of requiring MacPorts
to install its own version. The current MacPorts install of Python
2.5 doesn’t include a Framework install, which is required by OSX to
use any python-based GUI.
-
10.5 does not include (what looks to be) the “standard” suite of 64-
bit file-access API’s … for example, I think in Linux one would
have “open64”, “close64”, “fseek64” and so forth for the 64-bit
compliant versions, and just “open”, “close”, and “fseek” for the 32-
bit versions. OSX uses the same function names for both versions
(just “open”, “close”, and “fseek”), but apparently the actual
library figures out which version to use (64- or 32-bit). The only
exception seems to be the Xstat routines, which have different (and,
“standard”, as above) APIs for both 32 and 64-bit functions (e.g.
“fstat” and “fstat64”). Apple also does this same trick with
“off_t” … there is no “off64_t”, just an “off_t” which is 64-bits
wide under 10.5 (and also in 10.4, at least on Intel-Macs). I
learned all of this when getting GUILE 1.8.3 to compile; I have to
say I like the (presumedly) Linux version better: consistent,
explicit separation of 32- and 64-bit APIs.
-
“make check” fails on 10.5 -only- in qa_goetzel
Notation: expected ?= actual computed
- 10.4:
0.5 == 0.499997220368 within 5 places
0.0 == 4.00525894099e-06 within 5 places
- 10.5:
0.5 != 0.49998197625655755 within 5 places
0.0 != 8.6014477400182496e-06 within 5 places
→ I cannot explain why the outputs would be different. This is
the -exact- same computer hardware just running the different MacOS X
versions.
-
While it is possible to use 10.5, and will become easier as
libraries / includes / applications are ported to 10.5, I do not yet
recommend using it. 10.5 I found unstable for doing much of
anything; 10.5.1 is much better, but still crashes regularly or just
hangs. X11.app, as provided by Apple, has lots of issues due to
moving from XFree86 to X.org codebase; there is a side effort that
makes X11 -MUCH- more stable and usable, entirely replacing the
X11.app provided by Apple. At the current rate of improvement,
10.5.4 should be stable enough for general use … so, another few
months of suffering for those who have no other choice 
On Dec 18, 2007, at 3:53 PM, Michael D. wrote:
With only a small amount of hacking / patching, I’ve gotten GNU
Radio mostly running on MacOS X 10.5 “Leopard”.
2 weeks later:
I’ve submitted to the MacPorts project all of the fixes needed to get
the Python 2.5 and related ports (e.g. wxPython) up and running on
both MacOS X 10.4 and 10.5. Most of the ports work “out of the box”
on 10.4 and 10.5 now, but Python is one of the remaining holdouts
mostly due to conflicts in the dynamic library crowd versus the
framework crowd (which is inherently dynamic, just in its own install
space). Once those fixes are in place, my 10.4 install script should
work just as it is … with the same issues as before (e.g. SDCC from
MacPorts won’t work on Intel Macs; download and install the pre-
compiled one).
I still can’t get GNU Radio’s WX GUI stuff to work using GNU Radio’s
scripts. OTOH, using the demo scripts I wrote over the summer,
including a partial “framework” for doing GNU Radio applications, I
can get pretty much everything working on 10.5 just as it does under
10.4. The primary difference, I think, between my framework and the
GNU Radio examples is that the latter uses the new “top_block”, while
the former uses “flow_graph” … yes, I know I need to update - I just
hesitate to fix what ain’t broke until I need to 
Anyway, we’ve experienced this issue before with the spectrum_sense
code - “flow_graph” version works while the “top_block” one hangs …
but in this case the issue was fixed by moving from Python 2.4 to
2.5. Now I find a similar issue when running on MacOS X 10.5 versus
10.4, both under Python 2.5. 'Tis a mystery.
I will continue to investigate this issue; more later. - MLD
Hi Michael,
On 3/1/08 03:08, “Michael D.” [email protected] wrote:
<>
I’ve submitted to the MacPorts project all of the fixes needed to get
the Python 2.5 and related ports (e.g. wxPython) up and running on
both MacOS X 10.4 and 10.5. Most of the ports work “out of the box”
on 10.4 and 10.5 now, but Python is one of the remaining holdouts
mostly due to conflicts in the dynamic library crowd versus the
framework crowd (which is inherently dynamic, just in its own install
space). Once those fixes are in place, my 10.4 install script should
work just as it is … with the same issues as before (e.g. SDCC from
MacPorts won’t work on Intel Macs; download and install the pre-
compiled one).
Great work and much appreciated!
Thanks to you helping with the omnithread problem I had on Leopard I now
have usrp_wfm_rcv_nogui.py working with a recently delivered USRP + TV
Rx.
And am now listening to BBC Radio 4 FM broadcast with this. Although the
audio output is really low with volume turned up full on my Mac. Is
there
any way I can set the audio gain in GR?
I still can’t get GNU Radio’s WX GUI stuff to work using GNU Radio’s
scripts. OTOH, using the demo scripts I wrote over the summer,
including a partial “framework” for doing GNU Radio applications, I
can get pretty much everything working on 10.5 just as it does under
10.4. The primary difference, I think, between my framework and the
GNU Radio examples is that the latter uses the new “top_block”, while
the former uses “flow_graph” … yes, I know I need to update - I just
hesitate to fix what ain’t broke until I need to 
The GUI examples don’t work for me either and I get a lot of the
following
messages in /var/log/system.log:
Jan 3 21:21:24 rhys kernel[0]: USBF: 11844.563
AppleUSBEHCI[0x6c51800]::Found a transaction past the completion
deadline on
bus 0xfa, timing out! (Addr: 2, EP: 6)
Although radiogui.py and stereo_rcv_gui.py from the following site
appear to
work:
http://www.nd.edu/~jnl/sdr/stereo-fm.shtml
I say “appear” as the GUI seems to function and I get noise. Haven’t
spent
much time looking at the configuration of these scripts yet but suspect
they’d need tweaking for my hardware configuration. And perhaps the
reason
they work at all is down to them using flow_graph instead of top_block
as
the GR GUI examples do.
Many thanks,
Andrew
Andrew (et.al.) - You’re welcome! I hope all of that hard work on
MacPorts files pays off, since it would make installing the background
requirements for GNU Radio “as simple” as it is in 10.4. We (me, and
some MacPorts developers) are still discussing these changes, and I’m
having trouble convincing them that a Framework install is OK … at
least one of them seems to want to have the GUI-capable Python install
without a Framework - sort of “de-framework-ify-ing” a framework
install - which I don’t think is possible (and, why would one really
want to that in the first place?!). Anyway, more when that comes to
pass.
On a more positive front, I’ve tracked down and have a fix for the
issues we’ve seen on the GUI. Turns out that MacOS X 10.5 / Darwin 9
changes the behavior of threads, so that the fast-usb code’s threads
would not do flow control (notification of start / finish of
individual threads) reliably. I’ve created a testing branch with
changes that work well for me on 10.5, and should be backwards
compatible with 10.4 (I’ll try that tomorrow; requires a reboot).
These changes allow the GUI to work for me, which completes the
(short) list of issues that I know of between 10.5 and GNU Radio.
I would appreciate it if MacOS X users (10.4 or 10.5) could try out,
and provide feedback on, the branch at:
http://gnuradio.org/svn/gnuradio/branches/developers/michaelld/usrp_fusb_fix
and verify that USB transport works for them. You can do this via any
USRP scripts, and/or heading into “usrp/host/apps” and executing “./
test_usrp_standard_rx” and “./test_usrp_standard_tx”. - MLD
Hi Michael,
On 5/1/08 08:57, “Michael D.” [email protected] wrote:
<>
I would appreciate it if MacOS X users (10.4 or 10.5) could try out,
and provide feedback on, the branch at:
http://gnuradio.org/svn/gnuradio/branches/developers/michaelld/usrp_fusb_fix
and verify that USB transport works for them. You can do this via any
USRP scripts, and/or heading into “usrp/host/apps” and executing “./
test_usrp_standard_rx” and “./test_usrp_standard_tx”. - MLD
Just built your branch on 10.5 and it works a treat. Currently listening
to
a broadcast station via usrp_wfm_rcv.py, and the USB timeout errors in
system.log have gone.
Thanks for all your hard work, and averting a downgrade to OS X 10.4!
Regards,
Andrew
The USRP fixes work on 10.4 as well, for me, running Python 2.5.
I’ll also try them on OSX 10.4 / Python 2.4 later today when I have
more time.
That said, there’s another bug somewhere keeping the waterfall
display from operating correctly, at least on OSX 10.4. The behavior
is the same both with and without the USRP fixes in this branch, and
in my initial trials does not seem to affect 10.5. This could just
be an “CPU speed” issue, but I’ll investigate either way and see what
can be found.
All of that said:
I would appreciate it if MacOS X users (10.4 or 10.5) could try out,
and provide feedback on, the branch at:
http://gnuradio.org/svn/gnuradio/branches/developers/michaelld/
usrp_fusb_fix
and verify that USB transport works for them. You can do this via
any USRP scripts (including trying the waterfall display, to see if
you have issues), and/or heading into “usrp/host/apps” and executing
“./test_usrp_standard_rx” and “./test_usrp_standard_tx”. - MLD