|
I just forked Keenerd's repo, which actually has support for turning dither on/off in the API, but of course, gr-osmosdr has no support for it.
My fork is:
https://github.com/patchvonbraun/rtl-sdr
Also the difference in frequency resolution with dither on/off is very small--less than the error introduced by the standard crystal.
On 2016-06-28 06:55, Piotr Krysik wrote:
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 address@hiddenhttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
|