Re: [Discuss-gnuradio] Multi-rtl - making multi-channel receiver out of multiple RTL-SDR dongles

[Piotr Krysik]

W dniu 25.06.2016 o 01:56, Marcus D. Leech pisze:
> 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.
>
Hi Marcus,

If it is possible to do estimate this frequency offset correctly (better
than one would expect from normal measurement thanks to some a-priori
knowledge like ~0.072Hz granularity that as you said might be there) - I
can live with additional step. What might be possibly harder for me to
swallow is if the estimated value of frequency offset has some error
that may be avoided if one patches rtl-sdr driver to include the changes
mentioned by you before.

Thanks for pointing to Peter's East work - I will try to experiment with it.

Best Regards,
Piotr Krysik