Yet another Mega-post...
Well, there could be a dozen or so things preventing a nice clean decode using SDR# aka SDR Sharp (Shark, eh?). If I had to point to three things that might immediately improve things it would be this:
1) on the main SDR# interface, under the Audio settings, uncheck - that means remove the check in the box if there is one aka deselect it - the option to Filter audio. DSD+ (and DSD as well) requires a good clean baseband audio signal to work which is what the direct discriminator tap (with a proper cable) allows to be delivered to those decoders. With SDR# you have the ability to filter the audio in several respects so it sounds better or whatever but the downside of the filtering is it tends to wreck the signal since you're taking the baseband audio and processing it through one or more filters. Unchecking/deselecting that filtering option has proven itself to almost instantly get you a vastly more usable baseband audio signal to feed to DSD+ and DSD.
2) an adequate volume level (and I don't mean the Windows mixer either because you're not going to be listening to the P25 data stream itself, I mean the AF Gain which controls the audio level of the baseband audio signal being fed to DSD+ or DSD) which has two requisites:
- adjusting the actual AF Gain aka "volume slider" in SDR# itself to roughly 80% of the scale which would be the next to last marker from the right side (there are tiny little positional markers on the slider (can be difficult to see on some monitors), you may alter it a few notches back if needed but I've discovered that setting it for that 80% marker gives me solid decodes pretty much 99.999% of the time.
- making sure the actual signal you're tuning in has sufficient signal strength to get a decode from it meaning the SNR (Signal to Noise Ratio) is decent enough so you get a clean signal and not one that's buried in hiss. I see you said you're getting good signals with "analog audio" which is excellent - funny thing there: everything you can hear is analog audio, including "digital" communications - it has to be transmitted in an analog format, that's why you can hear a P25 or any other type of "digital" data stream with any analog scanner that can tune the frequency it's being broadcast on. Anyway, ensuring the RF Gain (for actual signal strength) is adequate will help with that aspect. If I had to make a recommendation on it I'd say get the RF Gain adjusted so you're seeing at least a peak of
at least -35 dB on the spectrum to ensure it's a good signal (antenna choice here matters depending on your location, so will the position, and so on).
I would recommend - this is only a recommendation - that you work with this stuff by not using the RTL or Tuner AGC options in SDR# - avoid them at all costs if possible and only use the RG Gain slider as the RTL AGC will push everything up about 20 dB which is nice in some respects but that includes the noise; you'll see the entire noise floor jump across the spectrum too if you enable that option. And the Tuner AGC just maxes it out (+49.6 dB) for the RTL sticks which is horrid stuff indeed. I used to keep the RTL AGC on constantly for the first few weeks till I realized that's not necessarily a good idea in an RF-rich zone (which I have here in downtown Las Vegas) because it'll overload and de-sense the tuner pretty severely overall. My preferred RG Gain slider setting is about 28 dB, sometimes higher, sometimes lower, but that setting has provided me with useful signal strength across the entire monitoring spectrum I bother with (110 to 940 MHz basically), your stick and your situation may require different settings and you'll only find them by experimentation.
3) ensuring that DSD+ (or DSD) are configured with command line switches to specifically decode P25 only and ignore everything else which is done by adding the -f1 switch; I'd also recommend using the -v4 switch (for testing purposes till you get solid decodes) because it'll show you the errors when they happen if they exist for whatever reason. Obviously by default both DSD+ and DSD will basically try to identify the frame types and protocols automagically but that isn't always possible for various reasons; locking in the specific protocol you want decode is recommended (it's the recommendation in documentation for both decoders, not just me saying it) over just using the default "Auto" setting.
Having said all that (yes, I'm wordy, and I type 115 wpm so it kinda works for me), the last tidbits may also be relevant depending:
- ensure your ppm is set as accurately as possible since these RTL sticks do suffer from signal drift and lackluster accuracy
until you know what the proper ppm setting for your specific device happens to be after roughly 10 minutes of usage as the RTL stick warms up. Voice transmissions of all kinds, be it AM or NFM can still be heard with clarity even if they're tuned slightly off-frequency; digital protocols aren't nearly as forgiving and can be completely missed or result in horrible decoding performance with DSD+ and DSD. Make no mistake: DSD+ is outstanding in its ability to pull a working decode from even noise-laden signals, far more so than DSD is capable of, but even DSD+ has limits on how well it'll do - the fact that you can "tune" the decoder to handle low quality signals and sometimes get a rather massive improvement in the end result by comparison to a non-tuned sampling from the same signal/system is pretty damned amazing. But having that ppm is an absolute must, especially for digital protocols you're hoping to decode.
- depending on which "virtual audio cable" driver/program you're using, there may be a need to alter some of the configuration parameters either with the app/control panel directly for the driver, or on the simplest basis just opening the Windows Recording mixer and ensuring that the driver is functioning properly AND that it's set to 2 channels (stereo) with a 48 kHz sampling rate - DSD+ and DSD both require the input signals be at that particular configuration. Actually DSD pretty much works with a single channel aka mono since it doesn't provide a dual-channel capable output stream for something like DMR/MOTOTRBO or NXDN which are two-slot capable protocols; the difference between them is that DMR/MOTOTRBO broadcasts the two slots on the same frequency while NXDN uses two offset frequencies (from the assigned one). When you use DSD to decode a DMR/MOTOTRBO signal, it will start the voice decoding on whichever slot transmits first and that's what you hear even if the other slot is also transmitting a voice signal. DSD+ improves on that by providing both voice signals simultaneously - one from the left audio channel, one from the right. It's pretty wicked hearing two voice comms happening at the same time on one frequency, reminds me of having two scanners going at once in some respects. Regardless, the audio subsystem configuration needs to be 2 channel 48 kHz for optimal decoding by DSD+ and DSD.
- Filter type may affect things as well so experiment with that setting during all this tweaking. While those filters have their most dramatic effect on the audio signal
when the Filter audio option is selected, they still have a slight effect on the baseband as well to some degree since it's an analog signal. I've noted that in some instances for P25 that using the Blackman-Harris 4 filter type provided a better decode than the other 4 available ones, but that's just in my particular setup - as stated above, experimentation will allow you to find the best particular settings for your hardware meaning you're not going to break something by making minor adjustments here and there as long as you know where you're at in the process.
- The overall sample rate (set in the Configure option of SDR#) should not have any effect on the signal at all but it can't hurt to adjust it to something like the 0.900001 or 1,024 MSPS setting. I used to use the 0.900001 all the time but moved to the 1,024 a few weeks back and it's fine for me. That setting controls how wide the visible spectrum is but it also uses less CPU resources which is another aspect of all this - some computers just have an issue with running this kind of program and will "choke" on some tasks. Your machine could be super-powerful, I don't know, I'm just adding the potential option to adjust it. If you're using Unitrunker + SDR# + DSD+ or DSD to tune in and monitor trunked P25 systems that's a chunk of CPU power to get it all done in real-time adequately. In that respect, with SDR# tuning in a single frequency at a time, there's no reason to force the program to keep displaying a 2.4 MHz wide spectrum when a much narrower one will suffice and lower CPU usage. It's just a click or two to adjust it, can't hurt to experiment there as well.
I'll shut up for now, that should be more than enough to get you going on good P25 decodes. Also: DSD+ sets the polarity automagically and I've yet to have an issue with it for any digital protocols while DSD does require you to specify if you're working with an inverted (non-positive) DMR/MOTOTRBO signal. I know this won't matter with P25 and DSD since it handles the polarity of that protocol without issues (that I'm aware of, that is) but I figured I'd toss it out there just in case.
Hope this helps...
