[rtl-sdr] store frequency correction in eeprom?
andreas+osmocom at gate450.dyndns.org
Wed May 29 15:53:00 UTC 2013
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.
> 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 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.
More information about the osmocom-sdr