W dniu 28.06.2016 o 15:50, mle...@ripnet.com pisze:
>
> 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
>
>
Hi Marcus and all,
I've
On 06/28/2016 06:25 AM, Piotr Krysik wrote:
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
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
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
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
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:
On 06/25/2016 04:25 PM, Piotr Krysik wrote:
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
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
>>
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
A bias in the dither algorithm could explain that, which is why turning
off dither clears up the problem. The drifting-out-of-lock problem is
due to charge-pump current settings being too low in some cases.
On 2016-05-26 11:47, Juha Vierinen wrote:
> Would either of these issues in the rtlsdr
Would either of these issues in the rtlsdr driver consistently tune the two
dongles on slightly different frequencies, even if you ask them to tune to
exactly the same frequency? This is what the problem seems to be.
juha
On Wed, May 25, 2016 at 10:35 AM, wrote:
> There are
I was using a dongle with r820.
juha
> On May 25, 2016, at 23:27, Piotr Krysik wrote:
>
> Juha,
>
> What type of demodulator did you have in the dongles used for the test?
>
> --
> Piotr
>
> W dniu 25.05.2016 o 14:46, Juha Vierinen pisze:
>> In my testing, this phase rate
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
Juha,
What type of demodulator did you have in the dongles used for the test?
--
Piotr
W dniu 25.05.2016 o 14:46, Juha Vierinen pisze:
> In my testing, this phase rate difference seemed constant and I could
> simply calibrate it out by looking at the phase rate term estimated
> from the phase
The AirSpy uses the R820T2 chip for the tuner, but a different
sampling/DSP "engine".
Yes, making the charge-pump and "dither" mods will help with
phase-coherence.
Somebody needs to "own" the rtlsdr driver, and merge in the last couple
of years of field experience and branching that has gone
Hi Marcus,
I don't know much about AirSpy.
Does it use the same demodulator chip as current RTL-SDR dongles?
And does it mean that change to low level part of rtlsdr driver might
help to get rid of that frequency offset?
--
Piotr
W dniu 25.05.2016 o 16:35, mle...@ripnet.com pisze:
>
> There
There are a couple of issues with the rtlsdr driver used by gr-osmocom
in this regard:
(A) The charge-pump loop current is too constrained for the higher
frequencies
(B) The "dither" option appears to have a bias that causes a (small)
frequency offset.
The driver that AirSpy uses fixes
That, or simply, the output clock VCO changes its reaction to the
control voltage under certain circumstances (temperature, frequency) so
much that the control loop loses the ability to reach stationary
exactness (e.g. due to natural limits on the magnitude of the VCO
voltage). These devices
In my testing, this phase rate difference seemed constant and I could
simply calibrate it out by looking at the phase rate term estimated from
the phase of the cross-correlated noise. The samples stay aligned for
hours, so the issue is caused by the tuner or the DDC. One theory that I
had was that
Hi,
> of the drift remains a mistery (probably due to the implementation of the PLL,
> but I cannot understand why Phase Locked Loops would drift in Phase !).
If the phase comparator is digital ( i.e. a XOR ) and the input clock
is somewhat analog, the gate thresholds might vary depending on
>From our own experience with dual-dongle measurements, the phase drift
seems to be strongly related to R820T(2) temperature. We reduced significantly
the phase drift by gluing a large heat sink common to both chips on both
dongles, without completely removing this effect (we aim at measurements
Hi Juha,
It wouldn't be as simple as it was for me as a developer and as it
(hopefully) is for the end user without your hardware mod.
Can you say something more about the residual center frequency
difference? Where might it come from? I prepared little test of
coherency between the receivers
This is awesome! I'll definitely try this out soon. I use one off python
scripts to find the sample offset and the small residual center frequency
difference. This simplifies the process significantly.
This should make it much easier to implement a passive radar block, or an
interferometry block.
Hi Piotr,
Another great stuff from you after Gr-GSM.. thank you for sharing. will
take a look there..
best regards,
-Bass
On Wed, May 25, 2016 at 2:16 AM, Marcus D. Leech wrote:
> On 05/24/2016 08:20 PM, Ben Hilburn wrote:
>
> Hi Piotr -
>
> Nice work, good docs, and thanks
On 05/24/2016 08:20 PM, Ben Hilburn wrote:
Hi Piotr -
Nice work, good docs, and thanks for sharing this.
You should create a proper OOT module from this (you basically already
have) and submit the recipe to PyBOMBS and get it on CGRAN!
Cheers,
Ben
Yup, this is good stuff. I will have to
Hi Piotr -
Nice work, good docs, and thanks for sharing this.
You should create a proper OOT module from this (you basically already
have) and submit the recipe to PyBOMBS and get it on CGRAN!
Cheers,
Ben
On Tue, May 24, 2016 at 4:25 PM, Przemek Lewandowski
wrote:
>
Nice Job :)
Good to see friends from Poland playing with GnuRadio :)
All Best
2016-05-24 22:03 GMT+02:00 Piotr Krysik :
> Hi all,
>
> I want to announce new GNU Radio related project prepared by me -
> Multi-rtl:
> https://github.com/ptrkrysik/multi-rtl
>
> It is a Gnu Radio
Hi all,
I want to announce new GNU Radio related project prepared by me - Multi-rtl:
https://github.com/ptrkrysik/multi-rtl
It is a Gnu Radio block that combines multiple RTL-SDR receivers into
one multi-channel receiver.
Only hardware modification to RTL-SDR dongles required is connecting
them
28 matches
Mail list logo