Retirement Project - Fixing up the SWTPc 6809

Given that it is 50 years old, the SWTPc 6800 Computer System which I call my retirement project has been in need of some "fixes". 

Having made the BBUG ROM monitor changes to allow for extended address decoding, it was time to do some surgery on the motherboard. Might as well make some fixes.

Post close-up

Posts

The original SWTPc kit held the motherboard in place with seven plastic clips along the edge. They were designed to be pushed down from the top and clip in to the chassis bottom. A plastic arrow held the motherboard in place and could be easily unclipped. In theory.

The sad reality is the clips never engaged correctly with the chassis bottom, and often one whole end of the motherboard would be loose in the box.

Seven posts

Around 1979, just before heading to the ISEF, I replaced these clips with #6 screws, lock washers and multiple nuts. Four nuts supply the spacing, with a fifth nut holding the motherboard in place. The #6 screws are a tight fit through the holes in the motherboard, but everything is aligned. 

I took some pictures of these beauties in case someone needs to replicate them.

Feet

Chassis bottom with new feet,
and the adhesive of the original.

The original SWTPc 6800 Computer System kit supplied rubberized stick-on feet. Honestly, they held up pretty well nearly 50 years. Along the way, one of them had fallen off and gotten lost, and the replacement foot wasn't quite tall enough. I replaced them with rubber feet held in place with a #6 screw.

This meant drilling some additional holes in the pan of the chassis. Not a big deal, nor was the placement critical. One foot borrowed the #6 screw holding the clamp for the power cord. The other three used new hardware.

I eyeballed the placement of the other three screws, and the results were acceptable -- certainly compared to the old stick-on feet.

LM7805 Bypass Caps

Input and output 0.1 uF caps
lap-soldered across LM7805.

Because the SWTPc uses an unregulated 8 volt supply, every board has one or more LM7805 +5 volt regulators. Examining my bit rate generator board, I wondered the regulator was properly bypassed. I remembered an issue in a different project where an LM78xx regulator oscillated because it wasn't bypassed correctly. 

A search of the data sheet provided a concise answer:

• All LM7805 regulators should have 0.1 uF ceramics across the input and output.
• LM7805 regulators that supply 50 mA (or more) current should have 10 uF per 100 mA on the output.

These were simple rules to follow. A quick survey of the SWTPc schematics made it clear that the designers had never heard of the first rule. There were no input bypass caps at all. Output electrolytic bypass caps were present on those drawing more current, with an occasional 0.1 uF cap. The Tanner and Gimix boards were more heavily bypassed. My home-brew boards were no better than the SWTPc designs.

This problem was easy to solve. I have a bunch of 0.1 uF multi-layer ceramic caps. I added them to the boards:

• 0.1 uF on input of bit rate generators card
• 0.1 uF on input and output of MP-S cards
• 0.1 uF on input and output of MP-C (modified to MP-S) card
• 0.1 uF on input and output of MP-LA card
• 0.1 uF on input of MC68B09 V2 CPU card
• 0.1 uF on input of MP-B motherboard

For the MP-S, MP-C and MP-LA cards,  I lap-soldered the caps on the back-hand side of the board, rather than drill holes. Easily done in a few minutes.

I added some small-value electrolytic caps to the output of some LM7805's. Generally, boards that include these caps have a 100 uF unit, which is good enough for 1 A of current -- overkill for some boards.

• 22 uF on output of bit rate generator card (more than necessary, 15 uF would be enough)
• 10 uF on output of MP-B motherboard 

It could be that none of these bypass caps are required, but seems like they can't hurt.

Extended Decoder

Dec 1986 decoder circuit

December 1986, I added an extended address decoding circuit to the motherboard. The decoding avoided aliasing of the xExxx pages that prevented access to RAM or other devices. With the MC6809E V1 CPU card, this worked fine with BBUG, but the OS/9 ROMs had a different idea on how to program the DAT, so it didn't work with OS/9. I disabled the decoder and didn't figure out the problem until much later.

