DSDPlus

[DaveNF2G]

Dave,

Two things:

a. the author did in fact name the binary "dsdplus.exe"

The author is unknown and the uploader are unknown. the uploader changed the name of the exe to 'dsd.exe' prior to uploading. Nothing can be done about that now. I'm sure it will be so noted in the future.

b. dsdtune is not made by the DSDPlus author.

If you want to use dsdtune on an exe called dsdplus.exe, simply add '-x dsdplus.exe' to tell dsdtune that the the DSDPlus executable's name is dsdplus.exe.

Mike

Thanks for the clarifications.

Does dsdtune work with either program depending on which one is present or called, or only with the one that is actually dsdplus?

 

[deboe]

Does dsdtune work with either program depending on which one is present or called, or only with the one that is actually dsdplus?

It only works with the dsdplus program (does not matter what it's named, if its not dsd.exe you just need to pass the -x dsdplus.exe, or what you named it).

dsdtune works by reading the output of dsdplus where it reports the sucess of the last decode [ decoding score = xx,xxx ]

 

[DaveNF2G]

It only works with the dsdplus program (does not matter what it's named, if its not dsd.exe you just need to pass the -x dsdplus.exe, or what you named it).

dsdtune works by reading the output of dsdplus where it reports the sucess of the last decode [ decoding score = xx,xxx ]

In that case, the dsdtune author really should recode the program so it looks for dsdplus.exe, as dsd.exe is a different and incompatible program.

 

[deboe]

In that case, the dsdtune author really should recode the program so it looks for dsdplus.exe, as dsd.exe is a different and incompatible program.

I am the author of dsdtune. The reason it looks for dsd.exe buy default is the zip file posted had the dsdplus program named dsd.exe. So dsdtune by default looks for the default name of dsdplus.

I was thinking about maybe adding code if it sees dsdplus.exe it will try that first (not high on my free time priority list). The code is in github so if anyone else wants to add it, feel free to submit a pull request.
https://github.com/dreinhold/dsdtune

 

[frazpo]

Deboe, Sent you a PM.

 

[n4yek]

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

That's what I always got while trying to download with Firefox browser. I then tried using Internet Explorer and it downloaded with no problem.
Give that a shot.

 

[W4UVV]

I'll Tell You How SliceWizard!!

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

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

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.

Slicewizard, I am ignoring, but not excusing, your rude, snide, condescending, impuning post bordering on a personal attack i.e., (He also wrote the above, which casts doubt on anything else he wrote).

! will tell you how it works for me. Almost two years ago now I configured a dsd software/hardware configuration installing dsd 1.4.1 on my Win 7 desktop's C drive. "dsd14.exe" works fine. Upon program execution "Digital Speech Decoder 1.4.1", "mbelib version 1.2.3" and Audio In/Out info texts display. When tuned to a target MOTOTRBO, P25 Phase 1, or NXDN signal is detected it immediately begins decoding. Anytime during that attempted decoding process I press "CTRL C", it interrupts and returns me to a command line prompt "c:\DSD>". Entering "dsd" (dsd.exe) with no related attributes it begins decoding the target signal(s) for MOTOTRBO, P25 Phase 1 and NXDN 4800 baud which I have tuned to on my modified R7000 receiver. If I press "CTRL C" again while dsd 1.4.1 is running it interrupts the decode process and returns me again to a "c:\DSD>" command prompt where, for example, I can enter "dsd -xr" to search for an inverted MOTOTRBO or P25 Phase 1 signal on a target frequency.. I can press "CTRL C" ANYTIME dsd 1.4.1 is running to return to a command prompt. THAT'S HOW I DO IT!!!!!

I am aware of the main differences between "dsd1.4.1" and DSD Plus. This morning I installed DSD Plus on my Win 7 desktop C drive whereas yesterday I installed it on one of my WinXP desktops on a different drive. I am experiencing the same results today as yesterday regarding no keyboard entries being recognized except "CTRL C" and "ESC". Experimenting yesterday I found the "CTRL C" keyboard entry is recognized by DSD Plus and has the same result as "ESC." for whatever reason terminating the program and exiting to the desktop shortcut icons level.

I renamed the DSD Plus executable in my Win 7 configuration to "dsdplus.exe" with the same results experienced as previously. Upon executing "dsdplus.exe" DSD Plus info displays below the "Mono decoding press Esc to exit..." . When tuned to a target MOTOTRBO, P25 Phase 1 or NXDN target signal on my modified R7000 it begins decoding all three modes fine.

I also am aware that "CTRL C" should possibly apply only to "dsd 14.exe" for a new command prompt user keyboard selection. However, FYI again for whatever reason in DSD Plus if ":CTRL C" is pressed it also exits program the same as if pressing "ESC". I don't care about that. What I do care about is getting DSD Plus to recognize ALL my keyboard entries.

Attached are two screen captures. First you can see the basic DSD Plus text displays awaiting a signal to decode. In the second picture I interrupted a good MOTOTRBO signal decode. Again, the DSD Plus program for whatever reason does NOT recognize any of my keyboard entries except "CTRL C" and "ESC".

If anyone has any helpful recommendation(s) as how to resolve this no full keyboard entries recognition issue by DSD Plus vice posting impuning personal comments, I welcome them.

John

 

[br0adband]

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?

I don't know for certain but that might just be something I need to consider - the funky thing is that I found another NXDN system last night just by chance (I don't find them by searching through the RadioReference database or the FCC, I actually just tune frequencies that appear to be data streams and see if DSD/DSDPlus are able to decode anything, if they do then I note it as whatever type of mode detected) and yes this other system does the same damned thing: I'm not picking them up precisely on their FCC assigned frequencies, I get their transmissions (from the base/repeater) slightly off the licensed frequencies just like that other system does.

Everything above and below said frequencies still tunes perfectly normal, on their precise published ones without issue (dead-center waterfall reception with the calibrated ppm settings for each stick I own), and yet once again here's yet another system that's just not quite where they should be.

Holy crap this NXDN stuff is weird here in my area, it seriously is with this funky stuff.

Thanks for pointing that info out, jhampton2000, it's something to go on - I mean if this was just a one-shot that would be one thing, a fluke I suppose, but that's now 2 entirely different and unrelated NXDN systems and both of them are exhibiting the exact same behavior of not transmitting on their licensed frequencies. Just for the record this other system is Rebel Communications, LLC WPKT842 in case there's someone else here in Las Vegas that might be curious.

 

[Jay911]

Anytime during that attempted decoding process I press "CTRL C", it interrupts and returns me to a command line prompt "c:\DSD>". Entering "dsd" (dsd.exe) with no related attributes it begins decoding the target signal(s) for MOTOTRBO, P25 Phase 1 and NXDN 4800 baud which I have tuned to on my modified R7000 receiver. If I press "CTRL C" again while dsd 1.4.1 is running it interrupts the decode process and returns me again to a "c:\DSD>" command prompt where, for example, I can enter "dsd -xr" to search for an inverted MOTOTRBO or P25 Phase 1 signal on a target frequency.. I can press "CTRL C" ANYTIME dsd 1.4.1 is running to return to a command prompt. THAT'S HOW I DO IT!!!!!

I am aware of the main differences between "dsd1.4.1" and DSD Plus. This morning I installed DSD Plus on my Win 7 desktop C drive whereas yesterday I installed it on one of my WinXP desktops on a different drive. I am experiencing the same results today as yesterday regarding no keyboard entries being recognized except "CTRL C" and "ESC". Experimenting yesterday I found the "CTRL C" keyboard entry is recognized by DSD Plus and has the same result as "ESC." for whatever reason terminating the program and exiting to the desktop shortcut icons level.

Um... Ctrl+C doesn't just "return [you] to a command prompt", it exits the program. Regardless of whether you're using DSD or DSD-plus. Or any other console-level program.

You should be running DSD-plus from a command prompt anyway, so you can enter switches and options, rather than clicking on it from "the desktop shortcut icons level".

 

[Jay911]

Anytime during that attempted decoding process I press "CTRL C", it interrupts and returns me to a command line prompt "c:\DSD>". Entering "dsd" (dsd.exe) with no related attributes it begins decoding the target signal(s) for MOTOTRBO, P25 Phase 1 and NXDN 4800 baud which I have tuned to on my modified R7000 receiver. If I press "CTRL C" again while dsd 1.4.1 is running it interrupts the decode process and returns me again to a "c:\DSD>" command prompt where, for example, I can enter "dsd -xr" to search for an inverted MOTOTRBO or P25 Phase 1 signal on a target frequency.. I can press "CTRL C" ANYTIME dsd 1.4.1 is running to return to a command prompt. THAT'S HOW I DO IT!!!!!

I am aware of the main differences between "dsd1.4.1" and DSD Plus. This morning I installed DSD Plus on my Win 7 desktop C drive whereas yesterday I installed it on one of my WinXP desktops on a different drive. I am experiencing the same results today as yesterday regarding no keyboard entries being recognized except "CTRL C" and "ESC". Experimenting yesterday I found the "CTRL C" keyboard entry is recognized by DSD Plus and has the same result as "ESC." for whatever reason terminating the program and exiting to the desktop shortcut icons level.

Um... Ctrl+C doesn't just "return [you] to a command prompt", it exits the program. Regardless of whether you're using DSD or DSD-plus. Or any other console-level program.

You should be running DSD-plus from a command prompt anyway, so you can enter switches and options, rather than clicking on it from "the desktop shortcut icons level". To run from a command prompt, go Win+R and type "cmd" in the dialog box, then hit Enter. You'll have to find the folder you put DSD-plus in by yourself, using the cd (change directory) command.

 

[br0adband]

*snip*

W4UVV: Honestly I think there's a failure to communicate going on here, so I'm going to try and be brief but clear and concise as possible.

What's happening with you - and this is how I "decode" what you're saying - is that when you run DSD (the original decoder you've been using for 2 years), it runs in a Command Prompt window aka "a DOS box" and that when you terminate it with Control-C (that's how you kill it, or just close the Command Prompt window by clicking the red X, of course) what happens is "the DOS box" window remains on the screen allowing you access to the Command Prompt so you can execute something else, etc.

However, when you're using DSD+ what happens when you press Control-C is that the Command Prompt window aka "the DOS box" disappears totally. Am I getting that correct?

If so the solution is pretty simple: DSD and DSD+ are both known as command line executables - they are not "DOS programs" even though they use the old visual style for their interfaces. DOS is dead, has been for a very long time now, and a Command Prompt window isn't DOS, it just looks like it from years passed.

Anyway, I suspect that when you execute DSD (the old decoder) you're probably doing it with either a batch file (.bat) or you're opening a Command Prompt with cmd.exe from the Run prompt which isn't the same way you're starting DSD+ - I suspect that you're starting DSD+ by double-clicking on the .exe file. If that's the case what happens with DSD+ (and any command line executable, actually) is that the Command Prompt that opens will open in exclusive mode meaning it exists only for that particular application - as soon as you press Control-C that application will terminate and that Command Prompt window will cease to exist aka it'll up and vanish on you like a fart in the wind.

Having said that, what slicerwizard and I and others understand about DSD and DSD+ that you're missing or simply not understanding properly is that when someone says "keyboard entries" that means to us this:

When DSD or DSD+ are running, you can tap a key and it will alter how the program is functioning, or enable/disable some specific additional functionality in the program while it's running. Here's the important part so please read it at least twice if necessary so you fully comprehend what I'm saying (and this is where the failure to communicate is happening):

DSD (the original program) has no run-time keyboard options - there's nothing you can press on the keyboard to alter how it's running once it's functional. If you wish to alter the options for DSD you must do it from the command line when you execute the program. For example, by default DSD will listen for any and all types of modes (P25/NXDN/etc) and it's well known that you can get much better decoding performance overall if you specifically "lock" DSD into a specific decoding mode. Say for example you want to monitor a P25 system and nothing else - you have no intentions of listening to or monitoring (or decoding) any NXDN system, or ProVoice, or whatever. You're going to listen in on a local P25 system for the night, as the case may be. The best option for DSD would be to start it up aka execute it from the command line with this command:

dsd.exe -f1 (and then press Enter)

That will run DSD in a mode that tells it "Ok, listen specifically for P25 frames and ignore absolutely everything else that comes down the pike..." more or less. It's more efficient that way and helps to make DSD work better - all the potential decoder modes are controlled by command line switches meaning the part after dsd.exe like the -f1 there which tells DSD to look for and decode only P25 frame traffic.

Basic gist: once DSD is running you don't do anything with it from that point on but let it do it's job.

Now, with DSD+ things are a bit different because DSD+ does offer the ability to modify a few options when it's running (as well as still being able to provide the command line switches before you execute it like DSD does), as listed in the readme/user guide for DSD+ and they are:

    Active keys:
      -           Toggle command line options display
      I           Toggle input audio level display
      R           Start/stop recording of raw input audio to .wav file
      S           Display group/user stats
      Esc         Terminate real time decoding
      Ctrl-C      Terminate .wav file decoding

What that means is that when DSD+ is running (note we're not talking about DSD anymore) you can press any of those keys on the keyboard and it alters something with DSD+ while it's running. DSD offers no such options for "keyboard entries" so that's a wash.

Looks like Jay911 offered you the "short short version" of basically what I've just said. To run either DSD or DSD+ you should be opening a Command Prompt and then navigating to where DSD or DSD+ reside (where their .exe files are) and then running them manually from the command line as just described.

If you simply double-click on their .exe files, or you have a batch file to run either or both of them, the batch file when terminated is probably "dumping you back to the Desktop" which seems to be what you've described.

Open a Command Prompt, change to the directory where you have the .exe files (you can put them in the same directory, of course, just name the old version dsd.exe or whatever, and dsdplus.exe or however it works best for you). I have all my decoders in the same folder so I don't have to scramble all over the place looking for them, just makes it simpler and more efficient for me.

This is just a failure to communicate, nothing more, with some terminology that hasn't been clarified up to this point - hopefully that's now corrected.

 

[AZScanner]

I always put the command "pause" (without quotes) at the end of any batch files so that if something happens I can review the screen for errors. If you're testing or tweaking different command line parameters, that's a good way to go.

-AZ

 

[slicerwizard]

Slicewizard, I am ignoring, but not excusing, your rude, snide, condescending, impuning post bordering on a personal attack i.e., (He also wrote the above, which casts doubt on anything else he wrote).

You made claims that are impossible. You claimed that you can modify DSD's operation while DSD is running, which is patently false. That does cast doubt on any other claims you make. There is nothing personal in that assessment. Solutions are not arrived at by ignoring the implications of wild claims.

Your screen shot shows that you're invoking/running DSD and DSD+ differently and that explains the "differences" you're going on about. You should be able to sort it out now.

 

[alpha-alligator]

Provoice help

Hi all.. the software is great and sounds better, a big thanks to the author.

Can there be some info somewhere about what these filters do? ie.hotspot size and Roll off filter

I get a good decode of this system, but quite frequently there is this,,,, i dunno( tone\protocol\whatever..... and then I lose part of the coversation.

Dumpt - Image Host
you can see it in the middle. with little dots on either side....

Anyone see this before? and will these filters fix this?

HAPPY NEW YEAR!!!

 

[mtindor]

Hi all.. the software is great and sounds better, a big thanks to the author.

Can there be some info somewhere about what these filters do? ie.hotspot size and Roll off filter

I get a good decode of this system, but quite frequently there is this,,,, i dunno( tone\protocol\whatever..... and then I lose part of the coversation.

Dumpt - Image Host
you can see it in the middle. with little dots on either side....

Anyone see this before? and will these filters fix this?

HAPPY NEW YEAR!!!

What's up with that filter bandwidth? 10? You can't use 10 and expect to decode. Try something around 9000. If you had your filter width wide enough, it would be enveloping that signal rather than shutting out 99% of it.

Also, who do you have a Shift entered in there? And at least "Correct IQ" ought to be checkmarked.

Aside from those things, it looks like interference. If you're using DSDPlus, how about recording some raw audio (preferably when you know it is going to happen). If you can anticipate that happening, pressing "R" in DSDPlus and then recording about a minute and then pressing "R" again will give you a DSDPlus-Raw-*.wav file that you coudl then upload to someplace like dropbox or zippyshare so we can all take a listen.

But then again, you really need to get things straightened out with your settings in SDR#. I don't know why you would need Shift, and I'm not sure why you are using a filter width of '10'' or why you don't have "Correct IQ" checkmarked. What you really need to do is calibrate the dongle by tuning to a signal whos frequency you know absolutely. Then go from there.

Before I go any further, can you tell me why you have Shift set, why you do not have Correct IQ set, and why you have a Filter Width of 10? You may have a good reason. I just need to know before I proceed. I don't configure my dongle anything like the way you do.

Mike

 

[alpha-alligator]

bandwdth works..

It seems to make no difference.. I tried it either way. I still hear the same...But i will leave it at 12500..
What does correct IQ mean?
I set the freq. PPM then make minor adjustment using the shift..
Aside from that, have you seen this before?
Dumpt - Image Host

It walks over this conversation.

 

[Jay911]

Think of bandwidth as the "keyhole" you're looking at something through. The typical signal is roughly 8000 kHz wide. (Guys, please don't take me to task for this huge generalization - it's an example.) By setting your bandwidth to 10, you are peering at a very miniscule cross-section of the signal, only 10 kHz out of 8000 (or 1/800th of the signal).

 

[mtindor]

Aside from that, have you seen this before?
Dumpt - Image Host

It walks over this conversation.

It would be best if you capture raw audio by pressing "R" in DSDPlus and then waiting for that anomaly (sp?) to appear in SDR#, and then pressing "R" in DSDPlus again. Then find that recorded raw audio WAV file that begins with DSDPlus-Raw* and upload it somewhere so that we can feed that audio into our own and check it out. I'd actually just listen to the audio. I'm betting you simply have one transmitter in one location walking over the other. But ya never know. You could have a really strong local signal on another frequency that, when active, wreaks having on the frequency you are trying to monitor.

Mike

 

[alpha-alligator]

will post raw audio,

working on it. I had tried a different antenna to see if it would go away but it made my signal weaker.
I will post back tomorrow, As my wife won't let me on the roof at this hour and I had a few post new years eve drinks.

Be Safe, Happy New Year!

 

[br0adband]

Just as a followup to my previous situation with NXDN here in the Las Vegas area, and based on what jhampton2000 said about some suppliers programming NXDN hardware to actually transmit +/- 3.125 kHz off their assigned frequencies - say for example a unit should be transmitting at 463.600 and actually transmits at 463.596875 (seriously) then you'd only get a dead-on tuning of that transmission if you tuned to 463.596875. You might get a usable signal just above or just below that weird offset frequency to some degree but if your hardware is capable of it then tuning it precisely or as precisely as possible is the best course of action.

So I went back and looked at the FCC licensing info for The D, noted the frequencies, then tuned them precisely according to the licensing (well, 2 of them have activity at least, the third I haven't noted anything on just yet) and watched for any activity + or - off that frequency and as expected (and noted the past few days) I got the NXDN transmissions just slightly off the actual assigned ones.

Did some simple math, calculated the proper frequencies and voila, a spot on match:

462.850000 will either show activity at 462.846875 (- 3.125 kHz) or 462.853125 (+ 3.125 kHz) whenever I do actually pick something up.

463.596875 seems to be Security and is now "locked in" and receiving the NXDN stream with the 50 ppm without a single issue for hours now.

The last assigned frequency of 463.625 is where it gets interesting because I'm getting activity below and above that one:

463.621875 (- 3.125 kHz) and 463.628125 (+ 3.125 kHz) and both of those also are locked on for hours now with no issues and at 50 ppm meaning everything is tuning properly without me having to touch anything at all.

And yes, the second system I detected - Rebel Communications - is doing the same thing and responds the same way by adjusting the offset. I'm not using the Shift feature for these frequencies, I'm just putting them into the Frequency Manager + Scanner database at the actual frequencies I'm picking them up at. Seems a bit odd to me, perhaps whoever supplied the radios to both companies here in this area is doing the same thing and programming them at these weird offset frequencies, I don't know.

But if you're monitoring NXDN systems yourself, and you find that the frequency you're trying to listen in on (the FCC assigned ones, at least for those of us here in the US that is) and you're getting the sides of the transmissions in the spectrum/waterfall display and not the actual dead-on ones, this could be the reason why - some funky +/- 3.125 kHz deviation on the actual hardware itself.

Maybe this info will help others, I don't know, but there it is.

jhampton2000: Thanks again for pointing that little tidbit out, it's proven most helpful.

Happy New Year to one and all, also... make it a good one, folks.