james at peroulas.com
Sun Nov 18 16:09:37 UTC 2012
On Sun, Nov 18, 2012 at 3:05 AM, Dimitri Stolnikov <horiz0n at gmx.net> wrote:
> I had to apply the attached patch for it to compile on my machine.
Thanks for the patch! cmake is something very new to me :)
> Unfortunately i wasn't able to test the tools, as both of them segfaulted
> in xc_peak_freq? Backtrace fragment attached.
Fixed (and pushed)! That was an easy bug to find and was related to the
fact that LTE cells in your area were at such a high frequency (1.8GHz).
The one's I've worked on were in the 700MHz band.
> Also, i noticed that you calculate the expected tuning frequency for e4k
> tuners in order to make your calculations more exact. Can you tell us which
> tuning errors you get from the e4k driver usually and how this affects your
Well, it's like this. Since the LO and sampling clock are derived from the
same reference, if I can figure out the frequency error of the LO, I will
know the frequency error of the ADC and I can use the frequency error of
the ADC to predict where I should be sampling the data. That way, in
LTE-Tracker, when the dongle's chrystal output stabilizes, the time offset
of the tracked basestations should not change (as long as the dongle itself
is not moving). I needed to calculate the actual LO and sampling
frequencies used by the dongle in order to remove the small time offset
drift I was observing.
As a new feature request, it would be nice for the library to return the
actual frequency that was programmed into the dongle in floating point
(fractions of a Hz sometimes matter). So, if I request 739,000,000Hz, the
library would be able to tell me that the actual programmed frequency was
739000025.5123... Hz. Similarly for the sampling rate.
> Nice documentation & videos! Linked the page on the rtl-sdr wiki.
Thanks for the comments and the link!
*Integrity is a binary state - either you have it or you don’t.* - John
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the osmocom-sdr