On 05/26/2016 04:09 AM, Piotr Krysik wrote:
Is there some good candidate that can be asked to do that? When I search
for rtlsdr driver the first page with actual source code is osmocom's
site:
sdr.osmocom.org/trac/wiki/rtl-sdr
Maybe they have the maintainer who feels responsible for how this code
works?
I can try to correct this offset in software (especially if it doesn't
change too often) but it doesn't seem as the optimal solution. Frequency
offset estimation might not be perfect either.
--
Piotr
Peter East has been playing with stuff as well, although his website
has been suffering from the "Slashdot Effect(tm)" since RTL-SDR blog
pointed to his paper a couple of days ago. Now, he does all his
stuff post-facto, rather than in real-time, but i don't see why there
couldn't be two stages of 'sync' state in your code--one to do time
synchronization, the other to do frequency-offset estimation based on
the phase of the cross-correlation after time sync. The residual
frequency offset (which shows up as a phase walk) is, according to
Peter, always some small multiple of about 0.072Hz--he measures the
slope of the cross-correlation a few thousand samples apart, and
uses that to estimate the frequency offset. That works well.
Ideally, yes, you just want the hardware to behave correctly--and for
the standard drivers to take care of this. But doing this in your
multi-rtl block isn't a lot of extra work, and it means you get no
residual phase-walk whether dither is turned on or off.