Return to KLUBNL.PL main page

rsgb_lf_group
[Top] [All Lists]

LF: WOLF bandwidth suggestions

To: [email protected]
Subject: LF: WOLF bandwidth suggestions
From: [email protected]
Date: Fri, 13 Apr 2001 13:15:10 EDT
Reply-to: [email protected]
Sender: <[email protected]>
Hi Stewart and LF group,

regarding the recent discussions about PSK, I'd like raise a couple of points to possibly minimize the occupied bandwidth. These are merely meant to be suggestions, I do not intend to criticise an excellent piece of work.
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. 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.
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%.
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.
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.
5. In the current implementation, the transmit file apparently uses only half
of the DAC range. Also, I wonder if one could possibly use Spectrogram's
RX-files taken at 5512 sps without resampling. 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.
73 es CU

Markus, DF6NM


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