Message-ID: <4957FDE8.7010008@telus.net>
Date: Sun, 28 Dec 2008 14:30:00 -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> <4957D4F8.9000709@telus.net> <F4491236631044FC9C53742E1D817C69@AGB>
In-Reply-To: <F4491236631044FC9C53742E1D817C69@AGB>
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 Graham

Thanks for the info, WSPR having a 3db advantage is not surprising as 
the sequence is twice as long, but you can't average with WSPR!  I had a 
look at the results have the following comments on what may constitute 
further study in the mode on LF/MF:

1) JT2 unlike JT65 never had the average feature enabled to my knowledge.
2) Enabling the average feature would be  more meaningful over a path 
with significant long term fading like the EME path.  Your tests seemed 
somewhat local and the signal levels somewhat constant.
3) You where using what in JT65 speak is referred to as Type 1 message 
which is kinda special  and not a 'true' text msg.  See the WSJT manual 
and other articles by K1JT for more info...  Basically, if the sending 
box goes yellow on TX it's a type 1 message, red Type 2 (raw text) and 
blue, Type 3 shorthand...  Type 1 messages have an advantage over type 2 
messages...

 From K1JT's WSJT manual:
JT65 messages can have one of three basic formats:
1. Two to four alphanumeric fields with specific contents, as described 
below
2. Any other arbitrary text, up to 13 characters
3. Special shorthand messages RO, RRR, and 73

To use the average feature, clear the buffer when you start a listening 
sequence.  As the the sequences go by you'll see one of the two average 
numbers doing their thing depending on which sequence the station you're 
attempting to copy is.  You'll see numbering something like this:

222000   1   1/2
222000   2   0/1

The above means that sequence one had a good sync on one sequence but 
not enough signal to decode the signal, but the sequence was added to 
the average buffer.  Sequence 2 has one frame but not a good sync so the 
sequence was not added to the buffer...  The key to success is actively 
managing the average buffer.

Hope that makes sense. 

Would love to see a weak JT65 signal to monitor on 600m to do some tests.

73 Scott
VE7TIL






Graham wrote:
>
> Scott,,
>
> JT65
>
> I did a test with jt65 a while ago .. it stopped working about 3 db 
> before the wspr .beacon  the K1JT version gave a s/n level about 3 dB 
> better than the multipsk version ....not sure why as they where sent 
> on alternate odd/even slots via the same sound card/tx system
>
> The test encountered a little mid band qrm  from a mal adjusted cw 
> beacon at the time , but the results are at
>
> http://groups.google.com/group/uk500khz/web/jt65-a--jt2-tests
>
> G ...
>
> --------------------------------------------------
> From: "Scott Tilley" <sthed475@telus.net>
> Sent: Sunday, December 28, 2008 7:35 PM
> To: <rsgb_lf_group@blacksheep.org>
> Subject: Re: LF: Re: WSPR and CW
>
>>
>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>
>>
>> No virus found in this incoming message.
>> Checked by AVG - http://www.avg.com
>> Version: 8.0.176 / Virus Database: 270.10.0/1866 - Release Date: 
>> 12/27/2008 20:49
>>
>
>
>