Re: [wsjt-eu] ISCAT and JT6M
- View SourceMany thanks to all who responded to my request for feedback on ISCAT and
JT6M! I've learned a number of new things. For reference, I will
include an abbreviated summary of received comments at the end of this
First, though, I'd like to respond in some detail to the excellent
points made by Tom Segalstad, LA4LN. I hope Tom (and anyone else!) will
comment further, if they have more to contribute to this public dialog.
I am sure that future versions of WSJT will benefit from such user input.
> When ISCAT was introduced, we tried a number of QSOs on 50 MHz and on 70It is a great pity that *nobody* bothered to report any of this to me,
> MHz using this new mode and JT6M under the same conditions, at different
> path lengths. Most of my operation via meteor scatter on 50 and 70 MHz
> is contest type operation. Then I need to make QSOs as fast as possible,
> in order to make as many QSOs as possible during the contest time
> period. The goal is of course to make as many points as possible, and
> ideally to win the contest. For each meteor scatter QSO we need to
> exchange call signs, reports, QTH locator, and the RRR, all according to
> the IARU standard.
> With this background or introduction, let me try to answer your questions.
> 1. Your understanding is correct. Many of us have tried ISCAT, and we
> went back to JT6M.
at the time.
The only negative comment I received about ISCAT from Europe was,
essentially, "it makes scatter QSOs too easy".
> 2. We are not skeptical to your statement that ISCAT has a significantlyNobody has shared this opinion with me before, either. For reasons I
> better performance that JT6M. The ISCAT mode decodes better, gives less
> undecoded "garbage" on the screen ... but here comes the snag: ISCAT is
> slower in finishing the QSO under weak conditions than JT6M. And that
> makes JT6M a better choice in making faster QSOs.
will go into further below, such feedback would have been extremely
useful. (Of course, it is still useful now.)
> Why is that? We, the operators, study the undecoded "garbage" on theMost definitely, I do not say such things !
> screen, to see if we can understand the message that we need. Maybe a
> partial "2" here and a partial "6" there -- and we understand that we
> received the report "26". We don't need to wait for a complete "26" to
> be decoded. ISCAT will not give us the partially decoded stuff. But JT6M
> will. Hence I will give one extra point for the JT6M. And we have saved
> time, giving another extra point for JT6M.
> But wait -- there is more. We can easily hear (with the ear) if JT6M is
> sending callsigns, or reports, or R in front of reports; definitely we
> can ear-decode RRR, and we also recognize "73". Even at so weak signal
> or noisy conditions, that the JT6M software is not decoding (cf. what I
> wrote before, about RTTY decoding by ear). And the RRR is the most
> important message, because it means that the QSO is completed! And its
> sound is so pronounced and easily recognizable with JT6M, that we don't
> need to see it on the screen when we hear it.
> This type of decoding by ear is not as easy with ISCAT. The most
> distinguished sound connected with the ISCAT messages is the high
> pitched periodic sound from "RRR". But it is not as pronounced as with
> JT6M. Hence JT6M got some more extra points vs. ISCAT.
> You may say that this is cheating! "Ear reception and decoding of my
> beautiful digital modes should be done by computers, and definitely not
> by ears and brains of well trained digital mode operators", you may say!
> Hence your programs should only be used by deaf people?
I've always strongly encouraged the use of every available decoding
means -- certainly including the operator's eyes and ears -- to copy
what's being received. It's hardly accidental that the short-form JT65
signals for the EME messages "RO", "RRR", and "73" are easily decoded by
eye and by ear. Good operators always use their eyes and ears on these.
I have a list of many ways in which the ISCAT decoder in WSJT9 can be
improved. Some of them directly address your wish to make the
completion of contest-style QSOs faster. (Faster than with JT6M, I
might add.) But nobody ever bothered to tell me that they considered
QSO speed an especially important goal... so until now, I have not
given these things a high programming priority.
There is absolutely no reason why ISCAT could not have
eye-and-ear-decodable messages for such things as R+rpt, RRR, 73, etc.
In North America we've done such things since the very first
introduction of FSK441. However, my impression was that these things
were basically sneered at in Europe. (Some were wholly opposed to the
idea of FSK441's "single tone" messages. So much so, that one unusually
loud blogger still brays about how such messages "carry no information"
-- despite the fact that we use them routinely, over here; and with
skilled operators, they virtually *never* lead to broken QSOs.)
Again, nobody in EU ever suggested that short-form messages might
enhance ISCAT. Nevertheless, such capabilities have been in the ISCAT
planning queue for some time, and have even been tested on the air.
With a little encouragement, they might come to pass in a released version.
> But when we need fast QSOs, using your software IN COMBINATION WITH earUnderstood, 100%. The only thing lacking was useful feedback!
> recognition of standard messages, we have experienced that many times we
> may complete a QSO in just half or 1/3 of the time it takes to complete
> the QSO with ISCAT. For a contester, this may mean up to, say, 3 times
> more contacts during the time the contest lasts. Hence this may make the
> difference between winning and losing.
> While ISCAT gives us 100% decoding on the screen, we crazy contesters
> don't necessarily need that. We need to complete the QSO, based on
> whatever partial decodes we have. Therefore we prefer the partial
> decoding given by JT6M, instead of the complete, but somewhat slower,
> decoding by the ISCAT.
> This is a vivid contester's experience. Like it or not ...
> 3. The most active VHF people here have tried and compared the modes,See below, on the "more familiar" point.
> and it doesn't look like people like a "more familiar" way of doing
> things. If ISCAT made faster QSOs in addition to better decoding, people
> would go for the ISCAT. For contest purposes, the QSO speed is given
> higher priority than a "cleaner decode screen".
> 4. Something else? Yes, indeed, for an experiment of long-haul QSOs whenYes and no. For a contester they may be rare or low-priority. For some
> time is subordinate, and we wanted a clean screen to prove a "first" QSO
> with a country, I would maybe choose the ISCAT, like in the examples you
> give. But these are fairly rare occasions.
others they are the most important things of all.
> Most of the time we want a fast QSO, with just enough informationI suspect that I've done more on-the-air testing of ISCAT than anyone
> exchanged to satisfy the QSO definition, like described above. And JT6M
> is a fantastic mode, in that we can combine the sounds we hear and the
> partial computer decoding on the screen, to find out what messages are
> being sent. This is not as easy when using ISCAT, according to our (my)
> experience so far.
else. My tests include the use of some un-released short-form message
styles. These messages could easily be polished up and released, if
there is significant support for them.
> And the same goes for JT6M vs. FSK441. That's why I prefer to use theAgain -- many optimizations of ISCAT are still possible. The mode is
> JT6M on 6m (50 MHz) and 4m (70 MHz) meteor scatter. But with pings and
> short bursts, we have to use FSK441 as the last way out.
> This is a description of my experience. And I would like to hear if
> others have the same experience as me, or can give me hints how to use
> Joe's software in a more efficient way. And with "more efficient way", I
> mean to get the necessary QSO exchange information the fastest way
> possible via meteor scatter (or other scatter propagation types) on 50
> and 70 MHz, certainly as a man + machine combination.
From my perspective, half the battle is determining with some
confidence what the majority of users want, and will support.
Finally, here is the promised summary of other responses received
1. Some have already worked, say 50 DXCCs with JT6M. They may be
reluctant to start over with ISCAT.
2. Many hams are conservative. We like old and familiar things.
3. Who would JT6M possibly prefer JT6M? ISCAT is clearly better.
4. Some may be using old, slow computers -- too slow for ISCAT?
5. WSJT 9.02 is broken; I've never been able to make it work reliably.
6. Some hams don't like to use beta releases. Make it a "full release",
and people will switch.
7. For really long-haul work, JT65A is better than either ISCAT or JT6M!
If anyone can add further useful comments, please do so. I am all ears!
-- 73, Joe, K1JT
- View SourceIn an email to Joe somebody wrote:
> > Why is that? We, the operators, study the undecoded "garbage" on theI really don't want to start a transatlantic flame war, but even in the days of
> > screen, to see if we can understand the message that we need. Maybe a
> > partial "2" here and a partial "6" there -- and we understand that we
> > received the report "26". We don't need to wait for a complete "26" to
> > be decoded. ISCAT will not give us the partially decoded stuff. But JT6M
> > will. Hence I will give one extra point for the JT6M. And we have saved
> > time, giving another extra point for JT6M.
200 letters per minute CW, sent and decoded with tape machines, most of us
with any integrity in Europe wouldn't accept just a single received character
as valid. Certainly, I always tried to copy at least two valid, contiguous,
characters before adding the result to my scratchpad. I suppose it depends on
how desperate you are to make the contact!
One of the several reasons why we in Europe don't like the idea of single-tone
reports and confirmations is that due to the much higher levels of activity
over here, there is a very significant chance that the signal heard doesn't
come from the guy you are trying to work!
There's more to this though. If I were to use the 'detected a single
character' criterion, I could have claimed to have been the first person to
have detected a signal across the Atlantic in tests with VO1/DM7MM in the 2009
Perseids. A group of us could probably have even claimed this in tests run in
the same shower during 1979 - see the RSGB magazine's VHF column for (I
think!) November 1979. I certainly received a QSL card for a 'completed'
transatlantic QSO from those tests, which I'm proud to say, went into the
trash can! It wasn't a QSO by my, or my friends' standards.
Although the data from 2009, looked-at in the raw FSK441 decodes, seemed to
provide evidence of more than a few very short bursts. The burst lengths were,
as might be expected, very short - tens of ms at best - and the signal levels
rather low. Quick sanity checks seemed to indicate that I wasn't fooling
myself. If I had time, I would run some proper statistical analyses on the
data, but extracting the information is very time consuming, and due to a
change in my personal circumstances, I can't see that I will be able to look
further for some time.
Incidentally, I'm not in any way 'anti-digital', having used most of the
modulation schemes suitable for VHF/microwave operation until my enforced QRT
in late 2009.
- View SourceHi Chris,
> I really don't want to start a transatlantic flame war, but......
> One of the several reasons why we in Europe don't like the idea of single-toneNo need for any transatlantic flames -- or indeed any flames at all.
> reports and confirmations is that due to the much higher levels of activity
> over here, there is a very significant chance that the signal heard doesn't
> come from the guy you are trying to work!
The words you worried about are from Tom, LA4LN, and I'm sure he'll
speak for himself if he wants to. But I can assure you, nobody has been
promoting any claims of valid copy on the basis of an odd single
character here and there.
Of course I'm well aware of the reasons single-tone reports are not used
in Region 1. Why do you think I've taken such care to make their use
optional, and indeed regional???
Over here, when we do use these signals, we've learned to do it in a way
that virtually *never* leads to broken or invalid QSOs.
> Although the data from 2009, looked-at in the raw FSK441 decodes, seemed toYou were kind enough to share those files with me, and I did some
> provide evidence of more than a few very short bursts. The burst lengths were,
> as might be expected, very short - tens of ms at best - and the signal levels
> rather low. Quick sanity checks seemed to indicate that I wasn't fooling
> myself. If I had time, I would run some proper statistical analyses on the
> data, but extracting the information is very time consuming, and due to a
> change in my personal circumstances, I can't see that I will be able to look
> further for some time.
analysis. As I said at the time, I did not find statistically reliable
evidence for any detected signal in the files.
So, as far as I can see, we're in perfect agreement about this.
While we're at it, do you have any response to my original questions
about ISCAT and JT6M mode?
With best wishes,
-- 73, Joe, K1JT
- View SourceHello Joe
Can I make it very clear that there was no negative criticism of any kind of
your work intended in my last email. Quite the opposite!
However, I'm afraid that I remain a sceptic regarding the use of single-tone
reports. If I recall the tests with VO/DM7MM, there was a period when I
received a single tone, which from its fading pattern appeared to be
propagated by meteor reflection - it sounded, and looked like a classic
'overdense' burst. Until I was able to speak to Joe, I had that marked as a
potential signal from him. It wasn't, as he was sending callsigns at that
time. But for about 48hours, I was optimistic!!
> You were kind enough to share those files with me, and I did someI don't think I ever received that reply, although it may have been lost in
> analysis. As I said at the time, I did not find statistically reliable
> evidence for any detected signal in the files.
the unrelated events which led to my close-down later in the year.
> So, as far as I can see, we're in perfect agreement about this.Certainly about the 2009 tests! Notwithstanding that, I still have a sneaking
suspicion that there may be some marginal indications in those files. However,
your use of statistics is clearly much more practiced than mine!
I still wouldn't discourage other people from trying MS into the (for want of
a better term) second-hop range. When I look at the potential improvements
which could have been made - particularly with regard to location at my end of
the circuit, transmitter power, and antenna gain - it should be possible to
improve the system by nearly 20dB.
> While we're at it, do you have any response to my original questionsNo. Unfortunately, I've been QRT since before ISCAT became available, and my
> about ISCAT and JT6M mode?
only experience of JT6M was briefly to see if it was useful for ionoscatter on
2m. (It was ...) Once I'm able to become active again, I'll probably once
again concentrate on microwave/mmwave EME, although if I'm finally able to find
a new QTH on a good site, I may just start playing on 144 and 432 ...
- View SourceDave, Jan, and all,
Thanks for your messages.
> Having read all the comments, leaving aside the technical issues,LA3EQ wrote:
> there are a significant number of people who want to use JT6M, so
> would the best option be
> to reinstate JT6M alongside ISCAT in the next revision and let the
> users decide which one they prefer to use.
> I agree with dave, G4RGK, Lets have both [ISCAT and JT6M] in the nextOf course, users can still choose. JT6M is available in WSJT7, ISCAT is
> rev. and let users choose.
> 1) What about an "auto detect" mode when listning to randomFeature requests are always welcome. You should be aware that this
> frequency...That way the program would choose automaticly the
> correct protcol (JT6M, ISCAT,etc) for ¨replying a random CQ call.
particular one may not receive a very high priority when the inevitable
time for "cost-benefit analysis" arrives.
Nobody would like it if the decoder took three times as long because it
had to try three different modes to see which matches a weak signal
best. Sure, you could add a mode-ID header to every WSJT signal, to
make this determination easier; but then there would be a significant
cost in threshold sensitivity. From its beginning, WSJT has been all
> 2) What about changing the TX/RX rate from 60 (or 30 sec) secISCAT already offers a choice of 30 s or 15 s T/R cycles.
> to 15 or even 10 sec. Timing would be thight, but the PA would
> be happyer due to less heat strain. And you would have faster qso's too...
Now, some philosophy:
User feedback is highly desirable, and I appreciate all received
comments and suggestions. My own decisions about what's included in
WSJT are never taken lightly, and they depend to a considerable extent
on feedback about real-world experience from users.
WSJT celebrated its 10th birthday last month. The program's development
has been a great learning experience for me (and for others who have
contributed to the code base). I'm happy that thousands of hams have
enjoyed using WSJT and its siblings. Perhaps many have learned good
things from that use, as well.
During its 10 years, WSJT has gained a number of new modes. It has lost
some modes when they were superseded by something better. "Survival of
the fittest," you might say.
JT44 was a good mode, but JT65 is certainly better. So JT44 was
dropped. FSK441-B and FSK441-C seemed like good ideas, but neither was
clearly superior to the original FSK441 over a wide range of conditions,
so they were dropped. Instead, performance of the original FSK441 was
JT2 worked well in controlled circumstances, but required better phase
stability than could be assured on its most interesting target
propagation paths. It was therefore dropped. On the other hand, JT4
has been kept, in part because some clever users found unanticipated
applications different from those I had envisioned.
The same thing is happening now with ISCAT. JT6M was dropped because
ISCAT is clearly better -- even in its original released form. And
ISCAT is still improving in a number of significant ways, thanks in part
to good user feedback. Some of that good feedback was received this
week, in response to my request.
One final thought:
It should be obvious that I won't be doing these things forever. When
it comes to matters under discussion here, I'm more like an architect
than a builder. I've always hoped that others with better programming
skills will take some of the ideas in WSJT, build on them, and create
more polished software than I can produce. That's one of the main
reasons that WSJT and its sister programs are open-source software.
One good example of this sort of cross-fertilization already exists: the
excellent program JT65-HF, by Joe Large, W6CQZ. Please, some others who
are interested and have the skills, accept my invitation to contribute
in this way to our wonderful hobby!
-- 73, Joe, K1JT
- View Source"It [WSJT] has lost some modes when they were superseded by something better."Joe summed it up there. I was always partial to JT44 in the old days. Heck, living only 30 miles from Princeton 10 years ago, I even helped a time or two with test transmissions of JT44. When it was superceded, I kept that old version on my computers for "years". Never used it [JT44] again. Now it's gone from my computer.Today, I keep a copy of WSJT7 with JT6M here. Because last year's Es season needed it. But I suspect that come May-July 2011, I will find most folks using ISCAT for those "marginal prop" attempts at US to DX QSOs. Might never use it [JT6M] again. And then it will be gone from my computer.And so it goes. ;>) Thanks for the continued work, Joe.Steve, W5KI----- Original Message -----From: Joe TaylorSent: Wednesday, April 06, 2011 10:11 AMSubject: [wsjtgroup] Re: [wsjt-eu] ISCAT and JT6M...During its 10 years, WSJT has gained a number of new modes. It has lost
some modes when they were superseded by something better. "Survival of
the fittest," you might say.
JT44 was a good mode, but JT65 is certainly better. ......The same thing is happening now with ISCAT. JT6M was dropped because
ISCAT is clearly better ...
- View SourceHi Ken and all,
With some concern that this may be starting to get repetitive, I'll try
to respond to your main points.
> I find that most users don’t even try using the digital modes on very longIf my understanding of ISCAT usage in EU is correct, how could you
> distance paths ( over 2000 kms) ... I
> have yet to see any real long distance qso’s being made with ISCAT.
expect to have seen such QSOs?
ISCAT hasn't yet been widely available during a northern hemisphere Es
season. Nevertheless, even in the first few weeks of field tests I made
ISCAT QSOs in the 3000-4000 km range. These QSOs were sub-audible, and
they could not have been made with JT6M.
> For myself I find that we are having more and more different modes comingThis is one of the reasons that when demonstrably better modes appear,
> along for people to try – and see which is the best – ROS, whisper – Joes
> portfolio etc.
> We are in danger and submerging in “what mode is best for XXX opening, what
> mode is better than YYY mode etc”
the modes they replace will (and should) eventually disappear.
A WSPR QSO mode was tried and tested, but for a number of good reasons
it never gained popularity. WSPR QSO mode has disappeared. The
beacon-like WSPR mode is extremely popular for what it does; but it does
not make 2-way QSOs.
ROS? Does anybody use it? I really don't know. (I never found it very
attractive, and some of its early claims could not be substantiated.)
> I have tried ISCAT on MS and find it is no better or worse than JT6M forA decision to move from JT6M to ISCAT was not made until after
> most qso’s – which have not exceeded 1800 kms. I pass no comment on whether
> is it or not better than JT6M – how can you judge – if the rocks aren’t
> there then you can’t compare. I haven’t had ANY qso’s over 1800 kms on ISCAT
> so again reserve judgement.
exhaustive tests -- tests under controlled laboratory conditions, as
well as on the air -- had shown it to be clearly superior.
If you have evidence to the contrary -- evidence, not "impressions" --
please make it public!
> The main gripe I have about ISACT, on MS, is that it doesn’t work well onThen I think you haven't yet learned to use ISCAT effectively. ISCAT
> weak short bursts ( that also may contain a bit of Doppler) – whereas , as
> above JT6M does – for me
can work well with bursts as short as just about any that can be useful
with JT6M. If the signal you're trying to copy is dominated by still
shorter bursts, you should be using FSK441.
This is important: all WSJT modes have benefited greatly by enhancements
to the decoders made after someone sent me recorded files with signals
they thought should have decoded, but did not. If you have any such
examples, please send them to me as email attachments!
> J. These short weak bursts that can be decoded byAgain: if you have not yet learned to get partial decodes from short and
> skilled use of JT6M are the backbone of MS as described above. If the
> digital programme being used only give full decodes and therefore requires
> long bursts – then there is no fun in it for me - as others have also
marginal ISCAT signals, then you're not yet up-to-speed in using ISCAT.
I know, of course, that better "how-to-use" instructions would be
helpful. I hope to get to that task, perhaps including some tutorial
files, before too long.
> It is a pity that JT6M was dropped as others have said from the later WSJTHere, I don't know what you mean. You must know that JT6M and ISCAT
> and that also the timings could not have been altered to 15 and 30 second
> periods, as I believe have been suggested in the past. If this were so then
> we might be able to compare apple with apples and not pears.
both use 30-second T/R cycles. (ISCAT also offers a 15-second period,
at least during this trial period.)
> ... JT6M, ISCAT etc are WEAK signal modes ( as Joe designed them) –No disagreement here. With adequate signals, you might as well use CW
> are again most people are using then for STRONG signal propagation – when
> ANY mode will do the job.
or SSB and have a real conversation!
-- 73, Joe, K1JT