Linrad with rtlsdr with and the e4000 tuner.
leif at sm5bsz.com
Sat Jun 23 20:00:36 UTC 2012
> 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
> > 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 .
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!
Leif / SM5BSZ
More information about the osmocom-sdr