[rtl-sdr] store frequency correction in eeprom?

Alan Corey alancorey at yahoo.com
Sun Mar 17 02:21:39 UTC 2013

It sounds like a good idea, but there'd have to be some standardization.  Maybe it would gain in popularity to the point where they'd ship precalibrated but I doubt it because of the time involved.

Of course different dongle types would have different addresses free, so you'd have to make up a table that had a pointer to the ppm data for each dongle type, and stick to it.  If Microsoft ever gets into the game they'll insist on redefining everything.  You could key the locations to the USB numbers.

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.


Radio Astronomy - the ultimate DX

> From: Benedikt Heinz <zn000h at gmail.com>
>To: osmocom-sdr at lists.osmocom.org 
>Sent: Saturday, March 16, 2013 4:27 PM
>Subject: [rtl-sdr] store frequency correction in eeprom?
>Some of you are probably using multiple dongles with alternating
>applications as well.
>Regarding the frequency correction, I put a sticker on each dongle and
>wrote the ppm value on it.
>However manually setting the value in each application is still annoying.
>So I used rtl_eeprom to write the value into the product-ID with the
>following format: "RTL%+dppm" resulting in sth. like this: RTL+87ppm
>I'm not sure if this is the best way to do it, but this approach works
>without changing librtlsdr.
>Another option might be storing the value in a non-used eeprom
>location and adding get/set functions to librtlsdr.
>Is it possible to write arbitrary values to unused eeprom locations
>without fucking up the realtek eeprom handling? Do you think this
>would be a better way?
>I'd like to hear your comments on this.
>It would be awesome if we could find a solution that many existing
>applications could incorporate.
>(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.)
>Best regards,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130316/7fc6765a/attachment.html>

More information about the osmocom-sdr mailing list