DSD+ and source code release discussion

[exkalibur]

The GPL is very much enforceable.

How? There's no GPL police out there, yet.

Also, we're all forgetting that these programs (DSD and DSD+) both use code that is in violation of DVSI's intellectual property rights. So really, even if the author is in violation of the GPL, it'd be pretty hypocritical to make a fuss about it, considering the IP issue.

I guess my point is that, we should just enjoy the program that has been released and be thankful he/she has released it. Nobody really has any right to expect any code, explanations or anything. Just use it and enjoy it. If you can't get over the source code issue, then just don't use it!

 

[groovy]

First- I understand that the author(s) of DSD+ is within their rights not to release the code. dsdauthor himself even stated: "[...]This software is distributed under a liberal BSD license so there is nothing to stop others from supplying patches, forking this project or incorporating it into a commercial product [...]"

On the other hand, I take issue with your comparison of copyright to the DVSI IP rights on MBE- They are quite different:

First, it is unclear what parts of DVSI's patents would stand up in court, given the recent revelations by the codec2 team that David Rowe's work preceded their patent filings. You can see Bruce Perens's comments on this issue on the issue on the digitalvoice mailing list. However as DVSI is a company with deep pockets, they could try to "win" by forcing victims to run up legal bills. In doing this though, they risk their IP, so it is in their interest to avoid going after hobbits who could gather supporters and stick to the bigger fish (if they chose to litigate at all after these revelations). dsdauthor, the dsd+ author, and many of the others involved chose to remain anonymous just in case.

Second, the patent system was designed to encourage experimentation and development of technology. That is why these patents are openly published. It is completely acceptable for me to experiment with MBE technology. I just may not distribute/sell it/use it without their permission. See the mbelib readme: "This source code is provided for educational purposes only. It is a written description of how certain voice encoding/decoding algorithms could be implemented. Executable objects compiled or derived from this package may be covered by one or more patents. Readers are strongly advised to check for any patent restrictions or licencing requirements before compiling or using this source code."

The copyright holder has a fairly free ability to control whether his works are redistributed. There is little leeway to dispute the validity of the copyright (though with anonymous authors I suspect the PGP private key will be the only proof that the person holds the copyright). There is some fair use right around copyright, but it is more narrowly defined than what you may do with patents. Ignoring the terms of the license and distributing binaries without source would seem a pretty open-and-shut case, if it got to court. (IANAL, and I am no expert on these issues)

How? There's no GPL police out there, yet.

Also, we're all forgetting that these programs (DSD and DSD+) both use code that is in violation of DVSI's intellectual property rights. So really, even if the author is in violation of the GPL, it'd be pretty hypocritical to make a fuss about it, considering the IP issue.

I guess my point is that, we should just enjoy the program that has been released and be thankful he/she has released it. Nobody really has any right to expect any code, explanations or anything. Just use it and enjoy it. If you can't get over the source code issue, then just don't use it!

 

[woodpecker]

That would be a good start. If we could get one version of DSD that included all the recent fixes and enhancements plus having D-Star support for voice, that would be absolutely awesome!

I've done a very quick merge of dsd 1.6 with the 1.7 code, it decodes dstar voice, I've not been through the code just thrown it together, let me know how you get on with it.

 

[RonnieUSA]

I've done a very quick merge of dsd 1.6 with the 1.7 code, it decodes dstar voice, I've not been through the code just thrown it together, let me know how you get on with it.

This build doesn't decode NXDN for Me.
Is that the way it's supposed to be?

 

[mtindor]

This build doesn't decode NXDN for Me.
Is that the way it's supposed to be?

If you're trying to decode NXDN trunked, then probably. DSDPlus is the only one that currrently handles trunked voice that I know of. This likely decodes the same NXDN as any other DSD (not DSDPlus) has ever decoded. I think Woody put this together specifically to provide D-Star support in a version of DSD that also has his own code improvements (better filtering, P25 isn't totally broken like DSD 1.7, etc)

Mike

 

[RonnieUSA]

If you're trying to decode NXDN trunked, then probably. DSDPlus is the only one that currrently handles trunked voice that I know of. This likely decodes the same NXDN as any other DSD (not DSDPlus) has ever decoded. I think Woody put this together specifically to provide D-Star support in a version of DSD that also has his own code improvements (better filtering, P25 isn't totally broken like DSD 1.7, etc)

Mike

Not trunked, conventional.

 

[mtindor]

Not trunked, conventional.

Are you forcing detection with -fi (NXDN48) or -fn (NXDN96) ? You must force it. It doesn't autodetect.

Mike

 

[RonnieUSA]

Are you forcing detection with -fi (NXDN48) or -fn (NXDN96) ? You must force it. It doesn't autodetect.

Mike

That I didn't know.
Thank You very much.

 

[rmosier]

Could anyone direct me to a reliable download location? Thanks.

 

[exkalibur]

We already have two divergent forks: DSD with DSTAR voice decoding, and DSD+ without that feature but with better P25 decoding.

DSD+ has a lot more features than just "better P25 decoding". Off the top of my head...

-Autodetection of all supported digital modes
-better NXDN decoding
-better DMR decoding
-better ProVoice decoding
-DMR dual-slot decoding
-auto record to eiter MP3 or WAV
-low CPU useage

 

[exkalibur]

