FW: [FFMA] Re: K7MKL/W6NF Rover
Besides how flat the response of your receiver is, one other item in the chain that also needs to be flat is the response of your soundcard. And what is the optimum input level to it for best SNR. With a fixed output from the receiver such as the Data output on the K3 you are depending on the input to the sound card to adjust for zero noise on the SpecJT screen. This may, or may not, be optimum for best SNR. I know Bill and many others run this way, but, in my case, I prefer to be able to adjust that depending on noise and the strength of the ping.
Using Spectrum Lab I found the best input level to my soundcard for optimum SNR and then I just adjusted the actual audio from the receiver to obtain zero. I do some other audio tricks before the soundcard as well. I have a K3 and one of the nice features is receiver audio equalization. I boost the range 800 to 2400 Hz by 9db which covers the 882-2205 Hz range of FSK. The audio from the receiver then passes through a Timewave DSP-599zx audio DSP which is set to cover 600-2600 Hz. As Bill has pointed out none of these filters are brickwall, but, by reducing the bandwidth to the soundcard the decoder has less extraneous noise to deal with which again helps with lowering the SNR. The Timewave in fact removes quite a bit of background noise itself.
I typically run my K3 with an 1800 Hz roofing filter which is more than adequate to cover the expected bandwidth. I know this restricts how far off frequency the other station can be but having said that I run TOL at 100 as my default so this setting is fine. Most stations I’ve encountered on 6 are reasonably close frequency wise. Certainly within the +/- 100 Hz range. I run “S” at -10 and rarely tough it. I adjust my audio gain if the ping is loud and have no trouble decoding loud signals. I also run with AGC off most of the time.
On the RF side of the picture I do a few things as well. I’m fortunate to live in a very quiet area so I’m able to run both the external K3 GasFet preamp and the internal one all the time. I have a Timewave ANC-4 noise canceller that helps when gardeners are running their gas trimmers etc. whose output then feeds a DCI 11 pole 300 kHz bandpass filter that limits any out-of-band signals. The bandpass filter then feeds the preamps.
For what it’s worth that’s how I am setup for WSJT.
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.
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; firstname.lastname@example.org
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.
(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?
Hope this helps! :-)
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
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
Silver Springs, NV