[rtl-sdr] store frequency correction in eeprom?
steve at steve-m.de
Thu May 30 15:08:08 UTC 2013
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?
> Well, my two sticks do still enumerate nicely with the change. I wonder
> if eeproms other than 2kbit ones are in use though, as that would make
> "last four bytes" slightly ambiguous...
All sticks I've seen so far use a 24C02 with 256 Bytes, so that should
>> (Of course the ppm value still changes with temperature, but having a
>> base value is still closer to the truth than 0ppm I'd say.
>> I measured the offset directly after grabbing samples for 20 minutes
>> at room-temperature and jitter is <1ppm.)
> After warmup, plotting the output of kalibrate-rtl with my specimens
> indicates an accuracy of about 0.1ppm as long as the room temperature
> doesn't deviate more than 1K.
> Alan Corey writes:
>> While you're at it it would be nice to use maybe at least a 16 bit
>> value if possible. I had mine all worked out to about 5 or 6 places
>> then found I could only store what might be an 8 bit integer. SDR
>> Sharp would only store mine as 102 instead of about 102.4567. Since
>> the correction is done in software there shouldn't be a limit on the
>> size (data type) of the number.
> Hmm, my solution would yield a resolution of about 0.035ppm. A better
> resolution is probably not meaningful when calibrating a plain XO.
I'm not entirely sure if storing the absolute frequency is the right
way to go. 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()...
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.
My initial idea was storing the correction value in ppb in the eeprom,
along with some redundancy or a 'magic' check value (so that seemingly
random data on unprogrammed sticks isn't interpreted as a correct
correction value). But then there's the question on how applications
should deal with that, as in: should a call to
rtlsdr_set_freq_correction() override the setting which has been read
from the eeprom, or should it be applied 'on-top'?
I'd go for override, and try to make sure that applications call
rtlsdr_get_freq_correction() to get the initial value first.
More information about the osmocom-sdr