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" <[email protected]>
Sent: Sunday, December 28, 2008 7:35 PM
To: <[email protected]>
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
|