When I switched to the MC68B09 V2 CPU card the problem had reversed -- the decoder would work with OS/9, but not with BBUG. 

With BBUG updated to initialize the DAT in a compatible way, I could fix the decoder. The picture shows  the original decoder was a hastily improvised circuit using a 74LS21 4-input AND gate to detect all "1" values on S0-S3, connected to IC6 Pin 6 (Enable).

I sketched out some changes to decode several address lines, but I either never made those changes, or I removed them. The key to the MP-B motherboard is IC6 - a 74LS138 3 to 8 decoder. These other address changes messed with IC3 -- a different 74LS138. The MP-B I/O port data buffers are activated from IC6, so additional decoding against IC3 was an incorrect solution, as the data bus was active, even if no I/O slot was selected.

The new decoder board had simple requirements:

• Disable Extended decode entirely
• I/O accessible from FE000-FE07F (and FF780-FF7FF)
• I/O accessible only from FF780-FF7FF

The I/O ports are aliased over a 2KB block -- each 16 byte I/O slot appears 128 times. This meant decoding S0-S3, A15-A12, A11, A6-A4. A15-A13 is handled by IC6, A6-A4 by IC3. A3-A0 is done by each I/O card. A10-A7 are not decoded. The decoder circuit just deals with S0-S3, A12 and A11.

Decoder showing jumpers

Decoder operation is jumper-selectable. This allows me to test each change and back out changes if something didn't work. The first jumper selects between the FFxxx I/O address or the FExxx / FFxxx aliased I/O address. The second jumper enables/disables extended decoding entirely. 

The 74LS21 has the first AND gate connected across S0-S3. The second gate is wired as a two-input AND that uses the output of the first AND gate and jumper-selectable A12 or a pull-up. The output of the second AND goes another jumper selecting IC6 pin 6 (Enable) to the output of the AND or a pull-up. A11 goes to IC6 pin 4 (Enable*) to ensure the I/O data bus buffers activate only on the lower 2 KB of the 4 KB memory page.

Clean mount of decoder

Circuit uses a bit of perf board and a 3M Scotchflex socket I've used for other projects. Surprisingly, I did not have a 74LS21 in my junk box. I salvaged the soldered unit I had hastily assembled in 1986. That worked out. The board is cleanly mounted on a spacer to the motherboard and all of the connections are made with wire-wrap wire.

Testing

Testing, much to my surprise, went perfectly. The disable jumper worked as before. Enabling the aliased extended decoding allowed me to use the xE pages of memory, and a special burn of the BBUG ROM allowed me to test I/O at FF780-FF7FF. This worked as expected. I could enable and use the FExxx block of RAM on the MC68B09 V2 CPU board and access it using the DAT,

Not sure why I was afraid of all these "fixes". I suppose I was shy about changing the motherboard in a way that might break the computer entirely.

Retirement Project: SWTPc 6800 (with 6809) Resurrection

In 2022, I documented my ancient SWTPc 6800 Computer System, which I had upgraded with several home-brew cards. It had been 25 years since I had last used the computer, but this ancient machine fascinated me. I wanted to record what I had done, as I'd forgotten a lot.

During this process, I plugged in one of the I/O cards incorrectly -- off by one pin. Normally, there's an index pin that prevents this, but some of my cards don't have the plug that blocks the pin. 

Sadly, when I powered it on, smoke was immediately released from one of the chips. After correcting that board, I found the system completely inoperable. This computer was 45 years old at the time, and I had many other projects that needed more attention. I decided that fixing it would be something I could do in my retirement. 

And, it remained broken until this year. You see, I've retired, so it was time debug this monstrosity.

When I originally built the CPU boards for this machine, I borrowed a 32-channel HP Logic analyzer. That allowed me to fix the bugs in the hardware and the software alike. But I long-ago lost access to such equipment. I had little more than the original kit manuals, schematics and notes, plus a digital voltmeter and an oscilloscope.

Symptoms

After the smoke let out, the machine crashed on reset. I could see from the front-panel LEDs that the CPU had gotten completely lost -- with every 4 KB block LED illuminating dimly. This is characteristic of a crash. 

Debugging

Initial step established what was working on the machine. I removed all the cards from the motherboard. I checked the power supply voltages on the motherboard:

• +8v: +8.3v
• +12v: +14.15v
• -12v: -14.06

These unregulated voltages were nominally good. I verified that several of the bus signals were pulled high on the motherboard, such as RESET*. Everything seemed good.

I added the Bit Rate Generator board. It supplies all the serial bit rates on the SS-30 bus. I couldn't find any clock rates using the oscilloscope. Looking at the original schematic and the MC14411 data sheet, I found one thing missing. The data sheet recommends a 15 M Ω feedback resistor across the crystal. My circuit had none. Other designs used a 1 M Ω resistor. So I added one. Now I found all of the bit rate clocks present. Funny that it worked before. 

Next was the 6809 V2 CPU board. The LEDs would light up on reset, then go into the characteristic crash. Examining the important signals on the bus:

• RESET* - goes low for 0.1-0.3s, then high
• HALT*, BREQ*, MRDY, NMI*, IRQ*, FIRQ* -- all staying high. 
• BA, BS - both low -- this means that the CPU is actively controlling the bus
• E* and Q* - these clocks running at 2 MHz, as expected, this mean the CPU was alive at least
• VMA* - cycling, meaning the CPU was attempting to access the bus
• R/W* - cycling as expected
• D0*-D7* - each data bus pin showed signs of normal activity
• A0-A15 - the Address bus had problems on two pins
• A3 - activity limited to 0v to 1v
• A14 - activity stuck around 0v

This was good news. The CPU was working and attempting to process instructions, as evidence by the clocks, the BA/BS status pins, and the data bus activity. 

The address bus seemed to be the source of difficulty. When the I/O board was plugged in incorrectly, one of the chips received -12v, and that same chip was also connected to A3. As there are no buffers on A2 or A3 between the SS-30 and SS-50 bus, it is possible the 74LS244 address bus buffers could have been damaged. That didn't explain A14, but it made sense.

I swapped out both 74LS244 chips, and the CPU board now acted correctly -- polling the E block of memory, where the I/O resides. The E LED was brightly lit.

An MP-S board was added next. Since it was not connected to the A3 line, it was unlikely to be damaged. I needed something to function as a terminal to connect to the MP-S. I fashioned a DB-25 to DB-9 cable and hooked it to a USB serial port on my MacBook Pro. Pressing RESET brought up the "BBUG v1.91" prompt. YES! After nearly four years of being non-functional, my old computer was able to run the ROM monitor. 

Using the capabilities of the BBUG monitor, I set about diagnosing the other parts of the system. Since the last time it was operation, I expanded the CPU board memory from 64 KB (really 56-60 KB) to 256 KB (really 248-252 KB). I set about testing to make sure all of this additional RAM was functional. Because the MC6809 processor can't access more than 64 KB of memory at once, I had to do this in steps. I manually re-programmed the DAT to use different blocks, leaving the D, E and F blocks alone. The additional memory worked great.

With the CPU card functional, I set about to determine what else was working. 

Working on the I/O slots, something was amiss with the MC6840 on the bit rate generator board. A 74LS04 inverter connected to the A3 bus line had apparently been damaged. Swapping it out restored operation to the MC6840.

The 5 1/4" Floppy Disk Controller (FDC) board was the one that had been plugged in wrong. A 74LS139 that let the smoke out had been replaced, and everything seemed to be working. Similarly for the 8" FDC board. Both boards would respond properly to basic commands, even with no disk drives connected.

The Tanner/Digital Research 64KB RAM board was next. It took some experimentation to discover how to address its extended memory address. I found that the BBUG "Q" command, which does a memory test, can be fooled by bus capacitance. That's a bug that needs to be fixed. While the memory appears to be present, at least some of the time, there appear to be some address or data convergence problems. I haven't quite sorted that out yet. 

Next Steps

There are still issues that need resolution. I've attempted to boot FLEX/09, but it fails rather quickly. It appears to be properly loading the boot loader off the first sector of the disk, but for some reason does not appear to be able to load FLEX.SYS. I think my problem is that I don't have 5 1/4" boot disks set up for these 80-track drives. Most of my use of FLEX was limited to 8" disks, and those drives aren't yet connected.

An attempt to boot into OS-9 Level I also failed, even though I have several 5 1/4" boot disks. That's going to take more time to diagnose. It could be there's other damage to the 5 1/4" FDC board that I haven't isolated yet.

Claude Helps with the Automatic Antenna Selector

Automatic Antenna Selector

I thought I was nearly finished with the Auto Antenna Selector. During my first week of retirement, I finally managed to locate something I had been looking for months -- A male-to-male DE15 cable. 

This cable connects the Auto Antenna Selector to the AUX port of a K3. I bought two of these a couple of years ago, and I easily found one. But the second one eluded me. Without it, I couldn't test the Selector in Design C (Dual Radio) mode. I had done all my testing in Design B (Single Radio) mode. 

Having the proper cables, I did my testing and found several bugs. Some of them were going to be difficult to fix. Part of the problem was my approach. I had organized my antenna selection table by the selections, then by band. This made it difficult to determine the choices available per band. So, I organized the table by band, then listed the choices. From this, I could determine which choices were available for a given band, skipping over those that would conflict with an existing port. 

This greatly simplified the code for making the mode selections, which are very different in Design B (Single Radio) and Design C (Dual Radios). In Design B, the first selection is assigned to the first port, so there can only be three additional choices. In Design C, only one port is selected per radio, so we can potentially use all four selections (so long as there's no conflict with the other radio).

Design C bugs were all addressed, and Design B worked better than ever.

Before I retired, I'd been messing around with Anthropic's Claude Code. I was curious what Claude might think of the firmware, so I requested an in-depth code review.

Claude Code came up with a number of good suggestions. It found some dead code, made several type suggestions, a minor code re-organization, and way better comments.

What impressed me, though, was that Claude Code had a deeper understanding of the particular PIC processor that I did. It suggested I turn on the Watch-Dog Timer (WDT). That I change how Timer 0 (TMR0) was used. And, that I use the PMD register to power-down the modules that I wasn't using in the device. 

I thought I was using TMR0 correctly. And I knew about the WDT, I just didn't think it was necessary. But the PMD register I knew nothing about. All of these suggestions seemed like a good idea to me, so I made them.

All in all, Claude Code did eight rounds of review of this code. It made a couple of suggestions that I knew were wrong, and it took corrections well. 

The next day, I burned a chip and plugged it in the unit for testing.

It bricked, Nothing. Not even a single flash of the LEDs on startup.

Somewhere in the midst of Claude's suggestions, we had changed the software in a way that it no longer worked at all. 

I made a new branch of the code and backed out some suggestions. I determined it had nothing to do with the WDT or PMD register. That left something amiss with TMR0. This could be a problem with Microchip Code Configurator (MCC).

I had switched TMR0 to use the HFINTOSC. It was programmed to generate an interrupt every 5 ms. Except it didn't work. I switched it back to us the LFINTOSC, also programmed for every 5 ms, and it worked as expected. I'm not sure why it didn't work with the HFINTOSC, but having several oscillators gives one options. I'm happy it works.

Once it was working again, I walked through all of the Design B and Design C test scenarios. Everything worked with flying colors. 

AI is certainly useful, even for amateur radio projects. Just don't blindly trust it. Remain in the loop for all changes.

Polishing Up the Rx Antenna Controller

Many software projects are never fully complete, as there's always something to add with a small change to the software. The Rx Antenna Controller isn't any different. 

The initial version of this project was basically done. But pressing the antenna selection buttons resulted in a response on the serial port. This could cause problems with computer control if the response was not anticipated.

I added a new command: &AI; and &AIn;. This gets and sets the Auto-Info mode, respectively. With &AI1;, pressing an antenna button results in an &ARn; response on the serial port. &AI0; turns off Auto-Info mode -- button presses do not result in a serial port response. The default is &AI0;.

I"m very happy with the way this project has turned out. While I have ideas for a Version 2, it mostly involves hardware changes to the remote switching box to allow selection of the AUX antenna for diversity reception.

Rx Antenna Controller

Rx Antenna Controller is QRV.

I started building this unit a couple of months ago. I called it the Beverage Controller, because my motivation was to select amoung the three Beverage antennas I had erected. Yes, I've managed to erect three 500 foot Beverages, one to the NE, SE and NW.

Performance of these antennas is convincing -- 1-2 S-units lower noise than the inverted-L or dipole antennas I use on 160 and 80m, respectively, plus a directional signal boost if the beverage is pointed in the right direction.

I discussed my design issues with this unit in the previous article. Debugging the serial port took another month.

Serial Port Debugging

The reason I had chosen the PIC16F18426 for this design was because of the built-in EUSART. Receiving worked just fine. I could send commands to the controller and it would act on the commands. But it sent no response. 

I had configured the PIC to use RC5 (pin 5) for the EUSART receive input, and RA5 (pin 2) for the EUSART transmit output. After a bit of troubleshooting, I found no action on RA5. It remained at 4.5 V the entire time. Was this a wiring problem, or a programming problem?

I ended up writing another PIC project and setting up a chip on a solder less breadboard to solve this. This project simply sent "Hello World!" at 300 baud every 5 seconds. It also drive two LEDS on the C port pins. The LEDs which alternate during a 1-second startup. When transmitting, the second LED would light up. 

My serial test project worked perfectly. LED 2 flashed for about 1/2 second every five seconds, just as expected. So, why didn't the beverage controller project work?

I modified the beverage controller project to also send "Hello World!" every 5 seconds. Except it didn't work. I traced the wiring in the controller head. RA5 was connected to the MAX232E pin 11. It was the MAX232E that was driving the pin to 4.5 V. With the MAX232E out of the circuit, RA5 stayed at 0 V all the time. It was like the software had configured RA5 as an input, not an output.

I got to the point that I could test both projects on the solder less breadboard. I even programmed the same chip with the serial test project -- and it worked. Programmed the same chip with the beverage controller project -- and it didn't. This was definitely a programming problem.

I tried several modifications of the configuration, eventually applying the serial test project configurations to the beverage controller project. At some point, it started working. I still don't understand what I changed to make it work.

Putting It Together

Remote relay box

After such a struggle, I was happy to finish. I re-programmed the chips to send and receive at 9600 baud. This is plenty fast enough for this purpose.

The controller supports one Kenwood/Elecraft-style command, which takes two forms - a Get and a Set operation:

• Get - &AR; -- responds with &ARn; where n is 1 through 5
• Set - &ARn; where n is 1 through 5 -- selects the antenna specified by n, responds with &ARn;

With the serial port transmit working, I could remotely interrogate the controller to determine which receiving antenna was currently selected. And selecting an antenna would respond to ensure that the controller had received my command.

The controller mounts nicely on the equipment shelf. I used some temporary stick-on labels until I find my computerized label-maker. 

What's Next

The current firmware sends an &ARn; response when a button is tapped. I probably need to make that configurable with a serial command.

I've also thought about adding a scanning feature. The controller could automatically switch antennas after a few seconds. Holding a button could add/remove that antenna from the scan.

However, after a couple of months of using the controller, I've found a glaring deficiency in my design. The Rx Antenna Controller only selects one antenna for the RX ANT port. I use a broadband splitter to also connect to the AUX port for diversity reception. But this only permits diversity reception of one receiving antenna against the transmit antenna. I can't do diversity reception between two receiving antennas. 

What would be nice is to have the remote relay box select the antenna for the RX ANT and AUX port. This would require twice as many relays and a way to control them individually. Doing this requires a re-design of both the remote relay box and the controller box. 

Bell & Howell IMD-202-2 (Heathkit IM-1212 In Disguise)

Bell & Howell IMD-202-2 in place at workbench.

When my Systron-Donner digital multimeter was damaged by lightning in June of 1992, I looked for a replacement. Somewhere along the line, I found a Bell & Howell IMD-202-2 at a hamfest. This was at least twenty years ago -- I have a email message from January 2005 asking about it.

Somewhere along the line, this meter refused to measure anything. When I moved it to Ward Mountain, it was time to fix it. 

The sticker of the multimeter says "Heathkit IMD-202-2", but it's not a Heathkit number. In twenty years, there's apparently more information available. I found that it's a Heathkit IM-1212 with a Bell & Howell label. They sold this unit in the late 1970s as part of an electronics instruction course.

While I couldn't find an assembly manual, I did find a schematic and a calibration procedure. The unit is a simple and straightforward design. Opening it up, there's a single circuit board, plus a bit of wiring around the function and range switches. 

Stepping through the calibration procedure, I couldn't find anything amiss. I had difficulty using a frequency counter to set the counter oscillator. Even with an oscilloscope, I couldn't find a clear signal to measure -- yet the unit was working. I decided to use the calibration without a frequency counter.

When performing the DC and AC voltage calibration, I backed up these measurements using a modern portable digital multimeter. In the twenty years or so since I obtained the Bell & Howell, I've purchased four of these gems. 

The calibration went smoothly, and the Bell & Howell now has an honored place on my workbench. 

Measuring 1k resistor.

Compared to modern instruments, it's not impressive. It sports 2 1/2 digits -- the first digit is just a neon lamp that signals a leading "1". A second neon lamp lights a "OVER" indicator. By comparison, my modern portable digital multimeters have 3 1/2 digits, and at least one of them is auto-ranging. Accuracy isn't great -- perhaps 2% when freshly calibrated.

Still, it's sufficient to be tied to the workbench. The problem with the modern portable digital multimeters is the "portable" part. I leave them all over, and can't find one when I need it. Plus, the nixie tubes are cool.

At least until I can fix the Systron-Donner, which is a much nicer instrument. I have full manuals for the Systron-Donner. Last I looked, it had a problem with fried comparator using a LM301AH with matched FET input amplifiers. Yes, that's a TO-8 style integrated circuit, something you haven't really seen since the early 1970s. And the matched FETs are in a common plastic case with six leads -- a rather uncommon part. I intend to remove the damaged parts and install new parts with socket pins. 

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.

RealVNC Changes Terms, without Notice.

Just over three years ago, I figured out how to Remotely operate FT8 using a product called RealVNC. 

RealVNC had a Home plan that allowed up to 3 users and up to 5 devices for non-commercial use. Perfect for remotely controlled computers in a ham radio shack.

Today, without any notice, RealVNC disabled my Home plan, and I had to choose between paying each month for a plan, or adopting their Lite plan, which allows 1 user and up to 3 devices for non-commercial use.

That's fine. They allow me to use their secure remote access software without fees. I can understand they might want to change the terms.

The Lite plan fits my usage. I've only ever had two devices active anyway, and it's just me as the user. 

But, without notice - that is just damned inconvenient. Since I switched plans, I need to visit each device and re-configure them to be part of the new plan. Which means I can't remote into those computers until that is completed. 

And, of course, since I'm remote, I'm not there.

Quite inconvenient.

FT8 is supposed to make DXing easy, why is it so hard?

FT8 has been a revolution. The technology has made DXing really easy. Or has it? I continue to be amazed at how much difficulty people have working DXpeditions on FT8. 

Last year, there were DXpeditions to Bouvet (3Y0J), Crozet (FT8WW) and Sable Islands (CY0S). The most recent DXpedition to Glorioso Islands (FT4GL) has brought it all back to me.

Let's start off with a few observations on people trying to work these DXpeditions:

• Wrong Cycle - It's amazing the number of folks trying to work DX that are calling on the wrong cycle. FT8 has even and odd cycles. Even cycles start at 00 or 30 seconds, and odd cycles start on 15 and 45 seconds. You always call on the cycle the DX station is NOT transmitting. Indeed, if you double-click on a decode of the DX station, WSJT-X will set up the correct cycle. So how are people getting it wrong?

• Endless Calling - I've noticed some stations keep calling the DX after the DX station has QSYed or QRTed. A little bit of hopeful calling isn't unusual on Phone or CW, or even RTTY. But stations continue to call much later -- like an hour later, and they are still calling.

• Calling without Response - Some stations don't respond when the DX station calls them. They keep calling instead of advancing to the next step. This can get really bad. During the FT8WW expedition, I saw FT8WW keep responding to the same station for more than 10 minutes. Each response had a different signal report. This made it clear that FT8WW was heading this caller quite well, but the caller wasn't hearing FT8WW at all. Instead, that station took up a valuable response slot for 10 minutes -- denying perhaps 20-40 stations from working FT8WW.

• Confusing Fox/Hound (FH) and MSHV - Most DXpeditions using FT8 use either FH or MSHV in order to maximize the number of contacts they can make. It is easy to get confused with these two modes. They appear similar. Both allow for the DX station to transmit multiple FT8 carriers at the same time. FH imposes additional behavior to both the Fox and Hound ends of the contact. In particular, there are audio-frequency dependencies that FH enforces. But, it is perfectly possible to work a Fox station even if you are not in Hound mode. MSHV requires no special modes. And yet someone accused people of DQRM, calling FT4GL below 1000 Hz, when the DX was using MSHV, not FH.

What causes all these odd observations? I believe they all resolve to a single cause -- people are calling DX they cannot hear. That's right, people are calling DX stations they aren't decoding at all.

This is fundamentally wrong. I wrote about this years ago on how to bust a pileup. You cannot work DX if you cannot hear them. If you aren't decoding the DX station, stop calling. Yeah, that's hard, but your calls won't net you a contact, and you may be actively depriving someone who can hear the DX from making one. 

I think FT8 has made some people lazy. They hear some DX station is active on some frequency, probably through a spotting network. So they switch to that frequency, set their watchdog timers to an hour or more, and enable their transmitter. Then they go off and drink a few cool 807s while their computer works the DX for them.

Farfetched? No, it explains all the observations above.

Be a good FT8 operator -- don't call DX when you cannot decode them. Wait until you can decode them reliably, just about every cycle -- then start calling.

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.

Forty Years of Personal Computing - Das Blinkenlights

SWTPc 6800 front panel, sporting sixteen LEDs.
Each LED indicates a 4 KB address block access.
You can also see a yellow power LED was added.

The SWTPc 6800 Computer System sports a rather spartan black and silver front panel. Unlike contemporaries of its day, there were no lights.

I'd already modified the front panel of my computer. I mounted the CIS-30+ cassette interface inside the case, which accounts for the assortment of holes in the upper right. There's a yellow power LED next to the reset button. Before I went to the ISEF 1979, I replaced the power switch with a key switch. I added the yellow LED so I could tell when the machine was on. 

While building the MC6809E V1 board, I decided to add some lights. Hooking up LEDs to the address bus didn't seem useful, since addresses change quickly. Plus, the DAT complicated the issue -- do you show logical or physical addresses?

I ended up with a simple solution. Running the top four CPU address lines into a 4:16 decoder, each LED indicator represents a logical 4 KB address block. This connects to the CPU board directly, before the address signals enter the DAT. 

Board holding 74LS154 and LEDs.

I drilled the front panel for sixteen LEDs. On the backside of the front panel, I mounted a 74LS154 4:16 decoder and wired up the LED cathodes. The board is held in place by the LED wires. A 16-pin ribbon cable goes back to the CPU board and attaches to a socket.

This socket has address pins A12-A15 from the CPU, the VMA* signal, the DAT write decoder signal, +5 volts, and ground. The VMA* and DAT write signals go to the two Enable* pins on the 'LS154. This means the address must be valid, and not writing to the DAT to enable.

The LEDs anodes are connected together to a resistor to +5 volts. Originally, this was a 470 ohm resistor. I found that the LEDs lit very dimly. Each LED is not asserted all the time. VMA* is not asserted at all times, and pulses every clock cycle, which limits how bright the LED can illuminate. I decreased the resistor value and experimentally arrived at a value of 22 ohms.

The resulting front panel is informative. I can see when the CPU is busy-waiting on I/O ports, if it is crunching away at some calculation, or if it has crashed entirely. And if the CPU executes a CWAI instruction to wait for interrupts, all the LEDs go dark.

Cool.

Nine-Band Worked All States

Nearly twelve years ago, I wrote about completing Worked All States on six bands. I'd worked all states on 160, 80, 40, 20, 15 and 10m. About three years ago, I finished up 30m, so now it was seven bands. However, finishing 17 and 12m seemed like it would take forever. I felt stalled out.

A couple of months ago, it occurred to me that I was only four band-states away from Ten-Band Worked All States. I needed Delaware on 17m, Kentucky on 12m, and Alaska and Hawaii on 6m. 

The 6m states would have to wait -- I'd need very special conditions to work either state. But with the recent rise in sunspots, working those close-in states on 17 and 12m seemed do-able. The biggest problem would be operating the Gwinnett station. That was solved after I configured the RemoteRig devices to allow remote operation. 

Indeed, the first afternoon operating remotely, I was able to work Kentucky on 12m and the LoTW confirmation came the next day. Finishing off 17m took a month longer.

It was surprising to me how calling CQ DEL AA4LR EM83 would gather so many responses from people who were not in Delaware. I worked at least one station in Delaware, but the LoTW confirmation was not forthcoming. Then the RemoteRig Control device no longer powered up.

I got lucky one Friday afternoon when I was in Gwinnett county and managed to get a legitimate answer to my CQ DEL message and a confirmation later that day. I'd done it. Worked All States on Nine Bands. 

Now, I just have to wait for those special conditions in order to work Alaska and Hawaii on 6m....

Remote Operation - Level 0 (RealVNC)

Sometimes experiment pays off. You never know until you try.

I was reading an article about remotely controlling computers over the internet. It occurred to me that if I could do this, it would be easy to operate FT8 from my Gwinnett QTH when I was at the Fulton QTH. Although I have rigs in both locations, Gwinnett is where I have the K3, and can operate on 6m. 

I started to research solutions. I found a product called RealVNC that can be licensed free for non-commercial use on up to five computers. Comes with a separate server and viewer product, and it works on Macs as well as Windows, Linux, even the Rasberry Pi. 

You have to create an account on their web site, but the installation was easy. I have a MacBook Pro hooked to the K3 at the Gwinnett QTH. I installed the server there. Then I installed the viewer software on a couple of Macs, and one Windows computer. 

Making the connection from Viewer to Server requires 2-factor authentication, so it is pretty secure. 

This software worked great. I was easily able to connect to the MacBook Pro and use WSJT-X. The K3 has to remain turned on, and I have no way to remotely change antennas, so I left it switched to the 3-element 6m beam. I also have no way to rotate the antenna remotely (it uses Armstrong rotation...), so I left the beam pointing SouthEast. I was hoping to pick up some propagation to the Caribbean or perhaps Central or South America. 

The first week of this experiment bore fruit the next day. I was in Fulton county, but checking I lucked into an opening to South America, where I worked two stations in Chile and two in Uruguay. Two new countries and four new grids! The next day, there was a powerful, but brief opening to the Cayman Islands, and Belize.

While one cannot predict 6m propagation, remote operating gives me a tool so I don't miss out on openings while I'm away from the Gwinnett QTH. 

This is only Level 0 of Remote Operating. I can only do FT8, and I can't change bands. That's next, I'm working on an automatic antenna switch driver to choose an antenna by the band selection of the K3. 

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.