N2EY:

Oh, we are talking about MUCH MORE than RTTY...

Not even close... RTTY is dead... but some dead languages are still
spoken, no surprise. Look at how long Latin was a dead language, but
still pressed to service the the catholic church...

John

On Thu, 04 Aug 2005 09:24:21 -0700, N2EY wrote:

What you folks are describing is just a form of RTTY using Morse Code
as the
encoding method, rather than ASCII or Baudot or some other scheme.

Of course it can be done, and has been done. Why it would be done is
another
issue. It is certainly not a "better way".

Consider a bicycle. If another wheel is added, the rider doesn't need
to worry about falling over, so the skill required to ride it is
greatly reduced.
Add a small gasoline engine and a suitable transmission, and
pedaling becomes much easier. A simple cover will protect the rider
from rain
and other inclement weather.

Eventually you wind up with a small, three-wheeled automobile that
could win
the Tour de France. Except it's not a bicycle anymore, and its rider
isn't
a cyclist by any stretch of the imagination.

Or consider the piano. Pianos and similar keyboard instruments have
been around
for hundreds of years. It takes considerable skill and practice to play
them, and
reading sheet music is a skill of its own.

With modern computers and software, however, one can simply have a
machine that
scans in the sheet music and turns it into a "performance" - without
all those
lessons, practice, etc.

There are many such analogies. But they are lost on some people - those
who
Shaw described as "knowing the price of everything and the value of
nothing."



John Smith wrote:
Len:

Yep, that is one way alright, and produces good results, there are others,
some better.

Adaptive learning by the program is the key, and the program must learn
what the senders' length of a di to a dah is, and the breath of the width
he is spanning of each the di and the dah.

The amateur abbreviations are in a table, and the dictionary from a spell
checker can be borrowed to check decoded morse words against which are not
abbreviations.

You are right, a high speed machine affords you time to do
abundant error checking--and here is where you gain close to 100% accuracy
from, final fall back is the ear and the mind, to correct any mistakes the
program cannot, yet, handle...

All words which do not match the table of abbreviations or the dictionary
have a copy of that word thrown into an error file, along with di's
represented by periods and dah's represented by underscores or hyphens, of
the word thought to be an error. This error file can be studied later and
the program "tweaked" to handle such errors in the future.

However, what interests me most is your knowledge on the subject, you most
certainly have a good grasp of the logic necessary to begin to put one
together.

Perhaps you have programmed and played with such yourself? Perhaps you
have a relative or friend in the field?

John

On Wed, 03 Aug 2005 22:23:57 -0700, LenAnderson wrote:

From: "John Smith" on Tues 2 Aug 2005 20:29

b.b.:

They are not "sending code so poorly that a pimply-faced No-Code Tech with a
code reader..." can't read it, they are attempting to send so badly that a
computer running software coded by one both CW and computer savvy has set up--I
suspect they think themselves smarter than the computer... maybe... grin

Indeed, a very good programmer would inject "nuances" into the way the app
translated his keyboard code to morse, making it virtually impossible for them
to tell they were copying automaton generated code, at a very respectable
speed! grin

I would think it would be a game, an enjoyable one...

John, that discussion took place in here a few years ago, my
remarking on what I'd seen, lent my Icom HF receiver for an
air test, on an ADAPTIVE decoder for morse. It was written
by a professional programmer as an intellectual exercise for
his own benefit, just wondering if it could be done. The
ADAPTIVE part was in automatically adjusting to the differences
in weighting of dits and dahs, their combination resulting in
a word rate equivalent. The ADAPTIVE part took most of the
source code...the translation of morse characters to ASCII for
immediate display was a small, small part of the source, just
a small look-up table in effect. It was done on a medium-old
clock rate PC but would be a snap to work at a 2 GHz clock.

To reverse the process, to add weighting to dits and dahs, even
to having different weighting for different characters, is a
snap with a random number routine. That wasn't done, but is
viable without much alteration of the source.

The PCTA extras in here will have NONE of such things! They
will attempt to THRASH anyone in a monumental display of deus
ex machina worthy of the most devout Luddite. shrug

don dit