hackrf pipe error

[derekchal]

Recently I have not been able to start gqrx on my desktop machine. I get a pipe error shown below:

_linux; GNU C++ version 6.2.0 20161005; Boost_106100; UHD_3.11.0.git-28-gc66cb1ba

gr-osmosdr v0.1.4-86-ge9dde9af (0.1.5git) gnuradio 3.7.12git-48-gc73a73fd built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy soapy redpitaya Resampling audio 96000 -> 48000 BookmarksFile is /home/derek/.config/gqrx/bookmarks.csv gr-osmosdr v0.1.4-86-ge9dde9af (0.1.5git) gnuradio 3.7.12git-48-gc73a73fd built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy soapy redpitaya Using HackRF One with firmware 2017.02.1 terminate called after throwing an instance of 'std::runtime_error' what(): hackrf_setfreq(1e+10) has failed (-1000) Pipe error Aborted

It works correctly with a rtl dongle and a funcube dongle.

Has anybody seen this error. I could well believe that I have updated something which causes a conflict.

[csete]

If you update your firmware in the device you have to make sure that libhackrf is also up to date and that gr-osmosdr / gqrx uses this latest library.

Please use the mailing list for user support matters and keep github issues for bugs and feature tracking http://gqrx.dk/user-support

[phocean]

You should reopen this issue. I am having the same problem, whereas all my libs and my firmware are in sync. Moreover, it should not fail silently with a core dump. It works if I open it on another device input, then switch back to the hackrf... until the next time I relaunch the tool.

[csete]

@phocean If somebody provides a proper error report using officially released packages and using gnuradio 3.7.10.x, I will consider. Note that the original poster used an arbitrary mixture of git snapshots and I don't even have a clue which operating systems are being used.

Even if there is an error and we reopen this issue, most likely nothing will happen. Gqrx is just a GUI and there is no device specific code in it. So the relevant developers who might be able to fix it wont even know. In the past I have spent a lot of time fixing and coordinating these issues but I don't have time for it anymore.

[phocean]

No problem, I understand perfectly. I will try to post more details.

For now all I can tell is that I am using packages from openSUSE Tumbleweed:

• gnuradio 3.7.11
• hackrf 2017.02.1 (lib and firmware)

I will have zero issue using grc.

Here is the kind of output I get (2 subsequent run, the last one fails):

% gqrx
linux; GNU C++ version 7.2.1 20171020 [gcc-7-branch revision 253932]; Boost_106501; UHD_003.009.007-0-unknown

gr-osmosdr v0.1.x-xxx-xunknown (0.1.5git) gnuradio 3.7.11
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy redpitaya 
Resampling audio 96000 -> 48000
BookmarksFile is /home/phocean/.config/gqrx/bookmarks.csv
gr-osmosdr v0.1.x-xxx-xunknown (0.1.5git) gnuradio 3.7.11
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy redpitaya 
Using HackRF One with firmware 2017.02.1 
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO

% gqrx
linux; GNU C++ version 7.2.1 20171020 [gcc-7-branch revision 253932]; Boost_106501; UHD_003.009.007-0-unknown

gr-osmosdr v0.1.x-xxx-xunknown (0.1.5git) gnuradio 3.7.11
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy redpitaya 
Resampling audio 96000 -> 48000
BookmarksFile is /home/phocean/.config/gqrx/bookmarks.csv
gr-osmosdr v0.1.x-xxx-xunknown (0.1.5git) gnuradio 3.7.11
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy redpitaya 
Using HackRF One with firmware 2017.02.1 
terminate called after throwing an instance of 'std::runtime_error'
  what():  hackrf_set_freq(1e+12) has failed (-1000) Pipe error
[1]    9736 abort (core dumped)  gqrx

I will try to reproduce from source on a test machine, if it helps.

[csete]

I'm surprised that it builds at all with gnuradio 3.7.11 c.f. issue https://github.com/csete/gqrx/issues/549

I have have had similar issues with LimeSDR where it appears that the device is not being closed https://github.com/csete/gqrx/issues/489

You should see the same behavior when using GRC.

I am reopening the issue, but all I can say is that this whole architecture is broken :(

[c5e3]

update from #583 :

i've symlinked /usr/local/lib/libgnuradio-osmosdr.so and libgnuradio-osmosdr.so.0.1.4 to libgnuradio-osmosdr.so.0.1.5git therefore gqrx v2.6 is using the same lib as v2.9-4-g4138038

[csete]

@c5e3 @phocean

I think I found the problem (in gqrx) and pushed a fix. Please pull and test if you can.

I apologize for my negative attitude in this matter, but I have been under lot of pressure and been dealing with a lot of "noise" last year.

[c5e3]

@csete i can confirm, that it works now! thanks for your quick fix! 👍

i can fully understand, that you have to ignore some sketchy error reports, since you get a lot of comments on gqrx and the sdr community is growing very quickly

[csete]

Ok thanks! I will make a new release to make this fix available.