16 Mar
2013
16 Mar
'13
9:27 p.m.
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,
Hunz
17 Mar
17 Mar
3:21 a.m.
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.
Alan
-----
Radio Astronomy - the ultimate DX
________________________________
From: Benedikt Heinz <zn000h(a)gmail.com>
To: osmocom-sdr(a)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,
Hunz
29 May
29 May
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
30 May
30 May
5:08 p.m.
Hi,
On 29.05.2013 17:53, Andreas Seltenreich wrote:
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.
Regards,
Steve
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
be fine.
(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.
3991
days inactive
4066
days old
3 comments
4 participants
participants (4)
-
Alan Corey -
Andreas Seltenreich -
Benedikt Heinz -
Steve Markgraf