From: John Smith on Aug 3, 10:51 pm

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.

There's no need to use a table of abbreviation...those can vary
from time to time and operator to operator. The MAJOR problem
is determining the "dit rate"...once that is done, the "dah" can
be separated, also the inter-character spacing.

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...

Those who've never gotten far INTO computer programming will NOT
fully understand how blazing fast a 2 GHz clock PC really is!
My platform isn't top-of-the-line at 2 GHz clock and 100 MHz
RAM access...but it can almost blow the mind on how fast it can
handle anything in the Win32 family...I am getting slowly into
that through PowerBasic Compiler, calling the canned Win32
routines directly.

Back in '92 I shifted over to a moderate PC with a 20 MHz clock
and 1 MHz RAM access rate...and was checking various forms of
complex number calculation combinations to handle LARGE two-
dimensional arrays. Had those runing at tens of thousands of
random-quantity repetitions in order to get the fastest. That was
for a ported-over circuit analysis program from RCA in the 70s
(which I had helped improve - along with others in Central
Engineering - then). In the 1970s, any mainframe with a 10 MHz
clock and 1 MHz RAM access was considered "top of the line." :-)
I dug out the same PC time test routines and ran them on THIS
platform and the runs were just an eyeblink long. :-) In order
to actually time them, I had to increase the number of iterations
a hundred times (from about 10K) in order to see some semblance
of actually working hard!

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.

I disagree. The first task is to ADAPT to the going rate. That
requires only a temporary memory (but a large one at that since
one dimension MUST be time) to set the approximate received rate.
When rate is approximated, there can be a built-in weighting on
time duration to determine dit from dah. Simple conditional yes-
no on duration but the trick seems to be arriving at a good
decision point in time.

"Abbreviations" tables aren't needed. In fact, from seeing such
a program working (and being able to look at the flow diagrams
of the routines...source was in C++ but flow diagrams were in
standard box-diamond form...the common abbreviations and Q codes
could be left as they were in ASCII on the screen. Since morse
operators tended to have a great variation in inter-character and
inter-word spacing, those spaces were just left in the screen
display and the human reader could do the final "adaptation" on
what the spaces meant (or didn't mean).

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.

In 1970 (at an RCA division in Van Nuys, CA) I got a chance to
do programmed calculations on an HP 9100 desk calculator...did
some statistics runs on aircraft collision avoidance estimates,
part of a long-range R&D project at RCA devised by the late
Jack Breckman (a genius type who could extemporaneously speak
in ordered paragraphs). Found that programming and I got along
very well and a "romance" of sorts happened, went full-flower
with successful negotiations with bean counters to get corporate
computer time (then horribly expensive). Got Dan McCracken's
softcover on FORTRAN IV Programming to explain the program
ordering (damn good book, Dan became President of the ACM for
a time later), won a steak dinner bet with another on being able
to make a running program and off it went to bigger, better
things. The epiphany happened due to a supplier delay on some
small inductors for a vital hardware delay line...could I use
a "close, but not quite right" inductor which was plentiful?
Did a simulation run for pulse shape on the corporate computer
using the possible replacement, decided it was okay. When the
replacement parts arrived, I quickly tack-soldered the delay
line together, viewed the pulse shape though it and found the
computer simulation waveform matched the real waveform EXACTLY!
I was sold and a definite believer in accurate simulation ever
since.

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

I never bothered with a "morse code reader" program. Wayyyyy
TOO MANY OTHER kinds of calculations that would be of immense
value. When my group at the RCA division was disbanded in '75,
I had six programs in the Central Engineering software library
and have had four other programs as Shareware back in times
before the Internet went public. Those are all Freeware now,
not that it matters much with Windows and other GUI-ey graphic
screens being "what all want." :-)

As a former voting member of the ACM, courtesy of cross-membership
privilege of the IEEE, I've worked with/known a bunch of computer
programmers. The kind that can DO THE WORK and DEMONSTRATE it
without pointing to a bunch of framed/plaqued certificates on the
wall. One of those was the guy I described...one who had the
HOBBY of programming as well as doing it every day for a living.
We were friends enough for him to let me look at all pages of his
project notebook...and myself letting him use my Icom receiver as
a morse signal source. He thought it was a fun program to do,
while I thought morsemanship wasn't worth bothering about...but,
it was a fascinating challenge to mechanize and to make work.
His development platform was rather faster than my 20 MHz clock
thing and - as it was written then without final optimization -
wouldn't work with high rates of the speed-freak hams (I knew of
two, one in Frisco, the other near San Diego, both retired and
busy beeping each other most every day then). Right now I can
order a Microchip PIC from DigiKey running at a 50 MHz clock,
get a couple large EPROMs to hold the source code (if ported)
and it would work fine, I'm sure. PIC's RISC instruction set is
NOT compatible with 80x86 instruction set and takes a lot of
translation. Thank you, I'll take canned PIC programs, use
those and be done with it.

