RadioReference on Facebook   RadioReference on Twitter   RadioReference Blog
 

Go Back   The RadioReference.com Forums > Computer Aided Monitoring and Programming > Software Defined Radio


Software Defined Radio - A forum for general discussion of software defined radio (SDR) receiver equipment.

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
  #61 (permalink)  
Old 09-20-2018, 4:10 PM
Member
   
Join Date: Sep 2002
Location: Toronto, Ontario
Posts: 4,717
Default

Quote:
Originally Posted by kb9mwr View Post
the original dsd author was gone (thanks to dsd plus)
So dsdauthor last posted here in February 2013 and the first sighting of DSD+ was Christmas 2013, therefore DSD+ drove off dsdauthor. You guys are hilarious.
Reply With Quote
Sponsored links
  #62 (permalink)  
Old 09-21-2018, 9:25 AM
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Aug 2008
Posts: 454
Default

Quote:
Originally Posted by slicerwizard View Post
So dsdauthor last posted here in February 2013 and the first sighting of DSD+ was Christmas 2013, therefore DSD+ drove off dsdauthor. You guys are hilarious.
There is sufficient evidence to support this. Bruce Perens (a founder of the Open Source Initiative) contacted the original dsdauthor who had several interesting things to say; some of which were mentioned in his "AMBE exposed" paper (available online via search)

Quote:
* The “mbelib” developers created a D-STAR decoder
called “DSD” and published it, with “mbelib”, under the
BSD license.

* Another anonymous developer created a proprietary fork
called “DSD+” and declined to share his source code
with the original developers.

* The original developers know better now, and will put
their future work under GPL instead of BSD, but they
probably aren't going to do more work that helps DSD+.

* Mbelib has remained at release 1.0 for more than a year
Another perspective, from the same paper
Quote:
* Recently, another closed-source DSD fork has
appeared called DSD Plus. [...] It greatly annoys me
that these improvements are locked out and
unavailable to people who want to make further
improvements. It annoys me even more that people
on the forums keep defending the choice of the
DSDPlus author to keep the software closed.

* I think the real pain for this developer of “mbelib”
was when he got a public “screw you” from what
was really his user community.
also I have personally heard through the grapevine that DSDPlus constantly lives in fear of DVSI and as well of NXDN's trunking patents...

Max
Reply With Quote
  #63 (permalink)  
Old 09-21-2018, 12:24 PM
Member
  Audio Feed Provider
Audio Feed Provider
 
Join Date: Dec 2002
Location: Syracuse NY
Posts: 22
Default

