-
Notifications
You must be signed in to change notification settings - Fork 253
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Display frequency mismatch with actual value #812
Comments
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. |
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:
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? |
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
The text was updated successfully, but these errors were encountered: