Saturday, July 29, 2017

Hay Baron

Owning 50 acres of land has a few downsides. It has to be looked after. My antenna farm when fully built will consume far less than the available space, requiring no more than 5 to 8 acres. The forest, bush and swamp take care of themselves so it is only 20+ tillable acres that are of concern.

It is therefore an asset that my neighbour farms the land. At present it is all hay. Years ago when he had a dairy operation he had several acres of feed corn where the big tower is now planted . Hay is pretty compatible with antenna since there is no plowing, just cut and bale however many crops the weather allows per year. We are having a record setting wet year which makes it difficult to find 2 or 3 consecutive days to do the harvesting.

Harvesting has finally begun.


It's all very neatly done. He works around the big tower anchors and base, not disturbing anything. You can see that the base section is now standing. It is temporarily guyed until I reach the 40' mark and can install the first set of permanent guys. Since the temporary guys are so low to the ground some hay could not be cut.

Freeing me from having to cut the field on my own is not the only advantage. I make money from the crop. Although I certainly won't get rich off the hay the income will buy small items for the station. Hay prices are up this year since the wet weather has impacted the crop across eastern Ontario.

To keep the haying operation going I need to minimize impediments for the farm equipment operating in the fields. For example I need to decide whether to bury cables running from the tower to the field boundary or suspend it overhead. Haying is compatible with both, although burial will disturb the crop along a path at least 1 meter wide.

When I build an 80 meter vertical array it will take one acre completely out of production. Haying is not compatible with radials. I will not start construction until after the fall crop is harvested.

The low band receive antennas will occupy a bush area of several acres where my experimental northeast Beverage is currently located. No farm equipment ventures out there. That field is behind the trees running between where you see the tower and the centre of the photo. The view is toward the northeast.

Keeping the tillable acreage to the maximum possible benefits me and my neighbour. Being a hay baron has benefits and responsibilities.

Were I to turn the big tower into a vertical on 160 meters I would put the radials down in the fall and roll them up in the spring. If I decide to build a wire yagi for 40 or 80 meters I would need to either make it a winter only antenna or arrange the element anchors to make it easy for the harvester to navigate. To do work on the tower I will mow paths and work areas just as I did for the foundation work.

So far I am happy with the dual use of the land. My neighbour has been very careful while working around the tower installation and has even moved stray cables aside to avoid driving over them.

Mid-summer update

The pace of blog posts has slowed. This is due to a combination of hard work on the tower and other station tasks, plus my disinterest in spending time in front of a computer during the fine summer weather.

Nevertheless there are several articles in the pipeline, all of which will eventually get done. The tower itself is progressing well, though not as fast as I'd like. I could raise sections right now if I wished since all is in place to do it. But I need to slow down since I received guying components that were the wrong type. The correct ones will arrive later this week. I don't want to have 40 to 50 feet of tower supported by temporary guys attached to the base section for longer than a day or two.

I am also shopping for the large amount of aluminum and steel I need for antennas and their supports. For a resource rich country that manufactures everything a ham could ever need it unfortunately does not follow that the distribution and retail side of the industry keeps pace. Most goes to export since Canada is a small market for the goods that are produced. It's annoying to often have to resort to buying from the US. Yet I persist in trying to source domestically when I can.

Tuesday, July 18, 2017

Tower Prep -- Almost (but not quite) Vertical

The big tower is still not up even though there has been a lot of activity. Consider this list of tasks I have been up to recently and you'll see why:
  • Repairing tower sections
  • Cleaning, scraping and repainting tower sections
  • Making the first set of lower guys
  • Gin pole design, construction and testing
  • Acquisition or refurbishment of a multitude of hardware: splice bolts; thimbles; turnbuckles; shackles; tower guy yokes; etc.
  • Transportation of tower sections to the site
There are also the environmental challenges such as a continuing very wet year, delay in my neighbour harvesting the hay crop and ticks. Of course tower work has to fit around the other items that fill my days. It is all taking longer than I'd like. Big stations involve big work.

