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.

The Great LoTW Outage

May 16th, there was an issue with Logbook of The World (LoTW). I could not load the main page at all -- receiving an error indicating the server wasn't responding.

That's pretty normal stuff, actually. There are dozens of problems that can result in this kind of error, so I wasn't surprised. I figured the ARRL staff would address it quickly. But, after much of the day, I was still getting the error. 

So, I sent a message to lotw-help@arrl.org, informing them that the web site wasn't responding, kindly asking when they expected it to be back up. I mentioned I was surprised there was no notice of the outage on the ARRL.org web site.

Later that day, the ARRL put up a notice that there was a service disruption involving access to the network, and that it affected LoTW and the ARRL Learning Center. They even updated it the next day, addressing concerns users had over information privacy.

But then, nothing happened. Not until May 22nd, when they updated the notice without really adding any information. 

Now, part of this delay may be due to the fact that much of the ARRL staff were all out at the Xenia Hamvention. But, that was a week ago.

What gives? Sure, networking problems. Honestly, though, as a computer professional, networking problems generally don't take more than a week to solve. I'm beginning to suspect there's something more than the ARRL hasn't told us, but I can't be sure.

I'm really missing access to LoTW. In the last 20 years, it has really become central in my enjoyment of the hobby. I do hope I'm wrong, and that ARRL manages to fix this problem soon.

Fixing up the Cushcraft A50-3S

A50-3S standing tall and
straight next to the house.

Last year, I moved the A50-3S out of the yard and up next to the house. I used a 19 foot mast made of two pieces of EMT. While putting it up the reflector bumped against the roof and turned askew about 15 degrees. 

Never the less, it worked well. I worked a few Europeans and several South and Central American using this antenna.

Still, it needed a bit of work. A one-piece mast would be better, and I could straighten out the reflector when I swapped masts. A bead balun at the feed point wouldn't hurt either. 

So, I researched these. You would not believe what a 20 foot piece of 1 1/2" 0.058 wall aluminum tubing goes for these days. A few years ago, I purchased a 12 foot piece of 2" diameter 1/4" wall 6061-T6 tubing for my gin pole. It was about $150, which seems right for such a substantial piece of metal. 

But 20 feet of the thinner mast? They quoted me $500! If I went with the 1/4" wall, well that was manufactured with a different process -- extruded instead of rolled, so it would be $250. Ridiculous. There had to be another solution. 

I did have 20 feet of mast in two 10 foot pieces. This was from an earlier experiment. I had an old Butternut  HF4B that I had rebuilt, and was hoping to erect in Fulton County. I bought two pieces of Rigid Metal Conduit (RMC) for this purpose. 

EMT and RMC are easily found at your local Home Depot. But it isn't exactly what you would call structural. EMT is design to bend. Easily. I have had some success using it as masting for very small, light antennas. The two pieces I used on the A50-3S lasted for over eight years, plus the several years holding up a 19 element 2m boomer Yagi. RMC is more substantial, and comes with threaded couplings to connect them together. 

Two pieces of 10 foot RMC was $30 a pop, so this wasn't a cheap experiment. Even with the coupling tightened all the way down, the 20 feet of mast had a substantial wobble in the top section. I tried inserting a solid piece of HDPE. That helped, but not enough to hold up the HF4B. 

It occurred to me that this might work with the A50-3S, even with the wobble. The A50-3S is held upright by a wall bracket at the eve of the house, well above the wobbly union. I just needed the vertical support, and not so much lateral rigidity. Besides, I already had $60 invested.

First order of business was to find the doggone things. I put them away three parsonage moves ago, and had hidden them well. They were hiding in my basement. After that, I had to locate the piece of HDPE, which I found in another box. 

It all came together this week. My youngest daughter Lauren helped me to lower the existing A50-3S and mast to the ground. Off came the antenna and the feed line, and the old mast was disassembled and put away. Then I coupled the RMC together with the HDPE stiffener and taped the coupling joints against any water intrusion. With the A50-3S mounted on the new mast, the reflector was aligned with the rest of the elements. 

For a balun, I used five snap-on ferrite beads. I measured these at about 100 ohms resistive at 50 MHz. Five conveniently fit on the 9913 coax from the driven element to the mast, so that is what I used. 

A50-3S facing South East.

Swinging the new mast up into place without bashing the antenna against the house took some patience. The RMC mast is much heavier than the two pieces of EMT. Once vertical, I positioned the mast in the eve bracket and loosely connected the u-bolt clamp. Both my daughter and I lifted the assembly to the top of the railing. From there, I tightened the bracket to eliminate play, but loose enough to allow the antenna to rotate. I used a couple of extra 1/4" nuts as jam nuts so the bracket could not tighten or loosen. 

