Re: [wsjt-devel] Using WSJT-X Decoding Technique with RTTY

2019-01-03 Thread n2lo 
Ft8 is 8 tone fsk. Rtty is 2 tone fsk. At the phys layer.We would use a log periodic horz on one rcvr and string a vert on the second rcvr to a diversity demod.Sent from Xfinity Connect Application-Original Message-From: n...@comcast.netTo: pat.9a...@gmail.com, fr...@fkirschner.net, wsjt-devel@lists.sourceforge.netSent: 2019-01-03 11:48:00 AM Subject: Re: [wsjt-devel] Using WSJT-X Decoding Technique with RTTYIs manchester fsk rtty legal on ham bands?Sent from Xfinity Connect Application-Original Message-From: pat.9a...@gmail.comTo: fr...@fkirschner.net, wsjt-devel@lists.sourceforge.netSent: 2019-01-03 11:42:29 AM Subject: Re: [wsjt-devel] Using WSJT-X Decoding Technique with RTTYHi Frank,You can try to download 2Tone for RTTY.So far best decoder was made for MSDOS by K6STI Bitty and Ritty. That was better than any Windows or so RTTY software nowdays.Best 73Patrik 9A5CW Datuma čet, 3. sij 2019. 17:14 Frank Kirschner  wrote:On 03/01/2019 15:33, Frank Kirschner wrote:
> Many years ago, I had a home-brew RTTY TU. It had two 88 mH torroids 
> in the tuned circuits and a differential amplifier as a detector. 
> Occasionally, the received signal would fade below the noise, but the 
> Kleinschmidt teleprinter would keep printing the decoded text. I have 
> tried several current software packages for decoding RTTY signals, and 
> all of them require quite strong signals to decode at all, and very 
> strong signals to provide 100% print.
>
> I was wondering if the decoding method used in WSJT-X for FT8 could be 
> ported to a RTTY decoder. I realize that FT8 has a lower symbol rate, 
> which provides more time to integrate, and incorporates redundancy, 
> which improves accuracy. But the theoretical lower limit for decoding 
> RTTY is something like -5 dB S/N, and the current programs are nowhere 
> near that.
>
> If RTTY facilities could be integrated with WSJT-X, not only would the 
> decoding be better, but the log scanning functions of WSJT-X and 
> JTAlert would be better, significantly improving contest operation.
>
> I confess I haven't looked at the decoding techniques used by RTTY 
> software, but I suspect, based on performance, that it could be improved.
>
> 73,
> Frank
> KF6E
>
Hi Frank,

this is well covered ground, some existing Baudot decoders have very 
good performance with built in weak and fading signal models to optimize 
them.

The techniques used to decode FT8 are based around a block message 
format that includes parity bits and checksums for advanced forward 
error detection and correction, Baudot is a character based stream code 
with no forward error correction capability. RTTY was designed for an 
era where automation was mechanical and quite limited, just having a 
code that could be used to modulate a transmitter and be printed by a 
receiver was about the sum of the technical design. RTTY's *only* 
similarity with FT8 is that it is a frequency shift keyed constant 
amplitude signal. Even the simplest addition of a single parity bit to 
detect, but not correct, single bit errors would need a fundamental 
non-backwards compatible change to the Baudot code.

73
Bill
G4WJS.



___
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] Using WSJT-X Decoding Technique with RTTY

2019-01-03 Thread Frank Kirschner 
Thanks. I'll try that.

73,
Frank
KF6E