Consider this a progress report. You'll get an idea of what's involved in working with big towers if you've never done this before. Most hams never do, and for good reason! None of this is a surprise to me and went into my plans from the start.

Bending jig

Used tower will usually have flaws. Commercial tower when taken down is often not treated with tender loving care since its resale value is rarely more than as scrap metal. Ham towers may be mistreated or carelessly handled. Expect to do some repairs.

In my case several sections had bent metal at the splices and a number of dented diagonals and girts. All were reparable without too much trouble. A few questionable damage areas were discussed with an engineer who knows this tower very well.

For example, several of the sections had old welds at the splices where they were tack welded for continuity assurance in an AM broadcast antenna. I removed those with a hand grinder so that the sections would smoothly slide together.

Simple bends were repaired with a block of wood and a small sledgehammer or with a pair of large adjustable wrenches. For the few cases where these were not effective I constructed a bending jig to hold the tower section while I applied some extreme force with improvised tools and snipes.

The jig is quite simple as can be seen above. Two short 1' screw anchors hold the ends of a heavy chain that is adjusted to fit snugly over a tower section adjacent to where the damage is located. This allows a force far greater than the section weight (120 lb) to be applied to the area to be bent with a long pipe acting as a snipe. When some of the force is axial to the tower I pressed lengths of rebar into the ground to prevent the section from sliding.

The jig also serves to hold the section in place while another is slid into the splice area. I did this to confirm proper alignment of the sections and holes for the splice bolts. Doing this on the grass helped since I was working alone and the heavy sections could be dragged into position.

Cleaning and painting

When I had 7 good sections (base section included) to reach the second guy station at 70' I set up an assembly line to clean and paint them.

This is a tedious process although not difficult. I stood them on the ground where the sun would be blocked from mid-afternoon onward -- never paint in direct sunlight. With a hose I washed off the dirt and debris that collected from years of outdoor storage. Stubborn stains were scrubbed off.

I then removed loose paint and rust spots with a set of steel wire brushes. There was little rush despite the tower's age. The sections are hot-dip galvanized and then had the standard aircraft red and white paint baked on at the factory. But they're old and needed to be refreshed. Frankly I could have skipped all of this since the tower will certainly outlive me. I expect the tower will be demolished if it's still standing when I move on.

Unfortunately galvanizing requires a special primer before the metal rust protective paint can be applied. I used the primer to cover the bare spots and then painted over the damaged and primed areas with the finish coat. To avoid an overly odd appearance I painted the exterior of all sections. Now all the sections are white except for two sections that were never painted (bare galvanized steel). I was free to use any colour since at 150' the tower is too short to require aircraft hazard colour banding.

Transportation

