Page 1 of 1

gqrx tips (mostly)

Posted: Tue Jul 05, 2016 2:11 am
by N4TKO
after a couple months playing around with the sdrplay and mostly gqrx, here's a few things i have found that might benefit new users.
first, for most of this i was using a sample rate of 2Mhz, and a bandwidth of 1Mhz which is the default in gqrx

images... there have been a few times i have found images that result from the interaction between internal signals in the sdrplay, and external signals. one good example is a "mystery" ALE network in the 5Mhz broadcast band, and what seemed to be a bit offset from a 1khz step. after getting the signal tuned in so the tones lined up where they were supposed to, i was still getting no decodes. and the signal just didn't sound "right". so i switched to LSB and again lined the tones up and began getting decodes. it was the FEMA net. FEMA doesn't use LSB for it's ALE net, so this turns out to be an image, a result of the original signal interacting with an internal signal in the sdrplay, and coming out as a mirror image. for the HF bands, the best way to reduce the possibilities of images, is to use higher sample rates and wider bandwidths. i haven't noticed any images yet using 5Mhz sampling and 5Mhz bandwidth, so that seems to help.

s/n ratio.... while using gqrx's defaults, many signals which i could see on the waterfall were buried in noise in the audio. again the change to 5/5 for sampling and bandwidth seems to have helped. maybe some of the noise was an image...

audio latency(a)... while decoding FAX transmissions with gqrx and fldigi (i'm using "skywave linux, a ubuntu variant specifically for SDR applications), i would get a few lines of print, and then the sync would jump randomly, resulting in a completely garbled picture. FAX requires solid audio sync, and i wasn't getting it. recording the signal using gqrx's audio record function resulted in good solid copy when played back. a big improvement was made by changing gqrx's priority to "high" and fldigi's priority to "low" using the ubuntu system monitor (you can't do that with windows unless the program has that as a configuration function). the sync was pretty solid with only a few small shifts once in a while.

audio latency (b)... after about an hour of running, or after changing the hardware frequency settings in the sdrplay (i.e. switching from a center frequency of 5Mhz to 10Mhz) the audio would start clicking and jumping. programs like fldidi would "complain" by running their audio waterfalls at extreme speeds, and not decoding anything. again, changing the IF sample rate and bandwidth to 5/5 seems to have cured this problem

another thing i would notice after running the system for extended periods of time was an increase in the number of interference spikes (which i think are from the USB connection) and the noise floor "jumping" at a regular rate (like about once or twice a second). rebooting and restarting gqrx would make everything work normally. i use gqrx's time lapse waterfall to monitor a section of spectrum for a long period of time. this helps in spotting "new" signals.-, as well of getting a good idea what part of the day certain chunks of spectrum are the most active. so far the change to higher sample rate and wider bandwidth seems to have cured the instability.

i'm wondering if the use of the defaults (2/1) causes a "backlog" of data that the system can't handle for long periods of time...