Digital modes in SDRSharp? #poll-notice


Ondřej Povalač
 

I would be interested in your opinion on adding digital modulation types directly to SDRSharp. Digital modes like DMR, D-STAR, P25, NXDN, YSF and others are already as common as FM, AM, SSB or CW.
I know there are external plugins available to decode digital modes, but direct implementation into SDRSharp would take this program to the next level. I suppose if digital mode decoding is functional as a plugin, it should be technically feasible to implement it in SDRSharp.
 
What is your opinion about direct implementation of digital modes directly into SDRSharp?

Thank you for your time.

Results

See Who Responded


Pietro Molina
 

Imho the goal would be a plugin that simulate a sound device, so I can switch quickly wsjt or other SW to using as input the output of sdr# without having to fight with Windows sound system...

Pietro I2OIM


Dale Elshoff WB8CJW
 

May I recommend a separate sound device.  I am using a Sabrent Audio dongle (USB Audio Device) $8 US that I have dedicated to JTDX and WSJT-x for audio in and out.  This makes it independent of the system sound settings and prevents system alert sounds from being sent to the transmitter.
 

On 8/4/2021 9:45 AM, Pietro Molina wrote:
Imho the goal would be a plugin that simulate a sound device, so I can switch quickly wsjt or other SW to using as input the output of sdr# without having to fight with Windows sound system...

Pietro I2OIM


h. garcia
 

Hi Ondrej, good morning.

Could you please clarify what's you role in the context of SDRSharp? Are you core or plug-in developer? End-user? Etc...

Though I found the poll interesting, it would only make sense to people involved with SDR-Sharp development (either core or plugins) to help them narrow down their effort/product focus.

Having polls like these may create the wrong expectations in the user base, unless it's clear how the results will be used for.

73,

pu3hag



On Wed, Aug 4, 2021 at 6:29 AM Ondřej Povalač <ondrej@...> wrote:

A new poll has been created:

I would be interested in your opinion on adding digital modulation types directly to SDRSharp. Digital modes like DMR, D-STAR, P25, NXDN, YSF and others are already as common as FM, AM, SSB or CW.
I know there are external plugins available to decode digital modes, but direct implementation into SDRSharp would take this program to the next level. I suppose if digital mode decoding is functional as a plugin, it should be technically feasible to implement it in SDRSharp.
 
What is your opinion about direct implementation of digital modes directly into SDRSharp?

Thank you for your time.

1. Digital mode decoding should be implemented directly in SDRSharp
2. Digital mode decoding should remain available only as a plugin
3. I don't use SDRSharp to receive and decode digital modes

Vote Now

Do not reply to this message to vote in the poll. You can vote in polls only through the group's website.


Pietro Molina
 

Dale, me too. 
But audio coming from sdr# has not to rely with that, or you have a suggest to forward the audio coming from wsjt (only) to a different SW? 
 
Pietro I2OIM


Shirley Dulcey KE1L
 

Although this would be a great thing to see, the licensing terms for the voice codecs might make it impossible. The plugins either require you to have a dongle that contains a DVSI chip, or use implementations of the voice codecs that are not authorized by DVSI, the patent holder of the various AMBE codecs used by those digital voice modes.


Joe M.
 

While SDR# is great, I would rather Youssef focus on making the receiving code better rather than add potentially hundreds of decoding algorithms that are better handled by third parties. The one thing I would like to see is a built-in AUX output that can feed those other programs. This output would have a level control independent of the main volume (speaker) and would have a control to mute that output and be able to specify the output destination (such as VB Cable). Given the slices, several AUX outputs would be ideal.

Leave the decoding to more experienced others who may be able to do it better. DSD+, for example, is code that Youssef should not be diving into since it involves potentially infringing code. That is how everything becomes better rather than add to Youssef's pile of work. That will also free his time to design even better hardware. Share the load.

Joe M.

On 8/4/2021 3:56 AM, Ondřej Povalač wrote:
A new poll has been created:

I would be interested in your opinion on adding digital modulation types
directly to SDRSharp. Digital modes like DMR, D-STAR, P25, NXDN, YSF and
others are already as common as FM, AM, SSB or CW.
I know there are external plugins available to decode digital modes, but
direct implementation into SDRSharp would take this program to the next
level. I suppose if digital mode decoding is functional as a plugin, it
should be technically feasible to implement it in SDRSharp.
*What is your opinion about direct implementation of digital modes
directly into SDRSharp?*

Thank you for your time.

