Hi,
my C++ program is already working great, except one major bug on OS X:
I cannot stop the flowgraph: When I call on the top block:
gr_tb->stop();
gr_tb->wait();
It will hang on the wait. That means the program cannot quit nicely, but
will always crash at exit. It´s working fine on Linux and Windows.
Is there some known problem?
First I installed GnuRadio using macports (removed and then installed
from source using depencies from macports).
Then I removed all the macports stuff and installed all dependencies
myself (with boost 1.56), same problem.
Hi Michael,
sorry, my mistake. I introduced a stupid bug in my short test program
with a sine source so I got a similar result like in my complete
program, although GnuRadio is working fine. The problem is probably
located somewhere in OsmoSDR/rtl-sdr/libusb. Without any hardware
connected (OsmoSDR generates null source) its working fine, with a
RTL-Stick connected it doesnt work. I tried two different ones (E4000
and R820T tuner), same result. Unfortunately I do not have any other
hardware to test.
Oh, I wont be on GRCon, flying to another continent just to get some
bugs fixed is probably a bit too much.
Thanks
Stefan
Hi Stefan - Thanks for reporting back; no problems on any mistakes or
bugs or not being at GRCon14. It sounds like stop() and wait() work on
OSX within GNU Radio, and that the actual issue is when using a
3rd-party interface between the hardware and GNU Radio. So, hopefully
these other projects are listening / reading - MLD
Can somebody provide me with a program that I can use to test on OSX? I’m happy
to provide patches … - MLD
Well, as I said above, osmocom_fft uses ->stop() then ->wait() in its
shutdown procedure to ensure the flow graph is stopped before the GUI
is destroyed. So running osmocom_fft and clicking the ‘close’ of the
window should trigger that.
Ah; OK. Running osmocom_fft using a HackRF Jawbreaker and everything
works OK; I can do “stop”, “run”, and close without issues. Maybe this
issue is specific to some RTL device(s) rather than OSX? - MLD
On Mon, Sep 22, 2014 at 3:47 PM, Michael D. [email protected] wrote:
Hi Stefan - Thanks for reporting back; no problems on any mistakes or bugs or
not being at GRCon14. It sounds like stop() and wait() work on OSX within GNU
Radio, and that the actual issue is when using a 3rd-party interface between the
hardware and GNU Radio. So, hopefully these other projects are listening / reading - MLD
Well, it works on windows and linux according to the OP. (and since
osmocom_fft does a stop() wait(), I can definitely confirm the ‘linux’
part).
Since none of the osmo people work on OSX, unless there is a confirmed
working patch attached to the message, this is pretty unlikely to
receive any attention.
Ah; OK. Running osmocom_fft using a HackRF Jawbreaker and everything works OK;
I can do “stop”, “run”, and close without issues. Maybe this issue is specific to
some RTL device(s) rather than OSX? - MLD
Well, it definitely works with rtl on linux, but it wouldn’t suprise
me if the issue was specific to the combination OSX+rtl since the
‘stop’ path is highly dependent of the hw driver and its interactions
with libusb.
Unfortunately I do not have any other hardware than two different RTL
devices (one with E4000 tuner and one with R820T).
I attached the most simple program to reproduce that error, it just
connects the OsmoSDR source with a null sink, starts the flowgraph,
waits a second and then stops it and exit.
Working fine on Linux and Windows, but not on OS X (10.9), program never
returns. Same problem with all stuff (boost/libusb…) self build or
installed using ports.
Is someone able to find the bug?
Unfortunately I do not have any other hardware than two different RTL
devices (one with E4000 tuner and one with R820T).
I attached the most simple program to reproduce that error, it just
connects the OsmoSDR source with a null sink, starts the flowgraph,
waits a second and then stops it and exit.
Working fine on Linux and Windows, but not on OS X (10.9), program never
returns. Same problem with all stuff (boost/libusb…) self build or
installed using ports.
Is someone able to find the bug?
I compiled your code using
{{{
c++ -O2 -I/opt/local/include -L/opt/local/lib -lgnuradio-osmosdr
-lgnuradio-runtime -lgnuradio-blocks -lboost_system-mt -Wall -o
osmo_test osmo_test.cc
}}}
then tried it using the following devices without issues (returns
cleanly), using MacPorts for all of the software installs, running on
OSX 10.8.5 (latest updates), Xcode 5.1.1 (Build version 5B1008):
HackRF Jawbreaker
NooElec R820T
ER B210
I’ll try on 10.9 shortly, since maybe this is an OS specific issue. -
MLD
Mine outputs (in gdb):
{{{
gr-osmosdr v0.1.3-1-g4bb2fa4e (0.1.4git) gnuradio v3.7.x-xxx-xunknown
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace
[Reading symbols for shared libraries . done]
Using device #0 Realtek RTL2838UHIDIR SN: 00000001
Found Rafael Micro R820T tuner
Program exited normally.
(gdb)
}}}
Can you try updating GNU Radio to the latest GIT master? You’ll have to
reinstall gr-osmosdr too. I’m installing the 10.10 preview right now
for GR / UHD testing; I’ll try this code on 10.10 and 10.9 soon. - MLD
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
- MLD
- MLD