29 May
2013
29 May
'13
5:53 p.m.
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