RTL2832 and librtlsdr

[thewraith2008]

This thread is the off topic continuation of this thread here.
The off topic part of the thread was discussing possible RTL dongle tuning improvements (via RTL2832 and R820T2 registers) to the librtlsdr driver.

This seems to be exactly what I'm suggesting ...

This is all from 2014. Why wasn't this pulled into the "official" rtl-sdr project?

This is good, I will have to add the rest of these changes to my librtlsdr and test out.

Seems to be the way, many forks created and people fiddle then nothing more happens.
The keenerd fork was probably not merged (into the main osmocom/steve-m fork?) because of the more extreme changes that may have been made and it maybe seen as unstable in some peoples eyes.
I find some commits to be poorly documented (in some repos) and the changes are not entirely clear. (to me at least)

The other big problem with librtlsdr is actually an issue with libusb. It will hold a device even though the application isn't actually using it. This blocks other applications from using the device - which is annoying as all get-out for the user. If I run SDR#, for example, even though SDR# isn't running the SDR, I have to un-select the Realtek to be able to use it elsewhere.

This is the SDR# frontend (plug-in) more than the librtlsdr itself as the frontend gets the device list and selects/instantiates (rtl_open) the first available device straight from the start. It's a shame SDR# removed the ability to experiment on the RTL frontend on newer versions, this is one of the main reasons I've stuck with using v1700-1716.

It focuses on the DTV decoder functionality. Just knowing which registers are DTV specific helps because you can eliminate them from your experiments. For example, the PID register is totally not what I thought.

I was hoping for more detail on the register on the RTL2832 page 1 offset 0x01
- Only bit 3 is mentioned which is the 'IIC_repeat'er (on page 15(or pdf 21) - Table 3)
- librtlsdr uses bit 2 and comments it as 'reset demod (bit 3, soft_rst)' which incorrectly says bit 3 but is actually changing bit 2.
I find using this 'reset demod' helps stop SDR# from crashing because the driver has partly hung in libusb because of a problem that has occurred with the RTL2832.

 

[Unitrunker2]

Hi Ian;

This is the SDR# frontend (plug-in) more than the librtlsdr itself as the frontend gets the device list and selects/instantiates (rtl_open) the first available device straight from the start.

How did you determine this?

That would be a reasonable safe default - AFTER the user has clicked the Start button.

I've already complained to Youssef on that one. I just tested SDR Console. It lets go of the device when I click Stop.

One application goes to a greater extreme by claiming all recognized SDRs. This is downright obnoxious.

I find using this 'reset demod' helps stop SDR# from crashing because the driver has partly hung in libusb because of a problem that has occurred with the RTL2832.

The issue I've run into recently is Windows 10 will report occasional USB transfer errors. I don't remember Windows 8 doing this. The errors appear benign in that no data was lost.

 

[GTR8000]

One application goes to a greater extreme by claiming all recognized SDRs. This is downright obnoxious.

As much as I love SDRTrunk, this has been one of my biggest gripes to Denny. It wouldn't be as obnoxious if it allowed you to whitelist/blacklist devices, but it doesn't. It simply greedily locks up every SDR it finds and will only release them if you shut down the software. I wound up making a few "dummy" receivers in UT that I start up before SDRTrunk to reserve those devices. PIA.

 

[thewraith2008]

How did you determine this?

From source code. (you can see old version of it here)
The 'IFrontendController' interface calls the 'Open' method on SDR# startup.
This then calls GetActiveDevices method which if returns a list of devices then calls SelectDevice.

I now use a custom frontend (only usable on SDR#1716 and less for reason stated in previous post) which allows me to see the serial numbers of available dongles(*) and set any valid samplerate (rather than presets), use decimation, manually set LNA/Mixer/VGA gains (requires custom librtlsdr), bias tee (RTL-SDR.com dongle only) and use/restore a configuration for each RTL dongle on selection (so long as dongle has unique serial number) and the ability to experiment with get/setting the R820T registers and some fixes to stop the SDR# crash because of the libusb delayed return.

* Cannot see serial numbers of dongles that are held open by another program. This seems to be a limit of librtlsdr.

That would be a reasonable safe default - AFTER the user has clicked the Start button.

I've already complained to Youssef on that one. I just tested SDR Console. It lets go of the device when I click Stop.

One application goes to a greater extreme by claiming all recognized SDRs. This is downright obnoxious.


The issue I've run into recently is Windows 10 will report occasional USB transfer errors. I don't remember Windows 8 doing this. The errors appear benign in that no data was lost.

I guess there are pro's and con's with both approaches of hanging on to dongle and releasing it.
Probably wouldn't take much to make the frontend release the dongle on SDR# stop play.

• Select first available RTL SDR on SDR# play if user has not selected one or if selected SDR is no longer available.
• Use the user selected RTL SDR on SDR# play. (so long as still available)

While I no longer use SDRTrunk (won't start on 32bit Windows and mainly focused around P25 and it's Java), the beauty of it is it's open source.
The only way to get what you want is to create fork/branch and make the changes you need yourself but I understand not everyone can do this.

 

[Unitrunker2]

* Cannot see serial numbers of dongles that are held open by another program. This seems to be a limit of librtlsdr.

More likely a limit of libusb. It is possible to enumerate all SDRs - and get their serial numbers - without touching any of them. This does require all serial #s to be unique. Device identity gets weird once you have a collision. Windows does its best to cope but the resulting device string may or may not be the same on the next reboot.