PPM correction support

[kronenberk]

I'd like to know if "PPM" correction will be supported in new releases?

There's offset correction (in Hertz) but no PPM stability setting .
Or it's just not documented and exists somewhere?

[AlexandreRouma]

It currently doesn't have that setting available, I'll add it in the next release if needed

[kronenberk]

The frequency received depends on ppm, say oscillator stability, its QRG=(f*ppm)/10^6 and it's very different from offset tuning (which is onl visual thing)
All rtlsdr users without tcxo will need this function (or if TCXO drifts somehow).
Parts per million correction is very very needed.

[Dieter9]

I have the same problem with my SDRplay RSP1A. The deviation of a few ppm is already very noticeable at high frequencies like the 70cm amateur band. I would appreciate it very much if SDR++ would allow a PPM correction.

[AlexandreRouma]

the SDRplay doesn't offer PPM correction, nothing I can do

[Dieter9]

For example, the program GQRX has a ppm correction that works for all devices. I guess they convert the frequency accordingly.

[ve7it]

I see in the latest version PPM correction has been implemented for the rtl-sdr rtltcp sources. Along those lines, it would be really nice to have the PPM correction implemented for the Airspy source as it is really just an rtl source with faster sampling. My airspy R2 is pretty close, but could do with +2.3PPM correction. (makes about 400Hz difference at VHF frequencies). Excellent SDR program for linux SDR... my goto software!
cheers
Lawrence VE7IT
Nanoose Bay BC, Canada

[AlexandreRouma]

PPM correction is a hardware feature. It cannot be implemented unless the driver allows it, and the Airspy doesn't have such feature.
If I remember correctly, the PPM correction of the RTL happens inside the RTL sampling chip (in conjunction with the tuner), which the Airspy doesn't have.

Moreover the 0.5ppm integrated LO should already be super precise.
If your device has wide frequency errors I recommend contacting Airspy support.

[om3bc]

Why should it be a hardware thing? It can also be solved by software. The nominal frequency is shown on the display, but the corrected frequency is sent to the receiver - recalculated according to ppm. PPM correction would be great and useful for all types of receivers.
OM3BC

[om3bc]

Because at higher frequencies around 1.2 GHz, the hardware frequency correction of the RTL-SDR is already very coarse and inaccurate, I also use software correction for the RTL-SDR:
double real_center_freq = std::round(dongle_center_freq * (1.0 + real_ppm_error * 1e-6));
where real_center_freq = corrected center frequency
dongle_center_freq = nominal center frequency
real_ppm_error = real ppm with 2 decimal places