Sie sind auf Seite 1von 6

RtlSdr++ Project

Rationale: (Why did I build this silly and redundant stuff?)

I've discovered that playing with SDRs is fun, both from a user
standpoint and a developer standpoint. And the very cheap $15-$20
dongles are wonderful tools for exploring SDR concepts. They are so
much fun that I've acquired a modest menagerie of the little things.
Unfortunately they became unmanageable once I placed them all into
service at the same time. And the command line tools that exist were
not all that helpful in this regard.
This inspired me to take the existing rtlsdr.dll code and make it
more useful when more than one or two dongles are in service at once
using GUI tools. I developed a tool for changing dongle names, testing
dongles, and generally replacing the rtl_test.exe plus rtl_eeprom.exe
functionality with some extras tossed in for good measure. RTLTool is
available upon request. And so is it's source code for those
adventurous enough to brave my somewhat idiosyncratic formatting
style. (Hey, it works for my aging eyes quite nicely.) I also created a C+
+ based implementation of the rtlsdr.dll code following which I
proceeded to tweak it more than somewhat.
Simply rehashing rtl_eeprom.exe name changing and dropping the ball
at that point I figured some memory of what is or can be attached to
the system is called for. So I started saving pertinent information on
dongles in the registry as I found them in searching the system for
dongles. Thus the list of dongles can be presented in a common order
every time. So I now know that "Realtek;RTL2838UHIDIR;3" is
connected to the discone antenna and that it's the middle of the 5
dongles that are available. Dongle 3 (2 if 0 based) is always the
discone dongle regardless of where it is plugged in. It's also
recognizable as the dongle with a serial number of "3". So I can
remember it by full name, positionally in a list, and by its serial
number. So it's always easy to set it up when I want it.
This is fine; but, busy dongles cannot have their eeprom read to verify
the dongle's information that is read from a cache that WinUSB.sys,
which libusb leverages for the rtlsdr.dll interface, maintains. This
caught me up when I changed the name of a dongle and then could not
see that when I surveyed all dongles on the system. The only way I
could see it was to unplug the dongle and reinsert it. That's annoying
when you have the computer tucked away in another room to keep the
generated heat and acoustic and RF noise out of the user's room. I had
to get up, trudge into another room, and pull and reseat the dongle.
Since such activity proved bothersome, at least for awhile as I
moved dongles around from use to use, the registry beckoned as a
storage location. This proved worthwhile. But there remained a
question about whether the registry was up to date. Up until this latest
revision I "lived with it". This meant enduring longer program startup
times, which could become very long, when starting programs that use
the dongles. The dongles' eeproms take an absurd time to read
because of a defect in the RTL chips. Reading all 256 bytes in one
request tends to lockup the dongles on at least one system at
my disposal. So the bytes have to be read in 256 individual requests. At
about 10 ms per request this quickly becomes burdensome. Reading all
5 dongles can take almost 13 seconds unless the USB god smiles on
Since 13 seconds is an annoying wait I elected to find a way to shorten
the wait. I built "RtlSdr Catalog.exe". This is a little user program that
displays a little icon in the tray. It is designed to be used in the user's
startup folder with a "-quiet" parameter so that it starts up when the
user logs in and maintains the "directory" of dongles on the system. If
a dongle is removed or inserted RtlSdr Catalog is notified and
refreshes it's list of dongles. It keeps this list current in a shared
memory location. Every program using rtlsdr++'s rtlsdr.dll can see this
shared memory catalog of dongles on the system. RtlSdr Catalog
makes every effort to remain current with the known dongles, dongles
mounted on the system, and whether a dongle is busy or not. The long
wait is reduced to much shorter waits for programs using this facility
when large numbers of dongles are present. At the moment as many as
32 dongles are supported.
Then I noticed a problem with one of my dongles, a cheap little
square thing that "mostly works". It's dongle 0 here (1 for non-zero
based thinkers.) I have so many USB dinguses ("things") on my system
that the Rtl dongles do not seem to initialize properly when the system
reboots. Now, normally I would fix this inside a program tool of one
sort or another. Unfortunately the traditional PC interface for the
dongles uses libusb which itself uses the Windows supplied
WinUSB.sys facility; and; that WinUSB.sys mid-level hardware access
does not support a proper reinitialize capability. So, alas, I have to get
up and make the trek once a month to uplug and reinsert all 5
dongles. (Microsoft is in the land of "almost excellent" with defects so
annoying you want to find a random Microsoftie and plant a foot in his
"OWIE!".) Now that aforementioned dongle 0 has an additional defect.
It does not even allow it's eeprom to be properly polled when it is in its
mashed up state. This means RtlSdr Catalog acquires a spurious entry.
The database needs to be pruned to keep presentation nice if I start it
with the user login.
So as a result RtlSdr Catalog has a small user interface you can get to
by right clicking on the little dongle icon in the tray and selecting
"Show Window". A click on the "X" in the dialog's upper corner hides it
back in the tray as does the "Hide Window" menu selection either on
the dialog or tray icon. You can use the "Find Rtl Dongles" button to
refresh the dialog. And you can select an entry that is spurious and
delete it using the "Remove Selection" button.
Of course, RtlSdr Catalog can be used as a normal program that
plants itself in the tray as a side effect. Double clicking on its icon
brings up the program's user interface. If this is used to launch it each
time the database is maintained a little cleaner without the need for
pruning. So running Rtl Catalog without a command parameter brings
it up with its dialog. Running it with the "-quiet" or "/quiet" command
parameter starts it up directly in the tray in the background.
Finally I wanted rtlsdr++ to be useable without any of the RtlSdr
Catalog frippery if the user desires this. It's rtlsdr.dll version can be
used without RtlSdr Catalog running. You will experience longer
program loading times. But the dongle listing feature will remain. So
will the shared memory contents. So you can decide to run RtlSdr
Catalog any time whether or not any program using rtlsdr.dll is
currently active on the system.
Added Features not mentioned above:
RtlSdr++ includes some other features imported from "experimental"
branches of the canonical rtlsdr.dll source code. Chiefly it allows a
wider frequency range for R820T dongles, improved direct sampling,
and three gain profiles when using the R820T and E4000 tuners. The
wider frequency range is indeed rather experimental and exists but us
not tested. The same goes with the improved direct sampling. The gain
profiles, however, are tested and work, although not necessarily with
the accuracy implied by the digits after the gain decimal point.
The three gain profines include optimizations stressing sensitivity
and intermodulation distortion. Use the former in quiet settings with
no really large signals. Use the latter to improve signal handling when
very large signals exist in band or within 10-20 MHz around the tuned
frequency. The third profile is a compromise profile when there are
some modestly large signals present. It does not trim sensivity as
much as the IMD profile.
Using: (What do I do to make this fool stuff work?)
Unzip the files into any handy folder to which you can write
without annoying pop up dialogs requiring administrator
permission. C:\Ham Radio\RtlSdr would work nicely, for example.