Quote:
Originally Posted by boatbod View Post
Yes, this absolutely is possible and just requires the correct setup in asound.conf. The advantage over trying to monitor your own stream via broadcastify is far less delay (it's instantaneous).

rx.py needs to output to "mout0" device
darkice.cfg needs to receive from "loop0" device

(code snipped)
Boatbod,
Will this allow me to monitor my stream through the HDMI port on a Raspberry Pi or would it need to be modified?
Reply With Quote
  #64 (permalink)  
Old 09-21-2018, 12:29 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Mar 2007
Location: Talbot Co, MD
Posts: 1,196
Default

Quote:
Originally Posted by ka2zir View Post
Boatbod,
Will this allow me to monitor my stream through the HDMI port on a Raspberry Pi or would it need to be modified?
The only modification would be to change hw:0,0 to whatever values are needed to select the HDMI port. Perhaps "hw:1,0"?
Reply With Quote
  #65 (permalink)  
Old 09-21-2018, 12:32 PM
Member
  Audio Feed Provider
Audio Feed Provider
 
Join Date: Dec 2002
Location: Syracuse NY
Posts: 22
Default

Quote:
Originally Posted by boatbod View Post
The only modification would be to change hw:0,0 to whatever values are needed to select the HDMI port. Perhaps "hw:1,0"?
That was a quick reply! Thanks!

Edited to add: Just tried it on my backup Pi. Works like a charm, although HDMI port turned out to be hw:0,1.

Last edited by ka2zir; 09-21-2018 at 1:01 PM..
Reply With Quote
Sponsored links
  #66 (permalink)  
Old 09-21-2018, 1:27 PM
Member
   
Join Date: Sep 2002
Location: Toronto, Ontario
Posts: 4,717
Default

* The “mbelib” developers created a D-STAR decoder
called “DSD” and published it, with “mbelib”, under the
BSD license.

* Another anonymous developer created a proprietary fork
called “DSD+” and declined to share his source code
with the original developers.



When DSD was released, it did not do anything useful with D-Star (certainly no voice decoding) so it wasn't "a D-STAR decoder" and when DSD+ showed up, neither it nor the current version of DSD did anything with D-Star.

So your source isn't particularly reliable, for starters.
Reply With Quote
  #67 (permalink)  
Old 09-21-2018, 4:33 PM
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Aug 2008
Posts: 454
Default

well in the end I can't and don't speak for DSDAuthor, he must do so for himself, if and when he should so choose.

Nonetheless, here are some facts:

Fact: there are two success reports from OP25 users monitoring dstar, right in this thread.

Fact: some of the code in OP25 that decodes dstar originated in DSD (and was duly credited).

Fact: one hundred percent of the OP25 code is published under an open source license. The dstar modules from DSD retain the original BSD license and the remainder is licensed under the GPL V3.

Fact: I know of other open source projects that have borrowed code and various designs and logic from OP25 (I'm delighted); also we've received many code contributions and bug fixes, all that would have been impossible had the source been withheld.

Fact: the OP25 authors made the decision long ago to go with free/open source under the GPL. I fully share the annoyance voiced in the following quote:
Quote:
* Recently, another closed-source DSD fork has
appeared called DSD Plus. [...] It greatly annoys me
that these improvements are locked out and
unavailable to people who want to make further
improvements. It annoys me even more that people
on the forums keep defending the choice of the
DSDPlus author to keep the software closed.
There is every reason to believe this is an honest representation of the sentiments of DSDAuthor. Otherwise his decision to release the original DSD as source code would make no sense...

Max
Reply With Quote
  #68 (permalink)  
Old 09-23-2018, 11:43 PM
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Apr 2003
Location: Green Bay, WI
Posts: 106
Default

Quote:
Originally Posted by slicerwizard View Post
So dsdauthor last posted here in February 2013 and the first sighting of DSD+ was Christmas 2013, therefore DSD+ drove off dsdauthor. You guys are hilarious.
Well it was mostly an assumption on my part. I am not much of a coder, but know my way around a Linux system. I'd venture to say most people who write things with the sources available do so, so that others can learn/tinker and benefit from their work (if they so choose), rather than just be an end user.

If I were dsdauthor, and someone else came along with a similar software and were not sharing how they made improvements to the same concepts, I'd feel slighted.

Anyway I am glad a few like Max are carrying on in that sharing spirit. It makes a whole lot more sense to me than effectively forcing the next guy to start from square one.
Reply With Quote
  #69 (permalink)  
Old 11-14-2018, 12:20 PM
Member
   
Join Date: Nov 2014
Posts: 28
Default

What would be the easiest way to pipe the audio from a tinkerboard running dietpi to a local client?
Reply With Quote
  #70 (permalink)  
Old 11-14-2018, 12:54 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Mar 2007
Location: Talbot Co, MD
Posts: 1,196
Default

Quote:
Originally Posted by telvana View Post
What would be the easiest way to pipe the audio from a tinkerboard running dietpi to a local client?
Several ways to do this assuming you are talking about running op25 on the tinkerboard.

i. Use op25's native capability to send raw udp audio frames over the network, then use the included audio.py app on the local machine to receive and play the audio. Local machine will need to be running some sort of linux distro.

ii. Set up an icecast client on the tinkerboard much like you would if you were streaming to broadcastify, but have it send the stream to a local ices server. This would allow you access to the stream from any local machine with a compliant web browser. Downside is of course the complexity of setting everything up.
Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT -5. The time now is 5:52 AM.


Powered by vBulletin® Version 3.8.2
Copyright ©2000 - 2018, vBulletin Solutions, Inc.
All information here is Copyright 2012 by RadioReference.com LLC and Lindsay C. Blanton III.Ad Management by RedTyger
Copyright 2015 by RadioReference.com LLC Privacy Policy  |  Terms and Conditions