Re: [wsjt-devel] RTTY

[Neil Zampella]

The only reason you'd add RTTY to WSJT-X is if there were some way to
improve it for weak signal work, the program and its protocols were not
designed for any other reason.   The other reason is one you overlooked
in Dave's post:

Quote:

3. Each candidate development task has an "opportunity cost". The time spent 
extending WSJT-X to support RTTY is time that can't be spent improving WSJT-X in other 
dimensions. The WSJT-X developers are in a unique position to improve their product; 
there are many other developers who can further improve RTTY applications. David and Alex 
continue to improved their applications, and MMTTY is open source.

Thus I strongly recommend that the WSJT-X team continue to apply that 
all-too-rare skill among software developers: focus.

Unquote.

Neil, KN3ILZ

On 1/14/2020 11:18 PM, Frank Kirschner wrote:



On Tue, Jan 14, 2020 at 8:23 PM Dave AA6YQ mailto:aa...@ambersoft.com>> wrote:

1. RTTY is a well-defined protocol; the result of any
modifications to this protocol would not be RTTY.


I don't understand. No one suggested modifying RTTY, just using a
better discrimination technique on the receive end.

73,
Frank
KF6E
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] RTTY

[Christoph Berg]

Re: Dwayne Sinclair 2020-01-14 <1a7fafe0-f3f3-45ff-8ec9-a0f3e1f60...@gmail.com>
> I would like to propose adding RTTY to WSJT-X for two reasons 1. As a means 
> to reframe the DXCC discussion away from FT8 itself to “it’s just a UI for 
> managing QSO’s”, and 2. I believe WSJT-X would be a great tool for RTTY. From 
> an implementation perspective it may be possible to run interval and interval 
> less with RTTY with the WSJT-X UI.

Have a look at JS8call, that's pretty close to what you have in mind.
It's FT8 with the bits carrying free text instead of the compressed
messages from the FT8 protocol.

http://js8call.com/

Christoph


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] RTTY

[David Gilbert]

What would that be?  FT8/FT4 uses a better detection scheme than RTTY 
precisely because of the constraints that FT8/FT4 require. Those 
constraints are what allow the better decoding ... there is no "magic" 
involved here.  If you lock the signal to predetermined time windows, 
use 8 tones instead of 2, and constrain the message to a narrow protocol 
you can use more effective decoding than you could otherwise.  If you 
don't do those things, you're pretty much limited to various 
sophisticated two tone filter techniques just like the current RTTY 
applications use.


Dave   AB7E


On 1/14/2020 6:18 PM, Frank Kirschner wrote:
I'm not suggesting changing the RTTY FSK standard. I'm suggesting a 
better detection scheme for the existing RTTY standard.


73,
Frank
KF6E

On Tue, Jan 14, 2020 at 7:54 PM David Gilbert 
mailto:xda...@cis-broadband.com>> wrote:



I'm not so sure it would be that easy.  All of the WSJT-X modes
require some pretty rigid rules, not the least of which is fixed
time frames closely locked to the same reference.  They also
require some pretty narrowly constrained message formats.  I
really doubt that very many current RTTY users would be willing to
give up their current flexibility.  If they were, they'd be a
whole lot better off just to migrate to FT8 or FT4.

Besides, the RTTY protocol by definition has some rather severe
limitations, only two tones being one of them.

73,
Dave   AB7E


On 1/14/2020 5:21 PM, Frank Kirschner wrote:

Dwayne,

That's what I suggested some time ago. Not only would it put all
the digital modes I use together in one program, but it would
provide an opportunity to implement a really good RTTY detection
algorithm. Some of the current programs require a very high S/N,
and with the signal processing know-how of the originators of
WSJT-X, I'm sure that could be improved upon.

73,
Frank
KF6E


On Tue, Jan 14, 2020 at 2:28 PM Dwayne Sinclair mailto:nna...@gmail.com>> wrote:

Hey all,

My background is IT infrastructure with some code development
and I although I have been active in the amateur radio
community for less than a year, given my software, IT
infrastructure background, and electronics background I have
been assisting my local amateur radio community in all
aspects of computer interfacing to radios. First off, I am
really impressed with what has been accomplished with WSJT-X
and I am an avid user of all digital protocols including FT8,
FT8 WSPR and others. I recently attended a DX Club meeting
and got to see first hand the resentment towards FT8 in the
context of DXCC awards. I never got to speak in defense of
FT8 but what I do believe is there is a basic
misunderstanding on the fact that WSJT-X’s success is much
about the interface that WSJT-X provides to managing QSO’s.
“Ease of digital use” is completely missed on much of our
older amateur radio community yet the same operators have
fully embraced RTTY as a digital protocol.

