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

[Piotr Krysik]

W dniu 28.06.2016 o 03:31, Marcus D. Leech pisze:
> On 06/25/2016 04:25 PM, Piotr Krysik wrote:
>> 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
>>
> OK, now I've got people excited about building phased arrays.
>
> I suspect that the existing block will get awkward to use after about
> 8 inputs.  I wonder if there's a re-org of the input parameters that
> could make it less awkward?  Like having the device args all in one
> line, having a "General" and "RF Parameters" tab, etc.
>
>
Hi Marcus,

It's great to hear that there is interest in using the block. I can
change how parameters are displayed but I don't have clear idea how to
do this so the user experience with for a systems with 8+ inputs will be
improved. I can separate RF options to another tab but it won't improve
much - you will still have a very long list of parameters that you will
have to scroll.

I can do this - it is not any problem for me (actually I already did
this after your post:
https://github.com/ptrkrysik/multi-rtl/commit/dfda15b5332cafb7da9288707fc9c58be91370b6).
But in my opinion if you want to have more than 8 inputs you can
consider coding the flowgraph in Python. GRC might be cumbersome in
itself when you have blocks with
so many ports.

Regarding the coherent operation - I have to play with the driver
prepared by you. If it works fine - it is the way to go in my opinion.
Some people might still need dithering (i.e. because they don't care
about coherency but want to set the frequency more precisely). One
solution for this might be some additional option in the gr-osmosdr
block that turns on/off dithering. Or if frequencies for which dithering
is used can be easily listed/computed - then dithering can be just not
used when the user sets frequency that doesn't require it.

Best Regards,
Piotr