The antenna is easily Armstrong rotated from the base. Eventually, I'll mount a rotator on the top of the railing and retire my arms.

A quick SWR check showed a 1.2:1 SWR at 50.313 MHz. The antenna is pretty broad. Minimum SWR is around 50.8 MHz at 1.07:1. I suppose I could mess with the matching network to get a better match on the FT8 frequency, but the whole bottom 2 MHz of 6m is less than 1.5:1. 

The antenna is 28 feet (8.5m) off the ground with clear shots from the North clockwise to the South West. Points to the West and North West have to pass through the house roof.

I hope Es season hasn't passed me over yet. 

How 1984 wasn't like "1984."

In 1984, I was working at Hayes Microcomputer Products. They were the premiere modem manufacturer for small computers, back in the days when modems over telephone lines were a primary means of computer to computer and user to computer communications. 

In my job, I created communications software to talk to the modems. The software dialed the modem, established connection, provided terminal emulation (my specialty), allowed for the capture of the data stream to files, printing, file transfer with the remote computer (using protocols like XMODEM and YMODEM), and other features. 

These were the early days of personal computing. IBM introduced the PC in 1981, and it had rapidly evolved into a defacto standard computer, shoving out various CP/M designs from the previous decade. Personal computers were so new, people were trying to figure out what to do with them. Word processing, spreadsheets and other office applications had just been introduced. 

Hayes was trying to stay at the forefront. We had a laboratory filled with pretty much one of every personal computer, and when new ones came out, we would buy one. In late 1983, we got an Apple Lisa. It was a very different kind of computing experience. It was a curiosity to us, and as there was no programming environment available, we didn't see how we could build software to talk to a modem. Plus, at the price point, there were few buyers.

The Macintosh

Though the Macintosh was introduced in January of 1984, I didn't get hands on one until the late spring of 1984. Yes, we brought one into the lab, and it immediately garnered a lot of attention. 

While there were similarities to the Apple Lisa, the small screen with square pixels just seemed sharper and more distinct. The whole interface was friendly and approachable. We messed with MacWrite, MacPaint, and MacDraw. We printed on an ImageWriter, making appreciably decent images unlike anything we could do on another type of computer. There were several of us hooked and enthusiastic.

It's hard to describe those days. At this point, everyone has had decades to become familiar with computers that use a graphical user interface and a mouse or other pointing device to interact. Back then, it was a revelation. It was much more approachable than the command-line interfaces of the day. 

As I described it to someone in the early 90s -- other computer interfaces required one to reach toward the computer. You had to learn the special language and commands of that computer. The Macintosh was the first computer that reached back toward you -- the user.

The Machine

The Macintosh was based on a 16-bit Motorola MC68000 processor, running at 8 MHz. This was more than competitive with the Intel-based IBM clones circulating at the time. This processor was a great choices by Apple. It had many registers and powerful instructions for manipulating the bit-mapped screen.

Biggest constraint was memory. The 128 KB in the Macintosh was shared with 24 KB used for the screen, several more KB for operating system usage, leaving about 90 KB to run your program. Most of the critical operating system routines were in the Macintosh ROMs, which saved space. Building a program of any sophistication was difficult -- It was very tight to work with.

The single 400 KB floppy disk drive was also a limitation. Trying to save a file to another diskette could produce an endless amount of swapping. It was the lack of addition storage that kept me from buying a Mac until the Mac SE/20 was introduced in 1987. 

Next Steps

By summer, Hayes hired some consultants to look into the feasibility of developing communications software for the Macintosh. In just a few weeks, they had some rudimentary software going and concluded that it was quite feasible. 

We were soon green lighted to create a product for the Macintosh.

Forty Years of Personal Computing - Gimix 256 KB Static RAM

256 KB Gimix Static RAM board, sans battery.

In 1991, my employer moved to a new building. Before the move, we cleaned out storage closets containing old equipment. Much of this was obsolete gear. Things like pairs of "twiggy" disk drives removed from early Apple Lisa systems upgraded to 3 1/2" disks in 1985.

In one closet, we discovered something unusual. It was a complete Gimix III "Ghost" system. This was a  2 MHz 6809 system sporting a fifteen-slot SS-50 motherboard and eight SS-30 slots and floppy disks: a top-of-the-line 6809 system from the early 1980s. 

