<div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 18, 2012 at 3:05 AM, Dimitri Stolnikov <span dir="ltr"><<a href="mailto:horiz0n@gmx.net" target="_blank">horiz0n@gmx.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

I had to apply the attached patch for it to compile on my machine.<br></blockquote><div><br>Thanks for the patch! cmake is something very new to me :)<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



Unfortunately i wasn't able to test the tools, as both of them segfaulted in xc_peak_freq? Backtrace fragment attached.<br></blockquote><div><br>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.<br>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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 application?<br>
</blockquote><div><br>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.<br>
<br>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.<br>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<a href="http://www.evrytania.com/lte-tools/lte-tracker" target="_blank">http://www.evrytania.com/lte-<u></u>tools/lte-tracker</a><br>
</blockquote>
<br>
Nice documentation & videos! Linked the page on the rtl-sdr wiki.<br></blockquote><div><br>Thanks for the comments and the link!<br><br>James<br clear="all"></div></div><br>-- <br><i>Integrity is a binary state - either you have it or you don’t.</i> - John Doerr<br>
<br>
</div>