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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