By 1991, the company had no use for this equipment. I had the impulse to take the entire system home, but I didn't have room. My wife and I were living in a small house and the garage was already packed. She would not have been happy if I brought home a bunch of equipment. 

Instead, I salvaged exactly one board -- a Gimix 256K CMOS Static RAM board. It sported 256 KB of memory, with several options, including battery backup. The rest was scrapped by an electronics recycler. 

Obtaining the board, I tried it out in my system. I was able to map in 4 KB blocks of memory and test them. They all worked. I might use the additional memory as part of a virtual disk drive. 

In 1994, I moved, and the entire system was stored away for over 25 years. Looking at it recently, I found it needed repair. Over the years, the backup battery failed and leaked electrolyte on the board and motherboard. Several Molex connectors are damaged, and need to be replaced. Some of the components show signs of corrosion from the battery electrolyte. 

I removed the failed battery. I do hope the rest of the board still works once the repairs are complete. Perhaps I'll fix it in my retirement.

Forty Years of Personal Computing - MC6809 V2

MC6809 CPU card, version 2.

By March 1988, the MC6809E V1 card I designed in 1983 needed updates. I built an entirely new card with new features intended to run OS-9 more effectively. 

CPU

A MC6809 chip simplified things with the on-chip clock oscillator. The chip handled M.RDY without extra logic, and the rising edge of the Q clock did not need delay.

Memory

The MC6809E V1 card had no on-board RAM. There wasn't room. By 1988, a number of manufacturers had 32 KB static RAMs in 28-pin packages. 64 KB of memory is realized with a couple of chips. 

For the V2 board, I allowed for eight chips, totaling 256 KB of memory. This was a good compromise between cost and the space available. The memory is logically separate from the rest of the card -- decoding from the physical address and data bus, using appropriate buffers. In this way, the memory can be accessed by a bus master other than the CPU. It responds to physical addresses C0000-FDFFF or FEFFF, jumper selectable. For years, it held two chips -- 64 KB on the board -- with only 56 KB accessible. The six remaining chips were added recently, making 248 KB or 252 KB accessible. 

Buffering

20-pin bus driver chips reduced the chip count, even with two sets of bus drivers, one for the CPU, and one for the memory array.

Program ROM

The design allows for a much larger ROM. The MC6809E V1 card originally had two 2KB 2716-compatible sockets -- one for a ROM and another for ROM or RAM. To make swapping OS-9 and BBUG easier, I changed this to a single 4 KB 2732-compatible ROM socket

For the MC6809 V2 board, the ROM can be a 27128 or 27256-compatible device, holding 16 KB or 32 KB, respectively. The larger ROM permitted more OS-9 modules to reside there, if desired. 

As built, a 27256-compatible EPROM is used, containing a BBUG image in the top 4 KB of the lower 16 KB and the OS-9 ROM image in the upper 4 KB of upper 16 KB half. A jumper selects which half is active. This is much easier than swapping chips to go between BBUG and OS-9.

Accessing the correct amount of the ROM requires clever decoding. 

Decoder

A hard-wired decoder would limit the flexibility of the system, and it would be complex and difficult to change. Rather than discrete logic, the decoder consists of a Cypress Semiconductor CY7C291 2Kx8 EPROM. This is a fast device with a 70ns access time. The CPU address lines A5 to A15 are connected directly to A0 to A10 on the chip. The decoder is enabled with the logical OR of E and Q, which asserts during three quarters of the memory cycle. This way, the eight data output pins can be used as decoder selects programmable on every 32-byte segment of memory.

Three select lines are used: one for bus access (including the on-board memory array), one for the program ROM, and one for the DAT. Each select line is pulled up to +5v. Placing a 0 bit in the decoder ROM data array makes the select line active for that 32-byte memory segment. 

Modifying the memory map becomes a simple matter of programming the decoder ROM. I programmed the following logical memory map:

• 0000-EFFF - Bus
• F000-F77F - Program ROM
• F780-F7FF - Bus
• F800-FFFF - Program ROM
• FFE0-FFFF - DAT (writes only)

This configuration is compatible with the existing ROMs for BBUG and OS-9, which require I/O at E000-E07F. It has 4KB of program ROM, except for the hole at F780-F7FF. This hole deserves a bit of explanation. 

I/O Port Address Migration

BBUG occupies the top 2 KB of ROM. The OS-9 ROMs take up nearly 4KB. However OS9p2 doesn't use the last 128 bytes of that space. This unused space became an alternate location for the I/O ports. If the I/O ports moved from E000-E07F to F780-F7FF, the MC6809 could use RAM in the logical E block (E000-EFFF), for a total of 60 KB of RAM, up from 56 KB. 

