search

gqrx-sdr / gqrx

Software defined radio receiver powered by GNU Radio and Qt.
http://gqrx.dk
GNU General Public License v3.0
3.1k stars 544 forks source link

Gqrx issue with Ettus B200 #145

Closed Stanback closed 10 years ago

Stanback commented 10 years ago

When running Gqrx with the Ettus B200, it detects and initializes the hardware just fine and the audio and FFT visualization work for the first couple of seconds - then the audio abruptly stops and the visualizations stop showing the waveform.

I'm not sure whether the problem is with Gqrx, gr-osmosdr, Gnuradio, or the UHD driver. I've compiled the latest version of the code from the master branch of their respective repositories. I'm running on Mac OSX 10.9.1. The problem shows up regardless of which sample rate I've chosen and whether I'm using USB 2 or 3.

I've uploaded a video showing what happens here: https://www.youtube.com/watch?v=jyPHCEm5alE

What's the best way to go about debugging this? Any help would be greatly appreciated.

FYI, I'm using GNU Radio Companion and it works just fine with the WFM and NFM flow graphs that I've created. If I try to use Gqrx and then go back to GNU Radio Companion, GNU Radio Companion will error out with the following message until I unplug the USB and plug it back in again:

Traceback (most recent call last):
  File "/Users/brian/Desktop/fm_receiver.py", line 201, in <module>
    tb = fm_receiver()
  File "/Users/brian/Desktop/fm_receiver.py", line 115, in __init__
    channels=range(1),
  File "/usr/local/lib/python2.7/site-packages/gnuradio/uhd/__init__.py", line 122, in constructor_interceptor
    return old_constructor(*args)
  File "/usr/local/lib/python2.7/site-packages/gnuradio/uhd/uhd_swig.py", line 1754, in make
    return _uhd_swig.usrp_source_make(*args)
RuntimeError: RuntimeError: usb rx8 submit failed: LIBUSB_ERROR_PIPE
^CTraceback (most recent call last):
  File "/usr/local/bin/gnuradio-companion", line 72, in <module>
    ActionHandler(args, Platform())
  File "/usr/local/lib/python2.7/site-packages/gnuradio/grc/gui/ActionHandler.py", line 72, in __init__
    gtk.main()
csete commented 10 years ago

Sorry to hear about the issue. I don't know how much I can do about this right now as I nether have a B200 and not particularly familiar with the device driver code but I recommend trying the following:

  1. Ensure you build gqrx and gnuradio using portaudio backends (qmake AUDIO_BACKEND=portaudio). The default OSX backend won't work.
  2. Build gqrx with debug enabled (qmake CONFIG+=debug) and see what messages are printed before this happens.
  3. Try the latest snapshot from macports and/or check which patches there may be that have not been included in gnuradio or uhd.
beaubell commented 10 years ago

I can second this problem. I have a B210 running on Gentoo Linux with the latest git build of GQRX. I will recompile with debug symbols and see what happens.

csete commented 10 years ago

Ok, thanks for the info. So it is not an OS X specific issue which will probably make it easier to debug.

beaubell commented 10 years ago

here is a gdb session dump of a startup, the problem happening (within seconds), and application close.

beau@krios /usr/src/gqrx/build $ gdb ./gqrx GNU gdb (Gentoo 7.5.1 p2) 7.5.1 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". For bug reporting instructions, please see: http://bugs.gentoo.org/... Reading symbols from /usr/src/gqrx/build/gqrx...done. (gdb) run Starting program: /usr/src/gqrx/build/gqrx warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". linux; GNU C++ version 4.7.3; Boost_105300; UHD_003.006.002-64-g92b0b7ab

Controlport disabled No user supplied config file. Using "default.conf" gr-osmosdr 0.1.0 (0.1.0) gnuradio 3.7.2.1 built-in source types: uhd [New Thread 0x7ffff3a5d700 (LWP 19644)] [New Thread 0x7ffff325c700 (LWP 19645)] [Thread 0x7ffff325c700 (LWP 19645) exited] [Thread 0x7ffff3a5d700 (LWP 19644) exited] [New Thread 0x7ffff3a5d700 (LWP 19646)] [New Thread 0x7ffff325c700 (LWP 19647)] [Thread 0x7ffff325c700 (LWP 19647) exited] [Thread 0x7ffff3a5d700 (LWP 19646) exited] [New Thread 0x7ffff3a5d700 (LWP 19648)] [New Thread 0x7ffff325c700 (LWP 19649)] -- Loading firmware image: /usr/local/share/uhd/images/usrp_b200_fw.hex... done [Thread 0x7ffff325c700 (LWP 19649) exited] [Thread 0x7ffff3a5d700 (LWP 19648) exited] [New Thread 0x7ffff3a5d700 (LWP 19664)] [New Thread 0x7ffff325c700 (LWP 19665)] [Thread 0x7ffff325c700 (LWP 19665) exited] [Thread 0x7ffff3a5d700 (LWP 19664) exited] [New Thread 0x7ffff3a5d700 (LWP 19666)] [New Thread 0x7ffff325c700 (LWP 19667)] [Thread 0x7ffff325c700 (LWP 19667) exited] [Thread 0x7ffff3a5d700 (LWP 19666) exited] [New Thread 0x7ffff3a5d700 (LWP 19668)] [New Thread 0x7ffff325c700 (LWP 19669)] [Thread 0x7ffff325c700 (LWP 19669) exited] [Thread 0x7ffff3a5d700 (LWP 19668) exited] [New Thread 0x7ffff3a5d700 (LWP 19670)] [New Thread 0x7ffff325c700 (LWP 19671)] -- Loading FPGA image: /usr/local/share/uhd/images/usrp_b210_fpga.bin... done -- Operating over USB 2. [New Thread 0x7ffff2a5b700 (LWP 19677)] -- Detecting internal GPSDO.... not found -- Initialize CODEC control... -- Initialize Radio control... -- Performing register loopback test... pass -- Performing register loopback test... pass -- Performing CODEC loopback test... pass -- Performing CODEC loopback test... pass -- Asking for clock rate 32 MHz -- Actually got clock rate 32 MHz -- Performing timer loopback test... pass -- Performing timer loopback test... pass [Thread 0x7ffff2a5b700 (LWP 19677) exited] [Thread 0x7ffff325c700 (LWP 19671) exited] [Thread 0x7ffff3a5d700 (LWP 19670) exited]

