gqrx-sdr / gqrx Goto Github PK

The FFT plot has methods for setting the min/max dB as well as the split ration between pandapter and waterfall. We could take advantage of these by connecting them to slider widgets.
The FFT rate should be adjustable too.

Vesa Solonen has provided a synchronous AM detector design that we can implement and add to gqrx.
http://users.tkk.fi/~vsolonen/bonk/ssrp_HF_receiver.grc

The signal strength indicator measures approximately 20 dB more than what is shown on the FFT scope.
The scale is also incorrect.

The command line option to select antenna is not implemented.

Replace the triangular marker on the signal strength indicator with something nicer, e.g. a solid or gradient bar, see e.g. qtmm.

Add squelch block that was available in the original python version.

Allow bypassing the demodulator directly sending the band pass filter output to the two-channel audio out (resampled to audio rate).

When I close gqrx, the gain is (more or less correctly) stored in the configfile eg as "gain=0.5".

When I start gqrx again, the gain level is always at -20dB.

Add SSTV Robot decoder.

Currently, the "BC (75k)" setting does not set any of the FM demodulator parameters. Since the quad rate is now 96 ksps we can implement the WFM settings as well.

Integrate Phil Karn's BPSK1000 demodulator into gqrx so that we can receive BPSK1000 from ARISSat without messing with audio. It would be nice if we could test it during the test activation 30-31 July.

Currently, any frequency can be entered regardless of what the input device supports. The frequency range is available to us for each supported device and shall be used in gqrx to limit what the user can enter.

The command line option to select 8 bit data format is not implemented.

A device reported by rtl_test as "ezcap USB 2.0 DVB-T/DAB/FM dongle" appears as "Realtek RTL2838UHIDIR SN: 00000013". The device works fine, it's just confusing.

Sometime I'd like just to be able to see the spectrum and only save audio and I'd like to be able to build gqrx without pulseaudio being a requirement.