Moving the I/O address requires motherboard decoder changes and software changes to the BBUG and OS-9 ROMs, as well as revision to Flex09 and OS-9 I/O configurations. The V2 board decoder ROM would work with the existing motherboard, or with the motherboard and ROMs altered for the new I/O addresses.

Larger ROM

Once the I/O addresses are moved, the decoder can be reprogrammed to allow for more ROM space. This opens the option of moving OS-9 modules into ROM. The decoder allows the lower limit of the ROM to be changed in 32-byte increments. This allows an OS-9 system to be entirely in ROM. OS-9 would start from the reset button without requiring a boot disk.

DAT

Back side of MC6809 V2 card.

The DAT configuration is similar to the MC6809E V1 board, with one important difference. In the SWTPc MP-09 board, as well as my V1 board, the outputs of the DAT are inverted on the lower four bits (A12-A15), but non-inverted on the higher four bits (S0-S3). 

This means that values programmed into the DAT must be one's complemented on the lower four bits (A12-A15), with the higher four bits (S0-S3) not complemented. 

For the V2 board, all eight bits of the DAT are inverted on the bus. Thus, the value programmed into the DAT is the one's compliment of the highest eight physical address bits (A12-A15, S0-S3). 

Which makes programming correct DAT values simpler, since the entire byte is complemented.

I introduced a hardware bug in the DAT decoder. More on this later.

Building

Rather than wirewrap, I opted to try something new. A technician from work gave me a couple of 3M Scotchflex Breadboarding kits. This breadboarding system was brilliant. Chip sockets connected to IDC pins. Wiring is accomplished by forcing wire-wrap wire between the IDC pins with a special tool. 

It is way  easier than wire-wrap, because there's no tedious cutting, stripping, threading and winding of wire. One lays the wire down and pushes it on to the pins. Wiring several connections in succession, such as with a bus, is a breeze. The results also look great. The IDC pins are low profile, so there's less chance of shorting a connection than with wire-wrap.

It's sad 3M discontinued this product. It was great. 3M has since re-used the Scotchflex brand on three other products.

Fixing the Bug

The MC6809 V2 board worked great. There were no wiring errors. I did find a problem with the DAT.

In the default BBUG and OS-9 configuration, the DAT is written once during reset and never touched. And that seemed to work just fine.

Then I started playing with an OS-9 driver called VDisk. It created a virtual disk from selected extended memory blocks. At the time, I had 56 KB of memory from the MC6809 V2 card, plus another 60 KB from the Digital Research Computers / Tanner card. That made possible a 60 KB virtual disk.

Every time I tried to access the virtual disk, the computer would crash. This took a while to track down. 

I eventually realized the new decoder did not take into account the clock cycle when accessing the DAT. Transients on the R/W* line early in the clock cycle could cause bad data to be written to the DAT. After I added the missing gate, the VDisk driver worked perfectly. 

Usage

Like the MC6809E V1 board, this V2 board was exactly how I wanted it. There are only two jumpers. 

The jumper at the top edge of the board selects the 4 KB portion of the EPROM. This makes it easy to switch between OS-9 and BBUG. No more hassle of changing out chips - just move a jumper.

The jumper in the middle of the board, just above the decoder ROM enables the FE000-FEFFF block of on-board memory. This would be installed once the motherboard I/O addresses are moved out of the E-block of memory and would allow 60 KB of RAM to be used.

Future

Moving the I/O addresses out of the E-block gains 4 KB more usable memory for OS-9. Perhaps I'll try that in my retirement.

Another fun project would be to put a full OS-9 Level I system into ROM. Unfortunately, all of the essential modules take up just over 16 KB of memory, so the division doesn't fall on a natural 4 KB boundary. This might cause a conflict accessing extended memory with the DAT.  I'd also have to figure out how to program the decoder ROM. There are not many EPROM programmers that can program the Cypress Semiconductor CY7C291 devices, and I no longer have access to the ones I originally used. 

OS-9 Level II

This design works well for OS-9 Level I. To run OS-9 Level II, which allows each process to have a full 64 KB address space, requires more hardware. First, a second set of DAT memory chips allows the user and supervisors states to have separate memory maps. Second, a means of switching between those maps automatically -- like when servicing and returning from interrupts. Third, would require ROM to be accessible from an extended memory address, and then mapped into the supervisor space. 

Those requirements go beyond the scope of this design. Perhaps there's room for a V3 board. All of this assumes access to a copy of OS-9 Level II, which may be difficult to find.