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

[Piotr Krysik]

W dniu 28.06.2016 o 12:25, Piotr Krysik pisze:
> 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
>
By the way... do you have the driver source with added patches in some
publicly accessible repository?

Best Regards,
Piotr