From the house yard the travel distance to the tower site is ~150 meters (500'). I cannot carry these sections on my own at all and it is very arduous for two strong men. Since I had no intention of conning a friend (or friends) into doing this I had to devise something to allow me to transport the tower sections on my own without undue effort.

Indeed I prepared for this two years ago. After I transported the sections to my home in Ottawa and paid several teenagers to load and unload them and stack them in the back of my yard I knew that I'd need a wheeled device if I was to be able to move them on my own. So I designed and built a very simple device with a couple of scrap lawnmower wheels, a short length of 2x4 lumber a threaded rod and a few fasteners. Simple it is but it works and has been heavily employed recently.


The device can be seen in this photo taken after the 7 repaired and painted sections were moved to the tower site. It is still attached to the second section from the left. Two bolts secure the lumber platform to the splice bolt holes in the section. The 120 lb sections are moved rickshaw style but with the driver facing backward to avoid being poked by the unforgiving tower legs. Attaching and detaching the device takes no more than a minute and usually can be bolted and unbolted with fingers alone.

Although the wheels are small it has had no trouble dealing with the countless rocks, holes and vegetation along the route and more than a few tight turns. The design isn't perfect and I've had to occasionally adjust the wheel nuts and threaded rods when one of the wheels locked up. If I'd built two of them transport would have been easier though at the expense of doubling attachment and detachment time and more cumbersome towing and steering. Feet are nimbler than wheels.

Where it fell short was with the base section. The device can only attach to the top of the section so the other end, the heavy end, had to be carried. That was fine while working with it in the yard but not for the long route out to the site. Although it looks smaller the base section is heavier than the others. So I improvised.


I admit it looks ridiculous yet it worked. The heavy base plate fit nicely inside the front end of the wheelbarrow frame without interfering with the wheel. Since the plate is rectangular and not suitably oriented with any of the section legs it has a habit of trying to twist the section and whatever (or whoever) is holding it. This includes the wheelbarrow, as you can see.

A little bit of muscle is needed to keep the wheelbarrow level during the tow out to the site. What I couldn't do was make turns of small radius. In several places I had to turn the section by hand and then remount it on the wheelbarrow. Despite these inconveniences the trip was done in less than 10 minutes. You can see that I used the system to carry scrap lumber and other material out to the tower site.

But wait, there's more!

The 7 completed sections are less than half the total of 15 sections I am raising. There are 8 more of them to be cleaned and painted.

When I took the adjacent picture the metal was repaired and I had done a first pass with a wire brush. There is more scraping and painting ahead of me even while I go about the task of getting the first set of sections up in the air.

Coming up

All going well tower raising will begin shortly. I will follow up with articles on my gin pole design, guy design, temporary support for the lower sections (until the first guy station is reached) and other topics that may be of interest.

In the meantime I have other station work to perform on the Trylon tower. My T2X rotator is acting up again, coax will be upgraded and I need to adjust the yagi positions to better accommodate rotation loops. I have even been doing a little bit of operating and contesting though nothing serious during the warm summer months.

I'll leave you for now with the following pretty picture. This is looking east from the house toward the field where the tower is going up in the aftermath of a storm that moved through as I was wrapping up this article. Imagine if you will a 150' tower rising from behind the trees in the centre of the picture and piercing the rainbow. It will easily rise that high.


Thursday, July 6, 2017

Computer Contest Logging in 1977

As this year's IARU Radiosport contest approaches my thoughts turn back to the very first one. It was in 1977, 40 years ago. As I recall how it came to be the ARRL had such great success with the one time running of the Bicentennial contest in July 1976 that they saw an appetite for a summertime international contest. They must have been right since it's still going strong.

Back in 1977 I was in university working on my B.Sc. in Computer Science and on the cusp of exiting my teen years. I was an enthusiastic contester with a small home station and I was a member of club station VE4UM at the University of Manitoba. Since 1977 was the university's centennial we got a most unusual special call sign: VC9UM. At the time there was no 9th call district in Canada; it is now assigned to New Brunswick.

Dupe sheet from my 1970s files: contest unknown; the other side has US 6 to 0 and VE; one sheet per band
Every contester who predates K1EA's CT has painful memories of paper logging and dupe sheets. It was easily the worst aspect of contesting. There were a talented few who could simultaneously operate a keyer and write the log and use a dupe sheet. The rest of us cursed as the rate picked up and we scrambled to manually check the dupe sheet, fill it in (or chase away the caller) and log the QSO. Big gun multi-ops often had one person on the radio while another managed the log and dupe sheets. Unlike today dupes typically involved a penalty, and you didn't want that.

Imsai 8080: Not good enough, unfortunately (photo credit)
Personal computers at the time were wholly unsuited to the task of contest logging and dupe checking. Hams were experimenting with the simple home computers then available, such as the IMSAI 8080, using teletype machines as terminals and paper tape for storage. Soon enough the PC (including an updated IMSAI) would have the capability but in 1977 it was still a few short years in the future. The major impediments included:
  • No operating system: All I/O and other core tasks had to be manually coded.
  • No high level programming languages: It was all machine code or symbolic (assembly) machine language, or cross-compilers that ran on mainframes and minicomputers and downloaded to microcomputers.
  • No direct access to mass storage: Even floppy disks were not yet available, let alone anything larger. Programs were typically stored on and loaded from paper tape, either on the teletype terminal or the recently available electronic paper tape readers.
  • Insufficient RAM: Directly accessible semiconductor was typically no more than 4 KB. Try to fit a contest log and the logging software into that!
  • It cost money and we didn't have any. We were poor students barely scraping by.
Nevertheless computer logging was being done by a few. The early baby boomer contesters were by that time in their late 20s and working in industry. Many were engineers or an early generation of computer programmers and worked in large companies or other organizations with mainframes and minicomputers. An enterprising few were able to negotiate personal use of those machines over contest weekends.

This was no small accomplishment since those computers filled machine rooms and were expensive to power and required salaried operators to keep them running smoothly. It was typical for these computers to only be run during regular business hours except when dedicated to supporting clients with longer hours.

An idea is born

A friend and I talked it over. He -- Derrick VE4VV (SK) -- was also a fervent contester and a fellow student one year behind. We were too young and lacked influence to convince anyone with any power to grant us use of the university IBM S/370 mainframe or one of the several departmental PDP-11 minicomputers scattered across campus. I did try. The furthest I got was polite interest. The needs of graduate students and faculty would not be adjusted to suit my requirements.

From my personal library -- I enjoy hanging on to a few mementos
Since it was summer break I was working for a government agency as a systems and application programmer. I regularly used the a government owned S/370 and we had our own PDP-11/45 minicomputer. My attention focussed on that minicomputer. Like any machine that size it was turned off at the end of every workday. Could I get it left on for the weekend? That was my challenge. Software development was the least of my worries.

I shared my desire with my supervisor. Although he had no power to grant my request he became a strong ally. He was not a ham but had an interest in it. He also liked the idea of getting management to do something unconventional, to kick them out of their comfort zone so to speak. He talked it over with his boss. It took some persuasion to at least turn him neutral on the project. But it was his boss who would have to make the decision and he was a stereotypical senior government bureaucrat. He was not a mean person but one with a very narrow and well-defined comfort zone.

Of course he refused. Not only would it involve an expense for no sensible reason he could fathom it was a valuable government resource he was in effect turning over to a couple of teenagers. He saw it as risking unwelcome public exposure for him and his political masters should something go wrong. It was pointed out to him that I was in position every hour of every day to do anything at all with that computer, including access to confidential data and an ability to severely disrupt operations.

It took a few days when to my surprise and delight I received grudging approval. I never found out what was said to finally clinch the deal and at the time I didn't much care. What I did care about was that in fact we had no plan, no software and no idea how it was all supposed to happen in the few days we had until the contest started.

Putting a plan together

We had access to a minicomputer, but that was it. Every other problem was entirely up to us to deal with by dint of hard work. We needed remote access to the PDP-11/45 since downtown Winnipeg and the university are 10 km apart. The only possibility was 300 bps dial-up telephone modems of which we had two on the minicomputer for staff use.

Acoustic modems I've used (Columbia University)
If you've never heard of these contraptions they involved dialing the computer modem on a telephone then inserting the handset into the "ears" of the modem when you heard the carrier tone. If all went well the modem would detect the carrier and establish the data link. They were terribly unreliable and often dropped calls or failed to connect on the first attempt. At least we were only calling across town. Long distance calls and especially overseas calls often experienced phase shifting (it was almost all analogue transmission at the time) which was not tolerated well by the modems.

The terminal itself was a challenge. After exploring a couple of alternatives we borrowed a VT52 from my office and transported it to the club station. This wasn't easy since these "dumb" terminals were large, heavy and fragile. I didn't want to think what would happen to me if I dropped it or bumped into a wall as my friend raced ahead opening doors for me and guiding me around obstacles on the downtown streets towards his car.

VT52 from Wikipedia
It was remarkable that we got the terminal and communications link working at all. For the duration of the contest Derrick only experienced two line drops.

Software constraints and features

As already mentioned, when I got approval I had not yet written a single line of code. There was only a little over a week to develop a contest logging application from scratch. I didn't even have a clear idea of how to do it, what the user interface would look like and how I would deal with bugs and other disasters. All of this needed to be fleshed out, and quickly.

People are often surprised that many poets do not feel constrained by the need to fit their thoughts and emotions into a strict meter and rhyme template. Although a challenge it limits the range of possibilities to a solution space that is more tractable. My dilemma was much the same. I was limited by an interface that could paint no more than 30 characters per second on the screen, a couple of bulky hard disk drives and 32 KB of address space (the computer had 80 KB of magnetic core RAM, but each process was more limited by the system architecture). It simplified the problem by limiting me to what would fit these constraints.

The first thing to recall is that there was no such thing as computer control of rigs. Back then all transceivers were dumb. Neither were there integrated keyers. Well, that's not entirely true but very uncommon for contest software at the time since PCs were still terribly inadequate. There was no way a simple 300 bps ASCII connection to a dumb terminal in the shack was going to do anything like that. So the rig, keyer and microphone were manually operated.

All we were going to do was log and dupe. That's it. But that's a lot. If you're too young to remember those days it may not register just how difficult that was to do manually while operating, especially for a single op.

The software we decided would do the following, and nothing more:
  • Manually set the band and mode; Radiosport is a multi-mode contest.
  • Check for a dupe when a call is entered, and report log details for the earlier contact.
  • Enter an exchange and log the contact. The computer fills the time.
  • Check the band and mode, just in case.
  • Simple real time reports of contacts and zones logged.
  • Ability to back fill QSOs in case of temporary computer or communications outage.
  • Print log and dupe sheets and calculate score.
That's it. But as already said that's a lot.

The programming language was FORTRAN. Only that and assembly code were available. The DEC compiler for the RSX-11D operating system on the PDP-11/45 had libraries to support use of the data management services on the various storage devices. For our purpose these were two disk drives of 20 MB storage that were the size and weight of large washing machines. I forget the model number but they were roughly equivalent to the IBM 3330. Access time was not fast; that was a critical consideration if we were to achieve acceptable performance.

The VT52 has a graphics mode whereby the 24x80 character matrix could be directly manipulated. I eschewed that option since it added complexity and didn't seem to add much value for our limited feature set. I stuck with a scrolling text screen to keep it simple. It worked surprisingly well for the operator.

Development phase 1

With the clock running down I soon realized not all the planned features could be developed in time. Yet I was able to get the core functionality working within a few days, designing and coding in my spare time and, to be honest, during work hours. My supervisor knew what I was up to but chose to say nothing since my work assignments were progressing on schedule. More days were consumed in tweaking the software and data management to boost performance.

My design choices were greatly limited by the technology available to me. That a program could only be 32 KB, including code and dynamic data storage forced my hand. Think about the length of a call sign. Let's assume 16 bytes per log entry for a call sign, exchange data and time stamp. A log with 1,000 QSOs requires 16 KB, or half the address space. I had to support more than twice that number of QSOs and still have room for the program and the library routines that the compiler would include.

I investigate a variety of data compression algorithms. Unfortunately all involved substantial complexity. Then I discovered the program was consuming more space than I'd hoped for. I thus opted to put the log on the hard disk and optimize access with extensive hash tables and other techniques.

Happily it worked quite well during testing. Derrick came in one evening and I had him log random QSOs for a couple of hours to test the data base process. Afterward I analyzed the tables and adjusted the hash algorithm. Performance depended heavily on the QSOs being reasonably evenly distributed by a randomized hash key derived from the call sign.

For disasters in which the log data base was lost due to system or program failure I stored a plain text journal file on the second disk drive, writing to it after a QSO was logged. Although we never needed it there was comfort in knowing it was available. The journal file could only be used for post-contest log recovery since I had not yet developed code to recreate the log from the journal file.

User interface

The user interface was extremely simple, and surprisingly effective despite the simplicity. After connecting to the minicomputer the user signs in and executes the logging program. There was no setup to be done since only the one contest was supported. In case of a crash you run it again and carry on logging.

Whether running or S & P the UI was the same: enter a call sign and hit return. If it isn't a dupe nothing happens except for another prompt. You then enter the exchange, signal report optional. A dupe was flagged with log details and the sound of the terminal buzzer. It might look something like this (I forget the details so this is not precisely as it was). Plain text (not bold) is user input:
>=b20
>=c
>k3lr
>k3fr

>8
0334
>g3aa
>57927
0336
>f6abc
DUPE: *** F6ABC *** 1/2315 20 CW
>=s
>ve1xx
>9
0341
The first two commands (user input with the "=" prefix) set the band to 20 meters and mode to CW. Then a call sign is entered. The operator either made a mistake or didn't work the station and enters a new call sign. This action automatically erases the earlier entry.

The subsequent entry of an exchange (zone number) causes the call to be logged. Since no report was entered it defaults to 599 in the log. The time of the QSO is the only feedback given. Recall that we're working at 300 bps and brevity is important.

For the next call entered -- G3AA -- a signal report other than 599 is received. It is entered before the zone, just as it is sent by the the other station. The software parses the line to extract both items. The software assumes that 59 (or 599) is always sent so there is no way to log a different sent report.

The next call entered is a dupe. The log details are presented. The "1/" in front of the time indicates the day of the contest -- could be 1 or 2 since the first Radiosport was a 48 hour contest. The other data is parroted since the operator could have quite easily forgotten to change band or mode or typed the call incorrectly. Either way the operator proceeds to the next QSO. If it was a typo the correct call is entered followed by an exchange in the usual sequence.

Next, the operator changed mode to SSB and successfully logs an SSB contact.

The software did not fully validate call signs since the variety was too great and I didn't want to cause problems for the operator should the program improperly flag a valid call sign. Only simple errors such as a call beginning with a "0", no numeral present, trailing numeral and a few others were flagged. It was up to the operator to retype the call or ignore the warning and proceed to enter an exchange and log it. Although simple it worked well enough that we only found one badly formed call signed in the log after the contest.

There were a few other commands available. There was "=q" to report the number of QSOs in the log and "=z" to report the list of zones worked on the current band. Before entering an exchange a QSO time could be entered with something like "/20404" to override the computer clock and log the time as 0404Z on day 2 of the contest. This was needed in case of system outage so that manually written log entries could be put into the computer log during a break or after the contest.

I had a couple of debugging commands in there as well. These were of no use to the operator so I didn't even both to tell Derrick about them. If needed I could have walked him through their use over the phone.

The contest weekend

Late Friday afternoon Derrick drove over to my office to pick up me and the VT52. We had already acquired a modem from a helpful professor at the university -- it was summer and there was unused equipment available. I was given a key to the building front door and computer room by my boss. As the office closed for the weekend the operator shut down the computer per his procedures.

I restarted the minicomputer and ensured that it and the telephone ports were operational. I created a user account for Derrick to use. Then I shut the lights, locked the door and crossed my fingers. Off we went to the university to get him set up for the contest. I took a bus across town to my own home and station. Derrick was doing a single op, as was I from my own station. But I was on call in case disaster struck and I had to get downtown in a hurry to fix things. My attention was split between the contest and worrying that the phone would ring.

The phone never rang. That is, not until a few minutes after the contest ended. Derrick gave a enthusiastic report of the logging software. He couldn't stop laughing because it was the easiest and most relaxing contest he'd ever done. Apart from typing all he had to do was talk into the mic or press buttons on the memory keyer. Duping was a suddenly a relic of the past.

Since we were both tired from the contest we wrapped up and met the next day. In 1977 computer contest logging was a rarity. No one I personally knew had done it so I had no direct knowledge of how big a difference it would make. The difference was big, very big. We both realized right then that contesting would never be the same after the introduction of computers in the shack.

We got down to a serious post mortem discussion. Since he'd already practiced with it there was no learning curve to deal with during the contest. The limited feature set was itself a feature. He made a crib sheet with the commands written on it and found he didn't need it. We began talking of new features we could add.

A few problems did occur during the weekend though nothing too inconvenient. One was the expected line drops. Bell 103 modems with those bunny ears were not exceptionally reliable. We were lucky the problem only occurred twice. Each time he was able to redial and get back to business in a couple of minutes. He never had to resort to paper logging.

A bigger problem was that dupe checking became noticably slower with more than 1,000 QSOs in the log. Although the delay never got to be much more than 1 second in the heat of the contest it can seem an eternity. A few minutes of forensic analysis after the contest uncovered the problem. It had an easy solution. I counted myself lucky that nothing worse happened. The problem wouldn't have appeared if used at my small low power station since I made only 625 contacts in that first Radiosport (I actually found a copy of my old log).

The most delightful experience Derrick reported was the amazement from other hams, particularly when operating SSB, when he could not only tell stations they were dupes but the exact time of the QSO. Time and again they'd be suspicious and then astounded that the QSO was in their logs right where he said it was. Some even called back minutes later just to tell him he was right.

What they imagined was going on they likely never figured out and Derrick never told anyone on the air. Recall that this was 1977 and even technically savvy hams typically had zero experience and knowledge of computers. This was great fun!

Development phase 2

At the end of the contest we had a log and nothing more. I made backup tapes of the data base and software to protect our investment. Our next task was to print and score the log so that the VC9UM entry could be submitted. Those were features that I had deferred since they were not needed during the contest.

The log sheets were easy enough to format to look similar to the official ARRL/IARU log sheets. The one significant task was to parse the call signs in the log to determine the country and combine that with the zone (continent?) to calculate points for each QSO. At least that's the way I remember it. My memory of the scoring in that first Radiosport contest is hazy.

Dupe sheets were a problem. Of course there were no dupes since the software had already taken care of that. I went ahead and developed the features to score and print the log while Derrick made a few calls to the folks in Newington CT. There was an unanticipated difficulty.

Bureaucracy and the computer

The ARRL contest desk of 1977 refused to accept computer generated logs. They also demanded handwritten dupe sheets. This is despite the fact that the printed log sheets were nearly identical to the official sheets and there were no dupes. Both demands were nonsensical. Nevertheless they were unmoved by his protestations.

When it was pointed out to them that neither added any value, they would only point to the rules that declared entries must use the official log sheets (or copies of same) and that logs of over 200(?) QSOs must include dupe sheets. Flexibility was not in their vocabulary. That rigid compliance with the rules involved a substantial amount of work to manually transcribe the log and generate dupe sheets moved them not at all.

Derrick gave up the fight and spent a summer weekend doing what they demanded. It would be many years yet until the ARRL looked upon computer logs as helpful and even desirable. We were ahead of our time.

Aftermath

With a great success in our pockets we wanted to do it again. CQ WW was coming up in the fall and we set that as our goal. We had many ideas for improvements and new features that I was eager to build. This time it would be a multi-op effort so that I would not be left out of the fun.

It was not to be. Once I was back in school and no longer employed by the government the same senior bureaucrat was adamant that access to the PDP-11/45 was absolutely and categorically out of the question. My friends on the inside tried their best to no avail.

I made another play for the university department's PDP-11. It was even more impossible than before because the fall semester was in full swing. While there was still interest in what I was doing, and nothing sells better than proven success, they told me that, unfortunately, academic priorities would not and could not be set aside for even that one weekend.

That was the end of my foray into computer contest logging. I never did it again although I thought of it often.

Not long after that initial experiment I was working towards a post-graduate degree, and after that I moved across the country to start my professional career. PCs were by then very capable of contest logging and that's what many were doing. In my files I located notes from early 1980s of a far more sophisticated computer logging system. Those plans predated CT by a year. But I had no time for it and not even a station of my own to use it with.

When CT came out I was intrigued and thought of what might have been had I stayed with it. But by then my contesting activities were entering a lull as I put what little radio time I had into DXing and fooling around with antennas and modelling software. I did use CT a couple of times but that was for me and contest software for many years to come.

I missed a few generations of contest software and the computerization of radio equipment while I was absent from hobby between 1992 and 2013. When I made a serious return to contesting in 2014 I adopted N1MM Logger as my contest software from among the many excellent alternatives available. Three years on it remains my software of choice.

There is no reason at all for me to think about developing my own contesting software. I am more than happy to use the superb software that others have developed. I am content to be a user and put my energies into station building and operating.

Tuesday, July 4, 2017

The Price of Safety

I've been thinking lately about personal safety when it comes to hams and towers. It's come up on this blog from time to time. Too many hams are injured or killed pursuing the hobby we love. Many more come close to harm without really appreciating the precipice they were teetering on. They were just lucky someone else saw the danger and either warned them or did something about it.

When I say I've been thinking about safety I mean thinking about it more than I usually think about it. One reason is that I am about to put up a very tall tower. I've worked on big towers though never one of my own. This means I'll be at a great height more often than ever before. The other is that I recently did several tower jobs for others, involving both hams and non-hams who are not experienced with towers or tower safety.

How much is safety worth? Is it worth a friendship? This is not idle speculation. When you're up the tower and you see a friend step into the jaws of danger you have a choice to make: say something or don't say something. If the situation is urgent you may end up shouting words that are far from polite. Words that we never want to pass between friends.

When I was young I paid little attention to danger. Teenagers are immortal of course. Many times I climbed towers without any safety equipment to perform a routine maintenance task. Teenagers live in the moment where a one or two day delay to borrow even as little as a leather lineman's belt from a friend is too much. As I grew older I became more sensible as I hope most of us do.

When you've been on towers as much as I have over the decades you get to see far too many things that speak of mortal danger. I've been lucky not to have ever been seriously injured or had it happen to others I've worked with. Mostly that's due to good planning and a sensible crew. Other times it's just good luck. Face it, hams take stupid risks far too often.

When I was younger and most of the other hams were older I was reluctant to speak out when stupidity sprouted up around me. I am now far less likely to hold back. It is not a spontaneous eruption but rather a calculated urgent and forceful tone, a technique I learned from many years in corporate management. I want to incite an immediate response to mitigate a present danger.

What are these dangers? There are too many to list! Let me give a few examples:
  • Children allowed to play in the work area, including the tower base directly below me.
  • Refusal to wear a hard hat, or taking it off to be more comfortable.
  • Undoing a safety harness because it's "in the way".
  • Insisting on standing in exactly the wrong place when pulling on a rope and thus putting everyone at serious risk due to imminent mechanical breakage.
  • Acting with zero regard for the safety of the rest of the crew and risk to property.
  • Putting their hands or other body part where a sudden change in rope tension could result in severe injury.
  • Unsafe use of power equipment.
  • Chatting when they should be paying close attention.
  • Disappearing for a personal break without telling anyone.
  • Making mistakes out of no fault of their own other than a lack of experience. This is a management fault, often with me being the guilty party.
  • Not asking for a break when they need one or they aren't strong enough to accomplish a task. We all have our limits.
  • When a mistake is made the person loudly casts blame elsewhere. Ill will is bad enough but more worrisome is that failure to own up is a signal that more and worse mistakes will follow.
It's the innocent errors that most concern me. The others can be managed by not inviting or uninviting those who are unwilling or incapable of learning and correcting behaviour. Sometimes it can be accomplished diplomatically by finding a suitable task that puts them out of danger to themselves and others. The person may take offense so be prepared.

It can't always be done diplomatically and the need to act may be urgent. That's when I raise my voice. That's the moment when a friendship can be put in jeopardy. Afterwards or sooner if possible I make a point of apologizing to those I shouted at. I go on to explain that I was compelled to do so because I was concerned for their immediate safety or that of others. Usually they understand and all ends well. But not always.

July is the midpoint of antenna season in these northern latitudes and therefore marks a good time to revisit safety. Pardon the preaching but this is a message that cannot be repeated often enough. Sacrifice a friendship if you must. It is better to have a living ex-friend than a dead friend.

I am not immune. There are times when I am the target of a warning or unexpectedly stern advice. I've learned not to take it personally. I listen and usually discover that the warning or advice is warranted. To err is human and I am human. Welcome the intervention of your friends. They care about you.  I swallow my pride and gracefully adapt to the situation. And I learn.

When it's done right everyone gets to go home with a smile on their face, happy with a tower job done well, and still be friends.