Message-ID: <001b01c062a5$e30f98f0$0700000a@parissn2>
From: "Stewart Nelson" <sn@scgroup.com>
To: rsgb_lf_group@blacksheep.org,  lowfer@qth.net
References: <200012081559.KAA6713991@indyweb.cgocable.ca>
Subject: LF: Detection of QRSS ("LEK" raw data)
Date: Sun, 10 Dec 2000 13:36:56 +0100
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 Bill, Lyle, and all,

I have been looking at this signal to see how it might be received if
it were 20 dB weaker (please don't laugh).  IMO, coherent detection
would be a big step toward that goal, not only because it gains an
immediate 3 dB improvement in S/N, but also because it would permit
combining multiple repetitions of the message in an intelligent way.

Unfortunately, all my attempts to find coherency have failed, so I
tried to examine the signal to see what's wrong.

There are some spectra at http://www.scgroup.com/ham/lekspec.gif .
These are measured across the entire 81 second record, using a
Hamming window and no averaging.  The X axis is in Hz; the Y in
arbitrary linear voltage units.  The 6 dB bandwidth is about 0.02 Hz.
The dark blue curve is the received signal.  This is a far cry from
the spectrum that Steve Olney posted for the same signal!  Neither is
"wrong"; the measurement conditions were just very different.

I was disturbed by the apparent strong sidebands at 799.91 and
800.03.  They clearly weren't noise.  I didn't think that they
could be caused by the modulation, but, just to make sure, I generated
a local (noise free) "LEK" and adjusted it to match the carrier
amplitude and frequency of the received signal.  That's the purple
"simulated" curve.  There's almost nothing at 800.03.  Then I guessed
that maybe Murphy put a birdie just 0.05 Hz from our carrier.  Since
I knew that "LEK" was being sent, I zeroed out all the samples from
when the key was down, leaving what should be just noise.  That's the
yellow "key-up" curve.  Guess what - looks just like noise, no birdies.
Then I figured that a cleaner spectrum could be had by keeping only
the "key-down" samples; that's the cyan curve.  Ouch!  The lower
sideband is bigger than the carrier.  There's got to be some FM on
this signal.  Question is:  Tx, Rx, or the path?

The answer came when I demodulated the signal.  See curve at
http://www.scgroup.com/ham/lekmsg.gif . The dark blue curve is
amplitude in arbitrary voltage units; purple is phase in degrees.
The X axis is in dot widths.  I used a moving average filter one dot
time wide.  Although this gives a distorted view (a series of
noise-free dots would appear as a triangle wave), you can simply
look at the end of each element time to see what a matched filter
would output.  I fudged the X-axis so that the vertical gridlines
are the strobe times.  You can see that the data looks pretty good;
the smallest "1" is about 250 and the largest "0" is about 190.
This is error-free copy with some margin to spare.

Now have a look at the phase.  It's quite stable during all 3 dashes,
but jumps whenever the key goes up and then back down.  So I suspect
that Lyle's carrier frequency falls about 0.1 Hz when the key goes up,
so the phase is different on the next key down.  (Maybe it rises -
I haven't kept track of all my sines and cosines, and don't know
whether Bill used USB or LSB reception.)

Lyle, could you please verify if this 0.1 Hz shift really occurs?
If you don't have equipment to measure it directly, just couple the
oscillator (where it's a digital signal) to an HF receiver, and tune
in an odd harmonic on ten meters.  The 0.1 Hz should be multiplied to
about 15 Hz.  This should make the beat note shift from say, 400 Hz to
415, easy to hear or measure.

In a weird way, the above behavior might be a "feature" rather than a
bug, because it adds a powerful error correction capability not
normally found in Morse code.  For example, suppose you are not sure
whether you received "U" or "ET", because the second dot is weak.
With a suitably unstable Tx, the phase of the dash (and of the
remainder of the message) would differ depending on whether that
second dot had actually been sent.  This could be used by the receiver
to reconstruct questionable bits.

Comments and opinions welcome.

Thanks and 73,

Stewart KK7KA


----- Original Message ----- 
From: "Bill de Carle" <bill1@cgocable.ca>
To: <rsgb_lf_group@blacksheep.org>; <lowfer@qth.net>
Sent: Friday, December 08, 2000 4:58 PM
Subject: LF: QRSS - "LEK" raw data available


> I made another pass at LEK's QRSS-CW signal last night and managed to
> get some excellent data for analysis.
> 
> I set the machine to record from 5:15 am thru 7:00 am local (EST) time.
> After I crunched the raw data, LEK's CW ident was clearly audible in
> there for most of that time.  Conditions seemed to be very good last
> night, weather was clear and crisp (overnight low here was minus 28C,
> about 18 degrees below zero F, and that would have occurred pretty much
> right while I was recording).
> 
> The raw data file is a little over 100 Mb, so I extracted a representative
> sample which crunches down to about the same signal quality I posted last
> time.
> 
> The raw data was sampled at 8200 samples per second, 16-bit signed binary.
> There is a file called SLIVER02.AUD which has 665640 samples of this data,
> about 81 seconds of audio.  If you CRUNCH it you can recover one complete
> "LEK " ident sequence that sounds fine.
> 
> If you're interested you can download the file (about 1 Mb) from:
> 
> http://cafe.rapidus.net/bill1/sliver02.zip
> 
> Bill VE2IQ
> 
>