Hello Steve,
On 22.06.2012 21:55, Leif Asbrink wrote:
The most important modification is the gain
setting.
The tuner code requires knowledge of the gain table
or searcing for legal gain values by use of the returned
error code. I think that this is impractical and I changed it
so the routine will now always set the nearest possible gain
value and return it to the caller.
That's exactly what we have rtlsdr_get_tuner_gains() for.
Good:-) I overlooked
that and I will use it for the next
Linrad version.
The default IF
gain is too high. I reduced it by 6dB for
a 6 dB better dynamic range.
We still have to add functions to set the IF-gain from external
applications, this is something on the todo-list.
OK. Do you have an idea about the
time scale? It would be
a good thing from my perspective if this would be implemented
before I release the next Linrad version. The lower IF gain
is a significant improvement on 144 MHz. I do not know
anything about the design so I do not know whether one
should set IF gain differently on other frequencies.
With the
tuner_e4k.c currently incorporated in Linrad
there is an AGC action that degrades the dynamic range by
about 10 dB. I do not know anything about the e4000 internals
but in case this remaining AGC can be disabled and the gain
set 10 dB lower in the particular gain step controlled by the
AGC, the dynamic range would improve from 66 dB to 76 dB
with respect to the usual MDS (noise in 500 Hz bandwidth.)
The remaining AGC that's active is not in the E4K, but it's the Digital
AGC (DAGC) of the RTL2832. Unfortunately we don't know how to disable
it, since the way it's supposed to be disabled does not work.
That is bad
news:-(
Is there by any chance a way to reduce the sensitivity of the
RTL2832? Something that would place the AGC onset at a point
higher above the noise floor.
To be able to
use the callback in Linrad I have had to include
various structures in the Linrad c code. I need to have this
code in Linrad:
i = libusb_handle_events_timeout(dev_rtlsdr->ctx, &tv1);
Therefore I need the structure rtlsdr_dev which is not included
in rtl-sdr.h. That structure requires other structures and it
would be a good thing if those things as well as something
I don't really know why you're doing that... the way the asynchronous
callback is meant to be used is spawning a thread and calling
rtlsdr_read_async() from there. Just take a look at how gr-osmosdr or
rtl_tcp handles it. Another example of correct usage is sdrsharp [1].
I did it
because that is the way I used to do....
I will check the timing of the conventional approach and switch
to it if the difference is insignificant.
I have tested the ExtIO_RTLSDR.dll which I assume is written by
the book. It works fine on modern computers, even on less modern
ones like a 2.4 GHz Pentium 4 but it fails on Pentium 3 with bad
cpu overload (Win XP).
The Linrad code runs fine at 2 MHz sampling speed on my old Pentium 3
at 650 MHz. (under Linux X11, 2.6.32 kernel) The cpu load is 80% and
there are no glitches or other problems. The parameters are exactly
the same that fail badly with the ExtIO dll on the same computer.
The difference is most probably not due to Windows itself, it is
the USB interface that is more demanding. Significantly more!
Regards
Leif / SM5BSZ