I would like to propose adding RTTY to WSJT-X for two reasons
1. As a means to reframe the DXCC discussion away from FT8
itself to “it’s just a UI for managing QSO’s”, and 2. I
believe WSJT-X would be a great tool for RTTY. From an
implementation perspective it may be possible to run interval
and interval less with RTTY with the WSJT-X UI.

Regards Dwayne Sinclair NA6US
Redondo Beach, CA



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net  
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] RTTY

[Frank Kirschner]

On Tue, Jan 14, 2020 at 8:23 PM Dave AA6YQ  wrote:

> 1. RTTY is a well-defined protocol; the result of any modifications to
> this protocol would not be RTTY.
>
>
> I don't understand. No one suggested modifying RTTY, just using a better
discrimination technique on the receive end.

73,
Frank
KF6E
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] RTTY

[Dave AA6YQ]

1. RTTY is a well-defined protocol; the result of any modifications to this 
protocol would not be RTTY.

2. Significant work has been done to improve RTTY decoding; see

https://www.rttycontesting.com/downloads/2tone/ (David G3YYD)

http://www.dxatlas.com/Gritty/  (Alex VE3NEA)

Some digital mode applications can simultaneously display the results of 
several different RTTY decoders.

3. Each candidate development task has an "opportunity cost". The time spent 
extending WSJT-X to support RTTY is time that can't be spent improving WSJT-X 
in other dimensions. The WSJT-X developers are in a unique position to improve 
their product; there are many other developers who can further improve RTTY 
applications. David and Alex continue to improved their applications, and MMTTY 
is open source.

Thus I strongly recommend that the WSJT-X team continue to apply that 
all-too-rare skill among software developers: focus.

73,

   Dave, AA6YQ






I'm not so sure it would be that easy.  All of the WSJT-X modes require some 
pretty rigid rules, not the least of which is fixed time frames closely locked 
to the same reference.  They also require some pretty narrowly constrained 
message formats.  I really doubt that very many current RTTY users would be 
willing to give up their current flexibility.  If they were, they'd be a whole 
lot better off just to migrate to FT8 or FT4.

Besides, the RTTY protocol by definition has some rather severe limitations, 
only two tones being one of them. 

73,
Dave   AB7E



On 1/14/2020 5:21 PM, Frank Kirschner wrote:


Dwayne,

That's what I suggested some time ago. Not only would it put all the 
digital modes I use together in one program, but it would provide an 
opportunity to implement a really good RTTY detection algorithm. Some of the 
current programs require a very high S/N, and with the signal processing 
know-how of the originators of WSJT-X, I'm sure that could be improved upon.

73,
Frank
KF6E



On Tue, Jan 14, 2020 at 2:28 PM Dwayne Sinclair  
wrote:


Hey all,

My background is IT infrastructure with some code development 
and I although I have been active in the amateur radio community for less than 
a year, given my software, IT infrastructure background, and electronics 
background I have been assisting my local amateur radio community in all 
aspects of computer interfacing to radios. First off, I am really impressed 
with what has been accomplished with WSJT-X and I am an avid user of all 
digital protocols including FT8, FT8 WSPR and others. I recently attended a DX 
Club meeting and got to see first hand the resentment towards FT8 in the 
context of DXCC awards. I never got to speak in defense of FT8 but what I do 
believe is there is a basic misunderstanding on the fact that WSJT-X’s success 
is much about the interface that WSJT-X provides to managing QSO’s. “Ease of 
digital use” is completely missed on much of our older amateur radio community 
yet the same operators have fully embraced RTTY as a digital protocol.

I would like to propose adding RTTY to WSJT-X for two reasons 
1. As a means to reframe the DXCC discussion away from FT8 itself to “it’s just 
a UI for managing QSO’s”, and 2. I believe WSJT-X would be a great tool for 
RTTY. From an implementation perspective it may be possible to run interval and 
interval less with RTTY with the WSJT-X UI.

Regards Dwayne Sinclair NA6US  
Redondo Beach, CA




 
 
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



 

Virus-free. www.avg.com 

   




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] RTTY

[Frank Kirschner]

