Message-ID: <4957D4F8.9000709@telus.net>
Date: Sun, 28 Dec 2008 11:35:20 -0800
From: Scott Tilley <sthed475@telus.net>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: rsgb_lf_group@blacksheep.org
References: <4956BFEE.19110.2EE6D21@v.d.heide.on-line.de> <001601c968e6$912297e0$4201a8c0@home>
In-Reply-To: <001601c968e6$912297e0$4201a8c0@home>
Subject: Re: LF: Re: WSPR and CW
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org


Hi Jim

Interesting comments and its pretty much what I experience on WSPR HF.  
Another factor to consider with WSPR is the soundcard sampling rate it 
uses 12000sps.  Some have had issues with this as noted in a recent post 
on the WSPRnet blog:
http://wsprnet.org/drupal/node/339

This coupled with lack of time sync likely explains the issues 
encountered by 'super ham.' 

One thought would be to lengthen the sequence to deal with the 600m fade 
period OR allow WSPR to have an averaging function much like JT65.  With 
careful use of the average function in JT65 I was able to work many very 
small stations off the moon that would otherwise be impossible.  I bet 
the same would hold true for LF/MF and it would make all those not quiet 
good even sequences useful.

Has anyone tried JT65 on 600m???  That should send 'super ham' spinning...

73 Scott
VE7TIL

James Moritz wrote:
> Dear Klaus, Laurence, LF Group,
>
> I have been doing some experiments with WSPR on 2 PCs linked by audio
> cables. I would certainly agree with KL1X about the importance of clock
> accuracy - I found that an error of 5 seconds was enough to completely
> prevent decoding. Fortunately, the clock on my shack PC is accurate enough
> that setting it against an MSF-controlled clock once every several hours is
> OK.  I also found that the "QSO version" of WSPR in WSJT 7 and the WSPR 1.01
> beacon software will correctly decode each other's signals, although in
> either case the QSO mode requires reception of all the overs of the QSO in
> order to display the callsigns, due to the format used. When using the
> beacon software for reception, be aware that it may take some minutes for
> the decode to appear after the signal has been received - this seems to be
> due to the "off line" nature of the signal processing used.
>
> Recent experience here is that the WSPR mode offers advantages compared to
> CW, either manual or QRSS, on the 500kHz band due to the low SNR and the
> fading experienced. Many signals are either always below the audible noise,
> or not audible for long enough for aural CW copy without large numbers of
> repeats. With QRSS, and a sufficiently long dot period, one can indeed
> detect very weak signals, but the fading often prevents receiving, for
> example, a complete callsign without losing some symbols and so also
> requiring repeats. QRSS works much better on 136k, where the fading period
> is much longer.
>
> WSPR certainly decodes signals that are too weak for aural reception. In
> sensitivity terms, I think it is comparable to QRSS 3. WSPR has the
> advantage over QRSS 3 that the message duration is shorter. The 2 minute
> transmission period of WSPR is a reasonable match to the fading period
> experienced on 500kHz, so there is a good chance of sending the message
> successfully before the signal fades out. I have yet to see any readable
> trans-atlantic CW or QRSS signals at this QTH, while copy of WE2XGR//2 using
> WSPR was reasonably consistent, producing a decode for about 25% of the
> transmissions. The redundancy in the data should also make WSPR relatively
> resistant to errors caused by QRN impulses, although the QRN level has been
> low here recently. For beacon purposes, WSPR also has the huge advantage
> that reception, logging and reporting is automated, so the operator can go
> to bed sometimes!
>
> While WSPR does work well, I don't think it is the final word in LF/MF
> digital modes - In particular, the information in a QSO is largely
> restricted to "rubber stamp" exchanges. So I will certainly be interested in
> trying other modes, and look forward to see the results of Klaus' work.
>
> Cheers, Jim Moritz
> 73 de M0BMU
>
>
>
>
>
>
>
>