FATAL: AssertionError: assertion failed: A:0 is not a valid rx subdevice specification on mboard 0. possible values are: [A:A, A:B].

Trying to fill up 1 missing channel(s) with null source(s). This is being done to prevent the application from crashing due to a gnuradio bug. The maintainers have been informed.

Using Volk machine: avx_64_mmx_orc IQ DCR alpha: 1.04166e-05 [New Thread 0x7ffff3a5d700 (LWP 19678)] Using audio backend: auto New filter offset: 0 Hz Loading configuration from: "default.conf" Configuration file: "/home/beau/.config/gqrx/default.conf" gr-osmosdr 0.1.0 (0.1.0) gnuradio 3.7.2.1 built-in source types: uhd [New Thread 0x7ffff325c700 (LWP 19679)] [New Thread 0x7ffff2a5b700 (LWP 19680)] [Thread 0x7ffff2a5b700 (LWP 19680) exited] [Thread 0x7ffff325c700 (LWP 19679) exited] [New Thread 0x7ffff325c700 (LWP 19681)] [New Thread 0x7ffff2a5b700 (LWP 19682)] [Thread 0x7ffff2a5b700 (LWP 19682) exited] [Thread 0x7ffff325c700 (LWP 19681) exited] [New Thread 0x7ffff325c700 (LWP 19683)] [New Thread 0x7ffff2a5b700 (LWP 19684)] [Thread 0x7ffff2a5b700 (LWP 19684) exited] [Thread 0x7ffff325c700 (LWP 19683) exited] [New Thread 0x7ffff325c700 (LWP 19685)] [New Thread 0x7ffff2a5b700 (LWP 19686)] [Thread 0x7ffff2a5b700 (LWP 19686) exited] [Thread 0x7ffff325c700 (LWP 19685) exited] [New Thread 0x7ffff325c700 (LWP 19687)] [New Thread 0x7ffff2a5b700 (LWP 19688)] [Thread 0x7ffff2a5b700 (LWP 19688) exited] [Thread 0x7ffff325c700 (LWP 19687) exited] [New Thread 0x7ffff325c700 (LWP 19689)] [New Thread 0x7ffff2a5b700 (LWP 19690)] [Thread 0x7ffff2a5b700 (LWP 19690) exited] [Thread 0x7ffff325c700 (LWP 19689) exited] [New Thread 0x7ffff325c700 (LWP 19691)] [New Thread 0x7ffff2a5b700 (LWP 19692)] -- Operating over USB 2. [New Thread 0x7ffff1b7d700 (LWP 19693)] -- Initialize CODEC control... -- Initialize Radio control... -- Performing register loopback test... pass -- Performing register loopback test... pass -- Performing CODEC loopback test... pass -- Performing CODEC loopback test... pass -- Asking for clock rate 32 MHz -- Actually got clock rate 32 MHz -- Performing timer loopback test... pass -- Performing timer loopback test... pass -- Using subdev spec 'A:A'. New antenna selected: "TX/RX"

Gain name: "PGA" min: 0 max: 73 step: 1

