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

Re: [wsjtgroup] Re: K7MKL/W6NF Rover

Expand Messages
  • Jeremy Alexander
    I personally have always leased land in a quite location for my stations. It is the best way to have great radio. I don t think it s that far fetched, but
    Message 1 of 7 , Sep 7, 2011
    • 0 Attachment
      I personally have always leased land in a quite location for my stations. It is the best way to have great radio. I don't think it's that far fetched, but maybe I have just been fortunate. Most of us can find a relative with a farm or some land somewhere. To completely remote a station even multi-bands on EME is no longer impratical, it isn't even difficult.... www.w7eme.org
       
      The matter on the loop omni for 6m meter scatter is also ok....I have placed many commercial stations for MCC and it is common to use a dipole as the transceive antenna at a meteor burst station such as for hydrology or seismic monitoring...with the parent facility out to 700 miles or so on 40 and 70MHz. Directive antennas are needed for the long haul, but you will miss the other directions doing this. The latter may be irrelevant if you are spotting or using a logger though....
       
      My opinions, Jeremy w7eme

      From: Bill VanAlstyne W5WVO <w5wvo@...>
      To: aesitt@...
      Cc: FFMA@yahoogroups.com; wsjtgroup@yahoogroups.com
      Sent: Wednesday, September 7, 2011 9:16 AM
      Subject: [wsjtgroup] Re: K7MKL/W6NF Rover

       
      Hi Ed,

      Maybe you didn't get it that Jack and his XYL are doing mobile/portable grid
      activations. Unless you're trying to activate a grid corner (confluence),
      finding a quieter location is just a matter of driving to somewhere else
      nearby and checking the noise floor from there. :-)

      Having said that... Selling your house, buying a new one, and moving
      somewhere else JUST for a quieter ham radio location? I don't know. I guess
      if you're single, have no obligations to anybody or anything, and have
      plenty of money to throw at any exigencies that may arise, you could do it
      relatively painlessly. Most of us have a more interconnected lifestyle than
      that.

      OOTH, if your xyl is also a ham and has the same priorities you do, maybe
      it's not as unthinkable as it might sound on the face of it.

      Bill W5WVO

      I wonder how many people relocated because of a noisy location??

      (4) Too noisy an environment. If your background antenna noise level is more
      than S-2 or S-3 on your S-meter, your noise level is probably too high to
      make very many contacts on meteor scatter with a small antenna setup. Find a
      quieter location.

      ed n5jeh

      -----Original Message-----
      From: aesitt@...
      Sent: Wednesday, September 07, 2011 15:06
      To: Bill VanAlstyne W5WVO
      Cc: FFMA@yahoogroups.com ; wsjtgroup@yahoogroups.com
      Subject: Re: K7MKL/W6NF Rover

      Bill VanAlstyne W5WVO writes:

      > That�s a good suggestion to check first, as it�s easy to see and correct
      > if need be.
      > There are possibly two or more different problems here: (a) Not seeing (in
      > the waterfall) very many pings to decode; and (b) not being able to decode
      > signals that are obviously there.
      >
      > Here are a few possibilities that could account for (a) Not seeing (in the
      > waterfall) very many pings to decode:
      > (1) Too small/low an antenna. A mobile loop is generally not going to work
      > very well on meteor scatter, although it can work quite well on SSB/CW
      > under a strong sporadic-E opening. Meteor-scatter signals are usually
      > quite a bit weaker than that, though an occasional big burn (such as the
      > one you describe) does happen maybe once an hour, on average. Being able
      > to receive only big burns doesn�t give you enough to work with to make
      > regular QSOs. You should be seeing a decodable ping or burn every 5
      > minutes or so during morning �prime time� hours. Evenings are much slower
      > than that. Generally the minimum antenna for meteor scatter work in the
      > field is a 3-element yagi up at least 20 feet. (The difference in
      > performance between 15 feet and 20 feet is huge on 6 meters due to ground
      > effect and take-off angle.)
      > (2) Really cheap coax (like Radio Shack RG-58/U); extra unneeded coax
      > coiled up somewhere in-line. You put both of these together and you have a
      > built-in loss of 3 dB or more. You can�t afford to give away that much
      > signal on meteor scatter. With a small portable antenna setup, most
      > decodable signals are going to be between the noise floor and 3-4 dB. It�s
      > the exceptional signals that are stronger than that. You want more and
      > stronger pings? Going from 3 elements at 20 feet to 5 elements at 30 feet
      > is like night and day.
      > (3) A bad coax connector somewhere in-line. PL-259s are not difficult to
      > install correctly, but they are very easy to install badly. Remember that
      > just because a connector measures OK at DC with an ohmmeter doesn�t mean
      > it�s going to look good at 50 MHz RF.
      > (4) Too noisy an environment. If your background antenna noise level is
      > more than S-2 or S-3 on your S-meter, your noise level is probably too
      > high to make very many contacts on meteor scatter with a small antenna
      > setup. Find a quieter location.
      > (5) Improper receiver setup. You must be set up in USB mode or its
      > equivalent (some radios have a �digital� mode that emulates USB). IF
      > bandwidth must be at least 2 kHz. Any receive equalization should be
      > turned OFF. Be sure that the receiver audio output is adjusted so that the
      > noise floor registers around 0 dB on SpecJT.
      > (6) Computer clock not accurately set to correct time (within 1 second).
      > If your computer clock is not set to within 1 second, then you are giving
      > away time on both sequences.
      > (7) Inadequate receiver gain. Disconnect the antenna from the radio and
      > reconnect it. You should see and hear a very definite change in noise
      > level when you disconnect and reconnect the antenna. If everything above
      > this point checks out, then it�s possible your receiver doesn�t have
      > enough gain on 6 meters and you need an external pre-amp. (THIS IS NOT A
      > COMMON PROBLEM! ELIMINATE EVERYTHING ELSE FIRST BEFORE COMING TO THIS
      > CONCLUSION.)
      >
      > Here are a few possibilities (in no particular order) that could account
      > for (b) not being able to decode signals that are obviously there:
      > (1) The receive clock correction factor (discussed by K6EU) is non-1.0000.
      > Fix it as he described.
      > (2) �Tol� is set to too low a number, thereby eliminating signals that are
      > further away from the dial frequency than that number of Hertz. Leave
      > �Tol� set to the default �400� unless/until you need to set it lower and
      > understand what doing this will accomplish. Then don�t forget to set it
      > back to �400� before starting the next QSO attempt.
      > (3) �S� is set to too high a number, thus eliminating weak signals from
      > the decode attempt. If �S� is set above �1�, there will be some
      > discrimination against weak signals. The default setting is �1�, and
      > values of ��1�, �0�, and �1� work well. The higher number (�1�, the
      > default) will produce fewer �garbage� decodes, while �-1� will allow you
      > to see decoded characters amidst the garbage in an extremely weak signal.
      > Settings below �-1� typically get you nothing but more garbage and make
      > strong signals more difficult to decode.
      > (3) You are depending only on the automatic decode that happens at the end
      > of each �AUTO mode� receiving period. The AUTO decode does very well in
      > most cases, but it will not necessarily catch and decode all pings.
      > Right-Click on pings as they occur on the waterfall during the receive
      > period. Click just before, in the middle of, and just after the end of the
      > ping. All will typically give you different sync points to start the
      > decode attempt.
      > (4) You are set to the wrong WSJT mode. This is unlikely because the mode
      > setting applies to both receive and transmit. Since you were being decoded
      > by others, it is safe to assume you were in FSK441 mode. However, this is
      > a good thing to be aware of. Make sure it says �FSK441� in the status
      > line, backed by the color YELLOW.
      > (5) Extremely strong signals may be difficult to decode if you are running
      > the receiver with AGC disabled. (Not necessary, but some ops prefer it for
      > various reasons.) To decode a very strong signal that you have already
      > captured, right-click just before the signal starts on the waterfall.
      > Clicking INSIDE THE CAPTURED STRONG SIGNAL will often produce no decode.
      > You can also try increasing the �S� value to 4 or 5 (but don�t forget to
      > set it back to 0 or 1 afterwards). Using a combination of changing the �S�
      > value and clicking away from the beginning of the signal, even very strong
      > signals can usually be decoded � but not always.
      > (6) You have an extremely strong �birdie� (unintentional signal) in the
      > passband on that frequency. The birdy must be extremely strong to prevent
      > weaker pings from being decoded. But to be on the safe side, pick a
      > different frequency with no birdies. If you must operate in the presence
      > of a birdie, check the �Zap� checkbox, and the software will stop trying
      > to decode the birdie as a short-hand (single tone) intentional
      > transmission.
      > General tips:
      > (1) RUN THE CURRENT SOFTWARE (v9.x). It�s better, and it�s what almost
      > everybody else is running. Less confusion, better results. You can
      > actually run v9.x in parallel with older revisions if your computer is
      > fast enough. This is extremely compute-intensive.
      > (2) Number 1 Newbie Error: Always sending all five of the FSK441 messages
      > in every QSO. Do NOT send every single message. Doing so does not
      > invalidate the QSO, but it is not in compliance with the standard
      > operating procedure and wastes a lot of time. You transmit the NEXT
      > message in sequence AFTER the message you just decoded. For example: If
      > you just decoded the other station sending message Tx2 (both calls plus
      > signal report or grid square, whichever the agreed-upon exchange is), then
      > you would NOT then send Tx2 also. You skip ahead to the next message, Tx3,
      > which is the letter �R� [i.e., �roger�] and the signal report or grid
      > square. This protocol is summarized in WSJT; press the �F5� function key
      > to see the summary.
      > (3) �Rx ST� and �Tx ST� (v9 software only) control the operation of
      > single-tone shorthand transmissions. Do not check these boxes unless or
      > until you specifically want to encode and transmit (Tx ST) or receive and
      > decode (Rx ST) a single-tone shorthand message. You can choose not to send
      > single-tone messages if you don�t feel comfortable with them, but you
      > cannot choose what the other station is going to send, so to some extent
      > you must be familiar with single-tone shorthand messaging anyway in case
      > that�s what you receive.
      > (4) Received single-tone shorthand messages do not have to be
      > computer-decoded where it is obvious that it is being sent by the station
      > you are in QSO with. Observing the tone�s absolute frequency on the
      > waterfall verifies that it�s the message you�re expecting; observing its
      > visual offset from the hash-marks on the waterfall (which offset will be
      > fairly consistent throughout a QSO) verifies that the source of the tone
      > is the station you�re in QSO with. This is enough to verify reception of
      > that message. Go on to the next message when it�s your turn to transmit.
      > (5) Use �AUTO� (QSO) mode. This is usually intuitive for most guys, but
      > not for all. Just depends on how your wetware is wired. When starting a
      > QSO attempt., click on �Auto is OFF� and it will turn red and say �Auto is
      > ON�. This causes transmission to occur automatically during the first 30
      > seconds or the 2nd 30 seconds of each minute, depending on whether you
      > have �Tx First� checked or not.
      > (6) There are two rules about who goes on first sequence: (a) A Grid
      > DXpedition station always goes first, regardless of location; (b) if Rule
      > (a) doesn�t apply, then the westernmost station goes first.
      > (7) Learn how to correctly use the Options screen in the Setup menu of the
      > main window. One of things there that you will need to pay attention to is
      > whether you are going to transmit signal reports or grids in your Tx2 or
      > Tx3 transmission. By default, most everybody uses signal reports (26
      > unless you change it on the fly), but this is not valid during contests,
      > where you must exchange grid squares (and get them right). You set this up
      > in the Options screen.
      > (8) Read the manual!
      > (9) Did I mention to read the manual?
      > (10) RTFM!!
      >
      > Hope this helps! :-)
      > Bill W5WVO
      >
      >
      > From: Tom Carney Sent: Wednesday, September 07, 2011 03:58
      > To: FFMA@yahoogroups.com Subject: Re: [FFMA] Re: K7MKL/W6NF Rover
      > Hi Jack
      > One possible cause of the "no decode" problem is a mismatch in the
      > "rate-in" value. If you are using version 9, there should be two numbers
      > in the box at the lower, left corner of the WSJT screen. Both numbers
      > should be very close to 1.000. Anything between .9995 and 1.0005 is OK.
      > The first number is the "rate-in" value. If it's not between .9995 and
      > 1.0005 you will need to configure the software for the actual value. To
      > do so, click on setup and the options. The rate-in number is on the left
      > hand side one from the bottom. Enter the actual value you observed
      > before.
      > Hope this helps
      > 73,
      > Tom K6EU
      >
      >
      >
      > On Tue, Sep 6, 2011 at 6:18 PM, Jack/W6NF <vhfplus@...> wrote:
      > In the words of Katy Perry: "epic fail" :<(
      > We honestly don't know what happened but we decoded no signals while
      > in DN00/10/20. We know now that there were many stations calling and
      > we apologize for the frustration...both ours and yours. We could hear
      > occasional pings and on one occasion, at about 1520Z, had a good
      > signal for no less than 10 seconds, but still nothing decoding even
      > with clearly audible signals.
      > We'll try to do some troubleshooting but, at this point, don't know
      > what the rest of the trip holds in store for FSK441.
      > Shelley and I plan to be back in both DN00 and DN10 after we get back
      > home on September 18th. Hopefully we can get our system fully
      > functional and activate those grids before October 1st. We'll keep
      > everyone informed.
      >
      > --
      > Jack, W6NF
      > Shelley, K7MKL
      > Silver Springs, NV
      > DM09ji
      >

      I wonder how many people relocated because of a noisy location??

      (4) Too noisy an environment. If your background antenna noise level is more
      than S-2 or S-3 on your S-meter, your noise level is probably too high to
      make
      very many contacts on meteor scatter with a small antenna setup. Find a
      quieter
      location.

      ed n5jeh



    • Bill VanAlstyne W5WVO
      Russ makes a good point — which is true for most receivers, or maybe we should say “many” receivers. There are a few variables that interact here, and
      Message 2 of 7 , Sep 7, 2011
      • 0 Attachment
        Russ makes a good point — which is true for most receivers, or maybe we should say “many” receivers. There are a few variables that interact here, and I’ll try to explain how that works.
         
        NOTE: This is long and somewhat technical. If not interested, delete now.
         
        Every type of signal, even CW (depending upon its speed), has a characteristic bandwidth, an amount of “horizontal space” needed for the width of a perfectly on-frequency, perfectly tuned-in signal, modulation and all, to “fit through”. Any receiver bandwidth that is wider than this requirement will also allow signals that are a little off-frequency to slip through as well. Sometimes this is what you want to happen (such as in FSK441 meteor-scatter), and sometimes it is not what you want to happen (weak DX station in a pile-up on 20m CW). Let’s look at FSK441 more closely.
         
        According to the WSJT manual, FSK441 consists of tones of four frequencies: 882, 1323, 1764, and 2205 Hz. A single character consists of three defined tones sent sequentially, each tone in its own time domain slot of 1/441st of a second, such that a complete character can be encoded and transmitted in 3/441st of a second, or approximately 6.8 ms. This means that the character rate of FSK441 is about 147 characters per second. The code is self-synchronizing because just one character (the <space>) comprises only the tones 882 Hz and 2205 Hz sent in the sequence of 882 Hz, 2205 Hz, and 2205 Hz. This is the only time these two tones are transmitted in this precise relationship, so when the decoder sees one time period of 882 Hz followed by two time periods of 2205 Hz, it knows two things: (a) that it is a space character, and (b) that the starting or synchronization point for this character is the beginning of the 882 Hz tone. The decoder can simply then count off three time slots for each subsequent (or prior) character in the buffer to establish which three bits constitute a “character”.
         
        This is all in the manual. See why you read it? :-)
         
        Now, with tones of four frequencies between 882 and 2205 Hz, you have a frequency range of 2205 –882 = 1323 Hz. This is the minimum theoretical bandwidth required to receive and decode one on-frequency FSK441 signal.
         
        But the IF bandwidth of a modern receiver in USB mode is typically wider than that, so we can tolerate the station being a little off-frequency. HOW off-frequency? That is the question — but the answer is easily arrived at. Here’s a test you can do.
         
        For this test, set up the WSJT audio gain so that you have a regular antenna noise floor — no signals, no birdies, just your regular constant-level band noise. Then, in the SpecJT window using the slider to left of the dB readout, set the slider so the noise floor reads 0 dB. (This is how WSJT should always be set up. Yes, it’s in the manual.)
         
        Now, temporarily set the “S” control to “10” to prevent WSJT from seeing any incoming noise bursts as possibly decodable signals. (CAUTION: Don’t forget to set it back to “0” when you’re done with this test.)
         
        Look at the main screen of WSJT in FSK441 mode while it is “monitoring” (receiving). In the upper-right area of this screen, you see a nearly square black box. In this box, you can see the four FSK441 frequencies shown as yellow hash-marks along the top of the box, and frequency in kHz along the bottom of the box. Inside the box, you see a magenta-colored curve that rises from the baseline, establishes a plateau that is (or should be) more or less flat, and then drops back down to the baseline. Though it is in fact not calibrated, you can think of the vertical axis of this little graph as being in dB (received amplitude).
         
        In an ideal receiver (which cannot be built in the real world), this curve looks like the top part of a square or rectangle. In other words, the vertical sides are the same length and square to the x-axis, while the top of the curve is a straight horizontal line and is square to both the sides. This means that any signal element (like an audio tone) could get through the passband right at one of the extremities without being attenuated at all — but if it  crossed over that extremity, the signal would be gone. Completely. This is the theoretical picture of a perfect “brick wall” filter. No real-world filter or radio IF passband can actually look like that, because in the real world, things take time and arrive at their designed states gradually — with some designs operating more gradually than others! (Very important concept.)
         
        What you want to see is a magenta envelope that looks as much like that theoretical box as possible — or to put it in more poetic terms, like a mesa here in New Mexico: steep (but not vertical) sides and pretty much flat on top. That’s what my Elecraft K3 looks like. My Kenwood TS-2000, on the other hand, looks a lot like a slightly lop-sided hill. This means that a wide signal (like FSK441) centered in the passband is going to be attenuated a few dB at the low and high ends because the “top” of the hill isn’t flat and broad enough. If the signal is reasonably strong, it will be recovered and decoded OK. If the ping is very weak, though, you might miss some of those 882 Hz and 2205 Hz tones — and remember that you need to recover both those frequencies from at least one space character to produce synchronization. No synchronization = random garbage = no decode.
         
        And that is one reason — there are many more — why some receivers are better than others. It’s not just about bells and whistles you’ll never need or use. It’s about basic circuit design, implementation, and the resulting measurable performance.
         
        Now, real-world — an FSK441 ping close to the center of that TS-2000’s passband is going to decode OK because the 882 Hz and 2205 Hz tones aren’t all that close to the slopes of the “hill” (the hill that should be a mesa). But let’s say the signal is 400 Hz off-frequency (the limit for which WSJT was designed). An FSK441 signal that far off frequency might not decode easily on too many rigs, but it will decode on a K3, when properly adjusted by the user. Why?
         
        Because on the K3, there is no attenuation of any frequency between the lowest and highest frequencies tolerated: 482 Hz on the low end (882 –400) and 2605 Hz on the high end (2205 +400). That’s a total bandwidth of over 2100 kHz – still narrower than a lot of guys will typically run their passband on USB for ragchewing, but wider than how a lot of SSB contesters and DXers run their receivers. First thing you have to check, then, is: What do you have your USB passband set to? (Or, what does the manufacturer have it set to, if it’s not user-settable?)
         
        Wider is better. Open it up as wide as you can. There is NO advantage to running a narrow passband on FSK441. You want it to be as wide as it will go. Running your passband wide open will cover up a multitude of sins in an entry-level radio. You do have to understand how your own radio works, of course, and how to change the width of the passband (if you can). Your radio’s manual will tell you. In some radios, you can even apply receive audio equalization to try to “flatten” the IF passband after the fact, but in most cases this is a waste of time, simply because it is after the fact. If the lowest or highest FSK441 tones have already been rolled off by the lousy IF passband shape, there is no way to get them back again.
         
        So the take-home message here is that some receivers probably won’t support the full plus/minus 400 Hz frequency range claimed by WSJT when a signal is both very weak and very off-frequency. But some will, and the K3 is one that will. There might be others. In all likelihood, they will all be down-conversion receivers to a first IF below 10 MHz, with a good SSB crystal roofing filter (nominally 2.7 kHz, plus or minus a few Hertz) ahead of a 1st IF amplifier. Do the experiment above and see what your passband looks like through WSJT!
         
        Thanks to Russ for pointing this out.
         
        Bill W5WVO
         
         
         
        Sent: Wednesday, September 07, 2011 13:42
        Subject: RE: [FFMA] Re: K7MKL/W6NF Rover
         
         

        Hi Bill. One thing you did not mention.  FSK441 is fairly forgiving of frequency errors, up to a point.  But if his transceiver is more than about 100 hz off frequency then decodes get harder and harder.  At 400 Hz error, decodes are impossible.
         
        73, Russ K2TXB


        From: FFMA@yahoogroups.com [mailto:FFMA@yahoogroups.com] On Behalf Of Bill VanAlstyne W5WVO
        Sent: Wednesday, September 07, 2011 8:33 AM
        To: FFMA@yahoogroups.com; wsjtgroup@yahoogroups.com
        Subject: Re: [FFMA] Re: K7MKL/W6NF Rover

        That’s a good suggestion to check first, as it’s easy to see and correct if need be.
         
        There are possibly two or more different problems here: (a) Not seeing (in the waterfall) very many pings to decode; and (b) not being able to decode signals that are obviously there.
         
         
        Here are a few possibilities that could account for (a) Not seeing (in the waterfall) very many pings to decode:
         
        (1) Too small/low an antenna. A mobile loop is generally not going to work very well on meteor scatter, although it can work quite well on SSB/CW under a strong sporadic-E opening. Meteor-scatter signals are usually quite a bit weaker than that, though an occasional big burn (such as the one you describe) does happen maybe once an hour, on average. Being able to receive only big burns doesn’t give you enough to work with to make regular QSOs. You should be seeing a decodable ping or burn every 5 minutes or so during morning “prime time” hours. Evenings are much slower than that. Generally the minimum antenna for meteor scatter work in the field is a 3-element yagi up at least 20 feet. (The difference in performance between 15 feet and 20 feet is huge on 6 meters due to ground effect and take-off angle.)
         
        (2) Really cheap coax (like Radio Shack RG-58/U); extra unneeded coax coiled up somewhere in-line. You put both of these together and you have a built-in loss of 3 dB or more. You can’t afford to give away that much signal on meteor scatter. With a small portable antenna setup, most decodable signals are going to be between the noise floor and 3-4 dB. It’s the exceptional signals that are stronger than that. You want more and stronger pings? Going from 3 elements at 20 feet to 5 elements at 30 feet is like night and day.
         
        (3) A bad coax connector somewhere in-line. PL-259s are not difficult to install correctly, but they are very easy to install badly. Remember that just because a connector measures OK at DC with an ohmmeter doesn’t mean it’s going to look good at 50 MHz RF.
         
        (4) Too noisy an environment. If your background antenna noise level is more than S-2 or S-3 on your S-meter, your noise level is probably too high to make very many contacts on meteor scatter with a small antenna setup. Find a quieter location.
         
        (5) Improper receiver setup. You must be set up in USB mode or its equivalent (some radios have a “digital” mode that emulates USB). IF bandwidth must be at least 2 kHz. Any receive equalization should be turned OFF. Be sure that the receiver audio output is adjusted so that the noise floor registers around 0 dB on SpecJT.
         
        (6) Computer clock not accurately set to correct time (within 1 second). If your computer clock is not set to within 1 second, then you are giving away time on both sequences.
         
        (7) Inadequate receiver gain. Disconnect the antenna from the radio and reconnect it. You should see and hear a very definite change in noise level when you disconnect and reconnect the antenna. If everything above this point checks out, then it’s possible your receiver doesn’t have enough gain on 6 meters and you need an external pre-amp. (THIS IS NOT A COMMON PROBLEM! ELIMINATE EVERYTHING ELSE FIRST BEFORE COMING TO THIS CONCLUSION.)
         
         
        Here are a few possibilities (in no particular order) that could account for (b) not being able to decode signals that are obviously there:
         
        (1) The receive clock correction factor (discussed by K6EU) is non-1.0000. Fix it as he described.
         
        (2) “Tol” is set to too low a number, thereby eliminating signals that are further away from the dial frequency than that number of Hertz. Leave “Tol” set to the default “400” unless/until you need to set it lower and understand what doing this will accomplish. Then don’t forget to set it back to “400” before starting the next QSO attempt.
         
        (3) “S” is set to too high a number, thus eliminating weak signals from the decode attempt. If “S” is set above “1”, there will be some discrimination against weak signals. The default setting is “1”, and values of “–1”, “0”, and “1” work well. The higher number (“1”, the default) will produce fewer “garbage” decodes, while “-1” will allow you to see decoded characters amidst the garbage in an extremely weak signal. Settings below “-1” typically get you nothing but more garbage and make strong signals more difficult to decode.
         
        (3) You are depending only on the automatic decode that happens at the end of each “AUTO mode” receiving period. The AUTO decode does very well in most cases, but it will not necessarily catch and decode all pings. Right-Click on pings as they occur on the waterfall during the receive period. Click just before, in the middle of, and just after the end of the ping. All will typically give you different sync points to start the decode attempt.
         
        (4) You are set to the wrong WSJT mode. This is unlikely because the mode setting applies to both receive and transmit. Since you were being decoded by others, it is safe to assume you were in FSK441 mode. However, this is a good thing to be aware of. Make sure it says “FSK441” in the status line, backed by the color YELLOW.
         
        (5) Extremely strong signals may be difficult to decode if you are running the receiver with AGC disabled. (Not necessary, but some ops prefer it for various reasons.) To decode a very strong signal that you have already captured, right-click just before the signal starts on the waterfall. Clicking INSIDE THE CAPTURED STRONG SIGNAL will often produce no decode. You can also try increasing the “S” value to 4 or 5 (but don’t forget to set it back to 0 or 1 afterwards). Using a combination of changing the “S” value and clicking away from the beginning of the signal, even very strong signals can usually be decoded – but not always.
         
        (6) You have an extremely strong “birdie” (unintentional signal) in the passband on that frequency. The birdy must be extremely strong to prevent weaker pings from being decoded. But to be on the safe side, pick a different frequency with no birdies. If you must operate in the presence of a birdie, check the “Zap” checkbox, and the software will stop trying to decode the birdie as a short-hand (single tone) intentional transmission.
         
        General tips:
         
        (1) RUN THE CURRENT SOFTWARE (v9.x). It’s better, and it’s what almost everybody else is running. Less confusion, better results. You can actually run v9.x in parallel with older revisions if your computer is fast enough. This is extremely compute-intensive.
         
        (2) Number 1 Newbie Error: Always sending all five of the FSK441 messages in every QSO. Do NOT send every single message. Doing so does not invalidate the QSO, but it is not in compliance with the standard operating procedure and wastes a lot of time. You transmit the NEXT message in sequence AFTER the message you just decoded. For example: If you just decoded the other station sending message Tx2 (both calls plus signal report or grid square, whichever the agreed-upon exchange is), then you would NOT then send Tx2 also. You skip ahead to the next message, Tx3, which is the letter “R” [i.e., “roger”] and the signal report or grid square. This protocol is summarized in WSJT; press the “F5” function key to see the summary.
         
        (3) “Rx ST” and “Tx ST” (v9 software only) control the operation of single-tone shorthand transmissions. Do not check these boxes unless or until you specifically want to encode and transmit (Tx ST) or receive and decode (Rx ST) a single-tone shorthand message. You can choose not to send single-tone messages if you don’t feel comfortable with them, but you cannot choose what the other station is going to send, so to some extent you must be familiar with single-tone shorthand messaging anyway in case that’s what you receive.
         
        (4) Received single-tone shorthand messages do not have to be computer-decoded where it is obvious that it is being sent by the station you are in QSO with. Observing the tone’s absolute frequency on the waterfall verifies that it’s the message you’re expecting; observing its visual offset from the hash-marks on the waterfall (which offset will be fairly consistent throughout a QSO) verifies that the source of the tone is the station you’re in QSO with. This is enough to verify reception of that message. Go on to the next message when it’s your turn to transmit.
         
        (5) Use “AUTO” (QSO) mode. This is usually intuitive for most guys, but not for all. Just depends on how your wetware is wired. When starting a QSO attempt., click on “Auto is OFF” and it will turn red and say “Auto is ON”. This causes transmission to occur automatically during the first 30 seconds or the 2nd 30 seconds of each minute, depending on whether you have “Tx First” checked or not.
         
        (6) There are two rules about who goes on first sequence: (a) A Grid DXpedition station always goes first, regardless of location; (b) if Rule (a) doesn’t apply, then the westernmost station goes first.
         
        (7) Learn how to correctly use the Options screen in the Setup menu of the main window. One of things there that you will need to pay attention to is whether you are going to transmit signal reports or grids in your Tx2 or Tx3 transmission. By default, most everybody uses signal reports (26 unless you change it on the fly), but this is not valid during contests, where you must exchange grid squares (and get them right). You set this up in the Options screen.
         
        (8) Read the manual!
         
        (9) Did I mention to read the manual?
         
        (10) RTFM!!
         
         
        Hope this helps! :-)
         
        Bill W5WVO
         
         
         
         
        Sent: Wednesday, September 07, 2011 03:58
        Subject: Re: [FFMA] Re: K7MKL/W6NF Rover
         
         

        Hi Jack

        One possible cause of the "no decode" problem is a mismatch in the "rate-in" value.  If you are using version 9, there should be two numbers in the box at the lower, left corner of the WSJT screen.   Both numbers should be very close to 1.000.  Anything between .9995 and 1.0005 is OK.  The first number is the "rate-in" value.   If it's not between .9995 and 1.0005 you will need to configure the software for the actual value.  To do so, click on setup and the options.  The rate-in number is on the left hand side one from the bottom.  Enter the actual value you observed before. 

        Hope this helps

        73,

        Tom K6EU



         

        On Tue, Sep 6, 2011 at 6:18 PM, Jack/W6NF <vhfplus@...> wrote:
         

        In the words of Katy Perry: "epic fail" :<(

        We honestly don't know what happened but we decoded no signals while
        in DN00/10/20. We know now that there were many stations calling and
        we apologize for the frustration...both ours and yours. We could hear
        occasional pings and on one occasion, at about 1520Z, had a good
        signal for no less than 10 seconds, but still nothing decoding even
        with clearly audible signals.

        We'll try to do some troubleshooting but, at this point, don't know
        what the rest of the trip holds in store for FSK441.

        Shelley and I plan to be back in both DN00 and DN10 after we get back
        home on September 18th. Hopefully we can get our system fully
        functional and activate those grids before October 1st. We'll keep
        everyone informed.



        --
        Jack, W6NF
        Shelley, K7MKL
        Silver Springs, NV
        DM09ji
         
      • Russ K2TXB
        Hi Bill, you did a great job explaining the technical reasons for my comment. I want to add a little. The most important thing is to make sure you know what
        Message 3 of 7 , Sep 7, 2011
        • 0 Attachment
          Hi Bill, you did a great job explaining the technical reasons for my comment.  I want to add a little.
           
          The most important thing is to make sure you know what frequency your radio is on.  Bill (and I) use radios that are very close but many do not, especially for portable operations.  I think many people would rather use an older radio when they are taking it out in the wild for a grid expedition, rather than a brand new K3 or what have you.  Those older radios can often be up to 500 Hz off frequency compared to the dial reading.  So find out how accurate your radio is, and either adjust it, or else calculate an offset that you will use.  So if your radio is 230 hz low, then you would set it at 144.140.23 if you are operating fsk441 at 144.140.  This does two things.  It make sure that your signal is where you said it is and will be in the center of the passband of others receiving you (assuming they know where their radios are tuned).  And it makes sure that the signals you hear will also be in the center of your passband.
           
          That is all good in theory, but what do you do if you still hear signals which will not decode, or which decode poorly?  The answer is to be observant of the number in the decode data called "DF".  DF means Delta Frequency", and it tells you how far away from your receiver frequency the received signal is.  If DF is near zero then you don't need to worry about it.  You will decode as well as possible.  But if DF is over 100 (hz) or so then I would advise adjusting your receiver to accommodate the off frequency signal.  You do this by one of two methods.  You can adjust only your receiver, by using the RIT offset control.  If you are sure your radio has accurate frequency readout than that may be the best way - especially if you are on an expedition, working stations as fast as possible on a designated frequency.  You don't want to be confusing everyone by moving your transmitter around.  If the guy is calling you, odds are that he is receiving you ok, so don't move the transmitter - just use the RIT.  That will center his signal in your rx passband and provide you the best chance to decode.  (Of course you still need to learn all the other decode tricks enumerated by Bill and apply them as required.)
           
          If you are working a sked with a single station, it may be appropriate to move your main dial, when you see a signal that has a high DF value.  This will (hopefully) center your signal in his receiver as well as get your receiver tuned to him.  But there is the danger that he has already 'found' you and has set his tolerance accordingly.  In that case moving your transmitter will cause him to lose you.  If you are fairly sure he has not yet decoded you, then moving the transmitter may be appropriate.  Otherwise leave it alone and just use the RIT.
           
          In the paragraph above I mentioned 'tolerance', as did Bill.  Tolerance is how far from your center frequency WSJT will 'look' for a FSK441   When you have found a signal and it is tuned in correctly, reducing tolerance will help if there are interfering signals in the passband.  But you lose the ability to decode signals that are off frequency, even if they are in your passband.  I have used tolerance a lot and it has helped make some difficult contacts possible, but you have to be alert and ready to turn it off if you realize that you are no longer decoding the pings.
           
          This got long, but I hope it is helpful to some of the FSK441 operators on these reflectors.
           
          73, Russ K2TXB
           


          From: FFMA@yahoogroups.com [mailto:FFMA@yahoogroups.com] On Behalf Of Bill VanAlstyne W5WVO
          Sent: Wednesday, September 07, 2011 8:38 PM
          To: FFMA@yahoogroups.com; wsjtgroup@yahoogroups.com
          Subject: Re: [FFMA] Re: K7MKL/W6NF Rover

          Russ makes a good point — which is true for most receivers, or maybe we should say “many” receivers. There are a few variables that interact here, and I’ll try to explain how that works.
           
          NOTE: This is long and somewhat technical. If not interested, delete now.
           
          Every type of signal, even CW (depending upon its speed), has a characteristic bandwidth, an amount of “horizontal space” needed for the width of a perfectly on-frequency, perfectly tuned-in signal, modulation and all, to “fit through”. Any receiver bandwidth that is wider than this requirement will also allow signals that are a little off-frequency to slip through as well. Sometimes this is what you want to happen (such as in FSK441 meteor-scatter), and sometimes it is not what you want to happen (weak DX station in a pile-up on 20m CW). Let’s look at FSK441 more closely.
           
          According to the WSJT manual, FSK441 consists of tones of four frequencies: 882, 1323, 1764, and 2205 Hz. A single character consists of three defined tones sent sequentially, each tone in its own time domain slot of 1/441st of a second, such that a complete character can be encoded and transmitted in 3/441st of a second, or approximately 6.8 ms. This means that the character rate of FSK441 is about 147 characters per second. The code is self-synchronizing because just one character (the <space>) comprises only the tones 882 Hz and 2205 Hz sent in the sequence of 882 Hz, 2205 Hz, and 2205 Hz. This is the only time these two tones are transmitted in this precise relationship, so when the decoder sees one time period of 882 Hz followed by two time periods of 2205 Hz, it knows two things: (a) that it is a space character, and (b) that the starting or synchronization point for this character is the beginning of the 882 Hz tone. The decoder can simply then count off three time slots for each subsequent (or prior) character in the buffer to establish which three bits constitute a “character”.
           
          This is all in the manual. See why you read it? :-)
           
          Now, with tones of four frequencies between 882 and 2205 Hz, you have a frequency range of 2205 –882 = 1323 Hz. This is the minimum theoretical bandwidth required to receive and decode one on-frequency FSK441 signal.
           
          But the IF bandwidth of a modern receiver in USB mode is typically wider than that, so we can tolerate the station being a little off-frequency. HOW off-frequency? That is the question — but the answer is easily arrived at. Here’s a test you can do.
           
          For this test, set up the WSJT audio gain so that you have a regular antenna noise floor — no signals, no birdies, just your regular constant-level band noise. Then, in the SpecJT window using the slider to left of the dB readout, set the slider so the noise floor reads 0 dB. (This is how WSJT should always be set up. Yes, it’s in the manual.)
           
          Now, temporarily set the “S” control to “10” to prevent WSJT from seeing any incoming noise bursts as possibly decodable signals. (CAUTION: Don’t forget to set it back to “0” when you’re done with this test.)
           
          Look at the main screen of WSJT in FSK441 mode while it is “monitoring” (receiving). In the upper-right area of this screen, you see a nearly square black box. In this box, you can see the four FSK441 frequencies shown as yellow hash-marks along the top of the box, and frequency in kHz along the bottom of the box. Inside the box, you see a magenta-colored curve that rises from the baseline, establishes a plateau that is (or should be) more or less flat, and then drops back down to the baseline. Though it is in fact not calibrated, you can think of the vertical axis of this little graph as being in dB (received amplitude).
           
          In an ideal receiver (which cannot be built in the real world), this curve looks like the top part of a square or rectangle. In other words, the vertical sides are the same length and square to the x-axis, while the top of the curve is a straight horizontal line and is square to both the sides. This means that any signal element (like an audio tone) could get through the passband right at one of the extremities without being attenuated at all — but if it  crossed over that extremity, the signal would be gone. Completely. This is the theoretical picture of a perfect “brick wall” filter. No real-world filter or radio IF passband can actually look like that, because in the real world, things take time and arrive at their designed states gradually — with some designs operating more gradually than others! (Very important concept.)
           
          What you want to see is a magenta envelope that looks as much like that theoretical box as possible — or to put it in more poetic terms, like a mesa here in New Mexico: steep (but not vertical) sides and pretty much flat on top. That’s what my Elecraft K3 looks like. My Kenwood TS-2000, on the other hand, looks a lot like a slightly lop-sided hill. This means that a wide signal (like FSK441) centered in the passband is going to be attenuated a few dB at the low and high ends because the “top” of the hill isn’t flat and broad enough. If the signal is reasonably strong, it will be recovered and decoded OK. If the ping is very weak, though, you might miss some of those 882 Hz and 2205 Hz tones — and remember that you need to recover both those frequencies from at least one space character to produce synchronization. No synchronization = random garbage = no decode.
           
          And that is one reason — there are many more — why some receivers are better than others. It’s not just about bells and whistles you’ll never need or use. It’s about basic circuit design, implementation, and the resulting measurable performance.
           
          Now, real-world — an FSK441 ping close to the center of that TS-2000’s passband is going to decode OK because the 882 Hz and 2205 Hz tones aren’t all that close to the slopes of the “hill” (the hill that should be a mesa). But let’s say the signal is 400 Hz off-frequency (the limit for which WSJT was designed). An FSK441 signal that far off frequency might not decode easily on too many rigs, but it will decode on a K3, when properly adjusted by the user. Why?
           
          Because on the K3, there is no attenuation of any frequency between the lowest and highest frequencies tolerated: 482 Hz on the low end (882 –400) and 2605 Hz on the high end (2205 +400). That’s a total bandwidth of over 2100 kHz – still narrower than a lot of guys will typically run their passband on USB for ragchewing, but wider than how a lot of SSB contesters and DXers run their receivers. First thing you have to check, then, is: What do you have your USB passband set to? (Or, what does the manufacturer have it set to, if it’s not user-settable?)
           
          Wider is better. Open it up as wide as you can. There is NO advantage to running a narrow passband on FSK441. You want it to be as wide as it will go. Running your passband wide open will cover up a multitude of sins in an entry-level radio. You do have to understand how your own radio works, of course, and how to change the width of the passband (if you can). Your radio’s manual will tell you. In some radios, you can even apply receive audio equalization to try to “flatten” the IF passband after the fact, but in most cases this is a waste of time, simply because it is after the fact. If the lowest or highest FSK441 tones have already been rolled off by the lousy IF passband shape, there is no way to get them back again.
           
          So the take-home message here is that some receivers probably won’t support the full plus/minus 400 Hz frequency range claimed by WSJT when a signal is both very weak and very off-frequency. But some will, and the K3 is one that will. There might be others. In all likelihood, they will all be down-conversion receivers to a first IF below 10 MHz, with a good SSB crystal roofing filter (nominally 2.7 kHz, plus or minus a few Hertz) ahead of a 1st IF amplifier. Do the experiment above and see what your passband looks like through WSJT!
           
          Thanks to Russ for pointing this out.
           
          Bill W5WVO
           
           
           
          Sent: Wednesday, September 07, 2011 13:42
          Subject: RE: [FFMA] Re: K7MKL/W6NF Rover
           
           

          Hi Bill. One thing you did not mention.  FSK441 is fairly forgiving of frequency errors, up to a point.  But if his transceiver is more than about 100 hz off frequency then decodes get harder and harder.  At 400 Hz error, decodes are impossible.
           
          73, Russ K2TXB


          From: FFMA@yahoogroups.com [mailto:FFMA@yahoogroups.com] On Behalf Of Bill VanAlstyne W5WVO
          Sent: Wednesday, September 07, 2011 8:33 AM
          To: FFMA@yahoogroups.com; wsjtgroup@yahoogroups.com
          Subject: Re: [FFMA] Re: K7MKL/W6NF Rover

          That’s a good suggestion to check first, as it’s easy to see and correct if need be.
           
          There are possibly two or more different problems here: (a) Not seeing (in the waterfall) very many pings to decode; and (b) not being able to decode signals that are obviously there.
           
           
          Here are a few possibilities that could account for (a) Not seeing (in the waterfall) very many pings to decode:
           
          (1) Too small/low an antenna. A mobile loop is generally not going to work very well on meteor scatter, although it can work quite well on SSB/CW under a strong sporadic-E opening. Meteor-scatter signals are usually quite a bit weaker than that, though an occasional big burn (such as the one you describe) does happen maybe once an hour, on average. Being able to receive only big burns doesn’t give you enough to work with to make regular QSOs. You should be seeing a decodable ping or burn every 5 minutes or so during morning “prime time” hours. Evenings are much slower than that. Generally the minimum antenna for meteor scatter work in the field is a 3-element yagi up at least 20 feet. (The difference in performance between 15 feet and 20 feet is huge on 6 meters due to ground effect and take-off angle.)
           
          (2) Really cheap coax (like Radio Shack RG-58/U); extra unneeded coax coiled up somewhere in-line. You put both of these together and you have a built-in loss of 3 dB or more. You can’t afford to give away that much signal on meteor scatter. With a small portable antenna setup, most decodable signals are going to be between the noise floor and 3-4 dB. It’s the exceptional signals that are stronger than that. You want more and stronger pings? Going from 3 elements at 20 feet to 5 elements at 30 feet is like night and day.
           
          (3) A bad coax connector somewhere in-line. PL-259s are not difficult to install correctly, but they are very easy to install badly. Remember that just because a connector measures OK at DC with an ohmmeter doesn’t mean it’s going to look good at 50 MHz RF.
           
          (4) Too noisy an environment. If your background antenna noise level is more than S-2 or S-3 on your S-meter, your noise level is probably too high to make very many contacts on meteor scatter with a small antenna setup. Find a quieter location.
           
          (5) Improper receiver setup. You must be set up in USB mode or its equivalent (some radios have a “digital” mode that emulates USB). IF bandwidth must be at least 2 kHz. Any receive equalization should be turned OFF. Be sure that the receiver audio output is adjusted so that the noise floor registers around 0 dB on SpecJT.
           
          (6) Computer clock not accurately set to correct time (within 1 second). If your computer clock is not set to within 1 second, then you are giving away time on both sequences.
           
          (7) Inadequate receiver gain. Disconnect the antenna from the radio and reconnect it. You should see and hear a very definite change in noise level when you disconnect and reconnect the antenna. If everything above this point checks out, then it’s possible your receiver doesn’t have enough gain on 6 meters and you need an external pre-amp. (THIS IS NOT A COMMON PROBLEM! ELIMINATE EVERYTHING ELSE FIRST BEFORE COMING TO THIS CONCLUSION.)
           
           
          Here are a few possibilities (in no particular order) that could account for (b) not being able to decode signals that are obviously there:
           
          (1) The receive clock correction factor (discussed by K6EU) is non-1.0000. Fix it as he described.
           
          (2) “Tol” is set to too low a number, thereby eliminating signals that are further away from the dial frequency than that number of Hertz. Leave “Tol” set to the default “400” unless/until you need to set it lower and understand what doing this will accomplish. Then don’t forget to set it back to “400” before starting the next QSO attempt.
           
          (3) “S” is set to too high a number, thus eliminating weak signals from the decode attempt. If “S” is set above “1”, there will be some discrimination against weak signals. The default setting is “1”, and values of “–1”, “0”, and “1” work well. The higher number (“1”, the default) will produce fewer “garbage” decodes, while “-1” will allow you to see decoded characters amidst the garbage in an extremely weak signal. Settings below “-1” typically get you nothing but more garbage and make strong signals more difficult to decode.
           
          (3) You are depending only on the automatic decode that happens at the end of each “AUTO mode” receiving period. The AUTO decode does very well in most cases, but it will not necessarily catch and decode all pings. Right-Click on pings as they occur on the waterfall during the receive period. Click just before, in the middle of, and just after the end of the ping. All will typically give you different sync points to start the decode attempt.
           
          (4) You are set to the wrong WSJT mode. This is unlikely because the mode setting applies to both receive and transmit. Since you were being decoded by others, it is safe to assume you were in FSK441 mode. However, this is a good thing to be aware of. Make sure it says “FSK441” in the status line, backed by the color YELLOW.
           
          (5) Extremely strong signals may be difficult to decode if you are running the receiver with AGC disabled. (Not necessary, but some ops prefer it for various reasons.) To decode a very strong signal that you have already captured, right-click just before the signal starts on the waterfall. Clicking INSIDE THE CAPTURED STRONG SIGNAL will often produce no decode. You can also try increasing the “S” value to 4 or 5 (but don’t forget to set it back to 0 or 1 afterwards). Using a combination of changing the “S” value and clicking away from the beginning of the signal, even very strong signals can usually be decoded – but not always.
           
          (6) You have an extremely strong “birdie” (unintentional signal) in the passband on that frequency. The birdy must be extremely strong to prevent weaker pings from being decoded. But to be on the safe side, pick a different frequency with no birdies. If you must operate in the presence of a birdie, check the “Zap” checkbox, and the software will stop trying to decode the birdie as a short-hand (single tone) intentional transmission.
           
          General tips:
           
          (1) RUN THE CURRENT SOFTWARE (v9.x). It’s better, and it’s what almost everybody else is running. Less confusion, better results. You can actually run v9.x in parallel with older revisions if your computer is fast enough. This is extremely compute-intensive.
           
          (2) Number 1 Newbie Error: Always sending all five of the FSK441 messages in every QSO. Do NOT send every single message. Doing so does not invalidate the QSO, but it is not in compliance with the standard operating procedure and wastes a lot of time. You transmit the NEXT message in sequence AFTER the message you just decoded. For example: If you just decoded the other station sending message Tx2 (both calls plus signal report or grid square, whichever the agreed-upon exchange is), then you would NOT then send Tx2 also. You skip ahead to the next message, Tx3, which is the letter “R” [i.e., “roger”] and the signal report or grid square. This protocol is summarized in WSJT; press the “F5” function key to see the summary.
           
          (3) “Rx ST” and “Tx ST” (v9 software only) control the operation of single-tone shorthand transmissions. Do not check these boxes unless or until you specifically want to encode and transmit (Tx ST) or receive and decode (Rx ST) a single-tone shorthand message. You can choose not to send single-tone messages if you don’t feel comfortable with them, but you cannot choose what the other station is going to send, so to some extent you must be familiar with single-tone shorthand messaging anyway in case that’s what you receive.
           
          (4) Received single-tone shorthand messages do not have to be computer-decoded where it is obvious that it is being sent by the station you are in QSO with. Observing the tone’s absolute frequency on the waterfall verifies that it’s the message you’re expecting; observing its visual offset from the hash-marks on the waterfall (which offset will be fairly consistent throughout a QSO) verifies that the source of the tone is the station you’re in QSO with. This is enough to verify reception of that message. Go on to the next message when it’s your turn to transmit.
           
          (5) Use “AUTO” (QSO) mode. This is usually intuitive for most guys, but not for all. Just depends on how your wetware is wired. When starting a QSO attempt., click on “Auto is OFF” and it will turn red and say “Auto is ON”. This causes transmission to occur automatically during the first 30 seconds or the 2nd 30 seconds of each minute, depending on whether you have “Tx First” checked or not.
           
          (6) There are two rules about who goes on first sequence: (a) A Grid DXpedition station always goes first, regardless of location; (b) if Rule (a) doesn’t apply, then the westernmost station goes first.
           
          (7) Learn how to correctly use the Options screen in the Setup menu of the main window. One of things there that you will need to pay attention to is whether you are going to transmit signal reports or grids in your Tx2 or Tx3 transmission. By default, most everybody uses signal reports (26 unless you change it on the fly), but this is not valid during contests, where you must exchange grid squares (and get them right). You set this up in the Options screen.
           
          (8) Read the manual!
           
          (9) Did I mention to read the manual?
           
          (10) RTFM!!
           
           
          Hope this helps! :-)
           
          Bill W5WVO
           
           
           
           
          Sent: Wednesday, September 07, 2011 03:58
          Subject: Re: [FFMA] Re: K7MKL/W6NF Rover
           
           

          Hi Jack

          One possible cause of the "no decode" problem is a mismatch in the "rate-in" value.  If you are using version 9, there should be two numbers in the box at the lower, left corner of the WSJT screen.   Both numbers should be very close to 1.000.  Anything between .9995 and 1.0005 is OK.  The first number is the "rate-in" value.   If it's not between .9995 and 1.0005 you will need to configure the software for the actual value.  To do so, click on setup and the options.  The rate-in number is on the left hand side one from the bottom.  Enter the actual value you observed before. 

          Hope this helps

          73,

          Tom K6EU



           

          On Tue, Sep 6, 2011 at 6:18 PM, Jack/W6NF <vhfplus@...> wrote:
           

          In the words of Katy Perry: "epic fail" :<(

          We honestly don't know what happened but we decoded no signals while
          in DN00/10/20. We know now that there were many stations calling and
          we apologize for the frustration...both ours and yours. We could hear
          occasional pings and on one occasion, at about 1520Z, had a good
          signal for no less than 10 seconds, but still nothing decoding even
          with clearly audible signals.

          We'll try to do some troubleshooting but, at this point, don't know
          what the rest of the trip holds in store for FSK441.

          Shelley and I plan to be back in both DN00 and DN10 after we get back
          home on September 18th. Hopefully we can get our system fully
          functional and activate those grids before October 1st. We'll keep
          everyone informed.



          --
          Jack, W6NF
          Shelley, K7MKL
          Silver Springs, NV
          DM09ji
           
        Your message has been successfully submitted and would be delivered to recipients shortly.