rtlsdr.dll use:
Substitute the included rtlsdr.dll file for any rtlsdr.dll that may
reside on your system already. Ideally it can replace all your old
rtlsdr.dll uses, both 32 bit and 64 bit. Be sure to keep 32 bit and 64 bit
versions separately. Use the 32 bit version with 32 bit programs
(SDRSharp) and the 64 bit version with 64 bit programs such as
Simon's 64 bit SDRConsole version.
You can also cheat. If you have a 32 bit OS you can copy the 32 bit
version of rtlsdr.dll and it's matching libusb-1.0.dll into the
C:\Windows\System32 folder. If you have a 64 bit OS copy the rtlsdr++
64 bit rtlsdr.dll and its libusb-1.0.dll into C:\Windows\System32 and the
32 bit versions of those files into the C:\Windows\SysWOW64 folder.
Then you don't have to maintain copies all over your system. You can
override this with the old rtlsdr.dll by simply placing this in your
program's folder. Rename it to rtlsdr_old.dll and you get the rtlsdr++

RtlSdr Catalog use:

Create a shortcut to RtlSdr Catalog.exe. Right click on the shortcut
and edit it slightly. In the "Target:" edit box you will have something
like: ""C:\Ham radio\RtlSdr\RtlSdr Catalog.exe"" (Outer quotes to stress
that the dialog has quotes in it normally.) Amend that to read: ""C:\Ham
radio\RtlSdr\RtlSdr Catalog.exe" -quiet" without the outer
quotes, again. You can test it by double clicking. You should see a little
rtlsdr dongle sort of shape icon appear briefly in your notifications
tray. If that works copy this into your "Startup" and it will startup every
time you login without any bother on your part, hopefully. (That is, I
hope you don't have a flaky dongle such as my dongle 0 mentioned
You cam maintain the dongle database easily enough. Dongles are
discovered and read out when RtlSdr Catalog starts and whenever a
new USB device is installed. So about all you really would ever want to
do is see what is in the database and perhaps remove obsolete entries.
For those functions find the little dongle icon in your notifications
area. Right click on it and select "Show Window." A small dialog with a
scrollable (if needed) list of dongles will appear. You can refresh the
list, which should not be necessary, with the "Find Rtl Dongles" button.
You can select an entry to highlight it and use the "Remove Selection"
button to remove it from both the shared memory list and the registry
For the initial run if you have several dongles that have never had
their serial numbers changed it would be a really good idea to
introduce them to the catalog one at a time. Use RtlTool to change the
serial numbers to unique IDs as you introduce them. Note tha the
serial numbers do not need to be numbers only. "Discone 2" is a
perfectly valid serial number. They're strings just like the manufacturer
and product ID strings.
It is worth noting that RtlSdr Catalog.exe contains its own code for
dongle access. It does not require rtlsdr.dll present. So it is a nice tool
for bisecting installation problems. If it finds dongles but the program
you want to use does not you can look within the program's
installation for the problem. Typically it might be missing rtlsdr.dll or
libusb-1.0.dll files. Or the glue DLL which speaks to the program and
rtlsdr.dll may be missing.
RtlSdr Catalog.exe is a lowest common denominator x32 build. That
should run on any recent Windows OS. The shared memory will be
available to x64 as well as x86 programs. So only the one version is
included even though all four possible versions (UNICODE or MultiByte
and x64 or x86) can be compiled and used.

RtlTool.exe (if you go get it):

RtlTool.exe is a tool to replace both rtl_test.exe and rtl_eeprom.exe
from the canonical rtlsdr.dll distribution. It discovers and lists dongles
either standalone or using the shared memory database in RtlSdr
Catalog. It indicates missing dongles with a "-" in front of the name
and busy dongles with a "B" in front of the names. Or at least, that is
the plan. At the moment there is no indication for missing dongles and
busy dongles have an asterisk in front of the name. It's on the list....
Select the dongle you want to work with from the drop list in the
top center if it is blank. Otherwise the dongle in that window is the one
you are working with. The "Close" button next to that drop list closes
the currently active dongle. In general you want to close a dongle
before opening another.
The next step down the doalog is the "Gains Test" group. This allows
selecting a gain profile, if supported, and lists the gains available. And
that's the end of it for that group. Three profiles are listed in the
droplist, "MGC: Compromise", "MGC: IMD Optimized", and "MGC:
Sensitivity optimized."
The next group down is "Test Dongle". This performs a dummy data
transfer test using two different means of transferring data,
asynchronous and synchronous. The distinction is mostly of interest to
developers. (It shows that you can use either method to get good
results reading these dongles. The rtl_test.exe tool does not handle
synchronous transfers very well giving a false impression of the
rtlsdr.dll capabilities.) It takes awhile for the averaged data rate to
settle down to show "true" transfer rate. (Well, it is as true as your
computer's internal clock which itself is not usually very good at
Going down to the next group we find the "Brick your dongle" group,
that is the "Rename Dongle" group. I don't believe it will really brick
the dongle. But this is messing with some key data so do be careful. I
did mess up a dongle and was able to recover it to a usable state,
Note that there are three edit boxes present. They should be filled in
with data taken directly from the dongle's eeprom. They include the
textual manufacturer ID, vendor ID, and serial number string. The tool,
as with the rtl_eeprom.exe tool, allows modifing any or all three of
these strings. I would recommend modifying only the serial number
string even though it appears that it is safe to modify them all for your
The "Set Names" button will write name changes to the dongle. The
"Original Names" button sets the strings back to the set of names read
from the dongle when it was selected from the top droplist. The "Reset
Names" will restore the name set to the values last written since the
dongle was last selected. These name changes are propogated into the
shared memory and registry databases. So
they will appear to programs without requiring you to reset the
Windows WinUSB.sys cached data by unplugging and reinserting the
dongle you just renamed. (At least if you are using the RtlSdr++ version
of rtlsdr.dll.)