1. Digital mode decoding should be implemented directly in SDRSharp
2. Digital mode decoding should remain available only as a plugin
3. I don't use SDRSharp to receive and decode digital modes

Vote Now <https://groups.io/g/airspy/vote?pollid=23692>

Do not reply to this message to vote in the poll. You can vote in polls
only through the group's website.


Pietro Molina
 

Sorry, I misinterpreted "digital mode" and ready carelessly... I change my vote.

P. I2OIM


Ken Alexander
 

Amen!  No to bloatware.

Ken  VE3HLS

On Wed, Aug 4, 2021, 23:07 Joe M. <mch@...> wrote:
While SDR# is great, I would rather Youssef focus on making the
receiving code better rather than add potentially hundreds of decoding
algorithms that are better handled by third parties. The one thing I
would like to see is a built-in AUX output that can feed those other
programs. This output would have a level control independent of the main
volume (speaker) and would have a control to mute that output and be
able to specify the output destination (such as VB Cable). Given the
slices, several AUX outputs would be ideal.

Leave the decoding to more experienced others who may be able to do it
better. DSD+, for example, is code that Youssef should not be diving
into since it involves potentially infringing code. That is how
everything becomes better rather than add to Youssef's pile of work.
That will also free his time to design even better hardware. Share the load.

Joe M.

On 8/4/2021 3:56 AM, Ondřej Povalač wrote:
> A new poll has been created:
>
> I would be interested in your opinion on adding digital modulation types
> directly to SDRSharp. Digital modes like DMR, D-STAR, P25, NXDN, YSF and
> others are already as common as FM, AM, SSB or CW.
> I know there are external plugins available to decode digital modes, but
> direct implementation into SDRSharp would take this program to the next
> level. I suppose if digital mode decoding is functional as a plugin, it
> should be technically feasible to implement it in SDRSharp.
> *What is your opinion about direct implementation of digital modes
> directly into SDRSharp?*
>
> Thank you for your time.
>
> 1. Digital mode decoding should be implemented directly in SDRSharp
> 2. Digital mode decoding should remain available only as a plugin
> 3. I don't use SDRSharp to receive and decode digital modes
>
> Vote Now <https://groups.io/g/airspy/vote?pollid=23692>
>
> Do not reply to this message to vote in the poll. You can vote in polls
> only through the group's website.
>
>






Dr.Thamminana KR
 

Thanks... 

I am End User only.

Dr.Thamminana KR

On Wed, 4 Aug, 2021, 7:38 pm h. garcia, <pu3hag.l@...> wrote:
Hi Ondrej, good morning.

Could you please clarify what's you role in the context of SDRSharp? Are you core or plug-in developer? End-user? Etc...

Though I found the poll interesting, it would only make sense to people involved with SDR-Sharp development (either core or plugins) to help them narrow down their effort/product focus.

Having polls like these may create the wrong expectations in the user base, unless it's clear how the results will be used for.

73,

pu3hag



On Wed, Aug 4, 2021 at 6:29 AM Ondřej Povalač <ondrej@...> wrote:

A new poll has been created:

I would be interested in your opinion on adding digital modulation types directly to SDRSharp. Digital modes like DMR, D-STAR, P25, NXDN, YSF and others are already as common as FM, AM, SSB or CW.
I know there are external plugins available to decode digital modes, but direct implementation into SDRSharp would take this program to the next level. I suppose if digital mode decoding is functional as a plugin, it should be technically feasible to implement it in SDRSharp.
 
What is your opinion about direct implementation of digital modes directly into SDRSharp?

Thank you for your time.

1. Digital mode decoding should be implemented directly in SDRSharp
2. Digital mode decoding should remain available only as a plugin
3. I don't use SDRSharp to receive and decode digital modes

Vote Now

Do not reply to this message to vote in the poll. You can vote in polls only through the group's website.


Ondřej Povalač
 

Hi, I am end user only.
I was just curious how others feel about the future of digital vs analog regarding SDR devices in general.

However, I think it should be possible, if a skilled programmer invests his time and effort. To know whether it makes sense to ask for this feature, i created this pool... because maybe it is not important for many users.

Regards, Ondrej


Ondřej Povalač
 

I was expecting it is possible via software only - the DSD+ does them all... but I am not sure whether the DSD+ is OK when it comes to licensing...


Greg Ella
 

Encryption is not allowed in US Amateur Radio (except for spacecraft control).
The argument has been made that proprietary voice codecs that require a license
become de facto encryption, illegal for US Amateur Radio use.  In response to
this, there has been discussion of the vendors providing license free receive only
codecs, free of charge, for listening.  I think one of the protocols (D-Star?), has
already done this.