The introduction of the FFT performance improvement (issue #23) has triggered an application crash:

• start DSP processing and let it run for a short while
• start doing stuff in the GUI (change frequency, move filter)

Application will crash with SIGSEGV or SIGABRT in CPlotter::draw()

Although overall application performance has been significantly reduced, the FFT timeout function now takes longer since the actual FFT calculation are now also performed during this cyclic processing and it could be a race condition between the FFT drawing and drawing due to user actions. Increasing the timeout from 100ms to 500ms makes the problem disappear.

The SSB sideband selector has no effect. The receiver seems to be stuck in USB mode.

As of GNU Radio 3.7 several blocks used by gqrx are moved from gnuradio-core to other packages, see e.g. http://www.trondeau.com/home/2012/11/10/version-37-the-work-in-progress.html

It is to be decided whether the transition should be made before or after the GNU Radio 3.7 release.

This is general issue that concerns exceptions.

Many GNU Radio blocks throw an exception in their constructor if something goes wrong. Currently, gqrx doesn't catch any of these so the application will just crash. We should catch the exception and have a safe fallback or bail out with error messages that users can understand.

Implement support for using standard soundcards as input I/Q source.

Add options for fast, medium and slow AGC

Support doppler shift correction through interface with (g)predict.

This feature would allow the use of gqrx in a more permanent satellite ground station setup where the system will be running unattended. For example as a permanent telemetry receiver for a specific satellite, where the audio will be passed directly to a TNC.

We will have a look at implementing this ourselves, but would like your comment on the idea.

Regards,
Johan Christiansen
GomSpace ApS
Aalborg, DK.

The satellite tracking module shall be able to track satellites in real time and compensate for Doppler shift.
The Doppler shift is calculated from the range rate of the satellite. Together with the current demodulator frequency, the nominal satellite frequency is estimated. Hereafter the Doppler shift can be compensated at the channel filter level.

The satellite module should also have an interface to the scheduler so that the user can schedule recordings according to satellite passes instead of manually entering date and time.

Changes to the frequency correction value in the FCD configuration panel are discarded, and the ability to change frequency correction is not implemented in the rx_source_fcd class.

Create a base class for input sources in order to have a uniform API for all supportted devices (FCD and UHD for now).

Following important FCD controls are still missing:

• Preamp gain.
• I/Q corrections

The signal strength indicator could benefit from a simple exponential filter like the one used in qtmm.

The --no-hb command line option is not implemented.

A scheduler that allows recording I/Q data and/or audio starting at a specific time. An option shall allow the user to select a satellite pass rather than enter date, time and duration manually.

Currently and FFT is performed as soon as there are enough samples in the buffer and this is done independently of the the refresh rate of the FFT plot. We can save CPU by accumulating samples in a buffer and only call the FFT function when the FFT plot requests a new data set.

There is a problem with the ALSA sink which causes a runtime error when we reconfigure the flow graph. This is the case when we change mode and bandwidth. The error message is:

audio_alsa_sink[hw:0,0]: snd_pcm_hw_params failed: File descriptor in bad state
terminate called after throwing an instance of 'std::runtime_error'
what(): check topology failed on audio_alsa_sink(1) using ninputs=1, noutputs=0

Following this suggestion, we can prevent this from happening by adding a static boolean flag that controls whether snd_pcm_hw_params() should be called or not.

A simple patch to implement this is available here: https://gist.github.com/664132

The current AGC blocks available in GNU Radio do not seem to be suitable for AM-type analog communication. In particular the blocks have no knowledge of the sample rate, different attack and decay rates must be chose for different rates. Furthermore, none of the blocks have 'hang time' which is very useful for voice and morse code comms.

Currently we use the gr-agc2 block and I have found it very difficult to tune it to get some proper behavior (failed).

We should take a look at some of the other AGCs avaialble out there, e.g. Dttsp and Cutesdr.

The frequency range in the audio spectrum appears to be incorrect.

There should at least be command line options for selecting the input and out devices.

Add the convenient 1-click audio recording and playback that was available in the original Python gqrx.

The main toolbar should include shortcuts to common function.
The controls available via the toolbar should provide a set that would be sufficient for first time users:

• Input source (TBC when/if we will have multiple preconfigured sources)
• Demodulator (operating mode)
• Audio gain

My new Linux laptop moaned the other day about having a full root FS, which is on a separate 59GB partition from /home. After a little digging it turned out that a pair of files in /tmp were being continually written to by gqrx. gqrx seems so stable on my new laptop that I have a habit of leaving it running continuously, and these files can get quite big.

I thought that I may have enabled recording, but subsequently I've concluded that gqrx just writes to these files all the time. It seems to overwrite them next time it is started.

darren@len:~/src$ ll /tmp | grep gqrx
-rw-rw-r-- 1 darren darren 2811801600 2012-02-06 19:12 gqrx.bin
-rw-rw-r-- 1 darren darren 351473664 2012-02-06 19:12 gqrx.wav

I'm running from the git tip, this is the latest change:

commit 80ed78c
Merge: cfad8ec 6180f8b
Author: Alexandru Csete [email protected]
Date: Wed Feb 1 13:01:21 2012 -0800

Merge pull request #35 from jrcutler/master

Implemented FCD frequency correction

Cheers,

Darren, G0HWW

When performing a fast frequency change (multiple changes after each other eg. scrolling on the frequency number) using the Funcube Dongle, gqrx crashes:

(gdb) bt
#0  0x00007ffff04350d8 in libusb_submit_transfer () from /usr/lib/libusb-1.0.so.0
#1  0x00007ffff0436db0 in libusb_control_transfer () from /usr/lib/libusb-1.0.so.0
#2  0x00007ffff3fb6ee9 in ?? () from /usr/lib/libgnuradio-fcd-3.6.4git.so.0.0.0
#3  0x00007ffff3fb73f2 in ?? () from /usr/lib/libgnuradio-fcd-3.6.4git.so.0.0.0
#4  0x00007ffff3fb80af in fcdAppSetFreq () from /usr/lib/libgnuradio-fcd-3.6.4git.so.0.0.0
#5  0x00007ffff70eae62 in ?? () from /usr/lib/libgnuradio-osmosdr.so.0
#6  0x00007ffff70ceca2 in ?? () from /usr/lib/libgnuradio-osmosdr.so.0
#7  0x0000000000427a7a in ?? ()
#8  0x000000000041f5ec in ?? ()
#9  0x0000000000468250 in ?? ()
#10 0x00007ffff5a06b8f in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/libQtCore.so.4
#11 0x000000000046a05d in ?? ()
#12 0x000000000045579a in ?? ()
#13 0x0000000000456222 in ?? ()
#14 0x000000000045644d in ?? ()
#15 0x00007ffff5f69c84 in QWidget::event(QEvent*) () from /usr/lib/libQtGui.so.4
#16 0x00007ffff6314d36 in QFrame::event(QEvent*) () from /usr/lib/libQtGui.so.4
#17 0x00007ffff5f1a18c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4
#18 0x00007ffff5f1f0ad in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4
#19 0x00007ffff59f16ae in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/libQtCore.so.4
#20 0x00007ffff5f8468d in ?? () from /usr/lib/libQtGui.so.4
#21 0x00007ffff5f95d5e in ?? () from /usr/lib/libQtGui.so.4
#22 0x00007ffff5f94861 in QApplication::x11ProcessEvent(_XEvent*) () from /usr/lib/libQtGui.so.4
#23 0x00007ffff5fbaa22 in ?? () from /usr/lib/libQtGui.so.4
#24 0x00007ffff2828845 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#25 0x00007ffff2828b78 in ?? () from /usr/lib/libglib-2.0.so.0
#26 0x00007ffff2828c34 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#27 0x00007ffff5a1fb66 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#28 0x00007ffff5fba69e in ?? () from /usr/lib/libQtGui.so.4
#29 0x00007ffff59f03ff in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#30 0x00007ffff59f0688 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#31 0x00007ffff59f5328 in QCoreApplication::exec() () from /usr/lib/libQtCore.so.4
#32 0x000000000041a3b9 in ?? ()
#33 0x00007ffff4abba15 in __libc_start_main () from /usr/lib/libc.so.6
#34 0x000000000041ae51 in ?? ()

After issue 36 (writing to waterfall) was resolved and I fetched the git tip and rebuilt gqrx,, it continued to work normally for me for a short while, then something seemed to go persistently wrong. The symptom was a Pink waterfall - no audio underflows or overflows were reported. Reconnecting the FCD didn't help, nor did rebooting.
The next day I upgraded to the git tip but the issue persisted. The FCD seemed to work OK with gnuradio.

I cloned the git tip again today and tried to figure out what the problem might be with a fresh build, and discovered that if left long enough, the pink waterfall gradually fades down to the usual blue colour and the receiver starts to work. This may take from roughly 30 secs to over perhaps 90 secs, before a sensible level is shown on the FFT plot and waterfall. The dBFS value starts at "inf" and after a while shifts to about 350dBFS then winds down to a sane value after a while.

I notice that the I/Q values shown on stdout have unusual values, which become normal after some time:

AVG I/Q: -6.48728e+32/-0.000379419
AVG I/Q: -2.35081e+32/-0.000515609
AVG I/Q: -8.51869e+31/-0.000569706
AVG I/Q: -3.08694e+31/-0.000588061
AVG I/Q: -1.11862e+31/-0.000594157
AVG I/Q: -4.05358e+30/-0.000593843
AVG I/Q: -1.4689e+30/-0.00059447
AVG I/Q: -5.3229e+29/-0.000593402
AVG I/Q: -1.92887e+29/-0.000595783
AVG I/Q: -6.9897e+28/-0.000598192
AVG I/Q: -2.53287e+28/-0.000597032
aUAVG I/Q: -1.47904e+33/-0.000599944
AVG I/Q: -5.35962e+32/-0.000597073
AVG I/Q: -1.94218e+32/-0.000600439
AVG I/Q: -7.03793e+31/-0.000594943
AVG I/Q: -2.55035e+31/-0.000597479
AVG I/Q: -9.24176e+30/-0.000594425
AVG I/Q: -3.34896e+30/-0.000595716
AVG I/Q: -1.21357e+30/-0.00059777
AVG I/Q: -4.39764e+29/-0.000597115
AVG I/Q: -1.59358e+29/-0.000595978
AVG I/Q: -5.77471e+28/-0.000595082
AVG I/Q: -2.09259e+28/-0.000597014
AVG I/Q: -7.58298e+27/-0.00059915
AVG I/Q: -2.74786e+27/-0.000599379
AVG I/Q: -9.9575e+26/-0.000599158
AVG I/Q: -3.60832e+26/-0.000598093
AVG I/Q: -1.30756e+26/-0.000599042
AVG I/Q: -4.73822e+25/-0.000599934
AVG I/Q: -1.717e+25/-0.000597861
AVG I/Q: -6.22194e+24/-0.000598523
AVG I/Q: -2.25466e+24/-0.000599039
AVG I/Q: -8.17025e+23/-0.000594522
AVG I/Q: -2.96067e+23/-0.000597709
AVG I/Q: -1.07287e+23/-0.000599587
AVG I/Q: -3.88777e+22/-0.000597121
AVG I/Q: -1.40882e+22/-0.000597989
AVG I/Q: -5.10517e+21/-0.000596092
AVG I/Q: -1.84998e+21/-0.00059905

then later:

AVG I/Q: -0.000996173/-0.000599633
AVG I/Q: -0.000994948/-0.0005997
AVG I/Q: -0.000994425/-0.000595451
AVG I/Q: -0.000995082/-0.000597237
AVG I/Q: -0.000993751/-0.0005978
AVG I/Q: -0.000994039/-0.000599771
AVG I/Q: -0.000997688/-0.000597842
AVG I/Q: -0.000993183/-0.000601268
AVG I/Q: -0.000993793/-0.000602623
AVG I/Q: -0.000993176/-0.000597503
AVG I/Q: -0.000994207/-0.000601616
AVG I/Q: -0.000994689/-0.000602554
AVG I/Q: -0.000991886/-0.000602674
AVG I/Q: -0.00099506/-0.000599918

Hopefully this report will be of some use. I've been dabbling with gnuradio, grc, gqrx, the FCD and my newly acquired USRP for a week or two now and have a fair amount of confidence that hardware and software builds are good and well configured.

Implement basic AM demodulation.

Add an indicator for the current sql status (open/attacked) next to the slider

Add a frequency offset option, which allows using a transverter.

Add a "dummy" block in between the demodulator and the audio blocks to make reconfiguration simpler when the demodulator is changed.
This block could also act as resampler between demodulator and audio, allowing higher bandwidth demodulators (currently the BPF downsamples to 48k)

Add support for UHD devices from Ettus Research.

While monitoring a certain frequency that includes several nearby channels, it could be awesome to have an option to scan them:

• Define a group of receivable channels in the current frequency range (by receiver offset)
• Set an arbitrary order on selected channels
• Automatically tune receiver to first channel in set that is active (above squelch level)

I would like to take a stab at implementing this myself. I'm assuming the GUI is the easy part. Basically, I need a hook that allows me to inspect the signal after passing through FFT, determine if any of the selected channels are above squelch, and if so, set the receiver frequency to that channel.

Any pointers to places in the code I want to look at would be awesome.

Integrate the AFSK1200 decoder from qtmm into gqrx.

Create an interface where gqrx can interact with externa data decoder via stdin and stdout, i.e. gqrx sends raw audio samples to the stdin of the decoder and reads text output from the stdout of the decoder. To begin with the decoded text can be shown in a simple text browser,

A very nifty feature could be to have bookmarks on arbitrary frequencies, such that a user can:

• Set a bookmark on a given frequency
• Have that bookmark show up as a vertical line on both the spectrum and the waterfall
• Give bookmark a title and a short description to easily mark known frequencies
• Clicking on viewable bookmarks would set receiver frequency to tune to it