Message-ID: <003e01c0c53a$29315d90$0700000a@parissn2>
From: "Stewart Nelson" <sn@scgroup.com>
To: rsgb_lf_group@blacksheep.org
Cc: "LowFerQTH" <lowfer@qth.net>
References: <63.14878f3e.28088e1e@aol.com>
Subject: LF: Re: WOLF bandwidth suggestions
Date: Sun, 15 Apr 2001 01:25:13 +0200
Organization: SC Group
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org
Sender: <majordom@post.thorcom.com>

Hi Markus and all,

Thanks for your post.  I've fixed some of the minor problems, and have
comments on the major ones.  WOLF new version is 0.53, which can be
downloaded at http://www.scgroup.com/ham/wolf.html .
 
> 1. WOLF is using cosine-shaped zero-crossings with a risetime of only 5 ms, 
> which causes a few extra sidebands on each side of the spectrum. I'd prefer 
> to extend the cosine-envelope to the full symbol duration (like in PSK31), 
> then ideally only the 10 Hz wide main spectral lobe would persist.

The 't' (transition) option has been added for transmit.  You specify a
transition time, relative to the symbol duration.  Values from 0 to 1 are
valid.  The web page shows spectra for 0, 0.1, and 1.  The improvement,
when 't 1' is specified, is dramatic.  Many thanks for your suggestion.

> At a given 
> PEP level and with 50% phase transitions, on average we'd lose only 0.8 dB 
> SNR while saving 24% transmitted energy.

Unfortunately, the receiver is still matched to "rude" BPSK, so about 1.3 dB
is lost, relative to the old (and default) setting.

> 2. I wonder whether it would be possible to use fewer bits for the 
> pseudo-random reference stream, as this is known in advance and could be 
> averaged over longer times than the actual data. With only 1 out of 4 bits 
> donated, data rate could be increased by 50%.

At present, most failures to decode are failures to sync up.  Some are
directly caused by shortcomings in the program (poor search and tracking),
and some are caused by incorrect settings, e.g. sample rate, which are
indirectly caused by the lack of good status and diagnostic outputs.
After I get a chance to improve both of those areas, I'll reconsider how
much sync information is really needed.

> 3. QPSK at half symbol rate would reduce the BW down to 5 Hz. With 3 dB less 
> signal per channel and 3 dB less noise, SNR would remain unaffected. If only 
> one reference stream were needed for both I and Q, the net data rate could be 
> increased further.

QPSK works well for e.g. DBS satellite downlinks, where, although the signal
is very noisy, it's possible to average many thousands of bit transitions to
get an accurate carrier phase reference.  You can't do that in a weak signal
ham situation, because the packets are short, and path / equipment instabilities
limit the time constants for phase recovery.  If the reference for a BPSK
signal is 45 degrees in error, you have an additional 3 dB loss, and it
will take twice as long to recover the message.  But in the QPSK case, you
have total garbage, because the detector sees the "right" bit and a "wrong"
bit with equal amplitudes.

PSK31 has an error correcting QPSK mode, which is rarely used, because most of
the coding gain is eaten up by the loss described above, and the small remaining
gain does not justify the added delay.  IMO, the error correcting mode would have
been far more successful, if it simply ran in BPSK at half speed.  Most hams can't
type that fast.

> 4. We might then turn to OQPSK, ie. offset the I and Q streams by 50ms to 
> avoid the zero crossings. While we'd still want to use a linear amplifier, 
> the difficulties of Class-D envelope restoration schemes due to the undefined 
> phase at zero amplitude would be much alleviated.

The good news is that OQPSK with proper filters has an essentially constant
envelope, and is used on some satellite links so that the transponder can be
run saturated for maximum output.  The bad news is that it is essentially
equivalent to MSK with a recoded input stream, and IMO weak signal FSK should
use every other bin, to minimize interference resulting from reference errors,
even if one must use a higher rate code to maintain the same bandwidth.  Going
from, say, a rate 1/6 code to a 1/3 costs only about 0.44 dB, see graph at
http://scitec.uwichill.edu.bb/cmp/online/p31q/Lecture14/lect14.htm .

I believe that a coherent m-ary FSK system would be technically superior to WOLF,
but have not attempted to implement one, because there are very few hams (you
being one of them) who have the means to generate such a signal at LF.  But
that would be the best way, IMO, to build a system that would occupy
about 1 Hz of bandwidth, but would still permit a transatlantic LF QSO to be
completed within one hour.

> 5. In the current implementation, the transmit file apparently uses only half 
> of the DAC range.

The 'a' option can now be used to specify transmit attenuation, relative to
full scale.

> Also, I wonder if one could possibly use Spectrogram's 
> RX-files taken at 5512 sps without resampling.

WOLF will now accept .wav files recorded at any sampling rate, and will display
a warning if the rate is not 8000 Hz.  If -r is not given, the internal sampling
rate is set to that of the input file.

> After cheating by overwriting 
> the sampling rate in the wav header, I could decode using -r 5512, but 
> somehow WOLF didn't terminate at the end.

I wrote several files with Spectrogram 6.0.8, but could not reproduce the trouble.
If you use the undocumented -v (verbose) option, WOLF will display (among other
things), the amount of data it thinks is in the input file.  You can compare that
to the file length or other software's notion of the size.  It's also possible that
there is a bug where certain data or settings causes the program to hang or loop,
having nothing to do with the input file format.  If you can see a failure on a
relatively small file, email it to me, along with the console output, and I'll
try to find the bug.  My mail server will accept an attachment of up to about 7 MB.
If it only fails with a bigger file, I'm still willing to take a look, but you'll
have to upload it to some server and send me the URL.

Everyone, please let me know of any problems with the new code.

73,

Stewart KK7KA