QRSS and normal CW

That has to  be  the  final on/off  challenge !

G :)

--------------------------------------------------
From: "Andy Talbot" <[email protected]>
Sent: Sunday, May 06, 2012 6:04 PM
To: <[email protected]>
Subject: Re: LF: Generating 8970 Hz carrier with Spectrum Lab ?

Watchiing QRSS on a screen doesn't give the 4 - 7dB of gain you get
with the error correction inherent with weak signal data modes - when
comparing signalling with the same symbol rate.   If you have to
repeat a CW message several times that slows down the rate (and adds a
sort of erro rcorrection).  Always compare like with like

QRSS and normal CW (at least in the hands of an old timer who knows
how to decode it) needs greater that at least 10dB S/N in its symbol
bandwidth.   WSPR/FSK/Opera or whatever using non-coherent power
detection with error correction can usually manage 3 - 4dB in the
symbol bandwidth.

Of course,QRSS at the moment offers the narrowest bandwidths of any
mode, the new OP4H with 60s symbols is only 16.7mHz compared with the
4.5mHz and 500uHz being talked about on VLF.

Assuming the radio link can support an arbitrarily narrow bandwidth
then you can always get better and better results by going narrower
and narrower, and slowing down your transmission rate.  But the
Bits/second/Hz figure of merit will always remain constant.for a given
mode at an arbitrarliy adequate error rate.   For CW/QRSS it will be
around  10 - 15dB for 1 Bit/second/Hz depending on opeator experience.

And eventually ther ewill come a point where the RF link cannot
support signalling any slower.  Has anyone actually stopped and
thought what the slowest data rate at 9kHz might be?    Diurnal shifts
in the ionospheric waveguide height limiting you to one bit per 12
hours perhaps ??   Discuss .....

To put the figures into real values, consider fast normal CW.  A good
op has ears which filter t something like 20 - 50Hz bandwidth.   30WPM
(I'lll bet Mal can do that, another ex marine radio op I knew could
:-) is about 24Hz dot rate, so its in the region of 1Bit/s/Hz.   And
10db S/N in 24Hz is a pretty weak CW signal.  I detect hear a tone at
that S/N quite easily, but doubt I would  be able to decode CW at any
speed at it.

BUT....   The same data rate, 24 Bits/s in 24Hz  bandwidth  ON off or
FSK  will be decoded perfectly at 5dB S/N with proper error correction
built in.

Incidently, 5dB  at 1B/s/Hz corresponds to -29dB S/N using the
reference 2.5kHz that seems to have been adopted universally now.
Scale this magic figure to your symbol bandidth to see what S/N
'ought' to be possible at any version speed  of OP. WSPR / JTxx

Andy
G4JNT


On 6 May 2012 17:26, mal hamilton <[email protected]> wrote:

Andy
All these complications to accommodate the Appliance Operator who cannot
read MORSE or watch QRSS on a screen.
g3kev

----- Original Message -----
From: "Andy Talbot" <[email protected]>
To: <[email protected]>
Sent: Sunday, May 06, 2012 4:14 PM
Subject: Re: LF: Generating 8970 Hz carrier with Spectrum Lab ?


The problem with USB slippage comes about because of the Isochronos
mode (yes, that is spelt correctly, it is not IsoSYNchronous)   -
where it sends puts real time rapid data transfer as more important
than lost samples and sends samples in real time without checking
This is probably just what music and audio people want, but it screws
up using USB based sound cards as precision timed A/D converters.
USB does have other modes with full error checking, albeit with some
latency, but the latency wouldn't matter here.

While it would be a pretty simple task these days to build an external
A/D converter and interface to USB properly, the resulting data stream
would need a custom driver written, then all the decoding software we
know and love would have to be modified to work with this custom
interface.   Then someone else would come along with another design
and we'd have to start again.

I suspect it is going to be absolutely impossible to use the soundcard
as a guaranteed glitch free A/D converter.

Joe Taylor K1JT  in the WSJT suite has a dead simple pragmatic
solution.   Instead of trying to read the data in real time, all the
WSJT modes read the entire transmisisons' worth of data to a .WAV
file, and the software works on that.   While WSJT  uses the soundcard
to do the job it will suffer from the same slippages (which don't
matter' of course' for those modes) the idea of an intermediate buffer
file would help.

A custom A/D could send its data in its own format via USB, or serial
COM port or whatever, to software that saves blocks in the format of a
.WAV file.  Then the decoding software works on the resulting .WAV
files.   It won't be real time any more, but none of these slow data
modes actually are that real time.  The speed of reading and switching
(using a pair of ping-pong files if necessary) can make the whole
system pseudo real time - in the same way as WSJT appears to run
continuously.

Now, any A/D design can be used provided the results are written to a
.WAV file.   Wav files can have any sample rate (so long as it is an
integer number of Hz) and do not have to be restricted to 48000, 11025
or whatever, so custom LF receivers using quite slow A/D converters
and low sample rates are now valid.

Just throwing that idea into the ring..

Andy
www.g4jnt.com


On 6 May 2012 16:14, James Moritz <[email protected]> wrote:

Dear Andy, LF Group,

A bit late, but never mind...

Has anyone tried using an external USB soundcard with a separate
locked clock? Most work from a 12MHz crystal which can be replaces
with a GPS locked source without too much effort. But I can't help
wondering if there will be subsequent USB synchronisation glitches
upsetting the input sampling.

I can confirm that glitches do occur with USB sound cards. I have found

this

to be a perennial problem trying to use such a sound card with the laptops

I

have available. For 9kHz reception, the relatively rapid temperature

fluctuations inside the laptop, and resulting cyclic drift of the internal

soundcard sampling frequency interfere with the operation of DL4YHF's

ingenious sample rate correction facility in SpecLab, making the internal sound card unusable for FFT resolution below a few millihertz. I found my

USB soundcard solved this particular problem quite well, but introduced

glitches that made achieving FFT resolution in the uHz range impractical.

Watching Speclab's sample rate correction "history" window, the USB card
sample rate typically starts off a few hundred ppm low (much larger than

the

actual clock frequency error), but remaining stable to within a few ppm,

but

then at unpredictable intervals abrupt jumps in sample rate of a similar
order of magnitude occur, with corresponding "blips" on the spectrogram
traces. The reported sample rate is always lower than the nominal value,
suggesting that some samples are being periodically discarded somehow.

The sound card uses a single-chip integrated audio codec and USB

transceiver, using a single 12MHz crystal. I can't really believe in "USB slippage" in the hardware - surely losing some of the data would either be

handled quietly by the USB error checking, or result in endless error
messages. The same sound card seems to work in a glitch-free way when
plugged into my desktop machine, where the reported sample rate error is

in

line with the error in the crystal frequency.

Cheers, Jim Moritz
73 de M0BMU