cjcliffe
Display frequency mismatch with actual value
In some positions of the spectrum scale, the displayed frequency may not correspond to the actual value. In the screenshot, the APRS station was received at 144.779 MHz and should be at 144.800 MHz. But if you move the spectrum left or right with the mouse, the frequency can become 144.800 MHz
This effect is the same on versions 0.2.6a and 0.2.5
This is perfectly normal and expected behavior. Devices such as SDR aren't perfect and will have a frequency mismatch from the actual frequency, a cheap device like an RTLSDR typically is less accurate than something like a USRP B200.
The so called Parts per Million (PPM) of the main oscillator crystal is typically the dominating factor in this. it is pretty common for cheap devices to have a couple of PPM say 2/4. At 144 million (hertz) that would give you an error of around 600 hertz.
Now granted 1400 hertz is quite a lot, have you tried running it at a lower sampling rate. You seem to be sampling it at 4Mhz which is really high for a RTLSDR.
I'm now seeing this issue with RTL-SDR on Linux; almost as if the RTL SDR module isn't delivering all the final frequency changes to the device when you stop dragging.
It might be good to add a rate limiter to the frequency change requests; it's probably spamming it based on framerate..
If you tap the frequency up/down a single Hz it kicks back in and lines up again..
Experimental SoapyRTLSDR branch that should fix this issue is up at https://github.com/pothosware/SoapyRTLSDR/tree/frequency_mismatch -- only verified to fix the issue on Linux so far.
This problem is present not only on "RTL-SDR", but I can also see it on "hackRF One" with the optional highly stable reference oscillator installed. For example, at sample rate: 3 MHz, 4 MHz, 6 MHz, 7 MHz
@ah1102 thanks, I've merged a patch for SoapyRTLSDR but I'll try it with my hackRF as well, it might be a similar fix.
How to use this patch?
You will have to compile from source or wait for a new binary release that includes the libraries with the patch.
I compiled from the source code and nothing has changed with hackrf
The actual steps are a bit more involved but I mistakenly thought you were hesitant to compile from source previously so I left them out.
You will only have to recompile SoapyRTLSDR from source if you already have CubicSDR installed from source. Navigate to were your SoapyRTLSDR directory is and execute the following.
git fetch --all
git checkout frequency_mismatch
Now just follow the regular build instructions that you previously followed for SoapyRTLSDR, since soapy modules are dynamically loaded by SoapySDR compiling the rest of the dependencies and CubicSDR itself is unnecessary.
I compiled from the source code and nothing has changed with hackrf
It's just RTL-SDR fixed so far; haven't tried with HackRF yet, but I'll take a look now
@ah1102 I've been unable to reproduce the issue with hackRF One here; all frequency updates that are sent to the device work properly. I can't see any issue here even with adding USB hubs and extensions and stressing the CPU load.
Here's my hackrf_info output:
hackrf_info version: unknown
libhackrf version: unknown (0.5)
Found HackRF
Index: 0
Serial number: 0000000000000000457863c82f14491f
Board ID Number: 2 (HackRF One)
Firmware Version: 2018.01.1 (API:1.02)
Part ID Number: 0xa000cb3c 0x006c4339
As I don't have the "optional highly stable reference oscillator" perhaps it's related to that -- is it something you can disable and see if it improves the issue?