Re: [Discuss-gnuradio] gr-rds
Hi Marcus, I did some further testing. Took me some time unfortunately. The RDS reception outside is slightly better. But I still got "Lost Sync" info in the terminal window. However, I could see decoded information. I can't fight the feeling, that I am missing quite a bit of sensitivity. I did some more testing with a flowgraph from the gr-gsm packet in the apps directory. There must be BTSs out there ;-). But I could not see anything. I used the Ettus Log-Per antenna. I want to check the hardware and make sure everything is working correctly. But I will move my question concerning the hardware to the USPR-users mailing list. Best regards, Mike > Hi Marcus, > > I hoped so, that is why I bought one ;-). I think the max is 73dB. The > actual value I set with a slider is 90dB. Thus I am pretty much maxed > out there. But like I wrote earlier, that is the only way to receive at > least one station. Don't have good RF working conditions. Even cellular > is a problem. > > BR > Mike > > >> Hi Mike, >> the B200 should usually be a little more reliable than the RTL dongles; >> what gain setting are you using? >> >> Best regards, >> Marcus >> >> On 08/25/2015 02:08 PM, Michael Thelen DK4MT wrote: >>> Hi Andreas, >>> >>> thanks for the hint. However I am using a Ettus B200 and do not have >>> access to a different SDR right now. I will test outside and then trying >>> to find out what is going on. >>> >>> BR >>> Mike >>> >>> Hi Michael, i read your mail and i could remember i had a similar problem with a lot of lost sync and bad block messages. My solution was to use a different RTL USB stick and to play with antenna type / antenna position and the gain of the RTL stick. I used a "classical" lamda / 2 dipol UKW Radio antenna. The stick was a noname. regards, Andreas Am 23.08.2015 um 20:02 schrieb Michael Thelen DK4MT: > Hi Marcus, > > thanks, tried your script and found out, that it is always a little bit > uncomely if something is not really reproducible. This is the status: > > With your script I did not get the earlier error anymore. However with > my original I did not get it either. Instead I get the following message > in GRC: > @ Sync State Detected > @ Lost Sync (Got 50 bad blocks on 50 total) > > I do not get this message if I run your script. Both scripts though do > not show RDS information. So before I steal somebody's time I wonder if > one reason could be, that I can only receive one station really at the > limit and only if I set gain to a max. I can hear fairly clear audio, > but I am not sure if I can conclude from, that RDS decoding should work. > I am pretty much insulated from RF at my place. What would be in favor > by people being sensitive to EM waves, but for experimenting it is > pretty bad. > > So I might gonna check this outside, where I can see in my car, that RDS > reception is working on my radio and then I can compare. Just want to > make sure we or you aren't chasing an error which might be based on poor > reception. > > However the messages in the terminal have been there last time and the I > copied to also were there. Still don't no if this is part of the problem > though. Therefore probably more testing on my side. > > Best regards, > Mike > > > >> Hi Mike, >> >> dashed only means "message port connection" rather than "item stream", >> so that's nothing to worry about, usually. >> So the bad news is that this is possible a GRC bug, which on the other >> hand is good news, because it means that gr-rds isn't broken, GRC just >> has a hard time correctly generating the python file. >> Since that worked for me: can you try the attached python file? >> >> Best regards, >> Marcus >> >> On 22.08.2015 11:26, Michael Thelen DK4MT wrote: >>> Hi, >>> >>> I am using GNU Radio 3.7.7.2 and I checked out out and built gr-rds. >>> However RDS Decoding is not working. I found that there are to two >>> connections have dashed lines (see picture). And in the terminal all I >>> get is Error: Cannot create connection. But I could not find a hint, >>> what is going wrong. Can somebody tell me, what to check for? >>> >>> Best regards, >>> Mike >>> >>> >>> ___ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@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 >> > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org
Re: [Discuss-gnuradio] gr-rds
Hi Andreas, thanks for the hint. However I am using a Ettus B200 and do not have access to a different SDR right now. I will test outside and then trying to find out what is going on. BR Mike Hi Michael, i read your mail and i could remember i had a similar problem with a lot of lost sync and bad block messages. My solution was to use a different RTL USB stick and to play with antenna type / antenna position and the gain of the RTL stick. I used a classical lamda / 2 dipol UKW Radio antenna. The stick was a noname. regards, Andreas Am 23.08.2015 um 20:02 schrieb Michael Thelen DK4MT: Hi Marcus, thanks, tried your script and found out, that it is always a little bit uncomely if something is not really reproducible. This is the status: With your script I did not get the earlier error anymore. However with my original I did not get it either. Instead I get the following message in GRC: @ Sync State Detected @ Lost Sync (Got 50 bad blocks on 50 total) I do not get this message if I run your script. Both scripts though do not show RDS information. So before I steal somebody's time I wonder if one reason could be, that I can only receive one station really at the limit and only if I set gain to a max. I can hear fairly clear audio, but I am not sure if I can conclude from, that RDS decoding should work. I am pretty much insulated from RF at my place. What would be in favor by people being sensitive to EM waves, but for experimenting it is pretty bad. So I might gonna check this outside, where I can see in my car, that RDS reception is working on my radio and then I can compare. Just want to make sure we or you aren't chasing an error which might be based on poor reception. However the messages in the terminal have been there last time and the I copied to also were there. Still don't no if this is part of the problem though. Therefore probably more testing on my side. Best regards, Mike Hi Mike, dashed only means message port connection rather than item stream, so that's nothing to worry about, usually. So the bad news is that this is possible a GRC bug, which on the other hand is good news, because it means that gr-rds isn't broken, GRC just has a hard time correctly generating the python file. Since that worked for me: can you try the attached python file? Best regards, Marcus On 22.08.2015 11:26, Michael Thelen DK4MT wrote: Hi, I am using GNU Radio 3.7.7.2 and I checked out out and built gr-rds. However RDS Decoding is not working. I found that there are to two connections have dashed lines (see picture). And in the terminal all I get is Error: Cannot create connection. But I could not find a hint, what is going wrong. Can somebody tell me, what to check for? Best regards, Mike ___ Discuss-gnuradio mailing list Discuss-gnuradio@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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@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
Re: [Discuss-gnuradio] gr-rds
Hi Mike, the B200 should usually be a little more reliable than the RTL dongles; what gain setting are you using? Best regards, Marcus On 08/25/2015 02:08 PM, Michael Thelen DK4MT wrote: Hi Andreas, thanks for the hint. However I am using a Ettus B200 and do not have access to a different SDR right now. I will test outside and then trying to find out what is going on. BR Mike Hi Michael, i read your mail and i could remember i had a similar problem with a lot of lost sync and bad block messages. My solution was to use a different RTL USB stick and to play with antenna type / antenna position and the gain of the RTL stick. I used a classical lamda / 2 dipol UKW Radio antenna. The stick was a noname. regards, Andreas Am 23.08.2015 um 20:02 schrieb Michael Thelen DK4MT: Hi Marcus, thanks, tried your script and found out, that it is always a little bit uncomely if something is not really reproducible. This is the status: With your script I did not get the earlier error anymore. However with my original I did not get it either. Instead I get the following message in GRC: @ Sync State Detected @ Lost Sync (Got 50 bad blocks on 50 total) I do not get this message if I run your script. Both scripts though do not show RDS information. So before I steal somebody's time I wonder if one reason could be, that I can only receive one station really at the limit and only if I set gain to a max. I can hear fairly clear audio, but I am not sure if I can conclude from, that RDS decoding should work. I am pretty much insulated from RF at my place. What would be in favor by people being sensitive to EM waves, but for experimenting it is pretty bad. So I might gonna check this outside, where I can see in my car, that RDS reception is working on my radio and then I can compare. Just want to make sure we or you aren't chasing an error which might be based on poor reception. However the messages in the terminal have been there last time and the I copied to also were there. Still don't no if this is part of the problem though. Therefore probably more testing on my side. Best regards, Mike Hi Mike, dashed only means message port connection rather than item stream, so that's nothing to worry about, usually. So the bad news is that this is possible a GRC bug, which on the other hand is good news, because it means that gr-rds isn't broken, GRC just has a hard time correctly generating the python file. Since that worked for me: can you try the attached python file? Best regards, Marcus On 22.08.2015 11:26, Michael Thelen DK4MT wrote: Hi, I am using GNU Radio 3.7.7.2 and I checked out out and built gr-rds. However RDS Decoding is not working. I found that there are to two connections have dashed lines (see picture). And in the terminal all I get is Error: Cannot create connection. But I could not find a hint, what is going wrong. Can somebody tell me, what to check for? Best regards, Mike ___ Discuss-gnuradio mailing list Discuss-gnuradio@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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-rds
Hi Marcus, I hoped so, that is why I bought one ;-). I think the max is 73dB. The actual value I set with a slider is 90dB. Thus I am pretty much maxed out there. But like I wrote earlier, that is the only way to receive at least one station. Don't have good RF working conditions. Even cellular is a problem. BR Mike Hi Mike, the B200 should usually be a little more reliable than the RTL dongles; what gain setting are you using? Best regards, Marcus On 08/25/2015 02:08 PM, Michael Thelen DK4MT wrote: Hi Andreas, thanks for the hint. However I am using a Ettus B200 and do not have access to a different SDR right now. I will test outside and then trying to find out what is going on. BR Mike Hi Michael, i read your mail and i could remember i had a similar problem with a lot of lost sync and bad block messages. My solution was to use a different RTL USB stick and to play with antenna type / antenna position and the gain of the RTL stick. I used a classical lamda / 2 dipol UKW Radio antenna. The stick was a noname. regards, Andreas Am 23.08.2015 um 20:02 schrieb Michael Thelen DK4MT: Hi Marcus, thanks, tried your script and found out, that it is always a little bit uncomely if something is not really reproducible. This is the status: With your script I did not get the earlier error anymore. However with my original I did not get it either. Instead I get the following message in GRC: @ Sync State Detected @ Lost Sync (Got 50 bad blocks on 50 total) I do not get this message if I run your script. Both scripts though do not show RDS information. So before I steal somebody's time I wonder if one reason could be, that I can only receive one station really at the limit and only if I set gain to a max. I can hear fairly clear audio, but I am not sure if I can conclude from, that RDS decoding should work. I am pretty much insulated from RF at my place. What would be in favor by people being sensitive to EM waves, but for experimenting it is pretty bad. So I might gonna check this outside, where I can see in my car, that RDS reception is working on my radio and then I can compare. Just want to make sure we or you aren't chasing an error which might be based on poor reception. However the messages in the terminal have been there last time and the I copied to also were there. Still don't no if this is part of the problem though. Therefore probably more testing on my side. Best regards, Mike Hi Mike, dashed only means message port connection rather than item stream, so that's nothing to worry about, usually. So the bad news is that this is possible a GRC bug, which on the other hand is good news, because it means that gr-rds isn't broken, GRC just has a hard time correctly generating the python file. Since that worked for me: can you try the attached python file? Best regards, Marcus On 22.08.2015 11:26, Michael Thelen DK4MT wrote: Hi, I am using GNU Radio 3.7.7.2 and I checked out out and built gr-rds. However RDS Decoding is not working. I found that there are to two connections have dashed lines (see picture). And in the terminal all I get is Error: Cannot create connection. But I could not find a hint, what is going wrong. Can somebody tell me, what to check for? Best regards, Mike ___ Discuss-gnuradio mailing list Discuss-gnuradio@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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@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
Re: [Discuss-gnuradio] gr-rds
Hi Marcus, thanks, tried your script and found out, that it is always a little bit uncomely if something is not really reproducible. This is the status: With your script I did not get the earlier error anymore. However with my original I did not get it either. Instead I get the following message in GRC: @ Sync State Detected @ Lost Sync (Got 50 bad blocks on 50 total) I do not get this message if I run your script. Both scripts though do not show RDS information. So before I steal somebody's time I wonder if one reason could be, that I can only receive one station really at the limit and only if I set gain to a max. I can hear fairly clear audio, but I am not sure if I can conclude from, that RDS decoding should work. I am pretty much insulated from RF at my place. What would be in favor by people being sensitive to EM waves, but for experimenting it is pretty bad. So I might gonna check this outside, where I can see in my car, that RDS reception is working on my radio and then I can compare. Just want to make sure we or you aren't chasing an error which might be based on poor reception. However the messages in the terminal have been there last time and the I copied to also were there. Still don't no if this is part of the problem though. Therefore probably more testing on my side. Best regards, Mike Hi Mike, dashed only means message port connection rather than item stream, so that's nothing to worry about, usually. So the bad news is that this is possible a GRC bug, which on the other hand is good news, because it means that gr-rds isn't broken, GRC just has a hard time correctly generating the python file. Since that worked for me: can you try the attached python file? Best regards, Marcus On 22.08.2015 11:26, Michael Thelen DK4MT wrote: Hi, I am using GNU Radio 3.7.7.2 and I checked out out and built gr-rds. However RDS Decoding is not working. I found that there are to two connections have dashed lines (see picture). And in the terminal all I get is Error: Cannot create connection. But I could not find a hint, what is going wrong. Can somebody tell me, what to check for? Best regards, Mike ___ Discuss-gnuradio mailing list Discuss-gnuradio@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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-rds
Hi Michael, i read your mail and i could remember i had a similar problem with a lot of lost sync and bad block messages. My solution was to use a different RTL USB stick and to play with antenna type / antenna position and the gain of the RTL stick. I used a classical lamda / 2 dipol UKW Radio antenna. The stick was a noname. regards, Andreas Am 23.08.2015 um 20:02 schrieb Michael Thelen DK4MT: Hi Marcus, thanks, tried your script and found out, that it is always a little bit uncomely if something is not really reproducible. This is the status: With your script I did not get the earlier error anymore. However with my original I did not get it either. Instead I get the following message in GRC: @ Sync State Detected @ Lost Sync (Got 50 bad blocks on 50 total) I do not get this message if I run your script. Both scripts though do not show RDS information. So before I steal somebody's time I wonder if one reason could be, that I can only receive one station really at the limit and only if I set gain to a max. I can hear fairly clear audio, but I am not sure if I can conclude from, that RDS decoding should work. I am pretty much insulated from RF at my place. What would be in favor by people being sensitive to EM waves, but for experimenting it is pretty bad. So I might gonna check this outside, where I can see in my car, that RDS reception is working on my radio and then I can compare. Just want to make sure we or you aren't chasing an error which might be based on poor reception. However the messages in the terminal have been there last time and the I copied to also were there. Still don't no if this is part of the problem though. Therefore probably more testing on my side. Best regards, Mike Hi Mike, dashed only means message port connection rather than item stream, so that's nothing to worry about, usually. So the bad news is that this is possible a GRC bug, which on the other hand is good news, because it means that gr-rds isn't broken, GRC just has a hard time correctly generating the python file. Since that worked for me: can you try the attached python file? Best regards, Marcus On 22.08.2015 11:26, Michael Thelen DK4MT wrote: Hi, I am using GNU Radio 3.7.7.2 and I checked out out and built gr-rds. However RDS Decoding is not working. I found that there are to two connections have dashed lines (see picture). And in the terminal all I get is Error: Cannot create connection. But I could not find a hint, what is going wrong. Can somebody tell me, what to check for? Best regards, Mike ___ Discuss-gnuradio mailing list Discuss-gnuradio@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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@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
Re: [Discuss-gnuradio] gr-rds
Hi Mike,
dashed only means message port connection rather than item stream,
so that's nothing to worry about, usually.
So the bad news is that this is possible a GRC bug, which on the other
hand is good news, because it means that gr-rds isn't broken, GRC just
has a hard time correctly generating the python file.
Since that worked for me: can you try the attached python file?
Best regards,
Marcus
On 22.08.2015 11:26, Michael Thelen DK4MT wrote:
Hi,
I am using GNU Radio 3.7.7.2 and I checked out out and built gr-rds.
However RDS Decoding is not working. I found that there are to two
connections have dashed lines (see picture). And in the terminal all I
get is Error: Cannot create connection. But I could not find a hint,
what is going wrong. Can somebody tell me, what to check for?
Best regards,
Mike
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
#!/usr/bin/env python2
##
# GNU Radio Python Flow Graph
# Title: Stereo FM receiver and RDS Decoder
# Generated: Sat Aug 22 13:10:16 2015
##
if __name__ == '__main__':
import ctypes
import sys
if sys.platform.startswith('linux'):
try:
x11 = ctypes.cdll.LoadLibrary('libX11.so')
x11.XInitThreads()
except:
print Warning: failed to XInitThreads()
from gnuradio import analog
from gnuradio import audio
from gnuradio import blocks
from gnuradio import digital
from gnuradio import digital;import cmath
from gnuradio import eng_notation
from gnuradio import filter
from gnuradio import gr
from gnuradio import uhd
from gnuradio import wxgui
from gnuradio.eng_option import eng_option
from gnuradio.fft import window
from gnuradio.filter import firdes
from gnuradio.wxgui import fftsink2
from gnuradio.wxgui import forms
from gnuradio.wxgui import scopesink2
from gnuradio.wxgui import waterfallsink2
from grc_gnuradio import wxgui as grc_wxgui
from optparse import OptionParser
import math
import rds
import time
import wx
class rds_rx(grc_wxgui.top_block_gui):
def __init__(self):
grc_wxgui.top_block_gui.__init__(self, title=Stereo FM receiver and RDS Decoder)
##
# Variables
##
self.samp_rate = samp_rate = 100
self.bb_decim = bb_decim = 4
self.freq_offset = freq_offset = 25
self.freq = freq = 97e6
self.baseband_rate = baseband_rate = samp_rate/bb_decim
self.audio_decim = audio_decim = 5
self.xlate_bandwidth = xlate_bandwidth = 10
self.volume = volume = 0
self.gain = gain = 20
self.freq_tune = freq_tune = freq - freq_offset
self.audio_rate = audio_rate = 48000
self.audio_decim_rate = audio_decim_rate = baseband_rate/audio_decim
##
# Blocks
##
_volume_sizer = wx.BoxSizer(wx.VERTICAL)
self._volume_text_box = forms.text_box(
parent=self.GetWin(),
sizer=_volume_sizer,
value=self.volume,
callback=self.set_volume,
label=Volume,
converter=forms.float_converter(),
proportion=0,
)
self._volume_slider = forms.slider(
parent=self.GetWin(),
sizer=_volume_sizer,
value=self.volume,
callback=self.set_volume,
minimum=-20,
maximum=10,
num_steps=300,
style=wx.SL_HORIZONTAL,
cast=float,
proportion=1,
)
self.GridAdd(_volume_sizer, 0, 1, 1, 1)
self.nb = self.nb = wx.Notebook(self.GetWin(), style=wx.NB_TOP)
self.nb.AddPage(grc_wxgui.Panel(self.nb), BB)
self.nb.AddPage(grc_wxgui.Panel(self.nb), Demod)
self.nb.AddPage(grc_wxgui.Panel(self.nb), L+R)
self.nb.AddPage(grc_wxgui.Panel(self.nb), Pilot)
self.nb.AddPage(grc_wxgui.Panel(self.nb), DSBSC)
self.nb.AddPage(grc_wxgui.Panel(self.nb), RDS)
self.nb.AddPage(grc_wxgui.Panel(self.nb), L-R)
self.nb.AddPage(grc_wxgui.Panel(self.nb), RDS constellation)
self.nb.AddPage(grc_wxgui.Panel(self.nb), Waterfall)
self.GridAdd(self.nb, 2, 0, 1, 2)
_freq_sizer = wx.BoxSizer(wx.VERTICAL)
self._freq_text_box = forms.text_box(
parent=self.GetWin(),
sizer=_freq_sizer,
value=self.freq,
callback=self.set_freq,
label=Freq,
converter=forms.float_converter(),
proportion=0,
)
self._freq_slider = forms.slider(
parent=self.GetWin(),
sizer=_freq_sizer,
value=self.freq,
callback=self.set_freq,
minimum=88.1e6,
Re: [Discuss-gnuradio] gr-rds
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. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-rds
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 On Jan 17, 2014, at 2:39 PM, kai g kai.garr...@gmx.de wrote: 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! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-rds
On Wed, Jan 15, 2014 at 06:44:51AM +0100, Bastian Bloessl wrote:
On 2014-01-14 14:21, Michael Dickens wrote:
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
I never heard about install_name_dir, but I just pushed a fix and
hopefully I got it right now :-)
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
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-rds
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 :) - MLD On Jan 15, 2014, at 5:06 AM, Martin Braun martin.br...@ettus.com wrote: Good point, it seems like a harmless patch. Michael, what do you think? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-rds
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 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
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-rds
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 fix and hopefully I got it right now :-) Thanks for your help! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-rds
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 an easy default.
Both should be in the default PYTHONPATH; you can see this via the command
{{{
python -c import sys; print sys.path
}}}
So, you should not have to set PYTHONPATH to anything special for this install.
If you have Python files installed elsewhere, you might still need it for
those files.
The otool listing for the RDS library:
{{{
libgnuradio-rds.dylib:
libgnuradio-rds.dylib (compatibility version 0.0.0, current version
0.0.0)
}}}
is fine since nobody is going to be linking against it. Ideally, this first
entry would be the actual path/name combination
(/opt/local/lib/libgnuradio-rds.dylib), but since it won't be used for
anything else it doesn't really matter. If you want to correct it, you can do
so via:
{{{
install_name_tool -id /opt/local/lib/libgnuradio-rds.dylib libgnuradio-rds.dylib
}}}
If you do the otool command on _rds_swig.so, I think you'll find that it
contains:
{{{
_rds_swig.so (compatibility version 0.0.0, current version 0.0.0)
libgnuradio-rds.dylib (compatibility version 0.0.0, current version
0.0.0)
}}}
and this is where the issue is because the dylib cannot be found since DYLD
does not know where to look for it (DYLD can do a lot of things, but it does
-not- do arbitrary searches, generally, very well). Again, the actual path to
the .so is not important since this library (shared object) will never be
linked to, just used by Python.
You can change this incorrect linkage via:
{{{
install_name_tool -change libgnuradio-rds.dylib
/opt/local/lib/libgnuradio-rds.dylib _rds_swig.so
}}}
and then Python should be able to load RDS correctly.
Hope this helps! - MLD
On Jan 14, 2014, at 12:51 AM, Ulf Söderberg u...@soderbergsoftware.com wrote:
These are the files that gets installed in
/opt/local/lib/python2.7/site-packages/rds:
-rwxr-xr-x 1 root admin 373688 Jan 14 06:39 _rds_swig.so
In /opt/local/lib, the only file installed is:
-rwxr-xr-x1 root admin549160 Jan 14 06:39 libgnuradio-rds.dylib
The command otool -L libgnuradio-rds.dylib renders the following:
libgnuradio-rds.dylib:
libgnuradio-rds.dylib (compatibility version 0.0.0, current version
0.0.0)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-rds
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 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
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-rds
Hi Michael,
I tried that command you mentioned, but I can't see that the path
/opt/local/lib/python2.7/site-packages is there.
{{{
python -c import sys; print sys.path
}}}
gives:
['', '/Library/Python/2.7/site-packages/Pygments-1.6-py2.7.egg',
'/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python',
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python27.zip',
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7',
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin',
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac',
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages',
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk',
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-old',
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload',
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages',
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PIL',
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gtk-2.0',
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/wx-3.0-osx_cocoa',
'/Library/Python/2.7/site-packages']
Maybe that's the reason why the rds package isn't found then.
/Ulf
On 14 jan 2014, at 14:16, Michael Dickens michael.dick...@ettus.com wrote:
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 an easy default.
Both should be in the default PYTHONPATH; you can see this via the command
{{{
python -c import sys; print sys.path
}}}
So, you should not have to set PYTHONPATH to anything special for this
install. If you have Python files installed elsewhere, you might still need
it for those files.
The otool listing for the RDS library:
{{{
libgnuradio-rds.dylib:
libgnuradio-rds.dylib (compatibility version 0.0.0, current version
0.0.0)
}}}
is fine since nobody is going to be linking against it. Ideally, this first
entry would be the actual path/name combination
(/opt/local/lib/libgnuradio-rds.dylib), but since it won't be used for
anything else it doesn't really matter. If you want to correct it, you can
do so via:
{{{
install_name_tool -id /opt/local/lib/libgnuradio-rds.dylib
libgnuradio-rds.dylib
}}}
If you do the otool command on _rds_swig.so, I think you'll find that it
contains:
{{{
_rds_swig.so (compatibility version 0.0.0, current version 0.0.0)
libgnuradio-rds.dylib (compatibility version 0.0.0, current version
0.0.0)
}}}
and this is where the issue is because the dylib cannot be found since DYLD
does not know where to look for it (DYLD can do a lot of things, but it does
-not- do arbitrary searches, generally, very well). Again, the actual path
to the .so is not important since this library (shared object) will never
be linked to, just used by Python.
You can change this incorrect linkage via:
{{{
install_name_tool -change libgnuradio-rds.dylib
/opt/local/lib/libgnuradio-rds.dylib _rds_swig.so
}}}
and then Python should be able to load RDS correctly.
Hope this helps! - MLD
On Jan 14, 2014, at 12:51 AM, Ulf Söderberg u...@soderbergsoftware.com
wrote:
These are the files that gets installed in
/opt/local/lib/python2.7/site-packages/rds:
-rwxr-xr-x 1 root admin 373688 Jan 14 06:39 _rds_swig.so
In /opt/local/lib, the only file installed is:
-rwxr-xr-x1 root admin549160 Jan 14 06:39 libgnuradio-rds.dylib
The command otool -L libgnuradio-rds.dylib renders the following:
libgnuradio-rds.dylib:
libgnuradio-rds.dylib (compatibility version 0.0.0, current version
0.0.0)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-rds
On 2014-01-14 14:21, Michael Dickens wrote:
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
I never heard about install_name_dir, but I just pushed a fix and
hopefully I got it right now :-)
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.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-rds
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 filename 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 Dickens, Mac OS X Programmer
Ettus Research Technical Support
Email: supp...@ettus.com
Web: http://www.ettus.com
On Jan 12, 2014, at 2:53 AM, Bastian Bloessl bastian.bloe...@uibk.ac.at wrote:
On 2014-01-11 22:32, Ulf Söderberg 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 module
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
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-rds
On 2014-01-13 22:03, Michael Dickens 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. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-rds
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 module import rds ImportError: No module named rds Any ideas? /Ulf ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-rds
Hi Ulf, On 2014-01-11 22:32, Ulf Söderberg 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 module 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-rds
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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
