Loading ...
Sorry, an error occurred while loading the content.

5711Re: FSK441 vs JT6M -- when to use

Expand Messages
  • k4ymq
    Feb 1, 2009
      There is one other situtation where JT6M far outshines 441. that is
      when a high noise floor is present. I have found that I can decode a
      ping through S5 to 6 noise level with JT6M where 441 decodes zip.
      But it is not a magic pill for noise, as it won't work through the S8
      to 9 that I have so often here. The power company and I are both
      chasing noise sources and I am getting better co operation. I am also
      making a big effort to eliminate sources of noise in my home. Found
      some suprises so far.. my washer and dryer generates noise even when

      --- In wsjtgroup@yahoogroups.com, "Bill W5WVO" <w5wvo@...> wrote:
      > I hope nobody is upset with my posting these little tutorials for
      > newbies. If anyone thinks this is an inappropriate use of this
      list, please
      > email the list owner and let him know. On the other hand, if you
      just don't
      > find it useful or interesting, please simply delete. Thanks.
      > -----------------------
      > Many, many WSJT newbies have asked me what the difference is
      between FSK441
      > and JT6M, and when each mode should be used in preference to the
      > First, some history and a little technical explanation.
      > FSK441 was developed as a mode expressly optimized for meteor-
      > propagation. It is capable of decoding an entire message in
      > less than 1 second. FSK441, like all WSJT modes, is AFSK, or audio
      > frequency-shift keying. Your sound card creates four audio tones in
      > sequences to encode the alphabet, numerals, and a few special
      > FSK441 is not a "smart" protocol, meaning that it does not analyze
      > patterns to determine message contents (as does JT65), nor does it
      > "most likely" message contents by averaging multiple decodes of the
      > string (as do both JT65 and JT6M). What FSK441 decodes, character by
      > character, is what you see in the decode window. It is a very
      MANUAL mode!
      > And to get the best decoding performance out of it, more operator
      smarts are
      > arguably required than for any of the other WSJT modes. (Advanced
      use of the
      > FSK441 tools in WSJT is beyond the scope of this short article, but
      such a
      > paper should be written.)
      > JT6M came along later. It is not a "dumb" protocol like FSK441
      because it is
      > capable of making some intelligent guesses about the content of the
      > being decoded. For this reason, and because it is a slower protocol
      > therefore requires less bandwidth than FSK441, JT6M is a more
      > mode. On average, you can decode a more-or-less steady strength
      JT6M signal
      > at better than 10 dB below the noise floor. In comparison, FSK441
      > signals at least 1 or 2 dB above the noise floor.
      > For this reason, a lot of hams jump to the conclusion that JT6M
      must be
      > better for long-distance meteor-scatter contacts because it is "more
      > sensitive". This conclusion is incorrect, and we'll discuss the
      > here.
      > As anyone knows who has had any experience with meteor-scatter work,
      > meteor-scatter radio propagation events (variously called pings,
      burns, or
      > bursts) come in all strengths and sizes, from the weak 1-dB, 100-
      > (ms) ping up to the 20-second long, speaker-rattling "blue whizzer"
      > by a bigger than usual meteor hitting the atmosphere in exactly the
      > place. Now, here's the technical part:
      > The amount of ionization created by a meteor burning up (called the
      > density) is determined by a number of variables, including the
      > composition, its mass, its speed, and its angle of entry. When a
      very high
      > plasma density is achieved momentarily, the effective Maximum Usable
      > Frequency (MUF) for that meteor trail is quite high, sometimes as
      high as
      > 432 MHz or more. However, since this extremely high plasma density
      > only in a small portion of the meteor's ion trail and begins to
      > quickly, pings in the high VHF and UHF ranges are infrequent and
      > narrow, usually less than 1 second duration. The higher in
      frequency you go,
      > the more narrow and the more infrequent meteor pings are.
      > FSK441 was designed to decode meteor pings as brief as 150 ms
      > Therefore, under normal circumstances on 2 meters and above, FSK441
      > really the only mode that will reliably provide meteor-scatter
      > communication.
      > On 6 meters, however, propagation can be sustained with a lower
      > density, and meteor pings tend, on average, to be longer in
      duration, often
      > lasting more than a second or two. JT6M requires a burn of at least
      > second, and more reliably two seconds, in order to encode/decode a
      > worst-case length message (both calls plus reports). These longer
      > allow the more sensitive JT6M mode to be usable for some meteor-
      scatter work
      > on 6 meters.
      > Now, there is a catch. Here is the nexus of the problem:
      > Very weak pings that might seem to make the higher JT6M sensitivity
      > advantageous also tend to be very short. Therefore, even if a 200-
      ms ping
      > several dB below the noise floor could theoretically be decoded by
      JT6M (and
      > could not be decoded by FSK441), the ping is oftentimes too short
      to contain
      > a reliably decodable JT6M message. So your extra sensitivity is of
      > use! Pings that are long enough to contain full JT6M messages are
      > typically more than strong enough to be decodable by FSK441. And
      FSK441 will
      > also decode comparatively weaker messages only a few hundreds of
      > milliseconds long.
      > Therefore, in most cases, FSK441 is still a better performer in 6-
      > meteor-scatter work than JT6M, though plenty of meteor-scatter QSOs
      can be
      > made and are made every day using JT6M. It's just a matter of the
      > percentages.
      > If conditions are strong and the station you are trying to work is
      in the
      > "sweet spot" for meteor-scatter propagation (500-800 miles), JT6M
      > virtually always work just fine. If, however, you are: (1) working
      > poor MS conditions, or (2) you are trying to work a station at the
      edge of
      > MS range, or (3) you are trying to work a station very close to you
      > high-angle, high-MUF meteors, it is better to use FSK441. Why?
      Because all
      > three of these conditions tend to produce pings that are
      > shorter in duration, and FSK441 simply works better for short pings.
      > JT6M, however, has a wonderful redeeming value. It is an
      outstanding mode
      > for very weak signal work when signal strengths are either fairly
      stable or
      > variable over a period of at least several seconds. Such signals
      can come
      > from tropospheric, D-layer ionoscatter, and weak sporadic-E
      > When F2 propagation begins to return to 6 meters in a few more
      years, we may
      > find that JT6M is an outstanding mode for completing 6-meter QSOs
      > propagation is still too weak to support SSB or even CW
      > In general, then:
      > (1) On bands above 6 meters, use FSK441 for meteor-scatter QSO
      > JT6M will generally not be useful on 2 meters and above.
      > (2) On 6 meters, use FSK441 as your default mode for meteor-scatter
      > attempts. Use JT6M only when meteor burns are fairly long -- at
      least a full
      > second. More often than not, these conditions will also produce
      burns that
      > are fairly strong as well, again on average.
      > (3) Use JT6M for weak-signal QSO attempts using atmospheric
      > modes like tropo, ionoscatter, and sporadic-E.
      > These are not laws, merely suggestions based on observation and a
      > science. Exceptions to these generalizations do occur regularly on
      6 meters.
      > Bill W5WVO
    • Show all 8 messages in this topic