[RTTY] A repository of (poor) RTTY recordings?

[Richard Ferch]

On Wed, 21 Apr 2004 19:28:27 -0700 Bill Turner wrote:


>With all due respect Richard, I think it does matter what the text is.
>
>Which of the following would be easier to find errors in:
>
>GMANCUDKLJERJKSLVJNWFKJDBSDFHUHVADFQQJFAJDKD
>LKJDFKSDVUJBERBALKDVJIDHFLQJEFLKDJBLKKFDJALH
>
>or
>
>RYRY RYRY RYRY RYRY RYRY RYRY RYRY RYRY RYRY
>RYRY RYRY RYRY RYRY RYRY RYRY RYRY RYRY RYRY ?
>
>As for the FIGS/LTRS characters, I don't see any particular need for
>them in this exercise.  If a bit flip type of corruption is going to
>occur, it only matters that we are easily able to detect it, not which
>character it occurs in.  Am I wrong?

Hi Bill,

Why do the error-checking by hand when you have a computer to do it for 
you? It makes no difference to a computer whether the text is 
plain-language or random.

I am not convinced that all characters are equally susceptible to errors, 
i.e. that all errors are simple one-bit flips at random times. If some bit 
patterns are more (or less) susceptible to some kinds of errors than other 
bit patterns, then wouldn't we want our test text to include both types of 
bit pattern? I am thinking of strings of consecutive identical bits (as in 
letters like E, K, T and V) versus strings of alternating bits (as in RYRY) 
under selective fading conditions, for example.

I think you are right about the FIGS/LTRS though. My thought was to try to 
use a text that is representative of the patterns we actually use 
(especially during contests), but upon further reflection, the FIGS/LTRS 
codes introduce a source of confusion. Errors in these codes can persist 
over several characters, i.e. an error that happens to occur during a 
FIGS/LTRS code will result in several following characters being miscopied 
as well. The computer can be programmed to detect this and compensate for 
it, but it would be easier not to have to deal with this special case. 
Also, what we are trying to measure is the raw copying accuracy of the 
software or hardware under test, not how graciously it recovers from 
FIGS/LTRS errors. That is also an important feature for real life use, but 
it is a separate effect and should be tested for separately.

It would be easy to write a program to compare two files, count the errors, 
and display the error count. Optionally, it could be programmed to display 
the badly-copied file with the errors highlighted in some way. The program 
could be stored on the same web site that the RTTY recordings are stored on.

In fact, there is built-in software in Windows to do the file comparison 
part of the job. Here is a demonstration.

I created two short text files. One was:

PACK MY BOX WITH FIUF DOZEN LJOUOP JUGS
PACK MY B0X WITH F1VE DO2EN LIQUOR JUGS
PACK MY BOX WITH FIVE DOZEN LIQUOR JUGS
RACK MY BOX WITH FIVE DOZEN LIQUOR JUGS
PACK MY BOX WITH FIVE DOZEN LIQUOR JUGS

and the other was the same text without the errors.

I then opened a Command Prompt window (DOS window), moved to the correct 
directory, and typed:

FC /B file1.txt file2.txt

and the computer instantly came up with nine errors. A lot easier (and much 
less error-prone) than finding them manually. The tool is clumsy - I had to 
count the error messages, but they were one to a line, so that wasn't very 
hard. If I had used

FC /B file1.txt file2.txt >errors.txt

then I could have used a text editor to count the error messages.

73,
Rich VE3IAY