Hi,
I recently installed WSJT ver 8 on the shack PC and was suprised to see it wanting to over write the existing WSJT ver 7.x install, which you can avoid by telling it to install to a NEW location, then you can keep both. I suspect the K1JT wants to get everyone onto the new version ASAP but considering its a BETA I wanted to keep ver 7 working here.
Something else that suprised me was the amount of CPU resources this new version sucks up. Under ver 7 and before the shack PC (XP SP3) was happy under the load (Pent 4 1.8 GHz) but now it is noticably starved of resources, a DECODE operation at the end of a JTMS period can take up to around 5-7 seconds to complete along with a general slow down of anything else running. (delays not seen under ver 7 or earlier)
Are others noticing it is a bit hungry or has my shack PC past its use-by date?
Regards,
WSJT-8 Your impressions
-
VK5PJ
- Forum Diehard
- Posts: 708
- Joined: Sat Apr 02, 2005 7:38 pm
- Location: Barossa Valley S.A
- Contact:
WSJT-8 Your impressions
Peter Sumner, vk5pj
You have enemies? Good. That means you've stood up for something, sometime in your life.
- Winston Churchill
You have enemies? Good. That means you've stood up for something, sometime in your life.
- Winston Churchill
Re: WSJT-8 Your impressions
Did you see the e-mail from K1JT below regarding the first results with WSJT8 (beta) a few days ago?
Apparently the European MS guys are not impressed with JTMS, particularly its inability to decode pings less than 75mS (versus 40mS in FSK441).
On the other hand, ISCAT mode has had some positive results/feedback.
... seems there is more work to be done before WSJT8 might be considered a worthy successor to WSJT7 ... however, that is what beta releases are about
73, Bob ZL1RS
From: Joe Taylor <joe@Princeton.EDU>
To: "moon-net@list-serv.davidv.net" <moon-net@list-serv.davidv.net>, "wsjtgroup@yahoogroups.com" <wsjtgroup@yahoogroups.com>, WSJT Devel <wsjt-devel@lists.berlios.de>
Copy:
Date: Tue, 29 Jun 2010 15:30:22 -0400
Subject: [wsjtgroup] Tests of Experimental Modes in WSJT8
To: Users of WSJT
From: K1JT
My sincere thanks to all who have provided feedback on the experimental
testing of WSJT8!
The main purpose of these tests was to generate many on-the-air
recordings of signals using the four new experimental modes JTMS, ISCAT,
JT64, and JT8. These modes use a variety of schemes for
synchronization, source encoding, error-control coding, and modulation
-- most of them quite different from the protocols in WSJT7. The tests
were aimed at establishing how well each scheme performs under
challenging weak-signal conditions. This goal has been accomplished
very effectively, and I'm grateful to all those who sent me their
recordings.
Here are some early conclusions based on the many reports received from
around the world.
First, some technical results:
----------------------------------
1. The synchronization, coding, and modulation schemes built into JT8
and JT64 are effective. Both modes work well at HF; they also work well
for EME (although not with the decoders that were distributed in WSJT8
r1944). The decoders for both modes are sub-optimal in a variety of
ways, sometimes annoyingly so. They would need further work before they
could be declared suitable for a production release of WSJT8.
2. The modulation and coding scheme in JTMS works well for meteor
scatter at VHF. In particular, it has been clearly established that MSK
("minimum shift keying") is a viable modulation technique for the MS
path. Phase locking of a signal can be done reliably over the duration
of meteor pings and bursts. The bandwidth efficiency of MSK is very
attractive. A clear disadvantage of JTMS relative to FSK441 is that
JTMS cannot make good use of pings shorter than about 75 ms.
3. The ISCAT mode is highly effective for its intended purpose --
ionospheric scatter at 50 MHz -- and also for multi-hop Es signals too
weak for successful SSB or CW QSOs. I now have on hand many examples of
recorded ISCAT signals that decode perfectly while being essentially
inaudible and invisible on the waterfall display.
Now, some user-level results:
-----------------------------------
4. Many successful QSOs have been made with each of the new experimental
modes, both on their primarily intended propagation paths and on others.
The WSJT8 decoders are less polished and slower than those in WSJT7
(as was known to be true, even before any field tests were solicited).
5. Some users in IARU Region 1 are unhappy with the structured message
formats of JTMS and ISCAT, even though these structures are a super-set
of the well accepted ones in JT65. The reluctance seems to arise from a
wish to adhere strictly to procedures for MS QSOs dictated in Appendix
4, "Revised Meteor Scatter Procedures", described in the
VHF/UHF/Microwaves Committee Report Interim Meeting, Vienna 2004 (see
http://www.physics.princeton.edu/pulsar ... e04_02.rtf).
On this side of the Atlantic, we consider a QSO valid when operators
have exchanged callsigns, signal reports, and rogers. We do not dictate
the precise arrangement of information in the transmissions conveying
these bits of information.
The Region 1 VHF Managers Handbook, updated in May 2010, adopts the same
approach as used here in Region 2 (see
http://www.physics/princeton.edu/pulsar ... _V5_42.pdf ,
pp. 98-105). The WSJT8 message structures fully support the
requirements for valid QSOs laid out in the 2010 Handbook, which (I have
assumed) supersedes the 2004 document. If I am mistaken, I hope
someone will correct me.
6. Apparently someone has concluded (and "explained" to others) that
hashed callsigns are not usable by a DXpedition because the operator
would want to decode more than one caller while a QSO is going on. In
fact, there is no such problem. Hashed callsigns can be used very
effectively in such a situation. Many stations could be calling the DX
operator at once, and no confusion need arise over who is calling and
who is being worked. No doubt if WSJT8 is to survive, its eventual
User's Guide will need to give more examples, in order to allay this fear.
The Bottom Line?
--------------------
Each of the experimental modes is effective, and much has been learned
from their development and testing. However, the presently available
results do not support a conclusion that JT64 will provide substantial
advantages over JT65, or JT8 over JT4, or JTMS over FSK441. ISCAT is
clearly superior to JT6M in many -- perhaps most? -- circumstances, but
its decoder will need to be made faster if the mode is to become popular.
Happily, it seems likely that a number of lessons learned while
developing and testing JTMS, ISCAT, JT64, and JT8 can be back-ported to
the traditional WSJT7 modes with good effect. I intend to spend some
weeks looking into these possibilities before making a final decision on
whether WSJT8 merits further work.
As always, the views of others will be gratefully received!
-- 73, Joe, K1JT
Apparently the European MS guys are not impressed with JTMS, particularly its inability to decode pings less than 75mS (versus 40mS in FSK441).
On the other hand, ISCAT mode has had some positive results/feedback.
... seems there is more work to be done before WSJT8 might be considered a worthy successor to WSJT7 ... however, that is what beta releases are about
73, Bob ZL1RS
From: Joe Taylor <joe@Princeton.EDU>
To: "moon-net@list-serv.davidv.net" <moon-net@list-serv.davidv.net>, "wsjtgroup@yahoogroups.com" <wsjtgroup@yahoogroups.com>, WSJT Devel <wsjt-devel@lists.berlios.de>
Copy:
Date: Tue, 29 Jun 2010 15:30:22 -0400
Subject: [wsjtgroup] Tests of Experimental Modes in WSJT8
To: Users of WSJT
From: K1JT
My sincere thanks to all who have provided feedback on the experimental
testing of WSJT8!
The main purpose of these tests was to generate many on-the-air
recordings of signals using the four new experimental modes JTMS, ISCAT,
JT64, and JT8. These modes use a variety of schemes for
synchronization, source encoding, error-control coding, and modulation
-- most of them quite different from the protocols in WSJT7. The tests
were aimed at establishing how well each scheme performs under
challenging weak-signal conditions. This goal has been accomplished
very effectively, and I'm grateful to all those who sent me their
recordings.
Here are some early conclusions based on the many reports received from
around the world.
First, some technical results:
----------------------------------
1. The synchronization, coding, and modulation schemes built into JT8
and JT64 are effective. Both modes work well at HF; they also work well
for EME (although not with the decoders that were distributed in WSJT8
r1944). The decoders for both modes are sub-optimal in a variety of
ways, sometimes annoyingly so. They would need further work before they
could be declared suitable for a production release of WSJT8.
2. The modulation and coding scheme in JTMS works well for meteor
scatter at VHF. In particular, it has been clearly established that MSK
("minimum shift keying") is a viable modulation technique for the MS
path. Phase locking of a signal can be done reliably over the duration
of meteor pings and bursts. The bandwidth efficiency of MSK is very
attractive. A clear disadvantage of JTMS relative to FSK441 is that
JTMS cannot make good use of pings shorter than about 75 ms.
3. The ISCAT mode is highly effective for its intended purpose --
ionospheric scatter at 50 MHz -- and also for multi-hop Es signals too
weak for successful SSB or CW QSOs. I now have on hand many examples of
recorded ISCAT signals that decode perfectly while being essentially
inaudible and invisible on the waterfall display.
Now, some user-level results:
-----------------------------------
4. Many successful QSOs have been made with each of the new experimental
modes, both on their primarily intended propagation paths and on others.
The WSJT8 decoders are less polished and slower than those in WSJT7
(as was known to be true, even before any field tests were solicited).
5. Some users in IARU Region 1 are unhappy with the structured message
formats of JTMS and ISCAT, even though these structures are a super-set
of the well accepted ones in JT65. The reluctance seems to arise from a
wish to adhere strictly to procedures for MS QSOs dictated in Appendix
4, "Revised Meteor Scatter Procedures", described in the
VHF/UHF/Microwaves Committee Report Interim Meeting, Vienna 2004 (see
http://www.physics.princeton.edu/pulsar ... e04_02.rtf).
On this side of the Atlantic, we consider a QSO valid when operators
have exchanged callsigns, signal reports, and rogers. We do not dictate
the precise arrangement of information in the transmissions conveying
these bits of information.
The Region 1 VHF Managers Handbook, updated in May 2010, adopts the same
approach as used here in Region 2 (see
http://www.physics/princeton.edu/pulsar ... _V5_42.pdf ,
pp. 98-105). The WSJT8 message structures fully support the
requirements for valid QSOs laid out in the 2010 Handbook, which (I have
assumed) supersedes the 2004 document. If I am mistaken, I hope
someone will correct me.
6. Apparently someone has concluded (and "explained" to others) that
hashed callsigns are not usable by a DXpedition because the operator
would want to decode more than one caller while a QSO is going on. In
fact, there is no such problem. Hashed callsigns can be used very
effectively in such a situation. Many stations could be calling the DX
operator at once, and no confusion need arise over who is calling and
who is being worked. No doubt if WSJT8 is to survive, its eventual
User's Guide will need to give more examples, in order to allay this fear.
The Bottom Line?
--------------------
Each of the experimental modes is effective, and much has been learned
from their development and testing. However, the presently available
results do not support a conclusion that JT64 will provide substantial
advantages over JT65, or JT8 over JT4, or JTMS over FSK441. ISCAT is
clearly superior to JT6M in many -- perhaps most? -- circumstances, but
its decoder will need to be made faster if the mode is to become popular.
Happily, it seems likely that a number of lessons learned while
developing and testing JTMS, ISCAT, JT64, and JT8 can be back-ported to
the traditional WSJT7 modes with good effect. I intend to spend some
weeks looking into these possibilities before making a final decision on
whether WSJT8 merits further work.
As always, the views of others will be gratefully received!
-- 73, Joe, K1JT
Bob, ZL1RS in the Bay of Islands at RF64vs
-
VK6KXW
WSJT-8 Your impressions
from the JT65-HF reflector
The Beta period for WSJT8 release r1944 is now over, and Joe Taylor has published a summary of the data he has received from Beta testers. (See the WSJT Yahoo group, membership required.) No law against continuing to experiment with these modes as released in r1944, but be aware that there are numerous bugs and limitations in r1944, and the new modes are now once again either under further development or have been at least temporarily laid to rest. Joe's summary statement included the observation that the Beta test results showed no compelling superiority of JT64, JT8, or JTMS over their existing WSJT7 analogs (JT65, JT4, and FSK441 respectively), but that ISCAT, a possible replacement for JT6M, showed real promise if the decoder could be made much faster. ISCAT is characterized for use in extreme weak-signal ionoscatter, sporadic-E, or F2 propagation modes. It could be used on HF in the same manner as JT65A is being used now, if it is ever ready for prime-time.
Bill W5WVO
............................................................................................................................................................................................
from the wsjt group
1c. Re: WSJT8 Numbers
Posted by: "Joe Taylor" joe@Princeton.EDU k1jt
Date: Wed Jun 30, 2010 5:13 am ((PDT))
Hi All,
G0DJA wrote:
> > I wonder what the two numbers to the right of the decode screen in JT8 mean?
WSJT8 is an experimental program release designed to obtain on-the-air
experience with four experimental protocols. Decoders for the four
modes are functional but not yet optimized for either speed or
performance. The end-of-line numbers are there to help me do these
things. They are programmer's numbers, not general user numbers; that's
why I didn't spend time writing about them in the hastily-assembled
User's Guide.
The numbers mean different things in each mode, and these details are
subject to change in any future release.
JTMS: The first quantity is the number of hard-decision errors found
when comparing the 32-bit sync vector with its correct form. Low
numbers are good. Anything greater than 6 (or 8 if "aggressive
deecoding" has been requested) is treated as sync failure and rejected.
The second quantity is a measure of the metric returned by the Viterbi
decoder. Bigger is better.
ISCAT: First number is decoder type: 0=unsuccessful; 1=shorthand
message; 2=hard-decision Reed Solomon; 3=Koetter-Vardy algebraic soft
decision. Second number is starting time (0-30 s) of decoded
information. Third is number of repetitions of TxT (see Appendix C of
manual) averaged to produce the decode.
JT64: First number is decoder type: 2=hard-decision Reed Solomon,
3=Koetter-Vardy algebraic soft decision. Second number is 0.
JT8: First number is a measure of metric returned by Viterbi decoder.
Second number is the value currently taken as minimum acceptable measure.
-- 73, Joe, K1JT
The Beta period for WSJT8 release r1944 is now over, and Joe Taylor has published a summary of the data he has received from Beta testers. (See the WSJT Yahoo group, membership required.) No law against continuing to experiment with these modes as released in r1944, but be aware that there are numerous bugs and limitations in r1944, and the new modes are now once again either under further development or have been at least temporarily laid to rest. Joe's summary statement included the observation that the Beta test results showed no compelling superiority of JT64, JT8, or JTMS over their existing WSJT7 analogs (JT65, JT4, and FSK441 respectively), but that ISCAT, a possible replacement for JT6M, showed real promise if the decoder could be made much faster. ISCAT is characterized for use in extreme weak-signal ionoscatter, sporadic-E, or F2 propagation modes. It could be used on HF in the same manner as JT65A is being used now, if it is ever ready for prime-time.
Bill W5WVO
............................................................................................................................................................................................
from the wsjt group
1c. Re: WSJT8 Numbers
Posted by: "Joe Taylor" joe@Princeton.EDU k1jt
Date: Wed Jun 30, 2010 5:13 am ((PDT))
Hi All,
G0DJA wrote:
> > I wonder what the two numbers to the right of the decode screen in JT8 mean?
WSJT8 is an experimental program release designed to obtain on-the-air
experience with four experimental protocols. Decoders for the four
modes are functional but not yet optimized for either speed or
performance. The end-of-line numbers are there to help me do these
things. They are programmer's numbers, not general user numbers; that's
why I didn't spend time writing about them in the hastily-assembled
User's Guide.
The numbers mean different things in each mode, and these details are
subject to change in any future release.
JTMS: The first quantity is the number of hard-decision errors found
when comparing the 32-bit sync vector with its correct form. Low
numbers are good. Anything greater than 6 (or 8 if "aggressive
deecoding" has been requested) is treated as sync failure and rejected.
The second quantity is a measure of the metric returned by the Viterbi
decoder. Bigger is better.
ISCAT: First number is decoder type: 0=unsuccessful; 1=shorthand
message; 2=hard-decision Reed Solomon; 3=Koetter-Vardy algebraic soft
decision. Second number is starting time (0-30 s) of decoded
information. Third is number of repetitions of TxT (see Appendix C of
manual) averaged to produce the decode.
JT64: First number is decoder type: 2=hard-decision Reed Solomon,
3=Koetter-Vardy algebraic soft decision. Second number is 0.
JT8: First number is a measure of metric returned by Viterbi decoder.
Second number is the value currently taken as minimum acceptable measure.
-- 73, Joe, K1JT
-
VK2KRR
Re: WSJT-8 Your impressions
Not found any stations willing to test it yet so cant comment.
-
VK7JG
Re: WSJT-8 Your impressions
I have installed WSJT-8 although I have as yet not had a contact using it , I do find that having an EME Echo test is great . As it is missing from WSJT-7 and along the way I have deleted the original versions.
And yes it does work.
73
Joe
And yes it does work.
73
Joe
Re: WSJT-8 Your impressions
Hi Guys,
Have been testing wsjt8 a bit with Phil vk4fil and Brian vk4ek most mornings on the meteor scatter sessions on 50.230. Brad vk2qo (cw/ssb) is usually on 50.200 with the regulars chasing 'ms'.
So far it seems that jtms works, but fsk441 still hold its own for fast scatter. jt6m gives regular decodes plus 'rubbish' , whereas ISCAT gives (almost) error free decodes, but you often hear and see bursts, but it often not decode, where as jt6m usually decodes, plus some garbage, but you can still see the call sign & report.
Happy to do tests anytime.
Every month a new mode, what's next?
Cheers, Darrell vk2bls
Have been testing wsjt8 a bit with Phil vk4fil and Brian vk4ek most mornings on the meteor scatter sessions on 50.230. Brad vk2qo (cw/ssb) is usually on 50.200 with the regulars chasing 'ms'.
So far it seems that jtms works, but fsk441 still hold its own for fast scatter. jt6m gives regular decodes plus 'rubbish' , whereas ISCAT gives (almost) error free decodes, but you often hear and see bursts, but it often not decode, where as jt6m usually decodes, plus some garbage, but you can still see the call sign & report.
Happy to do tests anytime.
Every month a new mode, what's next?
Cheers, Darrell vk2bls
-
VK4FIL
Re: WSJT-8 Your impressions
Hi,
Yes I agree with Darrell (vk2bls) in that we generally run the new ISCAT and JTMS modes on the 6 meter band 50.230mhz most mornings of the week.
We also run the old FSK441 and JT6M modes and have found that the older modes produce lots more rubbish decodes but seem to be lot more sensative and decode fast MS sigs.
JTMS seems to be the best of the new suite of programs in wsjt8 for our use on scatter and MS in the mornings. ISCAT although decoding only rarely does so at 100%. Some strong sigs even with long duration are not decoded with ISCAT which I am sure jt6m would quite happily decode.
Anyway more testing but love the fact that new software is emerging from Joe K1JT and I am sure there will be improvements in the future.
Regards,
Phil vk4fil
Yes I agree with Darrell (vk2bls) in that we generally run the new ISCAT and JTMS modes on the 6 meter band 50.230mhz most mornings of the week.
We also run the old FSK441 and JT6M modes and have found that the older modes produce lots more rubbish decodes but seem to be lot more sensative and decode fast MS sigs.
JTMS seems to be the best of the new suite of programs in wsjt8 for our use on scatter and MS in the mornings. ISCAT although decoding only rarely does so at 100%. Some strong sigs even with long duration are not decoded with ISCAT which I am sure jt6m would quite happily decode.
Anyway more testing but love the fact that new software is emerging from Joe K1JT and I am sure there will be improvements in the future.
Regards,
Phil vk4fil