Hi,
Steve Markgraf writes:
> On 29.05.2013 17:53, Andreas Seltenreich wrote:
>> I just found this discussion on the topic after sending some patches to
>> the list (pending moderation)...
>
> I didn't see them yet, I guess Harald has to manually approve them
> because you weren't subscribed yet when you sent them?
yes, that's what Mailman told me. My changes are also available on the
master branch of my local repository at git://gate450.dyndns.org/git/rtl-sdr
> I'm not entirely sure if storing the absolute frequency is the right
> way to go.
It seems convenient to me because the redundant bits in the value caused
by the 28.8MHz±1kHz restriction obviate the need for a separate
magic/check value.
> The benefit that the application doesn't need to do anything is nice
> on the one hand, but it doesn't really know about the compensation as
> well. Okay, it could call rtlsdr_get_tuner_clock()...
The affected variable is also exposed to applications via
rtlsdr_get_xtal_freq(). I don't see a reason to keep it at a value that
I know is off by 26.4 and 15.1 ppm resp. for my specimens.
> Also, for correcting the sample clock it's better to use
> rtlsdr_set_sample_freq_correction() instead of changing the value of
> rtl_xtal, because it has (in theory) a much finer granularity than
> rtlsdr_set_sample_rate. But right now we only pass an integer as
> parameter for the ppm-value, so we can't use that granularity. Changing
> it to ppb would make sense in my opinion.
Agreed in case of short-term adjustments during application run-time.
But for a persistent value in the eeprom, I don't think ppb resolution
has an advantage over the 1 Hz one considering the
non-temperature-compensated oscillators of these dongles[1].
regards,
andreas
Footnotes:
[1] 24h plot of kalibrate-rtl output and room temperature:
http://gate450.dyndns.org/~andreas/rtlgsm.png