I'm not suggesting changing the RTTY FSK standard. I'm suggesting a better
detection scheme for the existing RTTY standard.

73,
Frank
KF6E

On Tue, Jan 14, 2020 at 7:54 PM David Gilbert 
wrote:

>
> I'm not so sure it would be that easy.  All of the WSJT-X modes require
> some pretty rigid rules, not the least of which is fixed time frames
> closely locked to the same reference.  They also require some pretty
> narrowly constrained message formats.  I really doubt that very many
> current RTTY users would be willing to give up their current flexibility.
> If they were, they'd be a whole lot better off just to migrate to FT8 or
> FT4.
>
> Besides, the RTTY protocol by definition has some rather severe
> limitations, only two tones being one of them.
>
> 73,
> Dave   AB7E
>
>
> On 1/14/2020 5:21 PM, Frank Kirschner wrote:
>
> Dwayne,
>
> That's what I suggested some time ago. Not only would it put all the
> digital modes I use together in one program, but it would provide an
> opportunity to implement a really good RTTY detection algorithm. Some of
> the current programs require a very high S/N, and with the signal
> processing know-how of the originators of WSJT-X, I'm sure that could be
> improved upon.
>
> 73,
> Frank
> KF6E
>
>
> On Tue, Jan 14, 2020 at 2:28 PM Dwayne Sinclair  wrote:
>
>> Hey all,
>>
>> My background is IT infrastructure with some code development and I
>> although I have been active in the amateur radio community for less than a
>> year, given my software, IT infrastructure background, and electronics
>> background I have been assisting my local amateur radio community in all
>> aspects of computer interfacing to radios. First off, I am really impressed
>> with what has been accomplished with WSJT-X and I am an avid user of all
>> digital protocols including FT8, FT8 WSPR and others. I recently attended a
>> DX Club meeting and got to see first hand the resentment towards FT8 in the
>> context of DXCC awards. I never got to speak in defense of FT8 but what I
>> do believe is there is a basic misunderstanding on the fact that WSJT-X’s
>> success is much about the interface that WSJT-X provides to managing QSO’s.
>> “Ease of digital use” is completely missed on much of our older amateur
>> radio community yet the same operators have fully embraced RTTY as a
>> digital protocol.
>>
>> I would like to propose adding RTTY to WSJT-X for two reasons 1. As a
>> means to reframe the DXCC discussion away from FT8 itself to “it’s just a
>> UI for managing QSO’s”, and 2. I believe WSJT-X would be a great tool for
>> RTTY. From an implementation perspective it may be possible to run interval
>> and interval less with RTTY with the WSJT-X UI.
>>
>> Regards Dwayne Sinclair NA6US
>> Redondo Beach, CA
>>
>>
>
> ___
> wsjt-devel mailing 
> listwsjt-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] RTTY

[David Gilbert]

I'm not so sure it would be that easy.  All of the WSJT-X modes require 
some pretty rigid rules, not the least of which is fixed time frames 
closely locked to the same reference.  They also require some pretty 
narrowly constrained message formats.  I really doubt that very many 
current RTTY users would be willing to give up their current 
flexibility.  If they were, they'd be a whole lot better off just to 
migrate to FT8 or FT4.


Besides, the RTTY protocol by definition has some rather severe 
limitations, only two tones being one of them.


73,
Dave   AB7E


On 1/14/2020 5:21 PM, Frank Kirschner wrote:

Dwayne,

That's what I suggested some time ago. Not only would it put all the 
digital modes I use together in one program, but it would provide an 
opportunity to implement a really good RTTY detection algorithm. Some 
of the current programs require a very high S/N, and with the signal 
processing know-how of the originators of WSJT-X, I'm sure that could 
be improved upon.


73,
Frank
KF6E


On Tue, Jan 14, 2020 at 2:28 PM Dwayne Sinclair > wrote:


Hey all,

My background is IT infrastructure with some code development and
I although I have been active in the amateur radio community for
less than a year, given my software, IT infrastructure background,
and electronics background I have been assisting my local amateur
radio community in all aspects of computer interfacing to radios.
First off, I am really impressed with what has been accomplished
with WSJT-X and I am an avid user of all digital protocols
including FT8, FT8 WSPR and others. I recently attended a DX Club
meeting and got to see first hand the resentment towards FT8 in
the context of DXCC awards. I never got to speak in defense of FT8
but what I do believe is there is a basic misunderstanding on the
fact that WSJT-X’s success is much about the interface that WSJT-X
provides to managing QSO’s. “Ease of digital use” is completely
missed on much of our older amateur radio community yet the same
operators have fully embraced RTTY as a digital protocol.

