DSDPlus

[mtindor]

No problem....I'm used to scavaging the internet for missing files. My problem now is when executing DSD Plus on my WinXP desktop I cannot make any keyboard entries, only press the "ESC" to exit the program.

John

What kind of keyboard entry are you expecting to make, John? For the most part it is not an interactive program. There are very few keys available while it is running. "R" to toggle recording the raw audio to a wav file, and a couple others besides CTRL-C and ESC.

You do everything via switches (eg: -fr, -o0, -O NUL) from the commandline before you start the program.

Mike

 

[br0adband]

For those that might have issues with the lameenc.dll (LAME Encoding dll) you can acquire it inside the LAME bundle from rarewares.org:

RareWares

which is as "official" a source for that software as you're likely going to find. Because of licensing issues, sometimes a software author isn't allowed to distribute support files written by someone else along with their own code, as odd as that seems.

As for the DSDPlus issues, I can't say for sure why you're having issues with the Zip archive, could be any number of them I suppose. The checksum is provided at the VirusTotal link so you can verify it against the file you actually downloaded (the actual .exe file, not the Zip archive) - if they don't match, obviously there's some corruption somewhere. I can mirror the archive if necessary, it's not like it's a big hassle to do it.

 

[frazpo]

Just another note on privacy enables conventional channels.

I run DMR Decode in parallel with DSDPlus on my little laptop (Works out well) and for signals that were encrypted on last nights recordings the audio playback (at first listen on the internal speakers) sounded like someone whispering into a mic but was unintelligible when I listened closely on headphones.

Just an FYI that some "audio" is recovered and recorded.
Dave

I believe this is the reason the source is not available. The term "muted" is used in the decode for a reason. IMHO. At least it is in P25 decodes.

 

[W4UVV]

DSD Plus keyboard entries...

What kind of keyboard entry are you expecting to make, John? For the most part it is not an interactive program. There are very few keys available while it is running. "R" to toggle recording the raw audio to a wav file, and a couple others besides CTRL-C and ESC.

You do everything via switches (eg: -fr, -o0, -O NUL) from the commandline before you start the program.

Mike

Mike,

I configured my "regular" DSD software/hardware configuration almost 2 years and am familiar with commands, switches, etc. and use it frequently in logging and identifying MOTOTRBO signals plus some P25 Phase 1 signals from more distant sites on the Virginia state trs. Using my R7000 receiver with a Win7 OS HD sound card and using the same antenna input, I can receive farther distant state trs sites because that dsd configuration is more sensitive that my digital scanners. "dsd.exe" defaults to MOTOTRBO and P25 Phase 1 decoding. I assume it is the same with DSD Plus.

Out of curiosity I thought I would try DSD Plus never expecting the problems I am encountering.

When my "regular" dsd.exe" is executing, from the keyboard I can change from a positive to an inverted MOTOTRBO mode search. I can change from a NXDN 4800 baud search to a 9600 baud search and do positive and negative searches. I can change to other switch settings. I CANNOT get to a command line to make any changes because DSD Plus will not accept any keyboard entries except so far "CTRL C".
which has the same result as pressing the "ESC" key.

John

 

[Audiodave1]

I believe this is the reason the source is not available. The term "muted" is used in the decode for a reason. IMHO. At least it is in P25 decodes.

Yes, P25 mutes and visually indicates it. I suspect this is since there is a defined bit to indicate ENC. DMR may not have an obvious "Bit" in the stream to activate a muting function or ENC call out on the DSD+ screen.

Just an observation...

Dave

 

[mtindor]

Mike,

I configured my "regular" DSD software/hardware configuration almost 2 years and am familiar with commands, switches, etc. and use it frequently in logging and identifying MOTOTRBO signals plus some P25 Phase 1 signals from more distant sites on the Virginia state trs. Using my R7000 receiver with a Win7 OS HD sound card and using the same antenna input, I can receive farther distant state trs sites because that dsd configuration is more sensitive that my digital scanners. "dsd.exe" defaults to MOTOTRBO and P25 Phase 1 decoding. I assume it is the same with DSD Plus.

Out of curiosity I thought I would try DSD Plus never expecting the problems I am encountering.

When my "regular" dsd.exe" is executing, from the keyboard I can change from a positive to an inverted MOTOTRBO mode search. I can change from a NXDN 4800 baud search to a 9600 baud search and do positive and negative searches. I can change to other switch settings. I CANNOT get to a command line to make any changes because DSD Plus will not accept any keyboard entries except so far "CTRL C".
which has the same result as pressing the "ESC" key.