[Thread 0x7ffff3a5d700 (LWP 19678) exited] [New Thread 0x7ffff3a5d700 (LWP 19694)] IQ DCR samp_rate: 8e+06 IQ DCR alpha: 1.25e-07 Changing NB_RX quad rate: 96000 -> 8e+06 Requested sample rate: 8000000 Actual sample rate : "8000000.000000" Requested bandwidth: 0 Hz Actual bandwidth : 0 Hz setFreqCorr : 0 ppm New LNB LO: 0 Hz "New frequnecy range: 34 - 6016 MHz (step is 0.00745058 Hz but we use 1 Hz)." "New frequnecy range: 34 - 6016 MHz (step is 0.00745058 Hz but we use 1 Hz)." Filter preset for mode 5 LO: -80000 HI: 80000 Genrating taps for new filter LO:-80000 HI:80000 TW:16000 Required number of taps: 49 New filter offset: 49000 Hz setFftRate to "15 fps" New FFT rate: 15 Hz setFftSize to "4096" [New Thread 0x7ffff09f0700 (LWP 19695)] [New Thread 0x7fffdfffe700 (LWP 19696)] [New Thread 0x7fffdf7fd700 (LWP 19697)] [New Thread 0x7fffdeffc700 (LWP 19698)] [New Thread 0x7fffde7fb700 (LWP 19699)] [New Thread 0x7fffddffa700 (LWP 19700)] [New Thread 0x7fffdd7f9700 (LWP 19701)] [New Thread 0x7fffdcff8700 (LWP 19702)] [New Thread 0x7fffbffff700 (LWP 19703)] [New Thread 0x7fffbf7fe700 (LWP 19704)] [New Thread 0x7fffbeffd700 (LWP 19705)] [New Thread 0x7fffbe7fc700 (LWP 19706)] [New Thread 0x7fffbdffb700 (LWP 19707)] [New Thread 0x7fffbd7fa700 (LWP 19708)] [New Thread 0x7fffbcff9700 (LWP 19709)] [New Thread 0x7fff9bfff700 (LWP 19710)] [New Thread 0x7fff9b7fe700 (LWP 19711)] [New Thread 0x7fff9affd700 (LWP 19712)] [New Thread 0x7fff9a7fc700 (LWP 19713)] [New Thread 0x7fff99ffb700 (LWP 19714)] [New Thread 0x7fff997fa700 (LWP 19715)] [New Thread 0x7fff98ff9700 (LWP 19716)] [New Thread 0x7fff7bfff700 (LWP 19717)] [New Thread 0x7fff7b7fe700 (LWP 19718)] [New Thread 0x7fff7affd700 (LWP 19719)] [New Thread 0x7fff7a7fc700 (LWP 19720)] [New Thread 0x7fff79ffb700 (LWP 19721)] [New Thread 0x7fff797fa700 (LWP 19722)] [New Thread 0x7fff78ff9700 (LWP 19723)] [New Thread 0x7fff63fff700 (LWP 19724)] [New Thread 0x7fff637fe700 (LWP 19725)] [New Thread 0x7fff62ffd700 (LWP 19726)] [New Thread 0x7fff627fc700 (LWP 19727)] New FFT rate: 15 Hz New FFT rate: 15 Hz No audio FFT data. Force RX reconf (jerky dongle workarond)... [Thread 0x7fff9b7fe700 (LWP 19711) exited] [Thread 0x7fff997fa700 (LWP 19715) exited] [Thread 0x7fff78ff9700 (LWP 19723) exited] [Thread 0x7fff637fe700 (LWP 19725) exited] [Thread 0x7fffbd7fa700 (LWP 19708) exited] [Thread 0x7fff7bfff700 (LWP 19717) exited] [Thread 0x7fffbcff9700 (LWP 19709) exited] [Thread 0x7fff79ffb700 (LWP 19721) exited] [Thread 0x7fffdf7fd700 (LWP 19697) exited] [Thread 0x7fff62ffd700 (LWP 19726) exited] [Thread 0x7fff63fff700 (LWP 19724) exited] [Thread 0x7fffbdffb700 (LWP 19707) exited] [Thread 0x7fffbffff700 (LWP 19703) exited] [Thread 0x7ffff09f0700 (LWP 19695) exited] [Thread 0x7fffde7fb700 (LWP 19699) exited] [Thread 0x7fffdcff8700 (LWP 19702) exited] [Thread 0x7fff7b7fe700 (LWP 19718) exited] [Thread 0x7fffddffa700 (LWP 19700) exited] [Thread 0x7fff9a7fc700 (LWP 19713) exited] [Thread 0x7fff7a7fc700 (LWP 19720) exited] [Thread 0x7fff7affd700 (LWP 19719) exited] [Thread 0x7fffbeffd700 (LWP 19705) exited] [Thread 0x7fff627fc700 (LWP 19727) exited] [Thread 0x7fff98ff9700 (LWP 19716) exited] [Thread 0x7fff797fa700 (LWP 19722) exited] [Thread 0x7fff9bfff700 (LWP 19710) exited] [Thread 0x7fffdd7f9700 (LWP 19701) exited] [Thread 0x7fff99ffb700 (LWP 19714) exited] [Thread 0x7fffbe7fc700 (LWP 19706) exited] [Thread 0x7fff9affd700 (LWP 19712) exited] [Thread 0x7fffdfffe700 (LWP 19696) exited] [Thread 0x7fffbf7fe700 (LWP 19704) exited] [Thread 0x7fffdeffc700 (LWP 19698) exited] [New Thread 0x7fff627fc700 (LWP 19728)] [New Thread 0x7fff62ffd700 (LWP 19729)] [New Thread 0x7fff637fe700 (LWP 19730)] [New Thread 0x7fff63fff700 (LWP 19731)] [New Thread 0x7ffff0946700 (LWP 19732)] [New Thread 0x7fffdfffe700 (LWP 19733)] [New Thread 0x7fffdf7fd700 (LWP 19734)] [New Thread 0x7fffdeffc700 (LWP 19735)] [New Thread 0x7fffde7fb700 (LWP 19736)] [New Thread 0x7fffddffa700 (LWP 19737)] [New Thread 0x7fffdd7f9700 (LWP 19738)] [New Thread 0x7fffdcff8700 (LWP 19739)] [New Thread 0x7fffbffff700 (LWP 19740)] [New Thread 0x7fffbf7fe700 (LWP 19741)] [New Thread 0x7fffbeffd700 (LWP 19742)] [New Thread 0x7fffbe7fc700 (LWP 19743)] [New Thread 0x7fffbdffb700 (LWP 19744)] [New Thread 0x7fffbd7fa700 (LWP 19745)] [New Thread 0x7fffbcff9700 (LWP 19746)] [New Thread 0x7fff9bfff700 (LWP 19747)] [New Thread 0x7fff9b7fe700 (LWP 19748)] [New Thread 0x7fff9affd700 (LWP 19749)] [New Thread 0x7fff9a7fc700 (LWP 19750)] [New Thread 0x7fff99ffb700 (LWP 19751)] [New Thread 0x7fff997fa700 (LWP 19752)] [New Thread 0x7fff98ff9700 (LWP 19753)] [New Thread 0x7fff7bfff700 (LWP 19754)] [New Thread 0x7fff7b7fe700 (LWP 19755)] [New Thread 0x7fff7affd700 (LWP 19756)] [New Thread 0x7fff7a7fc700 (LWP 19757)] [New Thread 0x7fff79ffb700 (LWP 19758)] [New Thread 0x7fff797fa700 (LWP 19759)] [New Thread 0x7fff78ff9700 (LWP 19760)] Filter preset for mode 5 LO: -80000 HI: 80000 Genrating taps for new filter LO:-80000 HI:80000 TW:16000 Required number of taps: 49