I would like to propose adding RTTY to WSJT-X for two reasons 1.
As a means to reframe the DXCC discussion away from FT8 itself to
“it’s just a UI for managing QSO’s”, and 2. I believe WSJT-X would
be a great tool for RTTY. From an implementation perspective it
may be possible to run interval and interval less with RTTY with
the WSJT-X UI.

Regards Dwayne Sinclair NA6US
Redondo Beach, CA



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] RTTY

[Frank Kirschner]

Dwayne,

That's what I suggested some time ago. Not only would it put all the
digital modes I use together in one program, but it would provide an
opportunity to implement a really good RTTY detection algorithm. Some of
the current programs require a very high S/N, and with the signal
processing know-how of the originators of WSJT-X, I'm sure that could be
improved upon.

73,
Frank
KF6E


On Tue, Jan 14, 2020 at 2:28 PM Dwayne Sinclair  wrote:

> Hey all,
>
> My background is IT infrastructure with some code development and I
> although I have been active in the amateur radio community for less than a
> year, given my software, IT infrastructure background, and electronics
> background I have been assisting my local amateur radio community in all
> aspects of computer interfacing to radios. First off, I am really impressed
> with what has been accomplished with WSJT-X and I am an avid user of all
> digital protocols including FT8, FT8 WSPR and others. I recently attended a
> DX Club meeting and got to see first hand the resentment towards FT8 in the
> context of DXCC awards. I never got to speak in defense of FT8 but what I
> do believe is there is a basic misunderstanding on the fact that WSJT-X’s
> success is much about the interface that WSJT-X provides to managing QSO’s.
> “Ease of digital use” is completely missed on much of our older amateur
> radio community yet the same operators have fully embraced RTTY as a
> digital protocol.
>
> I would like to propose adding RTTY to WSJT-X for two reasons 1. As a
> means to reframe the DXCC discussion away from FT8 itself to “it’s just a
> UI for managing QSO’s”, and 2. I believe WSJT-X would be a great tool for
> RTTY. From an implementation perspective it may be possible to run interval
> and interval less with RTTY with the WSJT-X UI.
>
> Regards Dwayne Sinclair NA6US
> Redondo Beach, CA
>
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] RTTY

[Dwayne Sinclair]

Hey all,

My background is IT infrastructure with some code development and I although I 
have been active in the amateur radio community for less than a year, given my 
software, IT infrastructure background, and electronics background I have been 
assisting my local amateur radio community in all aspects of computer 
interfacing to radios. First off, I am really impressed with what has been 
accomplished with WSJT-X and I am an avid user of all digital protocols 
including FT8, FT8 WSPR and others. I recently attended a DX Club meeting and 
got to see first hand the resentment towards FT8 in the context of DXCC awards. 
I never got to speak in defense of FT8 but what I do believe is there is a 
basic misunderstanding on the fact that WSJT-X’s success is much about the 
interface that WSJT-X provides to managing QSO’s. “Ease of digital use” is 
completely missed on much of our older amateur radio community yet the same 
operators have fully embraced RTTY as a digital protocol.

I would like to propose adding RTTY to WSJT-X for two reasons 1. As a means to 
reframe the DXCC discussion away from FT8 itself to “it’s just a UI for 
managing QSO’s”, and 2. I believe WSJT-X would be a great tool for RTTY. From 
an implementation perspective it may be possible to run interval and interval 
less with RTTY with the WSJT-X UI.

Regards Dwayne Sinclair NA6US  
Redondo Beach, CA

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Configuration (old thread) AKA XMLRPC

[Ken]

I read the email thread from a while back with interest.

Let me add my to cents (or less). A XMLRPC interface like FLDIGI and 
FLRIG uses is implemented easily. And would allow other related 
applications (like loggers) to interface with WSJT-X. I am especially 
interested in that I am writing a logger application I have named 
qLogger that now interfaces with FLDIGI and FLRig. I would very much 
like to interface with WSJT-X in the same way.


Please consider this my vote for the XMLRPC++ modules as an addition to 
your source. I think it will be a welcome addition by me and others who 
author logging apps.


---
73 AD5XJ Ken
(985) 746-5110
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel