RTTY Contest Operation and Messages

In 1985, I built a home-brew decoder and experimented with RTTY, but I never got it to work. I've since decided that I didn't know how to tune RTTY properly. Things changed in 2005 when I downloaded CocoaModem made my first RTTY contacts. 

Since I was involved in contesting, I naturally turned to RTTY contesting. Today, it is unusual to hear RTTY signals on the bands except during contests. Thirty or more years ago, RTTY was commonly heard on 80 and 20m. 

Characteristics

Several characteristics of RTTY must be understood in order to communicate effectively: 

• RTTY has no error correction or detection -- unlike AMTOR, Packet, FT4 or FT8. This means whatever that prints might be wrong. And if it is wrong, you will not know. 
• RTTY prints garbage. Without a signal, random characters print. This further complicates determining what is correct and what is not. 
• RTTY does not handle multiple signals well. When two or more stations call at the same time, RTTY will not print reliably. Certain decoders may print the strongest signal, if you are lucky.
• RTTY text comes in a continuous stream. Long lines wrap to the next, or one can force a new line by sending a carriage return / line feed combination. Wrapped lines are often difficult to read.
• RTTY has two shift states, LETTERS and FIGURES in the Baudot encoding. RTTY rests in the LETTERS state. An unprinted FIGURES character is transmitted to shift to the FIGURES state. A similar LETTERS unprinted character can be sent to shift back, or one can automatically unshift on a space character. 

Principles

For effective RTTY contest communication, several principles apply. 

• Brevity - every character sent must have a purpose. There should be no wasted characters.
• Duplication - every important element should be sent twice. This contradicts the brevity principle. Because RTTY prints incorrect characters, sending important elements twice helps ensure correct reception.
• Scrolling - each message starts a new line, but ends with a space. This technique keeps lines from wrapping, and avoids the end of message being confused by garbage characters when the signal drops. 
• Shifts - avoid needless shifts. Any sequence involving the unprinted FIGURES or LETTERS characters takes longer to send. 

Messages

(I'm using N1MM messages for my examples. Other software may have different macro names and techniques, but the same principles apply)

Every message starts with a {TX} and ends with {RX}. This transitions the software to transmit and back to receive. 

S & P

Let's say you want to answer someone's CQ. This means you need to send your call. For that, you'd use a macro like this:

{TX}{ENTERLF}{MYCALL} {MYCALL} {RX}

or

{TX}{ENTERLF}* * {RX}

(For N1MM, the asterisk and {MYCALL} macros are the same)

Notice the message starts with {TX}, performs a carriage return / line feed with {ENTERLF}, sends the call twice, ends with a space and then {RX} to go back to receive. Sending the call twice helps to ensure the recipient receives it correctly.

If you are lucky enough to get a response, you'll have to send the exchange. The exchange will vary by contest, but it could be a message like this:

{TX}{ENTERLF}! 599 GA GA DE {MYCALL} {RX}

This is what I send in the RTTY Roundup. First is the recipient's call (!). Then 599 -- don't use 5NN, because that actually takes longer to send in RTTY -- and send it only once, because it isn't important. Then the exchange is sent twice, followed by the prosign DE and my call, followed by a space. 

N1MM's authors recommend you use the ! character rather than the {CALL} macro. The reason is that {CALL} isn't subject to correction -- it sends the contents of the Call field at the start of the message. The ! character will send the Call field as it is being corrected in real time. As a practical matter, most RTTY contest contacts involve pointing and clicking on callsigns, so there's less typing, and therefore fewer corrections involved.

A couple of things here. Notice I did not use the {EXCH} macro above. When there are multiple elements to the exchange, I put the repetitions together. So, I tend put the exchange information into the macro directly. For example, here's an S & P exchange for CQWW RTTY:

{TX}{ENTERLF}! 599 GA GA 5 5 DE {MYCALL} {RX}

GA for Georgia, and 5 for zone 5. For NAQP RTTY, it would be:

{TX}{ENTERLF}! 599 BILL BILL GA GA DE {MYCALL} {RX}

Some might balk at the use of the DE prosign, particularly for exchanges that involve a state or section, since DE might be confused with Delaware. However, I think this prosign is useful, as it establishes the callsign is of the answering station, and not the CQing station.

CQing

Calling CQ in a contest is the most-used message:

{TX}{ENTERLF}CQ RU {MYCALL} {MYCALL} CQ {RX}

Note that the important information -- the callsign -- is repeated. The other curious thing is the "CQ" at the end. This indicates I finished a CQ message. This is important because one cannot tell when potential callers tune in to your signal. If they do so during the first callsign, the can't tell if you are calling or answering a CQ. Putting "CQ" at the end establishes you are calling CQ. And it is shorter than "QRZ?".

Naturally, one indicates the contest in the CQ message. Here it is "RU" for Round Up. Use whatever is appropriate for the contest, or simply "TEST".

When someone answers your call, you send an exchange message:

{TX}{ENTERLF}! 599 GA GA ! {RX}

Note that the exchange is sent twice, and if there were more than one element to the exchange, I'd send those twice as well:

{TX}{ENTERLF}! 599 BILL BILL GA GA ! {RX}

Another item to notice is there is no {MYCALL} macro in this message. Instead, the caller's callsign (!) is sent twice, once at the beginning and once at the end. There are two reasons for this. First, it follows the principle of sending important information twice. It could be the caller's callsign printed incorrectly to me, or perhaps it will print incorrectly when I send the message back. If I only send the callsign once, the caller might or might not correct it if is wrong, or they may correct it if it printed incorrectly to them. 

Unnecessary corrections are a waste of time, but necessary corrections are desired. 

Second, it may be that during the response with the exchange, other stations may also be calling. This, creates a good chance that the initial callsign in the response will print incorrectly. If you don't send the callsign again at the end, it could be unclear who you responded to. 

Once you've received the exchange from the caller, one sends an acknowledgement:

{TX}{ENTERLF}! TU DE {MYCALL} CQ {RX}

Short and simple. Two features here. One is the DE prosign, to indicate this is the transmitting station's call, and ending with "CQ" to invite new callers.

Turnaround

Occasionally, multiple callsigns will print in response to a CQ. You can only respond to one at time.  Since you can only respond to one at a time, this leaves someone waiting. Rather than have them call again, you can use a turnaround message which acknowledges a completed contact and starts a new one:

{TX}{ENTERLF}! TU {LOGTHENGRAB}NOW..{ENTERLF}{F5} 599 GA GA {F5} {RX}

This message omits {MYCALL}, and uses the {LOGTHENGRAB} macro to first log, then grab the callsign off the automatic decode stack, then it follows with the normal exchange. If you use Single Operator Call Stacking, you can use {LOGTHENPOP} instead. See the N1MM manual.

Note that instead of using the exclamation point (!), we use the {F5} macro. Both the exclamation point and the {CALL} macro won't be updated by the {LOGTHENGRAB} macro, but {F5} will.

Short

When signals are strong, and the bands are quiet, perhaps the principle of sending information twice doesn't apply. Most RTTY contests allows contacts on multiple bands, and the exchange doesn't change. In these cases, you may want to have short messages handy. Here are some examples:

{TX}{ENTERLF}! 599 BILL GA DE {MYCALL} {RX} -- short S & P exchange

{TX}{ENTERLF}! 599 BILL GA {RX} -- short exchange for S & P or CQing

{TX}{ENTERLF}599 BILL BILL GA GA {RX} -- repeat of just the exchange 

{TX}{ENTERLF}CQ RU {MYCALL} CQ {RX} -- short CQ

{TX}{ENTERLF}TU DE {MYCALL} CQ {RX} -- short acknowledgement

All these should be used when you have solid copy, want to get back to other callers quickly, or you are fairly certain the other operator already has your exchange information from a previous contact.

Tips

Some tips I've picked up over the last decade that are helpful.

• Use Slow AGC - Fast AGC can confuse decoders and introduce print errors
• Use TX Filtering on AFSK - If you are using MMTTY or similar software, use the 512 tap TX Filter. It helps transmit a cleaner signal.
• Listen with Headphones - sometimes you can hear signals that don't always print, if you listen with headphones, you can hear the stations calling you. It also helps you improve your timing in a pile.

On that last tip, turn the volume on the headphones way down. You just have to sense when signals are there, you aren't decoding them. (I believe it was the late Irv Hoff, W6FFC (SK) -- a RTTY pioneer -- who suffered hearing loss at 2125 and 2295 Hz from listening to RTTY signals)

Practical Messages 

There are a handful of other messages you may wish to have handy. Here's one I use often, when you didn't copy anything sent:

{TX}{ENTERLF}AGN AGN {RX}

Or perhaps you need a fill of one element:

{TX}{ENTERLF}STATE? STATE? {RX}

{TX}{ENTERLF}NR? NR? {RX}

{TX}{ENTERLF}NAME? NAME? {RX} 

 Before you open up with a CQ on a frequency,  this is good one:

{TX}{ENTERLF}QRL? DE {MYCALL} {RX}

 Maybe if you are not sure someone is calling you:

{TX}{ENTERLF}QRZ DE {MYCALL} {MYCALL} {RX}

Or the short version:

{TX}{ENTERLF}QRZ DE {MYCALL} {RX}

Every once and a while, directed call is useful, especially when two stations are calling CQ on top of each other:

{TX}{ENTERLF}! DE {MYCALL} {MYCALL} {RX} 

Conclusion

RTTY contests are a ton of fun. Program a set of messages and try it. You'll like it.

Forty Years of Personal Computing - RTTY Receiving Program

September 1985, I purchased a Kenwood TS-430S and became more active in amateur radio. In the apartment where I was living, I snuck wires out of a second floor window and began to make contacts. 

In October, I got the notion to try some Radio Teletype (RTTY). I built a demodulator using a circuit I've forgotten. Perhaps it used a couple of NE567 chips. Having a demodulator, I needed to translate the five-level Baudot characters into ASCII that I could display on the terminal.

(I purchased a Wyse 85 VT-220 emulator terminal in August of 1985, so I was no longer constrained by the 64x16 screen and 1200 bps limitations of the CT-64)

RTTY Decoder

I wrote a program for Flex09 to decode 45 Baud RTTY by bit-banging a PIA pin. I couldn't use the MC6850 ACIA, because it does not support 5 bit characters.

A delay loop established character timing: 

LOOP    LEAX -1,X
              BNE LOOP

Each pass through the loop consumes 8 clock cycles. With the right value loaded in X, fairly precise timings could be accomplished. A value close to 250 would be 1 ms on a 2 MHz machine. By calling this loop repeatedly, timings of 11 and 22 ms are measured. 

I connected the demodulator output to PIA Port B, pin 0. The program looks at this pin, waiting for a zero. Finding one, it calls the delay loop for 1 ms and checks again. If the pin is still zero, it waits 10 ms and checks Port B pin 0. A continued zero at this point indicates a start bit. The 11 ms total delay places us right in the middle of the start bit.

The next sequence waits 22 ms and then samples of value of Port B, pin 0. It does this five times. These samples are shifted into a byte value, which used to look up an ASCII character in one of two tables -- one for letters, and one for figures -- according to the shift mode. This character is then sent to the terminal, and we go back to waiting for a start bit.

The resulting program is about 300 bytes long. Despite the simplicity,  I had little success decoding RTTY signals. 

In hindsight, there are several reasons for this. 

• Decoding signals off the air that might have been noisy.
• Demodulator circuit was completely untested and might not have worked.
• No experience with RTTY, so signals might not have been properly tuned.
• Precise value of the 1 ms time delay not known. I used values of 230 and 240, allowing cycles for other program logic. 

At some point, I distinctly copied "RY RY RY RY RY RY RY" from someone, but not much else. Later, I figured out this meant my program, at least, was working. 

Hardware Solution

In November 1986, I decided to use serial chip that could do five-level Baudot. The MC6850 only allows 7 and 8 bit characters, so I needed a different chip. The NS8250 could do 5, 6, 7 and 8 bit characters, and sports a programmable bit rate generator for all the common RTTY rates. Hence, I added an NS8250 UART to the baud-rate generator board. 

Funny, though -- I never wrote software to use the NS8250. In February 1989, I removed the NS8250 and its associated circuitry. 

I didn't become active in RTTY on the air until 2005, using Cocoamodem.

SoundBlaster X G1

I'm always on the lookout for good USB sound cards. I've found a few. Some were expensive, like the M-Audio Transit. Others were cheaper, like the Startech ICUSBAUDIOMH. Both of these are 96 kHz, 24-bit, stereo input and output sound cards.

And neither of them work any more. You see, these devices, although the hardware is perfectly capable, are no longer supported with current drivers. As such, they no longer function with the latest operating systems. It's a very disappointing situation.

So, I continue my search to find good sound cards. I look for 48 or 96 kHz, 24-bit devices, preferably with stereo input. Sadly, this last function is hard to find.

The SoundBlaster X G1 seemed promising. It was advertised as 96 kHz, 24-bit, stereo device. It was only about $30, so it fit my criteria as inexpensive. I received one at Christmas time and checked it out.

The SoundBlaster X G1 comes with a TRRS mini phone jack, which should have been a clue that it didn't have stereo input. It comes with an adapter that exposes the connections as a separate headphone and microphone jack. The microphone input is connected to the ring terminal, the tip having no connection. This is apparently pretty standard for PC microphones.

When I first tested the device, I was disappointed that it only had 44.1 kHz, 16-bit input and output. At least, that's the only function it would perform out of the box. While the input appeared on the computer as stereo, both channels are hooked to the single input channel -- giving you two copies of the same input signal.

Turns out, the SoundBlaster people have created a device that has multiple "profiles" and can appear as a device with different capabilities. The default profile is intended to be compatible with the Sony Playstation, and has minimal capabilities. Using a special Windows program, I reconfigured the profile to the Generic profile.

On the Generic profile, the device conforms more closely to it's specifications. 96 kHz operation is restricted to output-only. Input maxes out at 48 kHz. But both input and output are 24-bit.

Once configured, the SoundBlaster X G1 makes a decent sound card, although it is restricted to a single input signal.

SoundBlaster also makes the SoundBlaster Play!, which appears to have similar capabilities 96/48 kHz, 24-bit, stereo out, mono in. The Play! is about 20% cheaper, but both are inexpensive.

VP6D on 30m CW

Odd things happen. During a long DXpedition, like the current VP6D expedition to Ducie Island, they are bound to happen. They happened during the K1N Navassa Island expedition, for example.

Last night I'm trying very hard to put VP6D in as many DXCC slots as I can. I hadn't worked them on 30m, and they were running RTTY. 30m is often tough, since everyone runs 200 watts, tops, and my 100 watt signal doesn't really stand out. RTTY makes it even harder. I called for a half an hour with no luck. And then VP6D disappears.

I continue calling for a little bit. It's a sort of anxious hope that sometimes works. Maybe they had a generator die, and the first thing the operator will hear when the generator comes back to life will be my callsign. Right? Well, it could happen.

After a couple of minutes I stop calling. I'm sitting there with the headphones on. The left ear is listening to 10142 kHz at about 450 Hz wide, the right is listening up around 10144.5 kHz, about 2 kHz wide. And, I'm hearing nothing. Nothing at all.

About three minutes after I stopped calling, I heard a signal. It sounds like a CQ. A CW CQ. It's off frequency, so I can't really tell. I'm not set up for CW. I'm in DATA mode, with settings all flipped around with wide filters. But - there it is again - in my right ear, it sounds like VP6D calling CQ, in CW.

Switch things around to CW, with a narrow filter, and then tune for the right frequency. I'm sure I'm going to miss it, but no, I find him. There he is CQ VP6D UP2. Plain as day on 10144 kHz. That's not where you'd expect him to be at all. No, the published CW frequency is 10105 kHz. This frequency is out of position for CW, but there he is, calling CQ VP6D UP2. And no one is answering. No one.

This is my chance. I go into split, up 2, and give him a call. But, again, CQ VP6D UP2. A couple of times. No answer. So, I figure, hey, maybe he's actually listening up 1 and doesn't realize his memory keyer doesn't match. I dial in up 1, and call. No dice. After a few calls, I wonder where he's listening really. Maybe he's listening up 2 from 10105 kHz. I give him a call on 10107 kHz. Nothing. Perhaps he's listening on his own frequency?

At this point, he's been calling CQ on 10144 kHz for two solid minutes and no one has answered him. I figure it's worth a try without being a DX lid. I turn off split and dump in my call: AA4LR. AA4LR 5NN comes the response. R 5NN TU, I reply.

And bam, quick as that, he's in the log.

He goes back to calling CQ VP6D UP2. I listen for a couple more minutes, but no one is calling him. I post a spot on dxwatch.com and listen for a couple more minutes. Still no one. I begin to wonder if he's just clueless to where he is in the band, and that no one is looking for him there. So, I dare to send again on his frequency: FREQ? He responds to my question by sending 10144 twice. So, yeah, he knows where he is. I post another spot, hoping some other DXer will find him, too.

After about 10 minutes of this, he goes silent. A minute after, I find him down on 10105 kHz, once again calling CQ VP6D UP 2. And, people are calling him, and he's answering. Good, that's what's supposed to happen.

Looks like I'll may be the only one who worked VP6D on 10144 kHz CW. Cool.

OK, I'm an Idiot....

Sometimes, it helps to just admit it to yourself. Let me explain.

Back in December 1st 2017, I started using FT8. I set up the WSJT-X Mac software and made my first contact. Mostly operating on 17m, 30m, 12m. I later discovered 6m. Indeed, this last summer was a huge opportunity to work much of the country on sporadic-E (Es) on 6m. I was amazed to work 40 states in just one summer. On all bands, I've worked all fifty states, and quite a few countries with this mode.

So, I've been using FT8 for months. However, one thing bothered me - everything seemed off frequency. You see, there are standard frequencies that are published for FT8, 12m is 24.915 MHz. But if I dialed in 24.915 MHz, everyone was too high -- like no one was using frequencies less than 2 kHz, and some were visible at 3.5 kHz and higher.

My solution to the problem was simple -- I just tuned higher. I decided that 24.916 was more accurate, and operated that way for months. I even reprogrammed WSJT-X so the 1 kHz higher frequencies were the right ones.

But, it bothered me. It seemed wrong.

I managed to work Baker Island using FT8, but it was a bit of trouble, and I had one fellow email me saying I was calling too low for the fox/hound DXpedition mode. I used a higher frequency and almost immediately had an exchange. This made me think about this issue more.

Originally, I had my K3 set up for RTTY using AFSK. This means I was using the AFSK A data mode on each band. For FT8, I would select DATA REV, so it would use USB instead of LSB.

What I didn't realize is that AFSK A means the display frequency is adjusted to reflect the Mark frequency of (in my case) 1445 Hz. This accounts for my frequency being too low -- I was off by 1.4 kHz.

With that figured out, I switched to DATA A, which has the display frequency of the suppressed carrier, as it would for LSB or USB. The frequency jumped, and I tuned again to the standard frequencies (the real ones, not my artificial higher ones).

But, it didn't work. I couldn't hear any signals. Back to AFSK A, and they are there, but switch to DATA A, and they are gone. What?

Turns out, AFSK uses LSB by default, while DATA A uses USB. Since I was using DATA REV, this means DATA A was LSB. Oops. Back to straight DATA mode, using the DATA A sub-mode, and everything works just as it should. Gosh, that's too easy.

I'm an idiot....

I'll just have to remember to change the DATA MD back to AFSK when I'm doing RTTY.

Radio 2017 - Progress March

I don't want to admit it, but no, not a lot of progress on this. No long vacation excuses this time, just busy with life. What can I say?

I did get to review the WWDC videos regarding storyboards. I (re-)discovered a few interesting things:

• Set the main storyboard in the info.plist - I had done this.
• You can build up window content by using content segues to multiple view controllers. I didn't have a need for this yet, but I'm sure it's coming.
• Control-Drag directly from a menu or button to a window content view. This will produce a segue to the view controller. Easy and useful. The host view controller receives a method call prepareForSegue:sender: before the window appears for the segue. I'm not using this because there doesn't seem to be a way to associate the document window for this action when it appears on the application menu. 

So, my main question became -- how does all the other document stuff work? When you select File / Save, how does that get to the NSPersistentDocument class? Turns out, it uses a basic target/action to the First Responder. 

I just had to figure out is how to add my action method for my modes window to the First Responder. That turns out to be easy. Select the First Responder icon of the main menu. Then, use the Attributes inspector, and you'll see a list of User-Defined actions. The weird thing is, though, once you've defined them, they disappear from this list.

No matter, just add an action, then edit it to be the method name you want. Then wire it up to the menu with control-drag as before. Implement the method anywhere in the responder chain. I implemented this in my document class. And my mode window comes up correctly, and I have a unique instance of it for each document. Cool.

Next is the hard part -- trying to figure out how to associate the managed object context of the document with the modes view controller. This is were it gets weird. The window controller has a property document which points to the document for that window. How you get to that value from the view controller is something I have not figured out yet. 

Radio 2017 - Progress February

Well, I can't say that I've made much of any progress since the last posting. I took a 10-day trip to Israel to visit Bethlehem, Masada, Galilee, Jericho, Jerusalem -- all the holy sites. The trip was very intensive, and after I returned home it took me about a week to recover and then catch up on all my missed work.

I did spend a little time going over my test programs trying to figure out the right way to write Cocoa code for MacOS X document-based apps with Storyboards. What I'm doing seems too complicated.

So, I've decided I need to go back and find the WWDC videos regarding using storyboards with MacOS X, and it also might be useful to view the the ones for iOS docment-based apps as well, to see if that gives me any insight.

With any luck, I'll make much more progress in March.

Radio 2017 - Progress January

Quick progress report on the Radio 2017 project. I've managed to get started on the casual logging program. I've created the basic framework and a local Git repository. An early cut of the Core Data model is in place. You can't do much more than run the program and create, save and close documents so far.

I have discovered that Storyboards on MacOS don't quite seem ready for prime time. First, there's a bug that windows don't cascade when creating a new document. Second, the split of the original NSDocument class into NSViewController and NSPersistentDocument subclasses creates something of a conundrum. The NSPersistentDocument owns the Managed Object Context, but the NSViewController subclass is the place that owns all of the UI actions.

To make things worse, the main menus actions only appear to be able to effectively target the application delegate. If you want to target something in the NSViewController or NSDocument, you have to write a handler in the application delegate to find the current document view controller and call the right method.

I've figured out the proper way to do the menu actions, but I'm still puzzling out how to handle the managed object context from the view controller actions.

None of this is rocket science, but it's certainly slowed things down, as I have had to create separate projects in order to figure out the most appropriate way to do things.

I'm still learning Swift. The nuances of optionals and when to use the various operators is something that will come with practice. The compiler is keeping me on the straight and narrow.

The Radio 2017 Project

My long-time friend Chris, K4JCW, invented the term GUP. It's an acronym for Great, Unfinished Project. Naturally, any unfinished project can always be great. Because, well, it is unfinished. If it lacks greatness at the moment, there's always a chance it could be added. The greatness of any project reaches maximum before it starts.

A couple of months ago, I got to thinking about some of my unfinished software projects. I've already talked about my casual logging program. While I've made a few small enhancements over the years, it's basically the same program I wrote in 2006. There are others I've been meaning to write for the Mac for several years.

This summer, after the Apple World Wide Developers Conference (WWDC), I studied the updated Swift 3 language. It seemed to me that Swift was probably mature enough to start using. I also caught up on several videos, including those on how to use storyboards in MacOS applications, something that was certainly not possible ten years ago.

I decided it is time to develop some new Mac software. I've labeled this the Radio 2017 project, as I hope to be done within the year 2017. I have identified the need for the following applications:

• Casual Logging Program - very basic logging program with import / export to ADIF, control of the Elecraft K2/K3, support for RTTY and PSK operating, as well as CW keying, automation via AppleEvents / Automator

• Contest Logging Program - logging program with contests, supporting main ARRL, CQ and NA contests. Import / export to Cabrillo, ADIF. Support for CW keying and RTTY and PSK operating.

• SDR Software to use with SoftRock Lite II - I purchased the SoftRock Lite II to use with the K3 IF frequency. This would serve as a pan adapter / spectrum analyzer.

• Remote Control Server  and Client - to allow me to operate my Gwinnett station from anywhere.

• QSL Tracking Software - track paper QSLs against awards.

All of these would be useful to me. There are probably a couple of utility applications to consider as well.

In writing this software, I've decided to stick to a few goals:

• Swift 3 - the applications should be written almost entirely in Swift 3. (There are a few APIs -- notably Core Audio -- that are more appropriately accessed with Objective C/C++. I'll likely use Swift-callable wrapper classes for those)

• Storyboards - the UI should be constructed using storyboards.

• UI Guidelines - applications should follow the latest Mac UI guidelines.

• Store-ready - should these applications turn out well, my stretch goal is to publish them on the Macintosh App store.

The hardest part of this sort of project is maintaining focus and motivation. I hope to help that by publishing my progress here each month. Wish me luck!

Uh-Oh.

There's that moment -- that moment of pure clarity. The pure clarity that occurs when you realize you've done something really stupid -- something stupid you can't take back.

This happened yesterday. You see, I got off work early and thought I'd spend the afternoon chasing a little DX. I managed to work VP6J on 12m CW, and later they moved down to 17m RTTY. I've never worked Pitcairn using RTTY, so I was watching their frequency closely. They weren't strong, but I went ahead and set up the amplifier on a clear nearby frequency. The day was waning, and I figured if they ever came up a bit so I could get clear print, I'd want to give it my best shot.

In the meantime, I moved down to 30m and worked some other stations. Of course, I switched the AL-80A to standby, and cranked up to 100 watts.

Everything was fine. Until later I went back to 17m to see how VP6J was doing. Their signal had come up a bit, and I could actually read the print well enough to try for a contact. I reached over and flipped the amplifier to operate, and clicked the button to send my call.

That's when I had my moment of clarity.

There was a loud noise from the RF compartment of the AL-80A, along with several sparks, and abruptly, it went dark. An acrid burning smell hung loosely in the air. Certainly, something had gone wrong.

I knew right away what I had done. I had transmitted 100 watts into an amplifier designed to take only 50 watts input.. An amplifier whose original design had not included 17m, and was happier with 40 watts on that band.

Roasted plate choke in AL-80A.

I switched the amp off and then back on, still dark. Clearly, I've blown a fuse. A quick check verified that one of the two 10A fuses had blown. It was replaced, and the amp came back to life. But as it turned on, there was a tiny arc coming from the plate choke. I switched it back off, turned the meter to the HV setting, and briefly switched it on again. The High Voltage looked fine, but I was going to have to get the amp on the workbench to see what was wrong with the choke.

Once I got the cover off, it was easy to see the problem. The plate choke has a black burnt mark. Looking closer, the turns of the choke had melted and separated. The choke would need to be replaced. From the location of the burn, it looks like it had arced from the end of a screw on the plate tuning capacitor to the choke.

I took the tube out and gave it a quick check with an ohmmeter. No grid to cathode or grid to plate shorts, which was good. The Taylor 3-500Z is pretty darn tough, and likely shrugged off the abuse I had just put it through.

Low voltage cap blown to protect meter.

While I had the amp on the bench, I checked out a couple of other things. Looks like one of the protective caps I placed on the B- rail to ground failed. Probably helped to protect the meter movements.

I'll be replacing that cap, along with the 1N4007 rectifier, since it must have gone open for the capacitor to fail. I'll replace it with the recommend 1N5408 rectifier, which can handle a whole lot more surge current.

Melted switch contacts.

Another mystery of this AL-80A I solved -- why it wouldn't tune up on 160m. An inspection of the front switch wafer shows that the switch contacts for the additional plate tuning cap have completely melted away. Since I've never used the amp on 160m, this was not me -- this was an existing problem. The switch contacts, or perhaps the wafer will need to be replaced to restore service on that band.

I ordered a replacement plate choke from Ameritron. They don't carry the original AL-80A part, but instead use a single choke (Part number 10-15197) for virtually all their amplifiers, including the more modern AL-80B. I've read this part avoids resonances on 17m which may be present in the original single-winding choke.

In the meantime, I'll have to chase DX without an amplifier for a while. Perhaps there won't be as many fireworks.

Update: I've been told that part of the problem with the 160m switch contacts is the lack of a corona washer. The picture clearly shows an absence of this part. I'll be adding one when I make the repair.

K1N - Fabulous DXpedition

My Results from K1N

Well, it's over now. The much-anticipated K1N DXpedition to Navassa Island is now over. Lucky for me, I made it into the log multiple times, which makes me quite pleased.

Granted, it was a pretty easy shot from here in northwest Georgia to Navassa Is compared to other parts of the world. They were quite strong on just about every band, with the exception of 10 and 12m. I never heard a peep from them on 6m.

The pileups in the low bands were completely crazy in the evenings. All of my contacts 30m and below were made in either the 0900z or 1000z hour -- 4 or 5 AM local. That's one of the secrets of working DX -- be on the band when others are not! The one exception was 60m, and, honestly, the channel was so crazy I'm not entirely sure how I made it into the log.

All of these contacts were made with 100 watts and wire antennas, either the Inverted-L or the 80/40m dipole. Working DX does not require huge amplifiers and large antennas.

The team on Navassa Island did a fantastic job handing out contacts despite unruly pileups, deliberate QRM and the usual craziness. I witnessed on CW pileups that extended over 30 kHz with people continuously calling. Finding the listening frequency in the second receiver was an incredibly difficult task, and quite often I was just guessing -- but a few times I got lucky.

As I told my friend Mike, W1YM, now that I have Navassa Is on nine bands, I'm planning to volunteer to operate the next time team heads to the island. Perhaps in 10 years....

K1N - Pumped for Navassa

Back when I first got interested in Amateur radio, I remember an article published in 73 Magazine about a DXpedition to Navassa Island.

This was something of an unusual article for 73 Magazine -- which, at the time, generally focused more on radio technology and construction articles. However, since the publisher Wayne Green W2NSD/1 had been part of the DXpedition, it was no surprise the story was covered.

I don't remember why, but the tale of hauling equipment and personnel up a steel rope and angle iron ladder from an inflatable boat amidst all the waves, surging and swells captured my imagination. You can read an account here.

It would be over a decade later that I would join the Atlanta Radio Club myself, but for some reason I never asked anyone about this trip. It wasn't until nearly two decades later, when I happened to strike up a conversation with Jim Streible K4DLI that I heard the story firsthand. (Ironically, Jim was the father of one of my colleagues at Georgia Tech as well - something I didn't piece together until that conversation)

At lot has happened since those days. When the Desecheo Island DXpedition was active in 2009, I intentionally worked them on as many bands as I could -- since it was clear that it might be decades before it was active again. I logged them successfully on 160-15m, using CW, SSB and RTTY. Given my relative proximity to the DX, it wasn't that hard to work.

Needless to say, I am pumped about the Navassa Island DXpedition. The pileups will be huge, of course, but I expect to work them on as many bands. It will be great fun trying.

How NOT to Run a W1AW/-Portable Operation

OK, I've been chasing some of the W1AW-portable operations. The light dawned on my back in February, when I realized that these operations could help me achieve WAS on the WARC bands of 30, 17 and 12m.

Managed to work quite a few, some with great ease. Some of it has to do with favorable propagation during the week they were on, but most has to do with the quality of the operators and their scheduling.

Others, I struggled to work at all, and in some cases barely made contacts on some bands. If this is the kind of operation you prefer, here's my list of tips on how to best optimize that outcome:

• Don't operate on the WARC bands. If you're not familiar with them, they are 30, 17 and 12m. These aren't terribly popular, since they have only been ham bands for a couple of decades now. I'm sure some folks don't even have equipment for these bands. Best to stick with the harmonically related bands of 40, 20, 15 and 10m, although I'm not to sure about 15m....

• Don't operate on 160 or 80m, even when it is dark. Rates will certainly be better on 40 or 20m, right. Few hams have the real estate for the enormous antennas required to operate these bands. Best to stay on the higher bands even after the sun goes down -- until the bands close, at least. 

• Don't operate exotic modes, like RTTY. Not many hams will have that fancy RTTY equipment. So, you're sure to work many more stations using good old-fashioned CW or SSB. If you must work a digital mode, make sure it is one of the new-fangled ones, like PSK 63 or JT 65.

• Don't operate split. Takes up too much bandwidth. We hams can't figure out how to set up our rigs for split anyway. Who cares if the rate really stinks, since everyone is calling on top of you. That will make getting the QSO all that much more challenging, right? 

• Don't operate between midnight and 7 AM. We hams certainly need our beauty sleep. They'll be no one to work anyway, right? Everyone should be asleep. And there's no need to start operating early in the morning, especially before sunrise. No one is awake then anyway, right?

• Don't operate more than one band at a time. Hams will get too confuse if you appear on more than one band at a time. Besides, there's probably only one band that's really open, so there's little need to move around.

OK, OK, I kid. I know, these operations are run by volunteers, and not everyone is an expert operator.  It just amazes me at how poorly scheduled a few of these operations were. It was especially frustrating wanting to work these operation on the low bands, and staying up late, or getting up early, only to find they were QRT.

I've slowly been increasing my LoTW totals for WAS from Floyd County. 

The Elecraft K3 is a Joy on RTTY

K3 - Right in the operating position

I built the K3 just after Christmas. Since then, it has been a joy to operate in many ways. Having just completed my third RTTY contest this year, I'm especially pleased with how it operates on RTTY.

Although I operated packet radio back in the 1980s, I never got a make a RTTY contact until 2005 - using my Elecraft K2. I built an audio interface using a couple of audio transformers and some resistors.

In many ways, the K2 is a great radio. Gary Breed K9AY told me that the K2 was, "a simple radio, superbly executed." While I do enjoy the K2, it is not at it's best running RTTY or any other digital mode. It suffers several limitations:

• Duty Cycle - The K2 is designed for a 50% or less duty cycle - CW or SSB. Without supplemental cooling, you can't run the K2/100 much more than about 25-30 watts. I added a small fan on top of my K2, and could safely run 50-75 watts of RTTY without overheating. The K3, of course, is a 100% duty cycle rig - no problem running 100 watts for hours. The case doesn't even get warm.
• Tuning Rate - Because of it's design, the K2 tunes in roughly 9 Hz steps. While the display shows the nearest 10 Hz at all times, the firmware selects the closest tuning point. As you turn the dial, it's not entirely smooth, sometimes jumping twice as far. With the finicky tuning of RTTY signals, you'll notice this.
• Frequency Readout - I put this one in my K2 Wish List. The K2 frequency doesn't account for the mark frequency, and thus reads 1-2 kHz high, depending on what audio tones you are using. While some contest software can compensate for this, the K3 works correctly by showing the mark frequency on the display.
• Variable Transmitter Gain per Band - this is the most annoying thing about using the K2 on RTTY. Because of the way the K2 transmitter gain control system works, you have to adjust your audio levels on each band -- very high levels on the higher frequencies, and extremely low levels on the lower bands. Every time you change bands, you must adjust the transmit audio level. Every time. The K3, on the other hand, calibrates itself so that it has the same gain on every band. 

But the best part isn't that the K3 can run flat out 100 watts, tune smoothly, display the right frequency, or make it so you don't have to mess with the transmit audio level in the middle of the contest. These other features of the K3 really enhance RTTY operation:

• Variable-Bandwidth IF - My K2 is programmed with a variety of bandwidths for RTTY: 1000 Hz, 500 Hz, and 300 Hz. But this isn't nearly as convenient as being able to select any bandwidth from 100-4000 Hz. On a quiet band, a bandwidth from 600-800 Hz works well. When the QRM gets tough, pulling down to 300 Hz puts it in its place. The K3 allows you to pick exactly the right bandwidth for the situation.
• Dual Passband - RTTY contests can get downright ugly. Sometimes strong stations are interlaced on top of one another, so the mark or space frequency of one station is right between the tones of another station. This situation does no good for anyone, as it makes it nearly impossible to copy either station. I'm convinced that this is largely due to the over-use of  dual passband filtering. This type of filter puts a huge notch between the mark and space tones. It's not useful for S & P work, because if you are slightly off frequency, you won't hear stations. And, it's not terribly useful for calling CQ, either, since someone can easily move in between your tones and you won't hear them. However, every once in a while, this filter makes the difference between completing a QSO and losing one to the QRM. Just don't use it all the time, OK?
• Fine Tuning - While the K3 tunes in perfect 10 Hz steps, you can select fine tuning mode with 1 Hz steps. I used this all the time as default for CW and RTTY and move it. It makes tuning across the band take longer, but it's easy enough to switch to 10 Hz steps when you need to.

So, every time I changed bands, tweaked out QRM with the filter or passband tuning, marveling at how cool the rig is running pumping out 100 watts hour after hour or just simply tuned stations in -- I'm consumed with joy over this fine radio. Definitely worth it.