Hello Jim & group,

Excellent paper from Jim, it seems a good starting point for an open
discussion.


One of the point that Jim mentions is the duration of a QSO.
While making the recent changes on QRS I have been doing some thinking how
we 'speed up' things.

I started with analyzing some typical QRSS (or DFCW) QSO's and came,
similar to Jim, to the conclusion that it takes about 50 characters to
complete a QSO.
The main if that is exchanged are callsigns (or parts of it), what means
that there is a rather random distribution of letters. So the 'smart
coding' of CW won't be of much use as 'E' and 'Y' will have the same
occurance.

Digging a bit further into the 'typical QSO' shows that the 50 characters
can be divided in :
- 32 letters (almost random)
- 18 figures (almost random)
- 10 spaces

Next I started comparing the modes, starting with the existing ones :
- in CW (QRSS) the average letter has a length of 11.2 dots, the average
figure is 17.0 dots long and a space is 6.0 dots long (inter character
spacing included).
- in DFCW the average letter is 4.1 dots long, the average figure is 5.0
dots long and the a space is 2.0 dots long
That means that the typical QRSS QSO will take 724 dotlengths while a
typical DFCW QSO will take 211 dotlengths, a time saving factor of 3.43.
So at 3 sec/dot it will take 36'12" in QRSS and 10'33" in DFCW. At 10
sec/dit it will take 2 hours in QRSS and 35 minutes in DFCW. And at 60
sec/dot it will take 12 hours in QRSS and 3.5 hours in DFCW.
Or the other way arround, if you want a complete QSO in 1 hour then you can
use 5 sec/dot in QRSS and 17 sec/dot in DFCW.

As mentioned by Jim, DFCW is a bit more difficult to implement, as you need
to FSK the transmitter. So the main advantage of QRSS is its simplicity.
The efficiency of QRSS can be improved by :
- reducing the dash/dot ratio from 3 to 2
- reducing the inter character spacing from 3 dotlengths to 2 dotlengths
- reducing the space length from 6 dots to 4 dots
As a result the average letter will be 8.8 dots long, the average figure
will be 13.5 dots long and a space will be 4 dots long. A typical (50
character) QSO will now be 565 dots long, a time saving factor of 1.28.
This means a 8 minute saving on a 3sec/dot QSO, a 26 minute saving on a 10
sec/dot QSO and a 2h40m saving on a 60 sec/dot QSO. This is not nearly as
good as DFCW, but it can be achieved without any changes to the equipement.

If we want more time efficient coding then we have to go to 'multiple
frequency modes'. A possibility is a 7 tone mode that will give us the
possibility to transmit 49 characters (enough for our purpose) at a typical
length of 3 dots/char (or 2 dots/char without inter character spacing).
At 3 dots/char a typical QSO will be 150 dots long, a time saving factor of
1.41 compared to DFCW.
At 2 dots/char a typical QSO will be 100 dots long, a time saving factor of
2.11 compared to DFCW. But at 2 dot/char this system has 2 disadvantages:
1. We loose synchronisation (so the RX has to know the start time of the TX)
2. We loose the reference frequency, so any offset between TX and RX will
cause problems (at 3 dots/char we can use the inter character spacing to
transmit a reference frequency).
Technical implementation of multi tone modes more difficult than DFCW. So
to be honest, taking into account that only very few stations (abt. 4-5 in
Europe) have set the step from QRSS to DFCW I'm afraid that the technical
implementation of a multi tone more will be a real burden.

Finally there were some suggestions for double tone modes, where 2 tones
wil be sent parallel. First of all you will need a linear PA, with reduced
efficiency, more stabilty problems and more difficult to built. But is
there really an advantage ?
If you transmit 2 tones, each tone will be 3dB down compared to a single
tone mode  (if you take the reduced efficiency into account it will be even
4dB or more). So what is the difference in transmitting 2 tones parallel
during 20 seconds or 2 tones sequential during each 10 seconds ? SNR will
be the same.


Another 'branch' are the modes as BPSK and WOLF (what is in fact BPSK with
some added 'intelligence'). First of all BPSK has an advantage of 6dB over
traditional 'on-off keying', at the same dotlength (while on-off keying is
a kind of 1 to 0 switching BPSK is a kind of 1 to -1 switching).
Further these modes have a different approach of improving SNR. Instead of
transmitting the characters very slow (as QRSS/DFCW does) they transmit the
characters rather fast and improve SNR by repeating them over and over and
doing some smart error correction.

An additional difference occurs at the RX side. QRSS/DFCW are received
'wideband', this means you can observe a rather big part of the spectrum
for DFCW/QRSS signals. This has the advantage that, even at signal
bandwidths of 0.01Hz, there is nor problem to 'hit' the transmitted signal.
One can even 'decode' more that one signal at the same time. Opposite to
this all receiving software for BPSK / WOLF is 'narrowband'. This means
that you have to 'hit' the transmitted signal very accurate and you can
receive only 1 signal at a time.

BPSK modulation is not so difficult, in theory you just need an XOR gate in
the drver circuit. But if you modulate you TX 'rude' the bandwidth of the
signal will be rather wide. In PSK this is solved by 'enveloping' the
signal (so you have zero amplitude at phase switching) but this requires a
linear PA and is not very power efficient.
Lowfers tend to use the 'rude' BPSK, but they have a 30kHz wide band and
are limited to 1 Watt input (few mW ERP) while we hams can run up to 1W ERP
(1kW input or more) and have only a 2.1kHz wide (or narrow) band.

Recents tests of the WOLF system have shown that it has some possibilities.
In my opinion the best way to check what WOLF is worth transatlantic is to
have a strong WOLF beacon in VE/W and as many as possible stations
monitoring this beacon in Europe. When good software becomes available it
will be no problem to get a few dozen receving sites all over Europe, the
WOLF system just invites for unattended (overnight) recepetion. That way we
would also avoid inter-EU QRM during this test phase.
So, we would need someone who is willing (and able) to write a good piece
of WOLF receiving software (using the soundcard, running under windows) and
who someone (at the other side of the pond) who can setup a 24h beacon.


So far my contribution,

73, Rik  ON7YD