On Thu, Jan 3, 2019, 11:42 Patrick 9A5CW  Hi Frank,
> You can try to download 2Tone for RTTY.
> So far best decoder was made for MSDOS by K6STI Bitty and Ritty. That was
> better than any Windows or so RTTY software nowdays.
>
> Best 73
> Patrik 9A5CW
>
>
> Datuma čet, 3. sij 2019. 17:14 Frank Kirschner  piše:
>
>> Hi, Bill,
>>
>> Thanks for your reply.
>>
>> I wasn't suggesting a change to the standard for RTTY, which, of course,
>> would be impossible at this point. I was pointing out that the software I
>> have used to decode RTTY is nowhere close to the theoretical limit, or even
>> the hardware discriminator I built years ago. DM780 and MMTTY, the two
>> programs I remember using, require very high signal to noise ratios to
>> provide even moderately good decoding.
>>
>> Do you have a recommendation on software that might perform better than
>> what I am using?
>>
>> I first used RTTY in the late 1960s, when I had my home-brew TU and a
>> Kleinschmidt teleprinter, so I'm familiar with the electro-mechanical
>> technology for which Baudot code was designed. I designed a weather
>> collection network for Thailand in the early 1970s that used mechanical
>> teleprinters and prepared tape messages. It was a bit of a kluge, but it
>> worked for years.
>>
>> 73,
>> Frank
>> KF6E
>>
>> On Thu, Jan 3, 2019 at 10:52 AM Bill Somerville 
>> wrote:
>>
>>> On 03/01/2019 15:33, Frank Kirschner wrote:
>>> > Many years ago, I had a home-brew RTTY TU. It had two 88 mH torroids
>>> > in the tuned circuits and a differential amplifier as a detector.
>>> > Occasionally, the received signal would fade below the noise, but the
>>> > Kleinschmidt teleprinter would keep printing the decoded text. I have
>>> > tried several current software packages for decoding RTTY signals, and
>>> > all of them require quite strong signals to decode at all, and very
>>> > strong signals to provide 100% print.
>>> >
>>> > I was wondering if the decoding method used in WSJT-X for FT8 could be
>>> > ported to a RTTY decoder. I realize that FT8 has a lower symbol rate,
>>> > which provides more time to integrate, and incorporates redundancy,
>>> > which improves accuracy. But the theoretical lower limit for decoding
>>> > RTTY is something like -5 dB S/N, and the current programs are nowhere
>>> > near that.
>>> >
>>> > If RTTY facilities could be integrated with WSJT-X, not only would the
>>> > decoding be better, but the log scanning functions of WSJT-X and
>>> > JTAlert would be better, significantly improving contest operation.
>>> >
>>> > I confess I haven't looked at the decoding techniques used by RTTY
>>> > software, but I suspect, based on performance, that it could be
>>> improved.
>>> >
>>> > 73,
>>> > Frank
>>> > KF6E
>>> >
>>> Hi Frank,
>>>
>>> this is well covered ground, some existing Baudot decoders have very
>>> good performance with built in weak and fading signal models to optimize
>>> them.
>>>
>>> The techniques used to decode FT8 are based around a block message
>>> format that includes parity bits and checksums for advanced forward
>>> error detection and correction, Baudot is a character based stream code
>>> with no forward error correction capability. RTTY was designed for an
>>> era where automation was mechanical and quite limited, just having a
>>> code that could be used to modulate a transmitter and be printed by a
>>> receiver was about the sum of the technical design. RTTY's *only*
>>> similarity with FT8 is that it is a frequency shift keyed constant
>>> amplitude signal. Even the simplest addition of a single parity bit to
>>> detect, but not correct, single bit errors would need a fundamental
>>> non-backwards compatible change to the Baudot code.
>>>
>>> 73
>>> Bill
>>> G4WJS.
>>>
>>>
>>>
>>> ___
>>> 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] Using WSJT-X Decoding Technique with RTTY