\ problem occurs right here, I then shutdown GQRX **

[Thread 0x7fffdfffe700 (LWP 19733) exited] [Thread 0x7fffde7fb700 (LWP 19736) exited] [Thread 0x7fff62ffd700 (LWP 19729) exited] [Thread 0x7fffbe7fc700 (LWP 19743) exited] [Thread 0x7fff637fe700 (LWP 19730) exited] [Thread 0x7fff7a7fc700 (LWP 19757) exited] [Thread 0x7fffbd7fa700 (LWP 19745) exited] [Thread 0x7fffdcff8700 (LWP 19739) exited] [Thread 0x7fff79ffb700 (LWP 19758) exited] [Thread 0x7fffbdffb700 (LWP 19744) exited] [Thread 0x7fff9b7fe700 (LWP 19748) exited] [Thread 0x7fffbffff700 (LWP 19740) exited] [Thread 0x7fff63fff700 (LWP 19731) exited] [Thread 0x7fffbeffd700 (LWP 19742) exited] [Thread 0x7fffbf7fe700 (LWP 19741) exited] [Thread 0x7fff997fa700 (LWP 19752) exited] [Thread 0x7fffddffa700 (LWP 19737) exited] [Thread 0x7fff78ff9700 (LWP 19760) exited] [Thread 0x7fff9a7fc700 (LWP 19750) exited] [Thread 0x7ffff0946700 (LWP 19732) exited] [Thread 0x7fffdeffc700 (LWP 19735) exited] [Thread 0x7fff627fc700 (LWP 19728) exited] [Thread 0x7fff98ff9700 (LWP 19753) exited] [Thread 0x7fffdf7fd700 (LWP 19734) exited] [Thread 0x7fff7bfff700 (LWP 19754) exited] [Thread 0x7fffdd7f9700 (LWP 19738) exited] [Thread 0x7fff9affd700 (LWP 19749) exited] [Thread 0x7fff9bfff700 (LWP 19747) exited] [Thread 0x7fff7affd700 (LWP 19756) exited] [Thread 0x7fff797fa700 (LWP 19759) exited] [Thread 0x7fff7b7fe700 (LWP 19755) exited] [Thread 0x7fffbcff9700 (LWP 19746) exited] [Thread 0x7fff99ffb700 (LWP 19751) exited] saveSettings *\ FIXME_ SQL on/off New FFT rate: 15 Hz [Thread 0x7ffff1b7d700 (LWP 19693) exited] [Thread 0x7ffff2a5b700 (LWP 19692) exited] [Thread 0x7ffff325c700 (LWP 19691) exited] [Thread 0x7ffff3a5d700 (LWP 19694) exited]

Program received signal SIGSEGV, Segmentation fault. 0x00000000000001d1 in ?? () (gdb) bt

0 0x00000000000001d1 in ?? ()

1 0x000000369dc812c0 in std::_Rb_tree<gr::basic_block, std::pair<gr::basic_block const, boost::shared_ptr >, std::_Select1st<std::pair<gr::basic_block const, boost::shared_ptr > >, std::lessgr::basic_block, std::allocator<std::pair<gr::basic_block* const, boost::shared_ptr > > >::_M_erase () from /usr/lib64/libgnuradio-runtime-3.7.2.1.so.0.0.0

2 0x000000369cc3b6b7 in __cxa_finalize () from /lib64/libc.so.6

3 0x000000369dc313a3 in ?? () from /usr/lib64/libgnuradio-runtime-3.7.2.1.so.0.0.0

4 0x00007fffffffd670 in ?? ()

5 0x000000369c80f1c7 in _dl_fini () from /lib64/ld-linux-x86-64.so.2

Backtrace stopped: frame did not save the PC (gdb)

csete commented 10 years ago

Ok, thanks. Actually I meant running gqrx on it's own and not through gdb. It's too early for that. Just look at what gqrx tells you:

FATAL: AssertionError: assertion failed: A:0 is not a valid rx subdevice specification on mboard 0. possible values are: [A:A, A:B].

Trying to fill up 1 missing channel(s) with null source(s). This is being done to prevent the application from crashing due to a gnuradio bug. The maintainers have been informed.

Try using one of the proposed subdevices instead of A:0

beaubell commented 10 years ago

GQRX will seem to run the initialization twice. The first time it'll ignore the configuration setting of A:A, use A:0 instead and then error out. The second time it will use A:A as seen in the output later on.

-- Using subdev spec 'A:A'. New antenna selected: "TX/RX"

csete commented 10 years ago

Ok, but it doesn't matter if it the switch to subdev A:A happens after the gr-osmosdr backend has decided to use a "null source" because of the error.

So we should find out where the initial "A:0" comes from; i.e. whether it's gqrx, gr-osmosdr or uhd. It surprises me though that the gr-osmosdr source works in gnuradio-companion.

beaubell commented 10 years ago

