RTTY
[Top] [All Lists]

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

To: rtty@contesting.com
Subject: Re: [RTTY] A repository of (poor) RTTY recordings?
From: Richard Ferch <ve3iay@rac.ca>
Date: Thu, 22 Apr 2004 07:00:48 -0400
List-post: <mailto:rtty@contesting.com>
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






_______________________________________________ RTTY mailing list RTTY@contesting.com http://lists.contesting.com/mailman/listinfo/rtty

<Prev in Thread] Current Thread [Next in Thread>