I do NOT have ANY sort of decoder for morse, TTY, commercial
SSB TTY tones, any of the TORs in-house. Not my cuppa either.
The 'TOR peripheral boxes are cheap enough that I could buy
one and use it if the interest struck. No problem. Someone
else did the design, debug, engineering and I respect that;
no sense in re-inventing wheels unless it's to make them more
rounded, smoother, etc. :-)

Note: Watch for Jimmie Noserve, the Nun of the Above, to pick
up on that last sentence and use it later in chiding postings
agin' me...it might be weeks before he do dat, but he gots a
memory like an effluent and will issue it later. Predictable.

NSA BSA

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

Len:

It is not even close...

The end of all that design in computer hardware and software, when
efficient and up-to-date, would be impossible for a human operator to send
let alone receive without hardware and software... RTTY is as dead as CW...

John

On Thu, 04 Aug 2005 10:22:01 -0700, an old friend wrote:


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.

indeed we are

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".

that does depend on the goal, and the operator. Personaly I find the
idea of the manual morse and compter morse interacting the only
redeeming virtue of the mode (please I know you disagree but go along
for a minute) That someone could use the simple assembly of the QRP rig
to reach out to a station like mine reading fby machine and sending it
back the same way. It is one the few occasion I can realy see much use
in the mode during an emergency gives the user the low signal abilities
of RTTY or PSK 31 but allowing the station in the affected area to
despense with a PC

Thus it is 'better" in some ways, indeed I am a much better operator of
computer morse than manual and it would make my staion a bteer station
by your standards (more modes more abilities)

so where your beef?


it is not your cup of tea sure fine


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.

all depends on what you want, to listen or to play

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

Len:

Right now I am running a 3.8Ghz processor clock with a 466Mhz memory clock
on a bus capable of 266Mhz.

The fastest keyer would leave the
hardware/software killing time to await his next di or dah...

The purpose of the "error file" is to catch new abreviations so they can
be added to the table, let them come up with as many variations as they
possibly can, in the end the reader is only made stronger...

John

On Thu, 04 Aug 2005 12:01:04 -0700, LenAnderson wrote:

From: John Smith on Aug 3, 10:51 pm

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.

There's no need to use a table of abbreviation...those can vary
from time to time and operator to operator. The MAJOR problem
is determining the "dit rate"...once that is done, the "dah" can
be separated, also the inter-character spacing.

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...

Those who've never gotten far INTO computer programming will NOT
fully understand how blazing fast a 2 GHz clock PC really is!
My platform isn't top-of-the-line at 2 GHz clock and 100 MHz
RAM access...but it can almost blow the mind on how fast it can
handle anything in the Win32 family...I am getting slowly into
that through PowerBasic Compiler, calling the canned Win32
routines directly.

Back in '92 I shifted over to a moderate PC with a 20 MHz clock
and 1 MHz RAM access rate...and was checking various forms of
complex number calculation combinations to handle LARGE two-
dimensional arrays. Had those runing at tens of thousands of
random-quantity repetitions in order to get the fastest. That was
for a ported-over circuit analysis program from RCA in the 70s
(which I had helped improve - along with others in Central
Engineering - then). In the 1970s, any mainframe with a 10 MHz
clock and 1 MHz RAM access was considered "top of the line." :-)
I dug out the same PC time test routines and ran them on THIS
platform and the runs were just an eyeblink long. :-) In order
to actually time them, I had to increase the number of iterations
a hundred times (from about 10K) in order to see some semblance
of actually working hard!

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.

I disagree. The first task is to ADAPT to the going rate. That
requires only a temporary memory (but a large one at that since
one dimension MUST be time) to set the approximate received rate.
When rate is approximated, there can be a built-in weighting on
time duration to determine dit from dah. Simple conditional yes-
no on duration but the trick seems to be arriving at a good
decision point in time.