Doing some research, "A:0" comes from gr-osmosdr and is fixed in a later revision of the git repository ( http://git.osmocom.org/gr-osmosdr/commit/?id=55d005e28d21bda0d20afd3796c822aa65bb0c35). I've gone ahead and forward ported gr-osmosdr to that revsion and recompliled gqrx. The "A:0" error is resolved but the subject issue persists.

linux; GNU C++ version 4.7.3; Boost_105300; UHD_003.006.002-64-g92b0b7ab

Controlport disabled No user supplied config file. Using "default.conf" gr-osmosdr v0.1.0-29-g55d005e2 (0.1.1git) gnuradio 3.7.2.1 built-in source types: file fcd rtl_tcp uhd Using Volk machine: avx_64_mmx_orc IQ DCR alpha: 1.04166e-05 Using audio backend: auto New filter offset: 0 Hz Loading configuration from: "default.conf" Configuration file: "/home/beau/.config/gqrx/default.conf" gr-osmosdr v0.1.0-29-g55d005e2 (0.1.1git) gnuradio 3.7.2.1 built-in source types: file fcd rtl_tcp uhd -- Operating over USB 2. -- Initialize CODEC control... -- Initialize Radio control... -- Performing register loopback test... pass -- Performing register loopback test... pass -- Performing CODEC loopback test... pass -- Performing CODEC loopback test... pass -- Asking for clock rate 32 MHz -- Actually got clock rate 32 MHz -- Performing timer loopback test... pass -- Performing timer loopback test... pass -- Using subdev spec 'A:A'. New antenna selected: "TX/RX"

Gain name: "PGA" min: 0 max: 73 step: 1

IQ DCR samp_rate: 2e+06 IQ DCR alpha: 5e-07 Changing NB_RX quad rate: 96000 -> 2e+06 Requested sample rate: 2000000 Actual sample rate : "2000000.000000" Requested bandwidth: 0 Hz Actual bandwidth : 5.6e+07 Hz setFreqCorr : 0 ppm New LNB LO: 0 Hz "New frequnecy range: 34 - 6016 MHz (step is 0.00745058 Hz but we use 1 Hz)." "New frequnecy range: 34 - 6016 MHz (step is 0.00745058 Hz but we use 1 Hz)." Filter preset for mode 5 LO: -80000 HI: 80000 Genrating taps for new filter LO:-80000 HI:80000 TW:16000 Required number of taps: 49 New filter offset: 693000 Hz setFftRate to "15 fps" New FFT rate: 15 Hz setFftSize to "4096" New FFT rate: 15 Hz New FFT rate: 15 Hz No audio FFT data. No audio FFT data. Force RX reconf (jerky dongle workarond)... Filter preset for mode 5 LO: -80000 HI: 80000 Genrating taps for new filter LO:-80000 HI:80000 TW:16000 Required number of taps: 49

* problem occurs here *

saveSettings *\ FIXME_ SQL on/off New FFT rate: 15 Hz

On Mon, Jan 20, 2014 at 11:42 AM, Alexandru Csete notifications@github.comwrote:

Ok, but it doesn't matter if it the switch to subdev A:A happens after the gr-osmosdr backend has decided to use a "null source" because of the error.

So we should find out where the initial "A:0" comes from; i.e. whether it's gqrx, gr-osmosdr or uhd. It surprises me though that the gr-osmosdr source works in gnuradio-companion.

— Reply to this email directly or view it on GitHubhttps://github.com/csete/gqrx/issues/145#issuecomment-32795178 .

csete commented 10 years ago

Can you try to comment out line 1365 in applications/gqrx/mainwindow.cpp https://github.com/csete/gqrx/blob/master/applications/gqrx/mainwindow.cpp#L1365

Recompile and see if it makes any difference.

If it works, try to change the mode - I think it will still crash.

beaubell commented 10 years ago

Yes! That fix works as long as I don't change the mode, as you said.

On Mon, Jan 20, 2014 at 12:23 PM, Alexandru Csete notifications@github.comwrote:

Can you try to comment out line 1365 in applications/gqrx/mainwindow.cpp

https://github.com/csete/gqrx/blob/master/applications/gqrx/mainwindow.cpp#L1365

Recompile and see if it makes any difference.

If it works, try to change the mode - I think it will still crash.

— Reply to this email directly or view it on GitHubhttps://github.com/csete/gqrx/issues/145#issuecomment-32798301 .

csete commented 10 years ago

Okay, I believe it is an issue with the B2xxx driver then, though I have to confirm that it works with older USRP before I report it to Ettus.

beaubell commented 10 years ago

That wouldn't surprise me since it's still in active development for this hardware platform. Thanks a lot for looking into this, Alexandru.

On Mon, Jan 20, 2014 at 1:28 PM, Alexandru Csete notifications@github.comwrote:

Okay, I believe it is an issue with the B2xxx driver then, though I have to confirm that it works with ooder USRP before I report it to Ettus.

— Reply to this email directly or view it on GitHubhttps://github.com/csete/gqrx/issues/145#issuecomment-32803292 .

Stanback commented 10 years ago

Thanks Alexandru and Beau for looking into it. Commenting out that line fixes the issue on my end as well (aside from the issue when changing the mode).

ion-concepts commented 10 years ago

Alex, Let us know what help you need, Balint and I ran into exactly this with B200, OS X and GQRX yesterday. Happy to try expedite the fix.

csete commented 10 years ago

Since we suspect the problem is in the UHD driver, I have reported the issue on the USRP-users mailing list: http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-January/008304.html

csete commented 10 years ago

Good news! There is now a patch to gr-uhd that should fix this issue. The fix is not yet in gr-uhd but those who want can apply the patch locally: http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-January/008364.html

ion-concepts commented 10 years ago

Curious to know if anyone has enjoyed success with this patch, I'm not seeing any improvement, same failure mode, we may need to work on this some more.

beaubell commented 10 years ago

Just tried the patch on gnuradio 3.7.2.1. Doesn't appear to fix the problem. Is there anything that I can do to help narrow it down?

On Fri, Jan 24, 2014 at 10:37 PM, ion-concepts notifications@github.comwrote:

Curious to know if anyone has enjoyed success with this patch, I'm not seeing any improvement, same failure mode, we may need to work on this some more.

— Reply to this email directly or view it on GitHubhttps://github.com/csete/gqrx/issues/145#issuecomment-33283315 .

csete commented 10 years ago

@ion-concepts @beaubell Maybe you could talk directly to Ettus on the above mentioned mailing list. I think it will be more efficient.

ion-concepts commented 10 years ago

@csete I work at Ettus...already updated the bug status internally, just looking for user experiences.

csete commented 10 years ago

Ah, ok. Now I understand :-)