2019-01-03 Thread n2lo 
Is manchester fsk rtty legal on ham bands?Sent from Xfinity Connect Application-Original Message-From: pat.9a...@gmail.comTo: fr...@fkirschner.net, wsjt-devel@lists.sourceforge.netSent: 2019-01-03 11:42:29 AM Subject: Re: [wsjt-devel] Using WSJT-X Decoding Technique with RTTYHi Frank,You can try to download 2Tone for RTTY.So far best decoder was made for MSDOS by K6STI Bitty and Ritty. That was better than any Windows or so RTTY software nowdays.Best 73Patrik 9A5CW Datuma čet, 3. sij 2019. 17:14 Frank Kirschner  wrote:On 03/01/2019 15:33, Frank Kirschner wrote:
> Many years ago, I had a home-brew RTTY TU. It had two 88 mH torroids 
> in the tuned circuits and a differential amplifier as a detector. 
> Occasionally, the received signal would fade below the noise, but the 
> Kleinschmidt teleprinter would keep printing the decoded text. I have 
> tried several current software packages for decoding RTTY signals, and 
> all of them require quite strong signals to decode at all, and very 
> strong signals to provide 100% print.
>
> I was wondering if the decoding method used in WSJT-X for FT8 could be 
> ported to a RTTY decoder. I realize that FT8 has a lower symbol rate, 
> which provides more time to integrate, and incorporates redundancy, 
> which improves accuracy. But the theoretical lower limit for decoding 
> RTTY is something like -5 dB S/N, and the current programs are nowhere 
> near that.
>
> If RTTY facilities could be integrated with WSJT-X, not only would the 
> decoding be better, but the log scanning functions of WSJT-X and 
> JTAlert would be better, significantly improving contest operation.
>
> I confess I haven't looked at the decoding techniques used by RTTY 
> software, but I suspect, based on performance, that it could be improved.
>
> 73,
> Frank
> KF6E
>
Hi Frank,

this is well covered ground, some existing Baudot decoders have very 
good performance with built in weak and fading signal models to optimize 
them.

The techniques used to decode FT8 are based around a block message 
format that includes parity bits and checksums for advanced forward 
error detection and correction, Baudot is a character based stream code 
with no forward error correction capability. RTTY was designed for an 
era where automation was mechanical and quite limited, just having a 
code that could be used to modulate a transmitter and be printed by a 
receiver was about the sum of the technical design. RTTY's *only* 
similarity with FT8 is that it is a frequency shift keyed constant 
amplitude signal. Even the simplest addition of a single parity bit to 
detect, but not correct, single bit errors would need a fundamental 
non-backwards compatible change to the Baudot code.

73
Bill
G4WJS.



___
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] Using WSJT-X Decoding Technique with RTTY

2019-01-03 Thread Patrick 9A5CW 
Hi Frank,
You can try to download 2Tone for RTTY.
So far best decoder was made for MSDOS by K6STI Bitty and Ritty. That was
better than any Windows or so RTTY software nowdays.

Best 73
Patrik 9A5CW


