Hello group,
It is a pleasant surprise to see the positive reactions on the suggested "7
tone" coding.
To keep things clear, this new coding is not meant to be a replacement for
QRSS or DFCW, just as these modes are not a replacement for good old CW. It
is just that in the recent transatlantic and transpacific tests we seem to
have come to the practical limits of QRSS / DFCW, so to have succesfull
QSO's at these ranges we need something more efficient. I believe that
using this '7 tone' coding and a 60 sec dotlength a QSO can be completed
with a period of 60 to 80 minutes.
Now some suggestions :
1. Taking 2 bits/character we can code 49 characters. Beyond the obvious
A-Z, 0-9 and space we might need '/' and eventually '?' (39 characters).
Further efficiency can be increased is we have special codes for the report
(TMO so far), for 'CQ' and for the 'K' and 'SK' at the message end (5 extra
codes).
For example, assume use special codes for the report 'M' and the
terminating 'K' (here shown as '#' resp. '$') the transmitted text
BMU TAG MM K (= 12 characters)
would become
BMU TAG##$ (= 10 characters, spaces before and after the report and before
the final 'K' can be omitted). It would also avoid possible confusion for
stations with 'MM', 'TT', 'OO', 'SK', 'CQ' etc.. in the suffix.
So this comes to 44 codes (39 characters + 5 special codes) leaving still 5
possibilities open.
2. A certain 'time synchronisation' is very usefull since this makes the
inter-character spacing redundant (so each character will only take 2 bits
instead of 3, a 33% saving !). Assuming the this 7 tone code will be used
with dotlengths of 1 minute it should not be so difficult to start a
transmision always at an even minute, so any RX station knows that during
the even minute the 1st bit is transmitted and during the odd minute the
second bit. Alternatively 120 sec/dot can be used, starting at a multiple
of 4 minutes.
3. Regarding the coding, apart from the space (= most frequent character)
that would get a code that includes both the lowest an highest tone I would
keep as certain 'logic' in the other codes.
For example (1 = lowest tone .. 7 = highest tone) :
A = 11 H = 21 O = 31 V = 41 0 = 51 7 = 61 space = 71
B = 12 I = 22 P = 32 W = 42 1 = 52 8 = 62 report 'O' = 72
C = 13 J = 23 Q = 33 X = 43 2 = 53 9 = 63 report 'M' = 73
D = 14 K = 24 R = 34 Y = 44 3 = 54 report 'T' = 74
E = 15 L = 25 S = 35 Z = 45 4 = 55 'CQ' = 75
F = 16 M = 26 T = 36 5 = 56 / = 66 final 'K' = 76
G = 17 N = 27 U = 37 6 = 57 ? = 67 final 'SK' = 77
The above is just a suggestion, maybe there are good reasons to change this
coding.
4. Maybe it is usefull to agree on a certain inter-tone spacing (frequency
shift), especially if we want to try machine decoding. Assuming a stability
of 0.1ppm over a period of 2 hours, what is not so hard to achieve using a
PLL of DDS signal source, this comes to stability of better than 0.02Hz per
2 hours on 137kHz. Further assuming a minimal dotlength of 30 seconds a
minimal spacing of 0.033Hz is required. To be on the save side we could
agree on a inter-tone spacing of 0.1Hz, making the signal only 0.6Hz wide.
5. In order to do some first tests, all we need it to (temporary) agree on
a code, inter-tone spacing and dotlength. Further we need one (or two)
brave souls who are able to adapt their transmitters and put some low power
tests in the air. (hint to Andy ;-)
The rest of us can use Argo or other software and try to copy and decode
the test transmisions.
Any comments and/or suggestions most welcome
73, Rik ON7YD
|