Stanback commented 10 years ago

I tried the patch today and I'm still encountering the same problem.

jdkbx commented 10 years ago

Same here. Patch did not change anything.

frmaier commented 10 years ago

Seems to be the same problem on a B100, also freezes after a few seconds and last output is the filter tabs:

linux; GNU C++ version 4.8.1; Boost_105300; UHD_003.006.002-1-g9fd308b3

Controlport disabled No user supplied config file. Using "default.conf" gr-osmosdr v0.1.0-65-g24f6f88a (0.1.1git) gnuradio 3.7.2.1 built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace Using Volk machine: sse3_64_orc IQ DCR alpha: 1.04166e-05 Using audio backend: auto New filter offset: 0 Hz Loading configuration from: "default.conf" Configuration file: "/home/zound/.config/gqrx/default.conf" Crash guard triggered!

Launching I/O device editor firstTimeConfig CIoConfig : Available input devices: 0 : "Ettus B100 E5R15UDB1" 1 : "RFSPACE SDR-IQ Receiver" 2 : "RFSPACE SDR-IP Receiver" 3 : "RFSPACE NetSDR Receiver" 4 : "RTL-SDR Spectrum Server" 5 : "Complex Sampled (IQ) File" CIoConfig : Available output devices: 0 : "Built-in Audio Analog Stereo" 1 : "M-Audio Delta 44 Analog Stereo" saveConfig Output device 1 : "alsa_output.pci-0000_00_07.0.analog-stereo" Loading configuration from: "/home/zound/.config/gqrx/default.conf" Configuration file: "/home/zound/.config/gqrx/default.conf" gr-osmosdr v0.1.0-65-g24f6f88a (0.1.1git) gnuradio 3.7.2.1 built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace -- USRP-B100 clock control: 10 -- r_counter: 2 -- a_counter: 0 -- b_counter: 20 -- prescaler: 8 -- vco_divider: 5 -- chan_divider: 5 -- vco_rate: 1600.000000MHz -- chan_rate: 320.000000MHz -- out_rate: 64.000000MHz

-- Using subdev spec 'A:0'. New antenna selected: "TX/RX"

Gain name: "ADC-pga" min: 0 max: 20 step: 1 Gain name: "PGA0" min: 0 max: 31.5 step: 0.5

IQ DCR samp_rate: 250000 IQ DCR alpha: 3.99998e-06 Changing NB_RX quad rate: 96000 -> 250000 Requested sample rate: 250000 Actual sample rate : "250000.000000" Requested bandwidth: 0 Hz Actual bandwidth : 0 Hz setFreqCorr : 0 ppm New LNB LO: 0 Hz "New frequnecy range: 68.75 - 2200 MHz (step is 0.0149012 Hz but we use 1 Hz)." "New frequnecy range: 68.75 - 2200 MHz (step is 0.0149012 Hz but we use 1 Hz)." Filter preset for mode 4 LO: -80000 HI: 80000 Genrating taps for new filter LO:-80000 HI:80000 TW:16000 Required number of taps: 49 New filter offset: 11000 Hz setFftRate to "15 fps" New FFT rate: 15 Hz setFftSize to "4096" New FFT rate: 15 Hz New FFT rate: 15 Hz No audio FFT data. No audio FFT data. Force RX reconf (jerky dongle workarond)... Filter preset for mode 4 LO: -80000 HI: 80000 Genrating taps for new filter LO:-80000 HI:80000 TW:16000 Required number of taps: 49

balint256 commented 10 years ago

I discovered the issue last night - a boost::interruption tears down the UHD source block worker thread while waiting for a libusb transfer to complete, leaving the streamer demux thinking the transport is still claimed. I'll be pushing a fix into UHD shortly, so please keep an eye out for an update to the UHD repo.

If you have the UHD source already checked out, you can try the broad quick-fix by adding

boost::this_thread::disable_interruption di;

as the very first line in 'recv' in host/lib/transport/super_recv_packet_handler.hpp

Stanback commented 10 years ago

Nice find balint. The quick-fix is working for me :+1:

beaubell commented 10 years ago

Just got around to testing it. Appears to work. Thanks!

On Sat, Feb 1, 2014 at 10:00 AM, Brian Stanback notifications@github.comwrote:

Nice find balint. The quick-fix is working for me [image: :+1:]

Reply to this email directly or view it on GitHubhttps://github.com/csete/gqrx/issues/145#issuecomment-33880262 .

balint256 commented 10 years ago

