R820t tuner fixes#10
Open
mutability wants to merge 2 commits into
Open
Conversation
…ion, not at kHz resolution. Also replace the manual divison loop with a simpler fixed-point calculation.
Contributor
Author
|
Before-and-after graphs for the changes. This data was generated by a modified version of kalibrate which accepts a manual tuning offset. For a fixed GSM signal you would expect that tuning 1Hz higher would move the measured signal 1Hz lower; anything different is tuner error or oscillator drift. You can see a little oscillator drift in these graphs, but most of it is clearly tuner error.
|
Contributor
Author
|
I already posted to the osmocom list about this - the pull request is just a useful place to collect the changes |
|
+1 looks useful |
itdaniher
added a commit
to itdaniher/librtlsdr
that referenced
this pull request
Jan 8, 2019
itdaniher
added a commit
to itdaniher/librtlsdr
that referenced
this pull request
Jan 8, 2019
itdaniher
added a commit
to itdaniher/librtlsdr
that referenced
this pull request
Jan 13, 2019
paulyc
pushed a commit
to paulyc/librtlsdr
that referenced
this pull request
May 31, 2019
Bug Fix for some Broken MinGW PThreads sources
Contributor
Author
|
That ship sailed long ago; I have moved on to other projects. If you'd like to use this PR as a starting point for trying to get something merged upstream, that's fine. |
This was referenced Aug 24, 2020
hayguen
added a commit
to librtlsdr/librtlsdr
that referenced
this pull request
Sep 9, 2020
* see #91 * vcocmin/vcocmax: sets VCO current for R820T/2 * added tuner internal caching for VCO current, that register isn't written when unnecessary * added vcoalgo option: - vcoalgo=2 allows to select/use r82xx_set_pll() from https://github.com/rtlsdrblog/rtl-sdr.git - vcoalgo=1 is previous algorithm, just with higher vco_max=3.9GHz - vcoalgo=0 is previous algorithm - the default: kept this until steve-m#10 is measured * rtl_test: added options -f and -e to define where to start and end the tuner range test .. for quicker testing if the new options change/extend the tuner's frequency range Signed-off-by: hayati ayguen <h_ayguen@web.de>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
These changes improve the R820T tuner code to calculate the VCO/PLL parameters more precisely. The old code rounded the reference frequency to the nearest kHz and did some slightly dodgy hand-rolled long division.
These changes empirically reduce the tuning error from approx +/- 750Hz to approx +/- 200Hz.
This is good enough to also fix some odd behaviour with applying frequency corrections, where for some PPM + frequency combinations, changing PPM by +/-1 would have no effect because the underlying tuner imprecision mapped both frequencies to the same PLL settings.
Tested on a generic RTL2832U with R820T tuner only.