Datuma čet, 3. sij 2019. 17:14 Frank Kirschner  Hi, Bill,
>
> Thanks for your reply.
>
> I wasn't suggesting a change to the standard for RTTY, which, of course,
> would be impossible at this point. I was pointing out that the software I
> have used to decode RTTY is nowhere close to the theoretical limit, or even
> the hardware discriminator I built years ago. DM780 and MMTTY, the two
> programs I remember using, require very high signal to noise ratios to
> provide even moderately good decoding.
>
> Do you have a recommendation on software that might perform better than
> what I am using?
>
> I first used RTTY in the late 1960s, when I had my home-brew TU and a
> Kleinschmidt teleprinter, so I'm familiar with the electro-mechanical
> technology for which Baudot code was designed. I designed a weather
> collection network for Thailand in the early 1970s that used mechanical
> teleprinters and prepared tape messages. It was a bit of a kluge, but it
> worked for years.
>
> 73,
> Frank
> KF6E
>
> On Thu, Jan 3, 2019 at 10:52 AM Bill Somerville 
> wrote:
>
>> On 03/01/2019 15:33, Frank Kirschner wrote:
>> > Many years ago, I had a home-brew RTTY TU. It had two 88 mH torroids
>> > in the tuned circuits and a differential amplifier as a detector.
>> > Occasionally, the received signal would fade below the noise, but the
>> > Kleinschmidt teleprinter would keep printing the decoded text. I have
>> > tried several current software packages for decoding RTTY signals, and
>> > all of them require quite strong signals to decode at all, and very
>> > strong signals to provide 100% print.
>> >
>> > I was wondering if the decoding method used in WSJT-X for FT8 could be
>> > ported to a RTTY decoder. I realize that FT8 has a lower symbol rate,
>> > which provides more time to integrate, and incorporates redundancy,
>> > which improves accuracy. But the theoretical lower limit for decoding
>> > RTTY is something like -5 dB S/N, and the current programs are nowhere
>> > near that.
>> >
>> > If RTTY facilities could be integrated with WSJT-X, not only would the
>> > decoding be better, but the log scanning functions of WSJT-X and
>> > JTAlert would be better, significantly improving contest operation.
>> >
>> > I confess I haven't looked at the decoding techniques used by RTTY
>> > software, but I suspect, based on performance, that it could be
>> improved.
>> >
>> > 73,
>> > Frank
>> > KF6E
>> >
>> Hi Frank,
>>
>> this is well covered ground, some existing Baudot decoders have very
>> good performance with built in weak and fading signal models to optimize
>> them.
>>
>> The techniques used to decode FT8 are based around a block message
>> format that includes parity bits and checksums for advanced forward
>> error detection and correction, Baudot is a character based stream code
>> with no forward error correction capability. RTTY was designed for an
>> era where automation was mechanical and quite limited, just having a
>> code that could be used to modulate a transmitter and be printed by a
>> receiver was about the sum of the technical design. RTTY's *only*
>> similarity with FT8 is that it is a frequency shift keyed constant
>> amplitude signal. Even the simplest addition of a single parity bit to
>> detect, but not correct, single bit errors would need a fundamental
>> non-backwards compatible change to the Baudot code.
>>
>> 73
>> Bill
>> G4WJS.
>>
>>
>>
>> ___
>> 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] Using WSJT-X Decoding Technique with RTTY

2019-01-03 Thread Frank Kirschner 
Hi, Bill,

Thanks for your reply.

I wasn't suggesting a change to the standard for RTTY, which, of course,
would be impossible at this point. I was pointing out that the software I
have used to decode RTTY is nowhere close to the theoretical limit, or even
the hardware discriminator I built years ago. DM780 and MMTTY, the two
programs I remember using, require very high signal to noise ratios to
provide even moderately good decoding.

Do you have a recommendation on software that might perform better than
what I am using?

I first used RTTY in the late 1960s, when I had my home-brew TU and a
Kleinschmidt teleprinter, so I'm familiar with the electro-mechanical
technology for which Baudot code was designed. I designed a weather
collection network for Thailand in the early 1970s that used mechanical
teleprinters and prepared tape messages. It was a bit of a kluge, but it
worked for years.

73,
Frank
KF6E

On Thu, Jan 3, 2019 at 10:52 AM Bill Somerville 
wrote:

> On 03/01/2019 15:33, Frank Kirschner wrote:
> > Many years ago, I had a home-brew RTTY TU. It had two 88 mH torroids
> > in the tuned circuits and a differential amplifier as a detector.
> > Occasionally, the received signal would fade below the noise, but the
> > Kleinschmidt teleprinter would keep printing the decoded text. I have
> > tried several current software packages for decoding RTTY signals, and
> > all of them require quite strong signals to decode at all, and very
> > strong signals to provide 100% print.
> >
> > I was wondering if the decoding method used in WSJT-X for FT8 could be
> > ported to a RTTY decoder. I realize that FT8 has a lower symbol rate,
> > which provides more time to integrate, and incorporates redundancy,
> > which improves accuracy. But the theoretical lower limit for decoding
> > RTTY is something like -5 dB S/N, and the current programs are nowhere
> > near that.
> >
> > If RTTY facilities could be integrated with WSJT-X, not only would the
> > decoding be better, but the log scanning functions of WSJT-X and
> > JTAlert would be better, significantly improving contest operation.
> >
> > I confess I haven't looked at the decoding techniques used by RTTY
> > software, but I suspect, based on performance, that it could be improved.
> >
> > 73,
> > Frank
> > KF6E
> >
> Hi Frank,
>
> this is well covered ground, some existing Baudot decoders have very
> good performance with built in weak and fading signal models to optimize
> them.
>
> The techniques used to decode FT8 are based around a block message
> format that includes parity bits and checksums for advanced forward
> error detection and correction, Baudot is a character based stream code
> with no forward error correction capability. RTTY was designed for an
> era where automation was mechanical and quite limited, just having a
> code that could be used to modulate a transmitter and be printed by a
> receiver was about the sum of the technical design. RTTY's *only*
> similarity with FT8 is that it is a frequency shift keyed constant
> amplitude signal. Even the simplest addition of a single parity bit to
> detect, but not correct, single bit errors would need a fundamental
> non-backwards compatible change to the Baudot code.
>
> 73
> Bill
> G4WJS.
>
>
>
> ___
> 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] Using WSJT-X Decoding Technique with RTTY