Greg Ella
N0EMP


On Wed, Aug 4, 2021 at 3:30 PM Ondřej Povalač <ondrej@...> wrote:
I was expecting it is possible via software only - the DSD+ does them all... but I am not sure whether the DSD+ is OK when it comes to licensing...


Joe M.
 

Yes, DSD+ does them all (voice decoding). So why not use that?

If you question the legality, try to identify the
author. There is a reason he remains *highly* anonymous.

Even if you pay for the Fast Lane releases,
you are paying less than the cost of licenses.

That is but one example of third party support being more effective.
If Youssef were to add that code to SDR#, that would be the end of SDR#.

As much as Youssef has issues with people who steal his
code, I doubt he will be willing to walk that same path.

Joe M.

On 8/4/2021 5:30 PM, Ondřej Povalač wrote:
I was expecting it is possible via software only - the DSD+ does them
all... but I am not sure whether the DSD+ is OK when it comes to
licensing...


Dale Elshoff WB8CJW
 

Hi Pietro,

I am using the virtual audio cable VB-Cable (https://vb-audio.com/Cable/) for hf audio from SDR Console or SDRSharp.  For FT8 I use a transceiver on 2m and select the audio source in JTDX/WSJT-x from the Sabrent usb module.  See picture attached.  Levels are set in the sound control panel.

The Windows audio mixer can be used instead of a virtual cable.  The VB-Audio setup is so easy I haven't used the Windows mixer for some time.  When I started using Windows 10 I later found out after installing VB the system mixer is just "hidden" and has to be enabled to use.

Sorry I took so long to reply.  Was getting a shingles vaccine so hopefully I won't have to deal with that again (3rd time).

73,

Dale WB8CJW


On 8/4/2021 10:11 AM, Pietro Molina wrote:
Dale, me too. 
But audio coming from sdr# has not to rely with that, or you have a suggest to forward the audio coming from wsjt (only) to a different SW? 
 
Pietro I2OIM


Bob Dengler
 

At 8/4/2021 03:57 PM, you wrote:
Yes, DSD+ does them all (voice decoding). So why not use that?

If you question the legality, try to identify the
author. There is a reason he remains *highly* anonymous.

Even if you pay for the Fast Lane releases,
you are paying less than the cost of licenses.
W.r.t. DSD the codecs are reverse-engineered, so there's no license involved. If this was illegal, I'd seriously question the legality of the use of any DV mode encumbered by such licensing on amateur frequencies, at least in the U.S. In that case, the question of integrating the decoding of DV modes into SDR# is moot.

Bob NO6B


David J Taylor
 

On 04/08/2021 17:06, Joe M. wrote:
While SDR# is great, I would rather Youssef focus on making the
receiving code better rather than add potentially hundreds of decoding
algorithms that are better handled by third parties. The one thing I
would like to see is a built-in AUX output that can feed those other
programs. This output would have a level control independent of the main
volume (speaker) and would have a control to mute that output and be
able to specify the output destination (such as VB Cable). Given the
slices, several AUX outputs would be ideal.
Leave the decoding to more experienced others who may be able to do it
better. DSD+, for example, is code that Youssef should not be diving
into since it involves potentially infringing code. That is how
everything becomes better rather than add to Youssef's pile of work.
That will also free his time to design even better hardware. Share the load.
Joe M.
Agreed!

Whilst I can see the potential attraction of a monster does-it-all program, the examples I've seen so far end up needing a training course for first-time users.

Keep the main program as simple as possible, and let those more expert in the decoding provide that in plug-ins.

David
--
SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv


prog
 

Maybe just a new demodulator API that integrates seamlessly in the GUI. Plugins can add whatever they want and it's the responsibility of their authors.
Btw, I have been contacted by the M17 project for integrating their codec in SDR#. I am more than happy to have it available for all the supported devices, but the time is lacking... Anyone interested in building a plugin for it? I can assist privately if needed. This is 100% legal. 


Zacharias Liangas
 

I also agree in that the program can support digital decode via external programs or via plugin. 
For an avid SW DX er or radioamateur hese modes could've for interest
Morse
Fax
SSTV
FSk and MFSK
these are the most basic while there are more than 35 formats available


Ondřej Povalač
 

Although I would like to see digital modes implemented directly in SDRSharp, I agree that it would be very helpful if SDRSharp implemented at least a function to route a secondary unfiltered audio stream to a virtual soundcard. That would help a lot.