its not ideal to have to run dsdtune to get it to work properly unless you can get away with one set of filter parameters that fits all modes, which is unlikely due to the different bandwidths and data rates.

DSD+ allows a user to fine-tune the symbol decoder parameters to match the characteristics of the transmissions and their receiver/discriminator tap. Every combination is going to be unique, so it makes sense to give the user the ability to "tweak" the settings that work best for him. No other (known) version of DSD allows you to do this.

 

[exkalibur]

Also regarding the argument for D-STAR decoding - it would be nice to have this working, but in reality that wouldn't be a huge plus for a lot of users. I can understand the developer not wanting to invest too much time on a feature that would be of limited benefit. Personally, I'd rather have a decoder that did a fantastic job on protocols that are actually used.

 

[mtindor]

Also regarding the argument for D-STAR decoding - it would be nice to have this working, but in reality that wouldn't be a huge plus for a lot of users. I can understand the developer not wanting to invest too much time on a feature that would be of limited benefit. Personally, I'd rather have a decoder that did a fantastic job on protocols that are actually used.

I concur. The more protocols the better, but if I have to choose from 6 protocols that barely work versus 5 that work flawlessly, well, I think you know which I prefer

Mike

 

[br0adband]

I managed to actually track down a D-Star broadcast a few days ago, first time I'd caught one here in the Las Vegas area. Only reason I did catch it was because I picked up two Hams in mid-discussion talking about the merits/demerits of D-Star and whatever, then one said something referring the other to do "this this, press that, choose this menu option, enter this info, and transmit..." so the other one did then the frequency went quiet which prompted me to take a peek at the spectrum and when I didn't see anything immediate (I use 1024 for the sample rate these days, works for me).

Sure enough about 2 MHz down they'd started up a new conversation with D-Star; it obviously stood out as a digital transmission on the waterfall quite readily. Using DSD+ all I could get was the text/ID/tag info - I've never cared for D-Star since I've never bothered with it so being the first time I suppose it wasn't all that in most respects. I don't have a Win32 compiled version of that newer DSD build which supports D-Star voice comms so I haven't actually heard it in use aside from some samples on one of the digital modes samples pages.

Not sure it matters I guess, but as others have stated, so far DSD+ is truly awesome as far as I'm concerned. Even got my first ProVoice catch a week or so ago, nothing special there either. It seems like it's P25, DMR/MOTOTRBO, and NXDN from here on out in order of infrastructure penetration.

Can't wait to see if DSD+ eventually gets P25 Phase II support, obviously, since the biggest system here in this entire area is reported to be moving towards that at some point, maybe even a move from 800 to 700 MHz in the process too which would really be something. Still pissed that the LVMPD went OpenSky and there's just no way to monitor that at all - they do a simulcast of two channels (primarily info related and not for active calls in progress).

Planning to build a Homebrew OCFD here in another week or so when I can get the parts together, and I'm sure once I do I'll just continue using DSD+ as I have since it was released.

But sure, the more protocols the better I suppose, it can't hurt if the DSD+ author can magically make it all happen.

 

[mancow]

It would be neat if some sort of gui could be built on top of dsd+ with some adjustment sliders and decode fields.

 

[exkalibur]

I agree with mancow - but that's a discussion better suited in the feature request thread. I hope the developer is aware of our conversations on here, or at least in the feature request thread.

 

[woodpecker]

Also regarding the argument for D-STAR decoding - it would be nice to have this working, but in reality that wouldn't be a huge plus for a lot of users. I can understand the developer not wanting to invest too much time on a feature that would be of limited benefit. Personally, I'd rather have a decoder that did a fantastic job on protocols that are actually used.

DSD 1.7 will decode dstar so all they need to do is copy the code, for now just use that alongside plus, its a shame we can't see the code for dsd+ as it could be combined with DSD to make one better program, in the meantime I'll carry on using both.

 

[AZScanner]

It would be neat if some sort of gui could be built on top of dsd+ with some adjustment sliders and decode fields.

Only if such a program was an add-on for, rather than a feature of, DSD+. I like the fact that DSD+ is a lean and mean console app that can be run from anywhere on the machine and that saves it's resources for where they are truly needed - decoding voice data. GUI apps are notorious memory hogs - they have to be to show you all those pretty buttons and sliders. Especially dot net apps. There's a reason why the dot net framework requires 1-2 gigs of disk space, folks.

I'd like to see something built that you could set the various parameters of DSD+ using the sliders and such, then click a button and it fires up DSD+ with all the parameters you set up in the pretty GUI, and then it would close and go away to return all those resources to the PC so it could decode voice more accurately. Something like that shouldn't be too hard to build. I could probably do it myself in an afternoon - but I'm busy/lazy. I might get around to it if there's enough demand for it.

-AZ

 

[br0adband]

What we really need is a plugin version of DSD+ for SDR#, I swear. I know it'll more than likely never come to fruition. Since SDR is still almost in its infancy with respect to the software side of things as people learn more about it and more importantly learn how to extract the best performance and most capabilities from it as well, it will be awesome to see where things go as time passes.

Now if I could just get a program that basically emulates everything possible with a modern scanner like the BCD-436HP sans the physical hardware I'd be all over it - and I'd be willing to fork over some cash too.

 

[SCPD]

This should go in the feature request thread.