Glad to hear it - I don't like that fix because it means someone expecting the interrupt exception won't receive it, so instead I've made a change elsewhere that's hopefully coming out with UHD 3.7.0 in the next day or two. If you wish to try it yourself, change recv_packet_demuxer_3000.hpp by putting #ifdef / #endif in the following clause (so effectively it will be disabled - thread safety is already up to the user for performance, since this is the fast-path):

#ifdef RECV_PACKET_DEMUXER_3000_THREAD_SAFE
            //----------------------------------------------------------
            //-- Try to claim the transport or wait patiently
            //----------------------------------------------------------
            if (_claimed.cas(1, 0))
            {
                boost::mutex::scoped_lock l(mutex);
                cond.timed_wait(l, boost::posix_time::microseconds(long(timeout*1e6)));
            }

            //----------------------------------------------------------
            //-- Wait on the transport for input buffers
            //----------------------------------------------------------
            else
#endif // RECV_PACKET_DEMUXER_3000_THREAD_SAFE
beaubell commented 10 years ago

Balint,

This may sound crazy, but I think this also fixed my USB 3.0 host controller (Etron EJ168) dying during stress testing with benchmark_rate. I was about to send an email to the linux-usb group and now I can't reproduce the problem. I'm going to do some further testing..

On Mon, Feb 3, 2014 at 10:37 AM, Balint Seeber notifications@github.comwrote:

Glad to hear it - I don't like that fix because it means someone expecting the interrupt exception won't receive it, so instead I've made a change elsewhere that's hopefully coming out with UHD 3.7.0 in the next day or two. If you wish to try it yourself, change recv_packet_demuxer_3000.hpp by putting #ifdef / #endif in the following clause (so effectively it will be disabled - thread safety is already up to the user for performance, since this is the fast-path):

ifdef RECV_PACKET_DEMUXER_3000_THREAD_SAFE

        //----------------------------------------------------------
        //-- Try to claim the transport or wait patiently
        //----------------------------------------------------------
        if (_claimed.cas(1, 0))
        {
            boost::mutex::scoped_lock l(mutex);
            cond.timed_wait(l, boost::posix_time::microseconds(long(timeout*1e6)));
        }
        //----------------------------------------------------------
        //-- Wait on the transport for input buffers
        //----------------------------------------------------------
        else

endif // RECV_PACKET_DEMUXER_3000_THREAD_SAFE

Reply to this email directly or view it on GitHubhttps://github.com/csete/gqrx/issues/145#issuecomment-33991138 .

balint256 commented 10 years ago

Hi @beaubell, thanks for letting me know! Please do forward anything you find. I'm always trying to improve it, so more info helps...

beaubell commented 10 years ago

I think I jumped to conclusions in my excitement. I reverted the quick-fix patch and the controller issues didn't come back as readily as it did before. I was able to trigger the problem in both cases by running benchmark_rate multiple times. The only other thing that I did was recompile the kernel with CONFIG_USB_DEBUG turned on in order to troubleshoot further. Sorry guys.

I'm still leaning towards a kernel or hardware bug since userspace shouldn't be able to trigger a condition requiring a restart in order to fix.

On Mon, Feb 3, 2014 at 2:58 PM, Balint Seeber notifications@github.comwrote:

Hi @beaubell https://github.com/beaubell, thanks for letting me know! Please do forward anything you find. I'm always trying to improve it, so more info helps...

Reply to this email directly or view it on GitHubhttps://github.com/csete/gqrx/issues/145#issuecomment-34015929 .

balint256 commented 10 years ago

