Installation (V3)


August 7th, 2016: All files required for RTL support are now included in the kits. A description of these files is below.


When you plug a dongle into a port for the first time or change the port you must run Zadig from http://zadig.akeo.ie/

If a dongle has never been introduced to the machine before the user must run Zadig from http://zadig.akeo.ie/ to couple the dongle to the Microsoft "WinUSB.sys" file that already exists on the system. Usually doing this once is sufficient. New dongles are discovered as they are plugged in. If the dongle is not recoognized (rtltool.exe cannot find it) then it's time to re-run Zadig on the dongle. This will allow any version of rtlsdr.dll to be found on the system.

Thanks to Paul Goetz for his help in the Yahoo! support forums.

  1. Download and install Zadig.
  2. Run Zadig with your dongle(s) plugged in.
  3. Select "List All Devices" from the "Options" menu.
  4. Click the drop-down, highlight the appropriate device and select "Replace driver" to replace the current driver (RTL2832USB) with WinUSB. Do not change any other values.
  5. Some Windows Updates may replace the driver so if things suddenly stop working, re-run Zadig and verify the replacement driver is still installed.
  6. Note that there are two versions of Zadig. One is for XP and the other is for Win7, Win8 and Win10. make sure you get the correct one (version 3 does not support XP).

If you have installed the correct drivers and SDR Console still cannot see the dongle, try rebooting. The RTL USB drivers are not very robust and can lose communications with the dongle. A reboot usually fixes it.

That's all folks!

The Files

May 24th, 2016: Here is the text and associated instructions you see in the Yahoo! support group.

All associated files are hosted on Google Drive [link]. When you click on this link three folders are visible:

RtlSdr++ contains one archive with documentation. Inside you find two folders, one for x86 (32-bit) and one for x64 (64-bit). Select the folder which corresponds to your operating system.

RTLTool is a tool for exploring the dongles a bit. It tests two different transfer mechanisms for data, can rename dongles, and can prove an rtlsdr installation.

SDRConsole contains two archives, one for x86 (32-bit) and one for x64 (64-bit). Each contains a SDR Console dll, named SDRSourceRTL2832U.dll.


  1. From RtlSdr++ copy rtlsdr.dll and libusb-1.0.dll to the same folder as your SDR-Radio.com (V3) installation, usually C:\Program files\SDR-Radio.com (V3).
  2. From SDRConsole copy SDRSourceRTL2832U.dll into the same SDR-Radio.com (V3) folder.


No special drivers are required.


A quick note about bandwidths. When you start the RTL dongle you have a dropdown where you select the bandwidth. Most (but not all) dongles work at 2.4MHz (that is 2.4 Msps), some will work at 2.5 MHz. In rare circumstances rates as high as 2.75MHz have been experienced.

If you hear breaks in the audio then restart with a lower bandwidth.


Support Group

Please do NOT send mail direct to the development team.

For installation of the RTL Dongles you need extra DLLs not provided by SDR-Radio.com due to GPL issues. Please ask for information in the Yahoo! support group: https://groups.yahoo.com/neo/groups/sdr-radio-com/info .


Authour's Comments

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 you. 

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++ version.

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 above.)

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 list.

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, however.

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 convenience.

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.)


For questions my email is jdow@earthlinkMUNGED.net. (Remove the "MUNGED" part to make it work.)

For style comments simply copy them to the trash folder. What you read is what you get unless you feel up to rewriting this. I'll critique the result for accuracy and adopt it if I think it's both informative and moderately engaging reading. I despise "engineering-ese" dry third person passive voice nonsense. I also admit I'm not by any means a techwriter or any other kind of writer except maybe a crayon scribbler. {^_-}


Note: Text slightly reformatted for appearance, original text is RtlSdr++ and RtlSdr Catalog documentation.txt in the RtlSdr++ Distribution archive