[rtl-sdr] store frequency correction in eeprom?

[Andreas Seltenreich]

Hi,

I just found this discussion on the topic after sending some patches to
the list (pending moderation)...

Benedikt Heinz writes:

> Another option might be storing the value in a non-used eeprom
> location and adding get/set functions to librtlsdr.

I modified my copy of librtlsdr to use the last four bytes of the eeprom
as the default XTAL frequency instead of the compiled-in 28800000Hz, if
it is within ±1kHz.  That way applications don't have to deal with the
calibration aspect at all.  Also, rtl_eeprom got an -x parameter to
store a value there.

    git://gate450.dyndns.org/git/rtl-sdr

> Is it possible to write arbitrary values to unused eeprom locations
> without fucking up the realtek eeprom handling?

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...

> (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[1] 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.

regards,
andreas

Footnotes: 
[1]  https://github.com/steve-m/kalibrate-rtl