"Abbreviations" tables aren't needed. In fact, from seeing such
a program working (and being able to look at the flow diagrams
of the routines...source was in C++ but flow diagrams were in
standard box-diamond form...the common abbreviations and Q codes
could be left as they were in ASCII on the screen. Since morse
operators tended to have a great variation in inter-character and
inter-word spacing, those spaces were just left in the screen
display and the human reader could do the final "adaptation" on
what the spaces meant (or didn't mean).

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.

In 1970 (at an RCA division in Van Nuys, CA) I got a chance to
do programmed calculations on an HP 9100 desk calculator...did
some statistics runs on aircraft collision avoidance estimates,
part of a long-range R&D project at RCA devised by the late
Jack Breckman (a genius type who could extemporaneously speak
in ordered paragraphs). Found that programming and I got along
very well and a "romance" of sorts happened, went full-flower
with successful negotiations with bean counters to get corporate
computer time (then horribly expensive). Got Dan McCracken's
softcover on FORTRAN IV Programming to explain the program
ordering (damn good book, Dan became President of the ACM for
a time later), won a steak dinner bet with another on being able
to make a running program and off it went to bigger, better
things. The epiphany happened due to a supplier delay on some
small inductors for a vital hardware delay line...could I use
a "close, but not quite right" inductor which was plentiful?
Did a simulation run for pulse shape on the corporate computer
using the possible replacement, decided it was okay. When the
replacement parts arrived, I quickly tack-soldered the delay
line together, viewed the pulse shape though it and found the
computer simulation waveform matched the real waveform EXACTLY!
I was sold and a definite believer in accurate simulation ever
since.

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

I never bothered with a "morse code reader" program. Wayyyyy
TOO MANY OTHER kinds of calculations that would be of immense
value. When my group at the RCA division was disbanded in '75,
I had six programs in the Central Engineering software library
and have had four other programs as Shareware back in times
before the Internet went public. Those are all Freeware now,
not that it matters much with Windows and other GUI-ey graphic
screens being "what all want." :-)

As a former voting member of the ACM, courtesy of cross-membership
privilege of the IEEE, I've worked with/known a bunch of computer
programmers. The kind that can DO THE WORK and DEMONSTRATE it
without pointing to a bunch of framed/plaqued certificates on the
wall. One of those was the guy I described...one who had the
HOBBY of programming as well as doing it every day for a living.
We were friends enough for him to let me look at all pages of his
project notebook...and myself letting him use my Icom receiver as
a morse signal source. He thought it was a fun program to do,
while I thought morsemanship wasn't worth bothering about...but,
it was a fascinating challenge to mechanize and to make work.
His development platform was rather faster than my 20 MHz clock
thing and - as it was written then without final optimization -
wouldn't work with high rates of the speed-freak hams (I knew of
two, one in Frisco, the other near San Diego, both retired and
busy beeping each other most every day then). Right now I can
order a Microchip PIC from DigiKey running at a 50 MHz clock,
get a couple large EPROMs to hold the source code (if ported)
and it would work fine, I'm sure. PIC's RISC instruction set is
NOT compatible with 80x86 instruction set and takes a lot of
translation. Thank you, I'll take canned PIC programs, use
those and be done with it.

I do NOT have ANY sort of decoder for morse, TTY, commercial
SSB TTY tones, any of the TORs in-house. Not my cuppa either.
The 'TOR peripheral boxes are cheap enough that I could buy
one and use it if the interest struck. No problem. Someone
else did the design, debug, engineering and I respect that;
no sense in re-inventing wheels unless it's to make them more
rounded, smoother, etc. :-)

Note: Watch for Jimmie Noserve, the Nun of the Above, to pick
up on that last sentence and use it later in chiding postings
agin' me...it might be weeks before he do dat, but he gots a
memory like an effluent and will issue it later. Predictable.

NSA BSA

John Smith wrote:
N2EY:

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

No, you're not.

The systems you're talking about consist of a keyboard and visual
readout,
same as RTTY and other "keyboard modes". The error-correction and other
features are simply enhancements - they do not change the basic method
of communication, nor the experience of the end users.

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...

Morse Code, OTOH, is alive and well on the amateur bands. You will find
many
more radio amateurs on the HF/MF amateur bands using Morse Code than
any
other mode except single sideband amplitude modulated voice.

Another analogy:

Inexpensive pocket calculators can do basic arithmetic far faster and
with more
accuracy than most humans, even with pencil and paper. Does that mean
there is
no reason to learn how to add, subtract, multiply and divide?




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

N2EY:

My gawd man, must you apply antique analogies to everything which is
attempting to break archaic methods to attempt to obfuscate anything you
don't like and/or agree with? Technology has passed you by man, the reins
have passed, what you are holding in your hands are the ashes of
yesteryear... don't embarrass yourself and others about you... speak on
things you understand, or not at all...

John

On Thu, 04 Aug 2005 14:00:07 -0700, N2EY wrote:


John Smith wrote:
N2EY:

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

No, you're not.

The systems you're talking about consist of a keyboard and visual
readout,
same as RTTY and other "keyboard modes". The error-correction and other
features are simply enhancements - they do not change the basic method
of communication, nor the experience of the end users.

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...

Morse Code, OTOH, is alive and well on the amateur bands. You will find
many
more radio amateurs on the HF/MF amateur bands using Morse Code than
any
other mode except single sideband amplitude modulated voice.

Another analogy:

Inexpensive pocket calculators can do basic arithmetic far faster and
with more
accuracy than most humans, even with pencil and paper. Does that mean
there is
no reason to learn how to add, subtract, multiply and divide?




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

"John Smith" wrote in message
news
Len:

It is not even close...

The end of all that design in computer hardware and software, when
efficient and up-to-date, would be impossible for a human operator to send
let alone receive without hardware and software... RTTY is as dead as
CW...

John

On Thu, 04 Aug 2005 10:22:01 -0700, an old friend wrote:


Every mode has its advantages and disadvantages. Neither RTTY nor CW is
dead. One just has more choices than in the past.

Dee D. Flint, N8UZE

wrote:
John Smith wrote:
N2EY:

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

No, you're not.

The systems you're talking about consist of a keyboard and visual
readout,
same as RTTY and other "keyboard modes". The error-correction and other
features are simply enhancements - they do not change the basic method
of communication, nor the experience of the end users.

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...

Morse Code, OTOH, is alive and well on the amateur bands. You will find
many
more radio amateurs on the HF/MF amateur bands using Morse Code than
any
other mode except single sideband amplitude modulated voice.

making it Number 2 number 3 in the ARS as a whole most likely (incduing
FM voice and the whole frequenct spread

Another analogy:

Inexpensive pocket calculators can do basic arithmetic far faster and
with more
accuracy than most humans, even with pencil and paper. Does that mean
there is
no reason to learn how to add, subtract, multiply and divide?

but it means there isn't much purpose in testing for it as part of the
ARS licens etest





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

John Smith wrote:
N2EY:

My gawd man, must you apply antique analogies to everything which is
attempting to break archaic methods to attempt to obfuscate anything you
don't like and/or agree with? Technology has passed you by man, the reins
have passed, what you are holding in your hands are the ashes of
yesteryear... don't embarrass yourself and others about you... speak on
things you understand, or not at all...

John

and Jim is the best of the Procoders the very best of them, and
confirms my long standing conviction that if there is in fact a
goodreason for Code testing the Procoders don't know what it is

On Thu, 04 Aug 2005 14:00:07 -0700, N2EY wrote:


massive cut

an old friend wrote:
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.

indeed we are

Glad you agree

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".

that does depend on the goal, and the operator.

True enough.

Personaly I find the
idea of the manual morse and compter morse interacting the only
redeeming virtue of the mode (please I know you disagree but go along
for a minute)

It's just *one* good thing about Morse Code (the ease and flexibility
of
human-machine interface. There are many more good things (redeeming
virtues?) of Morse Code.

That someone could use the simple assembly of the QRP rig
to reach out to a station like mine reading fby machine and sending it
back the same way.

One more tool in the toolbox.

It is one the few occasion I can realy see much use
in the mode during an emergency gives the user the low signal abilities
of RTTY or PSK 31 but allowing the station in the affected area to
despense with a PC

If the operators know Morse Code, there's no reason for a PC at either
station.

Thus it is 'better" in some ways, indeed I am a much better operator of
computer morse than manual and it would make my staion a bteer station
by your standards (more modes more abilities)

In that regard, it is "better". But it is not universally "better",
just as an automobile is not universally "better" than a bicycle.

so where your beef?

The idea that machine operation is somehow universally better.

it is not your cup of tea sure fine

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.

all depends on what you want, to listen or to play

Point is, there's a big difference.

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