2019-01-03 Thread Bill Somerville 

On 03/01/2019 15:33, Frank Kirschner wrote:
Many years ago, I had a home-brew RTTY TU. It had two 88 mH torroids 
in the tuned circuits and a differential amplifier as a detector. 
Occasionally, the received signal would fade below the noise, but the 
Kleinschmidt teleprinter would keep printing the decoded text. I have 
tried several current software packages for decoding RTTY signals, and 
all of them require quite strong signals to decode at all, and very 
strong signals to provide 100% print.


I was wondering if the decoding method used in WSJT-X for FT8 could be 
ported to a RTTY decoder. I realize that FT8 has a lower symbol rate, 
which provides more time to integrate, and incorporates redundancy, 
which improves accuracy. But the theoretical lower limit for decoding 
RTTY is something like -5 dB S/N, and the current programs are nowhere 
near that.


If RTTY facilities could be integrated with WSJT-X, not only would the 
decoding be better, but the log scanning functions of WSJT-X and 
JTAlert would be better, significantly improving contest operation.


I confess I haven't looked at the decoding techniques used by RTTY 
software, but I suspect, based on performance, that it could be improved.


73,
Frank
KF6E


Hi Frank,

this is well covered ground, some existing Baudot decoders have very 
good performance with built in weak and fading signal models to optimize 
them.


The techniques used to decode FT8 are based around a block message 
format that includes parity bits and checksums for advanced forward 
error detection and correction, Baudot is a character based stream code 
with no forward error correction capability. RTTY was designed for an 
era where automation was mechanical and quite limited, just having a 
code that could be used to modulate a transmitter and be printed by a 
receiver was about the sum of the technical design. RTTY's *only* 
similarity with FT8 is that it is a frequency shift keyed constant 
amplitude signal. Even the simplest addition of a single parity bit to 
detect, but not correct, single bit errors would need a fundamental 
non-backwards compatible change to the Baudot code.


73
Bill
G4WJS.



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

[wsjt-devel] Using WSJT-X Decoding Technique with RTTY

2019-01-03 Thread Frank Kirschner 
Many years ago, I had a home-brew RTTY TU. It had two 88 mH torroids in the
tuned circuits and a differential amplifier as a detector. Occasionally,
the received signal would fade below the noise, but the Kleinschmidt
teleprinter would keep printing the decoded text. I have tried several
current software packages for decoding RTTY signals, and all of them
require quite strong signals to decode at all, and very strong signals to
provide 100% print.

I was wondering if the decoding method used in WSJT-X for FT8 could be
ported to a RTTY decoder. I realize that FT8 has a lower symbol rate, which
provides more time to integrate, and incorporates redundancy, which
improves accuracy. But the theoretical lower limit for decoding RTTY is
something like -5 dB S/N, and the current programs are nowhere near that.

If RTTY facilities could be integrated with WSJT-X, not only would the
decoding be better, but the log scanning functions of WSJT-X and JTAlert
would be better, significantly improving contest operation.

I confess I haven't looked at the decoding techniques used by RTTY
software, but I suspect, based on performance, that it could be improved.

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