SDR# RTL 820T SDR# frontend decimation issues

[thewraith2008]

Does anyone use this alternative RTL frontend for SDR# ?
Does the decimation work at all for anyone in any version of SDR#.
Versions somewhere before v1570 just crash when setting the decimation and following versions, the decimation is not happening properly.

The decimation that occurs internally to the dongle (when you change the samplerate) just doesn't seem that good so I thought I'd give this a go.
I've managed to fix the problem in the code and recompiled it and it seems to be working pretty good now.

 

[DRL-XM43]

That is a lot of ppm correction these days is it an old style dongle? Perhaps a V3 or V4 standard dongle would handle things properly?

 

[thewraith2008]

That is a lot of ppm correction these days is it an old style dongle? Perhaps a V3 or V4 standard dongle would handle things properly?

That's not really the focus of the post and that PPM is not the worst one I have (89) and V3s see same result.
I'd be happy to receive a upgraded SDR via donation

 

[DRL-XM43]

That's not really the focus of the post and that PPM is not the worst one I have (89) and V3s see same result.
I'd be happy to receive a upgraded SDR via donation

The author said the decimation that occurs internally to the dongle (when you change the samplerate) just doesn't seem that good. Big PPM value indicates "old specs", so my question was about the capability of obsolete dongle and could it contribute to the issue.

 

[thewraith2008]

The author said the decimation that occurs internally to the dongle (when you change the samplerate) just doesn't seem that good. Big PPM value indicates "old specs", so my question was about the capability of obsolete dongle and could it contribute to the issue.

The decimation via the frontend occurs in software. (Standard frontend is done internally)
Crash is due to a change in a SDR# method (required value needed is now different than it was)

Dongle with a bad PPM is not the cause here.
With the fix I made, it works perfectly fine for any analog or digital application.
The PPM is bad because someone was throwing the crystal around the factory before they put it in my dongle.

 

[Ubbe]

Being able to change decimation down to a 30KHz spectrum would make SDR# a very light load for the CPU
and the dongle should also run much cooler, right?

I have a netbook using a Atom200 CPU that couldn't really run SDR# and DSD+ Maybe it's possible with that small spectrum width.

/Ubbe

 

[a417]

[redacted]

 

[kj6psg]

The dongle won't run cooler because the SDR is still being sampled at 2.4 MS/s. Sample rate isn't what drives heat production.

Decimation causes aliasing without good software filtering. I don't believe the decimation front-end implements that, and it would defeat some of the performance gains of decimation. I used to use that front-end in the past but could NEVER get good results with it. I've switched over to using the RTL-TCP front-end with a recent build of rtl_tcp; the RTL drivers provided with SDR# are ancient.

If that front-end stopped working right, that wouldn't surprise me. It's five years old, and SDR# has evolved quite a bit since then. Release 1333 was current at the time of release.

If you're running DSD+ on really low end hardware, use FMP/FMP24 that's provided with DSD+. SDR# does not like slow computers.

I've never encountered an RTL-SDR Blog V3 dongle (or Nooelec dongle with TCXO) that has needed more than 9ppm correction, and virtually all don't need any correction. They're rated for 1ppm and perform similarly. My old non-TCXO dongle needed 30-50ppm correction based on device temperature, and I've seen some over 80ppm. The PPM correction doesn't affect device performance at stable sample rates (2.4 MS/s and below), but it does impact trunktracking performance on narrowband/ultranarrowband systems.

 

[slicerwizard]

The author said the decimation that occurs internally to the dongle (when you change the samplerate) just doesn't seem that good. Big PPM value indicates "old specs", so my question was about the capability of obsolete dongle and could it contribute to the issue.

Not much difference between the R820T tuner in the older dongles and the R820T2 that's found in the newer ones. The digital side (the RTL2832U chip), which is where I'd expect any decimation to happen, should be identical. Most of the differences are in reference oscillator stability, reduction of spurious noise, thermal management, stuff like that.

 

[thewraith2008]

The software decimation won't save CPU as it uses them to do the extra decimation.

As mentioned decimation is performed by SDR# which uses (LP) filtering as a part of the process.
Comparing the internal and software decimation, software is definitely better here. Aliasing is no more then usual.

The high PPM dongles I have are the cheap eBay blues.

I've so noticed that the "standard" samplerates (e.g 2.4 MSPS) seem to introduce different artifacts. I've tried a custom rate and it cleans it up.