John

John,

If you were to read dsdplus.txt , you'll see that CTRL-C and ESC do not do the same thing. In fact, just a bit further up in this thread (in the last day or two) I believe this was discussed. Please read the the thread and the dsdplus.txt text file.

ESC is the proper way to exit the program if you want to make sure that any recorded audio .wav files are intact. If you hit CTRL-C, you might end up with a .wav file that doesn't play for you. I've never had it happen, but at least one person in the forums has.

DSDPlus should never be confused with DSD. They are not the same program. The author of DSD / contributors to DSD and the author of DSDPlus are different people. If you expect DSDPlus to behave exactly like DSD, you should not expect that.

If you can change operation of DSD after the program has been executed and is running, I am not familiar with that functionality. As far as I know, there is no behavior of DSD that can be changed while it is currently running. The only way I know to invert polarity or change from one decode option to another is to do it from the command line, while the program is not running. I have to cry foul and suggest that you are not correct when you state that you can run DSD and change invert / mode / etc while the application is running. If you can, you must have some magical version of DSD that I've never used.

You might want to consider opening a command prompt, navigating to the directory where dsdplus.exe exists (if yours DSDPlus is still named dsd.exe, you should change it -- it's not DSD), and then run DSDPlus from the command line [just like you would do with DSD].

Example: My DSDPlus binary is called dsdplus.exe. It is in the c:\dsdplus folder

* I open a command prompt
* I type: cd \dsdplus
* I type dsdplus -f1 -O NUL -v4 (or whatever I want for switches) and hit enter

If I want to change options, I hit ESC and am then dropped back to the Command Prompt. Then I simply re-run DSDPlus using new options.

Mike

 

[mtindor]

Just to avoid any confusion anyone might have:

Neither DSD or DSDPlus will decrypt encrypted audio. The functionality does not exist in the code.

In fact, it would not be possible for the code to do this without some sort of input from the user even if the application supported decryption. [this might not be an absolutely accurate statement for DMR/NXDN].

If you're hearing audio that sounds like it's encrypted with moments where you're hearing clear audio, then the audio being transmitted was clear all along and what really was happening is that you were getting a bad decode [either from interference or an extremely weak signal or a bad setup].

The term "muted" is used because DSD (and DSDPlus) both attempt to mute encrypted audio. Why? Because there is no reason to listen to encrypted audio, especially if there is never a hope of that encrypted audio being decrypted. Hearing encrypted audio may be useful at times [while troubleshooting], but as a general rule it is a nuisance and that is why the "mute" option is available.

On some versions of DSD, there is no P25 encryption muting. On some others there are, but it's broken. On DSDPlus there is P25 encryption muting. It works perfectly. If you ever hear encrypted audio, it isn't because DSDPlus isn't doing it's job -- it's because the required information was not able to be decoded that tells DSDPlus that what follows is encrypted traffic.

So it's entirely possible that once in a while, on a P25 signal, you might hear a few blurbs of encrypted audio. If you do, you are probably listening to a very weak signal, have some interference, have a bad discriminator tap, or have iproper settings in SDR software.

As for encryption muting on DMR, NXDN or anything other than P25, I don't know whether either application supports the muting of encryption for anything other than P25.

Mike

 

[frazpo]

Just to avoid any confusion anyone might have:

Neither DSD or DSDPlus will decrypt encrypted audio. The functionality does not exist in the code.

In fact, it would not be possible for the code to do this without some sort of input from the user even if the application supported decryption. [this might not be an absolutely accurate statement for DMR/NXDN].

If you're hearing audio that sounds like it's encrypted with moments where you're hearing clear audio, then the audio being transmitted was clear all along and what really was happening is that you were getting a bad decode [either from interference or an extremely weak signal or a bad setup].

The term "muted" is used because DSD (and DSDPlus) both attempt to mute encrypted audio. Why? Because there is no reason to listen to encrypted audio, especially if there is never a hope of that encrypted audio being decrypted. Hearing encrypted audio may be useful at times [while troubleshooting], but as a general rule it is a nuisance and that is why the "mute" option is available.

On some versions of DSD, there is no P25 encryption muting. On some others there are, but it's broken. On DSDPlus there is P25 encryption muting. It works perfectly. If you ever hear encrypted audio, it isn't because DSDPlus isn't doing it's job -- it's because the required information was not able to be decoded that tells DSDPlus that what follows is encrypted traffic.

So it's entirely possible that once in a while, on a P25 signal, you might hear a few blurbs of encrypted audio. If you do, you are probably listening to a very weak signal, have some interference, have a bad discriminator tap, or have iproper settings in SDR software.

As for encryption muting on DMR, NXDN or anything other than P25, I don't know whether either application supports the muting of encryption for anything other than P25.

Mike

Makes sense. Thanks for the clarification.

 

[br0adband]

While I'm not absolutely 100% certain of this, based on what W4UVV is saying so far, he's (or she's, sorry) simply unable to do anything from the keyboard except Esc or Control-C meaning the - I R etc keys as listed in the readme/user guide don't work at all. Call me crazy but that's what I'm reading in what W4UVV has said.

W4UVV: DSD (the original, not DSDPlus/DSD+) defaults to decoding all detected formats which would be the switch -fa (as listed in the options.txt file:

Decoder options:
  -fa           Auto-detect frame type (default)

which is pretty much what DSDPlus/DSD+ does too: it attempts, by default, to decode any format thrown at it by frame types.

As for all the options that W4UVV seems to be hoping for, DSDPlus is a different beast: it does all those automagically for the most part. It's possible to force it to do specific decode options (like decode only NXDN 4800 vs NXDN 9600) but they're not possible options once the decoder is actually running - they have to be set from the command line directly when you run the instance of the decoder or else it's going to listen for everything and decode as found unless a switch tells it not to.

Least that's how I'm understanding stuff so far...

Anyway, here's something: has anyone noted the need for some really excessive precision with respect to decoding NXDN? I've apparently only got two options for NXDN here in Las Vegas: the Luxor which I suspect is a bit too far away from me in downtown to get anything from since I have a ton of buildings and casinos and whatnot in the direct signal path (including a huge building right next to me that blocks pretty much all my ability to get traffic from McCarran Airport), and The D which used to be Fitzgerald's - they are using NXDN hardware but I can't even find a license for it yet with the proper emissions.

Having said that, the issue for me is that when I'm detecting the NXDN activity on a frequency (by hearing the data stream in one speaker), I have to manually retune the ppm aspect of SDR# to get an actual decode from DSDPlus and it's a bit frustrating at times. For example I can get the Fremont Street Experience MOTOTRBO content (Security) at 464.100 and it's spot on and I mean when I look at the zoomed in waterfall I've got my RTL stick calibrated to 57 ppm at 464.100 and it's perfect for DSDPlus decodes, rarely if ever will I see any errors whatsoever. Same situation with another MOTOTRBO system at 463.3375 (Trump International Hotel) - again the waterfall shows a dead-center frequency match (I use 470.309 to calibrate this stick I'm using, I have another stick that calibrates to 50 ppm).

While I can get content at 463.3375 and 464.100 dead-center and never have issues with decoding, whenever I'm grabbing NXDN content from The D on 463.6225 I have to retune the ppm to 59 to get a decode at all: if it's 58 or 60, I get zip, nada, zilch, absolutely nothing whatsoever even though the signal comes in booming since I'm just 3 blocks away and practically line of sight with their antennas on top of the their facility.

It almost seems like they're transmitting on frequencies that keep sliding up and down the scale somewhat, it's the weirdest thing I've encountered yet with this SDR kick I'm on. It's not the sticks as noted because I calibrate them every so often in a session just to ensure they're working right and that 50/57 ppm corrections I've noted a pretty much solid as far as a non-TCXO can be - as noted the other frequencies right there in the same range (within 1 MHz) all tune perfectly so, I'm not sure what the hell is going on. When I do get a "lock" on the signal I get great decodes, DSDPlus is really amazing in that respect, but it's somewhat irritating to have to keep retuning that ppm more frequently.

Is anyone else having issues with NXDN that make a decode so prone to being so spot on with the frequency/ppm? Just curious... guess I'm gonna need a frequency counter and go take a walk down to The D sometime.

 

[Astrak]

Any trick to getting the file to download from Mega? All I get is "temporary error, retrying".

 

[Boatanchor]

Anyway, here's something: has anyone noted the need for some really excessive precision with respect to decoding NXDN? I've apparently only got two options for NXDN here in Las Vegas: the Luxor which I suspect is a bit too far away from me in downtown to get anything from since I have a ton of buildings and casinos and whatnot in the direct signal path (including a huge building right next to me that blocks pretty much all my ability to get traffic from McCarran Airport), and The D which used to be Fitzgerald's - they are using NXDN hardware but I can't even find a license for it yet with the proper emissions.

Having said that, the issue for me is that when I'm detecting the NXDN activity on a frequency (by hearing the data stream in one speaker), I have to manually retune the ppm aspect of SDR# to get an actual decode from DSDPlus and it's a bit frustrating at times. For example I can get the Fremont Street Experience MOTOTRBO content (Security) at 464.100 and it's spot on and I mean when I look at the zoomed in waterfall I've got my RTL stick calibrated to 57 ppm at 464.100 and it's perfect for DSDPlus decodes, rarely if ever will I see any errors whatsoever. Same situation with another MOTOTRBO system at 463.3375 (Trump International Hotel) - again the waterfall shows a dead-center frequency match (I use 470.309 to calibrate this stick I'm using, I have another stick that calibrates to 50 ppm).

While I can get content at 463.3375 and 464.100 dead-center and never have issues with decoding, whenever I'm grabbing NXDN content from The D on 463.6225 I have to retune the ppm to 59 to get a decode at all: if it's 58 or 60, I get zip, nada, zilch, absolutely nothing whatsoever even though the signal comes in booming since I'm just 3 blocks away and practically line of sight with their antennas on top of the their facility.

It almost seems like they're transmitting on frequencies that keep sliding up and down the scale somewhat, it's the weirdest thing I've encountered yet with this SDR kick I'm on. It's not the sticks as noted because I calibrate them every so often in a session just to ensure they're working right and that 50/57 ppm corrections I've noted a pretty much solid as far as a non-TCXO can be - as noted the other frequencies right there in the same range (within 1 MHz) all tune perfectly so, I'm not sure what the hell is going on. When I do get a "lock" on the signal I get great decodes, DSDPlus is really amazing in that respect, but it's somewhat irritating to have to keep retuning that ppm more frequently.

Is anyone else having issues with NXDN that make a decode so prone to being so spot on with the frequency/ppm? Just curious... guess I'm gonna need a frequency counter and go take a walk down to The D sometime.

If you are using a $10 RTL dongle, I'm not surprised you have to keep re-calibrating.
My FuncubeDonglePro+ stays rock solid once calibrated (@ +4.9ppm in my case). The Funcube has a TCXO internal frequency reference, so it varies very little with temperature.

All of the cheap RTL dongles that I own, drift around a lot with temperature. The problem is obviously worse on 800Mhz as any ppm error in the dongle's 28Mhz reference crystal is multiplied as you go up in receive frequency. The RTL dongles tend to run pretty hot anyway, so there is going to be a lot of frequency drift in these things.

If you are using a narrow 'Filter' in SDR# (7000-8000Hz is actually best for weak signal DV decoding), a +- 2 ppm error can make a big difference to weak signal decode performance @ 800Mhz.

It could well be 'selective, multi-path fading' too.
There are some weak digital voice signals here that when viewed on the FFT/Spectrum Analyzer, actually display a slow fade profile that moves across the signal bandwidth. The fade doesn't affect the entire signal, only a portion of it. It's bizarre. It actually looks like a notch filter is being tuned across the signal. I can have a signal that is 15-20dB above the noise floor and DSD/DSDPlus can't decode it because 1/3rd of the signals bandwidth/carriers is simply not there due to the selective fading.

A few seconds later, the selective fading disappears and I get perfect decode again.

This phenomenon only occurs in signals with no direct LOS path to me. It is obvious that something along the indirect path is causing this weird fading process to occur.

And, If you are really serious about weak signal DV decoding, you really need a FCDpro or some other low noise/frequency stable front end. I'm actually chomping at the bit to get my hands on an AIRSPY, SDR when they are eventually released - hopefully in the next few months

For info, I get excellent voice decode on P25 signals only 10dB above the noise floor on the FCDPro+. It's hard to tell what the actual levels are of the weak signals without using a calibrated service monitor/spectrum analyzer, but I would guess that they would have to be down around -120 to -125dBm. This level signal is too weak to produce any decode at all, or only very broken decode on a Uniden 996XT or PSR600 scanner.

 

[br0adband]

I suppose, but like I said, at 463.6225 it's an issue - I can't absolutely confirm that's the TX frequency because I don't have an actual scanner presently, just the two dongles and both of them are rock solid once they've warmed up and the 50/57 ppm works for me from the VHF range well into the upper UHF 935 MHz range, I don't have to adjust it again anywhere in that range. But the few NXDN comms that I'm picking up are sandwiched into strange frequencies upon detection.

Finally snagged the Morse ID from 463.6225 (how I'm receiving it) and it's WQDI304 which is The D as expected but the license info says they should be on 463.625 - it's just odd to me that a frequency at 463.3125 (barely 300 kHz away) and then another one at 464.100 (barely 500 kHz away) both come in dead-on with respect to the ppm setting (57 ppm) while that 463.6225 sits in the middle of those frequencies and yet requires me to retune that ppm. Just seems a bit crazy to me, that's all.

Oh well, maybe I'll have to look into one of those TCXO-modded RTL sticks in the long run. This is the only instance where things are just not where they should be, with those 3 frequencies for The D and their NXDN system.

"Strange things are afoot with NXDN..."

 

[slicerwizard]

When my "regular" dsd.exe" is executing, from the keyboard I can change from a positive to an inverted MOTOTRBO mode search. I can change from a NXDN 4800 baud search to a 9600 baud search and do positive and negative searches. I can change to other switch settings.

We'd all love to know how you made these configuration changes to the original DSD while it was running.

While I'm not absolutely 100% certain of this, based on what W4UVV is saying so far, he's (or she's, sorry) simply unable to do anything from the keyboard except Esc or Control-C meaning the - I R etc keys as listed in the readme/user guide don't work at all. Call me crazy but that's what I'm reading in what W4UVV has said.

He also wrote the above, which casts doubt on anything else he wrote.

whenever I'm grabbing NXDN content from The D on 463.6225 I have to retune the ppm to 59 to get a decode at all: if it's 58 or 60, I get zip, nada, zilch, absolutely nothing whatsoever even though the signal comes in booming since I'm just 3 blocks away and practically line of sight with their antennas on top of the their facility.

For any decoding problem, you need to look at the raw audio that is being fed to the decoder. Doesn't matter if it's DSD, DSD+, TRUNK88, UT, LTR Analyzer, whatever. You need to record the raw audio and then look at it - or post it somewhere so others can look at it. Without that, no answers are forthcoming.

 

[br0adband]

I'm just being facetious placing the blame on NXDN for the issues I'm having. It's really this simple:

FCC records show a frequency that should be 463.600 - I'm picking up the broadcast at 463.5975 rock solid, perfect decoding. The tuner is calibrated dead-center and picks up traffic at 463.450 dead-center and also at 464.100 dead-center (and by dead-center I mean a waterfall with the tuned frequency smack dab in the center of the activity on the frequency). Using two different sticks with two different calibration settings (to make them dead-center on those two frequencies, 50 on one and 57 on the other) I get the exact same results: I can't get the traffic on the FCC assigned frequency, I get it 2.5 kHz off that one yet everything else around those frequencies is spot on.

It's almost like someone doesn't want me to tune in just those 3 frequencies exactly at their published numbers for some reason. </facetious>

It's not about decoding the NXDN which I can do just fine, it's about tuning the frequency so I can, that's my issue right now so I suppose I should stop this considering someone will say "It's a problem with SDR# and your RTL device, not DSDPlus..." which is what this thread is about so, I'll move on. Just for the record I just attempted it with HDSDR as well (first time I've used that app) and it does the same thing: I tune to 463.600 and it shows activity at 463.5975 - if I tune it down 2.5 kHz to that frequency DSDPlus gets the data stream and it's good to go even though I calibrated HDSDR the same way using the same stick.

BLEH.

 

[mtindor]

It's almost like someone doesn't want me to tune in just those 3 frequencies exactly at their published numbers for some reason. </facetious>

ROFL. Funny, and I guess that really can't be ruled out heh. Some crazy radio tech changing the frequency on the fly to thwart your efforts, as he is reading this thread on his netbook

Mike

 

[br0adband]

ROFL. Funny, and I guess that really can't be ruled out heh. Some crazy radio tech changing the frequency on the fly to thwart your efforts, as he is reading this thread on his netbook

Mike

Well it is pretty damned odd considering I can tune stuff just a hair below (there's a cab company at 463.450, another service at 463.500) and some stuff just above those 3 frequencies (another cab company at 463.850 and the aforementioned Fremont Street Experience at 464.100) and each one of those is a spot on match for their frequency assignments as well as what I'm tuning to and hearing them all with my "default" ppm of 50 or 57 depending on the stick I'm using - but those 3 frequencies used by this NXDN system simply are not transmitting on their assigned frequencies, of that I'm pretty damned sure.

There simply cannot be that much variation with a calibrated stick inside a < 1 MHz boundary, there's just something funky going on. When I calibrate these sticks to their given ppm I can tune most anything and it's where it should be from the low end to the high end stuff without issues. It's like knowing one of your most popular and dependable frequencies you monitor suddenly shifted itself 2.5 kHz off where it was always located and you go bonkers trying to figure out why it's happening when everything else tunes precisely where they always are/were.

Aside from that DSDPlus is snatching the NXDN when I get it without a single issue, decoding it beautifully so far, a very happy camper am I, so to speak. Done a few tuning sessions with traffic from this NXDN system and there's barely anything I can do to make it better; as I said I'm literally 3 blocks from the casino hotel itself so I can pick them up perfectly clear with the RTL gain off and RF Gain set to just 12.5 dB to keep it above full quieting (off frequency with squelch).

It's just the damnedest thing to me, go figure.

 

[Jay911]

This isn't precisely related to your issue, but I discovered tonight that the DAB-TV R820T sticks seem to have images at 2.4 MHz offset from the actual frequency, intermittently. I've confirmed this in the 140 MHz part of the VHF band and the 700 band. Just something people should keep in mind when using these things.

 

[br0adband]

Yah, it's the infamous "I hear something on <frequency> but it's not there now..." syndrome and you can easily spot it happening by noting you'll find the signals at the far ends (left and right) of the spectrum display (at least with SDR# which is my main SDR app). If you grab the display and scroll it left or right so that frequency would be placed in the middle of the spectrum - I don't use the centering plugin but some folks might - it'll disappear completely, growing weaker in amplitude as you drag it to center.

Funky stuff, really, I personally don't notice it that often because I keep the sampling rate at 0.900001 almost constantly, with random changes to the 2.4 MHz rate, but whenever I do bump it up to 2.4 that's when those "ghosts" appear and I have to remind myself that they're not really there.

As time passes I suspect we're going to be seeing some truly wicked SDR hardware like HackRF (nice but I have no need to transmit and it's way way out of my price range) and others.

I had like 25 frequencies written down with noted activity when I started doing this a few weeks ago then I went back and was like "Ok, where the hell did that one go, and that one, and that one too..." till I realized what was going on.

 

[racingfan360]

>Finally snagged the Morse ID from 463.6225 (how I'm receiving it) and it's WQDI304 which is The D >as expected but the license info says they should be on 463.625 - it's just odd to me that a >frequency at 463.3125 (barely 300 kHz away) and then another one at 464.100 (barely 500 kHz >away) both come in dead-on with respect to the ppm setting (57 ppm) while that 463.6225 sits in the >middle of those frequencies and yet requires me to retune that ppm. Just seems a bit crazy to me, >that's all.

So (in Europe) I've come across a radio supplier who programs some of his radios at -3.125kHz from the published freq I'd expect them to be on. This applies to 12.5kHz 'event' frequencies where the channels can often be used by other digital and analogue operators, so I'd assumed this to be a way of effectively creating two 6.25Khz channels and minimizing interference from other users on the published freq. A Nexedge radio needs to be set precisely on the freq (the radio wouldn't unmute if the rx freq was set more than 3.125kHz off): this might be what you're seeing on the SDR?


>As for encryption muting on DMR, NXDN or anything other than P25, I don't know whether either
>application supports the muting of encryption for anything other than P25.

So I've tested DSD+ on a few encrypted channels other than on P25: I've found it consistently mutes on just one encrypted NX9600 voice channel (which I believe is running an enhanced form of encryption). On all the other encrypted channels (a mix of trunked, simplex, base) I've tested on NX4800/NX9600/DMR it doesn't seem to mute.

 

[mtindor]

>As for encryption muting on DMR, NXDN or anything other than P25, I don't know whether either
>application supports the muting of encryption for anything other than P25.

So I've tested DSD+ on a few encrypted channels other than on P25: I've found it consistently mutes on just one encrypted NX9600 voice channel (which I believe is running an enhanced form of encryption). On all the other encrypted channels (a mix of trunked, simplex, base) I've tested on NX4800/NX9600/DMR it doesn't seem to mute.

I don't know if you are willing and/or able, but if you can please consider recording the raw audio from any encrypted NX4800/NX9600/DMR transmissions using the 'R' feature in DSDPlus and then upload the same to someplace like Dropbox or Zippyshare. The author can probably make use of additional samples of known encrypted traffic to improve the product.

Thanks,

Mike