Return to KLUBNL.PL main page

[Top] [All Lists]

LF: new visual-CW techniques

To: [email protected]
Subject: LF: new visual-CW techniques
From: "Rik Strobbe" <[email protected]>
Date: Mon, 15 Nov 1999 13:26:05
Reply-to: [email protected]
Sender: <[email protected]>
Thanks to all who responded to my previous mail, it seems that others had
similar ideas to increase the transmission speed for visual-CW.

For those who also appreciate the 'therapeutic' value of visual-CW and are
not interested in speeding up things there is the possibility to increase
the 'dot-length' by a certain factor (+/- 3). This will ensure that the
duration of the QSO will not be too short and has the advantage that you
can make the QSO with less power or cover a bigger distance with the same
Besides that it is not my intention start a crusade against the 'classic'

For those interested in 'optimizing' this visual mode I want to give some
insight in my approach to the problem :

First I tried to 'analyse' Morse-code and compare it with more classical
digital modes that use either ASCII-code or Baudot-code.
I came to 2 major differences :
1. Variable code length, the most frequent characters have short code. This
is very usefull for transmitting text but rather useless in the visual-CW
QSO's where data exchange is mainly limited to calls and reports. But regardless from this even in visual-CW Morse-code has the advantage
that we radioamateurs know it and can easily 'read' it (what is not the
case for ASCII or Baudot).
2. Where ASCII and Baudot are stricktly binary (on/off or 1/0 or
mark/space), Morse-code has 3 different 'components' : dot, dash and space.
For classical morse-code detection by ear this 3 'components' are converted
to a on/off (binary) system where the dot is represented by a on-off (or
10) sequence, the dash by a on-on-on-off (or 1110) sequence and the space
by a off-off-off (or 000) sequence. Characters are created by dash-dot
combinations, space is used to separate characters (single space) or words
(double space).

Next I took the 'pro' and 'contra' of the 3 systems (ASCII, Baudot, Morse) :

pro = fixed code length and generally accepted for data-exchange
contra = long (8 bit) allowing 256 characters, while in practice we only
need about 45 characters

- Baudot :
pro = fixed code length, widely known and accepted from 'teletype' and
shorter than ASCII
contra = 5-bit code allows only 32 characters, this is 'fixed' by having a
code for 'switch to figure'

- Morse :
pro = well know by hams, relative short code
contra = not only the characters have different length but even the
'components' (dot, dash, space) differ in length.

This contra in Morse-code can be eliminated in visual CW if we replace the
'time difference' between dot and dash by a frequency difference.
We can represent a dot by transmitting a 'low' frequency during 1
'timeperiod', a dash by transmitting a 'high' frequency during 1
'timeperiod' and a space by no transmission during 1 'timeperiod' (or as
alternative by transmitting a 'middle' frequency - but this will increase
average power by 50% and bandwidth by 100%).
As shown in my previous mail this will shorten time needed to transmit by
300%. Or the other way arround the length of a 'timeperiod' can be
increased by 300% to be able to cover the same distance with reduced power
or to increase the distance with the same power.

Some 'dry tests' (generating code on screen by software) have shown that
one can relatively easy 'decode' this kind of CW (for each 'low' you say
'dit', for each 'high' you say 'da'). Only for long characters that have
only dots or dashes it is a bit more difficult, but up to 3 same (eg. S or
O) it is no big problem (so T,M and O are easily kept apart, so are E,I and
S) but distinguising H from 5 takes some exercise on a screen. But this can
be easily solved when we can decide on a 'standard timelength' (eg. 3
seconds) and project a grid on the screen where eache 'square' represents 1
timeunit, so your eye has a kind of visual reference.

If there is interest I am willing to adapt the QRS software for those who
want to do some tests. Testing it in practice will be the only way to find
out if this 'alternative' is any good.

73, Rik  ON7YD

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