Gr-rds

GNU Radio
1

Hi all,

Clayton and I worked on the FM RDS project over the last weeks. I think
that the receiving side is in a pretty good state now. It works well
with the RTL SDR.

You can find a demo here:

and the code here:

There was also a talk about FM RDS at 30C3:

Best,
Bastian

2

Clayton and I worked on the FM RDS project over the last weeks. I think that the
receiving side is in a pretty good state now. It works well with the RTL SDR.

This is really cool! Worked right out of the box. It’s decoding and
displaying the local NPR station without any problems.

Sean

3

Clayton and I worked on the FM RDS project over the last weeks. I think that the
receiving side is in a pretty good state now. It works well with the RTL SDR.

I wonder how to get this working on Mac OS X with the macports version
of GNU Radio.

I downloaded gr-rds and followed the install procedure with the
following modification to the cmake command

cmake -DCMAKE_INSTALL_PREFIX=/opt/local

Everything seems to build and install fine, but when I try to run the
apps/rds_rx.grc in GNU Radio Companion I get the following error
message:

Traceback (most recent call last):
File
“/Users/ulf/Documents/Projects/gnuradio/gr-rds-master/apps/rds_rx.py”,
line 28, in
import rds
ImportError: No module named rds

Any ideas?

/Ulf

4

Hi Ulf - If this is still an issue, here’s my US$0.02 worth:

Yes: Python can’t find the module. If you installed into /opt/local,
then I agree with Bastian that the RDS Python related files were
probably installed into /opt/local/lib/python2.7/site-packages . If you
look in that directory do you see any obviously named files?

I -highly- recommend against setting DYLD_LIBRARY_PATH in your standard
shell environment … it will eventually lead to headaches. The only
reasonable time to use DYLD_LIBRARY_PATH is when running a script to do
local testing / execution … for example, CMake does this in “make
test”, such that locally created libraries are found ahead of already
installed ones.

That said, I’d bet that the issue is that CMake is not linking the RDS
library/ies correctly. You can check this if you can find the .so
and/or .dylib created by this project (e.g.,
{{{
find . -name “*.dylib”
}}}
when you’re in the RDS build directory; substitute “.so” for “.dylib” to
look for the other type. Then, once they are found, do “otool -L
” to see what the linkage is. I’ll bet that either the
self-id (the first entry; should be the exact filename including path 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 D., Mac OS X Programmer
Ettus R. Technical Support
Email: [email protected]
Web: http://www.ettus.com

5

On 2014-01-13 22:03, Michael D. wrote:

That said, I’d bet that the issue is that CMake is not linking the RDS library/ies correctly.
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.

…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.

6

Hi Ulf,

On 2014-01-11 22:32, Ulf Sderberg wrote:

Clayton and I worked on the FM RDS project over the last weeks. I think that
the receiving side is in a pretty good state now. It works well with the RTL SDR.

I wonder how to get this working on Mac OS X with the macports version of GNU
Radio.

Traceback (most recent call last):
File “/Users/ulf/Documents/Projects/gnuradio/gr-rds-master/apps/rds_rx.py”,
line 28, in
import rds
ImportError: No module named rds

Python can’t find the module. It should be at
/opt/local/lib/python2.7/site-packages and you have to add

export PYTHONPATH=/opt/local/lib/python2.7/site-packages

to you .bashrc.

However, I ran into problems with the shared libraries when I installed
it under /opt/local. I would recommend to installed it somewhere in your
home, like ~/usr. Then you have to add to your .bashrc something like

export PYTHONPATH=/Users/ulf/usr/lib/python2.7/site-packages
export DYLD_LIBRARY_PATH=/Users/ulf/usr/lib

Best,
Bastian

7

On 2014-01-14 14:21, Michael D. wrote:

Let me know if you want more direct help. - MLD
I never heard about install_name_dir, but I just pushed a fix and
hopefully I got it right now :slight_smile:
Thanks for your help!

Btw if this is the way to link under OSX it might be a good idea to add
this to the template of gr_modtool.

8

On Jan 14, 2014, at 1:24 AM, Bastian B.
[email protected] 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 up and I don’t recommend using it any more than
necessary. I’m taking about the absolute path. See my prior email on
this subject. Here’s what you do in CMake to fix this:
{{{
IF(APPLE)
SET_TARGET_PROPERTIES([LIBRARY] PROPERTIES
INSTALL_NAME_DIR “${CMAKE_INSTALL_PREFIX}/${LIBRARY_DIR}”
)
ENDIF(APPLE)
}}}
where [LIBRARY] is the CMake name for the library as defined by the
first argument to ADD_LIBRARY, and LIBRARY_DIR is traditionally used to
define where libraries are installed. You might use different names
than this, but I think you can figure this out. If you add this to both
the .so and .dylib CMakeLists.txt files, it should fix this issue since
CMake will then handle setting both the self-id and then any linkage
correctly both for “make test” as well as after “install”.

Let me know if you want more direct help. - MLD

9

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 modtool on OSX to see if/how it works :slight_smile: - MLD

10

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

11

On Jan 15, 2014, at 12:46 PM, Martin B. [email protected]
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 :slight_smile:

Just give me a quick thumbs-up (or -down) and I’ll make sure it gets
merged (or fixed).

Yes, that’s fine. Why not use ${GR_LIBRARY_DIR} instead of “lib”?
It’ll be correct, but globally settable from the top-level
CMakeLists.txt file.

Another change (not related to the OSX-specific one above): In the
“install(TARGETS”, why not do:
lib${LIB_SUFFIX} → ${GR_LIBRARY_DIR}
bin → ${GR_RUNTIME_DIR}
? - MLD

12

On Wed, Jan 15, 2014 at 06:44:51AM +0100, Bastian B. wrote:

Let me know if you want more direct help. - MLD

I never heard about install_name_dir, but I just pushed a fix and
hopefully I got it right now :slight_smile:
Thanks for your help!

Btw if this is the way to link under OSX it might be a good idea to
add this to the template of gr_modtool.

Good point, it seems like a harmless patch. Michael, what do you think?

MB

13

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
resolving. Enjoy! - MLD

14

Hi there,

I had to to do

sudo install_name_tool -change
/System/Library/Frameworks/Python.framework/Versions/2.7/Python
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/Python
/opt/local/lib/python2.7/site-packages/rds/_rds_swig.so

in order to point to the right python.

Now it works for me!

Best regards,
kai

–
View this message in context:
http://gnuradio.4.n7.nabble.com/gr-rds-tp45634p45792.html
Sent from the GnuRadio mailing list archive at Nabble.com.