Hi @beaubell could you please email me your output when it dies? (I'm balint at the domain ettus d0t com). Thank you!

hkopp64 commented 10 years ago

I have gqrx installed with uhd and gnuradio (without ice-3.4.2) and compiled without any problem;

Til I started gqrx which crashed after starting up with usrp-b210

linux; GNU C++ version 4.8.1; Boost_105300; UHD_003.006.002-1-g9fd308b3

gr-osmosdr v0.1.0-67-geb76e356 (0.1.1git) gnuradio 3.7.2.1 built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf rfspace -- Loading firmware image: /usr/local/share/uhd/images/usrp_b200_fw.hex... done Using Volk machine: sse4_a_64_orc gr-osmosdr v0.1.0-67-geb76e356 (0.1.1git) gnuradio 3.7.2.1 built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf rfspace -- Loading FPGA image: /usr/local/share/uhd/images/usrp_b210_fpga.bin... done -- Operating over USB 3. -- Detecting internal GPSDO.... not found -- Initialize CODEC control... -- Initialize Radio control... -- Performing register loopback test... pass -- Performing register loopback test... pass -- Performing CODEC loopback test... pass -- Performing CODEC loopback test... pass -- Asking for clock rate 32 MHz -- Actually got clock rate 32 MHz -- Performing timer loopback test... pass -- Performing timer loopback test... pass -- Using subdev spec 'A:A A:B'.

FATAL: port number 1 exceeds max of 0

Trying to fill up 0 missing channel(s) with null source(s). This is being done to prevent the application from crashing due to gnuradio bug #528.

Qt has caught an exception thrown from an event handler. Throwing exceptions from an event handler is not supported in Qt. You must reimplement QApplication::notify() and catch all exceptions there.

terminate called after throwing an instance of 'std::runtime_error' what(): throttle(52): insufficient connected output ports (1 needed, 0 connected)

Seems as the same problems as mentioned in the beginning of this topic earlier Can this be solved without installing ice-3.4.2 ? (I do not need the remote app for gnuradio) I use kubuntu-13.10

Thanks in advance

csete commented 10 years ago

@hkopp64 This has nothing to do with ICE (gqrx does not use it and in fact it disables ice when program starts). See message from balint 10 days ago -- he shows the fix that will be available in UHD 3.7

remcycles commented 10 years ago

Balint's recv_packet_demuxer_3000.hpp patch is working for me as well. Gqrx + B200 is beautiful. I had to learn how to add a new patch in the Macports build system, but once I did that and reset the Gqrx config file it works well. Thanks everyone!

csete commented 10 years ago

There have been many discussions on the USRP users mailing list about problems with USB3 controllers. So I would try a USB2 port first.

hkopp64 commented 10 years ago

csete,

I tried USB 2.0 port either but stil got the same isue Some more information for you , I tried SDR# with usrp b210 works without any problem on the same hardware platform with both USB 3.0 and 2.0 (970A-UD3 with AMD Phenom QuadCore 965 CPU) dual boot windows 7 64bit and Kubuntu 13.10 64bit. I'm sorry to say but i'm afraight that USB3.0 is not the real cause in my case.

I have not tried the boost quick fix and try if this can help in my case

csete commented 10 years ago

There is not much point in running it through gdb without getting a backtrace. It only adds noise to the gqrx output.

Anyway, I think you have a different problem than the bug discussed here. The bug in this thread only occurs when gqrx is reconfigured, while you get an error already during initialization when you see "FATAL: port number 1 exceeds max of 0"

hkopp64 commented 10 years ago

Yes, I understand I have to look for an solution by myself thanks for the help so far and sorry for the gqrx noise regards

jdkbx commented 10 years ago

hkopp64,

i am quite sure i have the same issue as you. The initial error appeared to be the same but the fixes did not change the behavior. I tried with up to date versions from the repositories of uhd, gr, gr-osmosdr without any luck. If you find any solution, please let me know.

hkopp64 commented 10 years ago

csete,

Build the whole stuff on opensuse 12.3 on intel dualcore laptop with usb-2.0 and build everything from git source (uhd-3.7.0, gnuradio-3.7.2.1, osmo-sdr, rtl-sdr, iq-balance, osmo-dsp, gr-osmosdr and gqrx) without any problems. (not with opensuse 13.1 had problem with uhd install because of gcc-4.8/glibc)

But unfortunately still got the same issue, after starting gqrx from gui, gqrx crashed again.

linux; GNU C++ version 4.7.2 20130108 [gcc-4_7-branch revision 195012]; Boost_104900; UHD_003.007.000-1-ga8caec5f

gr-osmosdr v0.1.0-70-gcc083037 (0.1.1git) gnuradio 3.7.2.1 built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf rfspace Using Volk machine: ssse3_64_orc gr-osmosdr v0.1.0-70-gcc083037 (0.1.1git) gnuradio 3.7.2.1 built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf rfspace -- Operating over USB 2. -- Initialize CODEC control... -- Initialize Radio control... -- Performing register loopback test... pass -- Performing register loopback test... pass -- Performing CODEC loopback test... pass -- Performing CODEC loopback test... pass -- Asking for clock rate 32 MHz -- Actually got clock rate 32 MHz -- Performing timer loopback test... pass -- Performing timer loopback test... pass -- Using subdev spec 'A:A A:B'.

FATAL: port number 1 exceeds max of 0

Trying to fill up 0 missing channel(s) with null source(s). This is being done to prevent the application from crashing due to gnuradio bug #528.

Qt has caught an exception thrown from an event handler. Throwing exceptions from an event handler is not supported in Qt. You must reimplement QApplication::notify() and catch all exceptions there.

terminate called after throwing an instance of 'std::runtime_error' what(): throttle(52): insufficient connected output ports (1 needed, 0 connected)

Warning: Program '/usr/local/bin/gqrx' crashed.

regards

csete commented 10 years ago

@hkopp64 I think you will have more success trying to debug your setup at a lower level. Try the test programs that come with UHD, if they check out you can try it through gnuradio, perhaps osmocom_fft or a simple GRC graph.

hkopp64 commented 10 years ago

csete,

I shall do some tests with uhd and gnuradio to find out where i can isolate the real problem I'll let you know if I have found something

hkopp64 commented 10 years ago

After I have convinced myself to have a stable linux system with opensuse13.1 64bit, gnuradio-3.7.4.0, driver uhd-3.7.0 and gqrx-2.2.0-88 with alsa-1027 and pulseaudio-5.0-2.1, I have done the next tests;

loading a gnuradio wfm example into gnuradio-companion and after compiling and loading into the usrp-b210, the audio demodulation is playing very well.

gqrx with rtl2838 is wfm playing also very well

But exept gqrx with usrp-b210 when starting gqrx the gqrx gui disappears and still have the same error message as mentioned earlier in this forum. What else for tests can I do to get closer to the real cause of the problem ?

csete commented 10 years ago

How about osmocom_fft? Also, I'm wondering why you aren't using the latest gqrx and gr-osmosdr code? Is it some suse repository?

hkopp64 commented 10 years ago

csete,

That will be the next step, but first want to see if the issue is still there and the rtl2838 with 820T chip is working very well with gqrx with pulse audio even its not the most recent one. Its no opensuse repo I have compiled the whole set include gqrx, gnuradio and uhd by source. Gnuradio wil sometimes have an issue with wrong soundcard id but when i choose alsa instead of pulseaudio there is no problem, i have noticed the problem yet by pulseaudio configuration. But gqrx has no problem with pulseaudio and works great with the right soundcard config by pulse audio.

osmocom_fft is next test on the list

csete commented 10 years ago

Gqrx PPA now includes UHD 3.7.0 which should have the original issue fixed. For other USRP-related issues please open a new ticket.