R7000 History

After my move in November 1994, it took over a year before I put up any antennas -- I was much too busy with young kids, new job, finishing the basement, etc. In January 1996, I put up a 125 foot doublet up about 15 feet and operated the NAQP CW contest. That doublet got mounted higher by the NAQP phone, and was joined with some attic antennas.

By the fall of 1996, I was in the market for an antenna that could reasonably support several bands, including the WARC bands. The R7000 seemed like a pretty nice solution -- seven bands with an option to  add 80m as well. I bought one in November of 1996.

To mount it, I joined a 10 foot piece of 1 1/2 inch rigid EMT to a 12 inch steel pipe nipple and planted it 3 feet in the ground using two sacks of concrete. The pipe union was buried in the concrete. The resulting vertical pipe was about 1.9 inches in diameter -- almost large enough to fit the mounting U-bolts -- and nearly 8 feet tall.

While not as optimal as the specified 2 inch mast, this support worked very well for 15 years. I only stopped using the R7000 a couple of years ago when the coax to it was cut when the cable company re-buried the cable. (That one was cut by septic tank workers repairing the system)

The R7000 was not a great performer, in my opinion. I first called it the R7000 attenuator. I later discovered that it was designed to work at a height of 18 feet, not the 8 feet I had installed it. After a few years, I got the idea to add some radials at the base of the mast. Seven 20-foot radials made the antenna appear to work a lot more reasonably.

Since I wasn't using it at the old QTH, the R7000 seemed like the perfect antenna to move to the Micro-Shack. It required only one support, covered seven bands, and with a few radials seemed to work OK. A mediocre antenna seemed better than none at all.

The Micro-Shack

It eventually happens. You get a QTH built up with a reasonable set of antennas, then you have to move. My friend Mike used to think he lived under a curse -- two years after he put a tower up, he ended up moving. This happened to him three separate times. He solved that problem when he moved last -- he hasn't put up a tower since.

My wife was moved to a new church, and with that posting came a parsonage. The little problem with the parsonage was it was a bit smaller than the previous house. So, where could I set up some radios? No more basement shack, cause, there is no basement. And there's no spare or "bonus" room. What to do?

There was a little utility room next to the car port. This is an unheated / (cooled) storage room, that houses the water heater and the electrical box. It's about 5x7 feet, and not good for terribly much. Perfect. (Well, not perfect, but it could work....)

The storage room was pretty dismal. While it had a window, the walls were thin, unpainted plywood that had seen a fair amount of abuse in 40+ years. I removed a beat-up cabinet that apparently had been salvaged out of someone's kitchen a few decades ago. A couple of coats of white paint considerably brightened the place up.

On the wall opposite the water heater, I put some adjustable shelf brackets in place, and had enough brackets on hand for five shelves. Then there was the small matter of the operating desk. I mounted 2x4 blocks on opposite walls by screwing into the studs and placed a piece of 23/32" plywood on top of them. (Do you know that it is crazy you cannot buy 3/4" plywood any more?) A couple of 2x4 blocks along the wall hold up the back end of the desk, and two strips of 1x4 glued to the bottom give it enough reinforcement that it would probably hold up my weight. Should be good enough for any boat-anchor I choose to put on it.

The operating desk fitted the space available: 5 feet 3 3/4 inches by 29 inches deep and 30 inches above the floor. The shelves just above the desk would support some equipment to free up a little desk space. It would be small, but quite usable.

Now, it's just a small matter of getting power, ground and some antennas up.

Awarded: 6B WAS

I discussed my pursuit of WAS, and then 5B WAS before.

Well, after a couple of miscues, including a lost QSL card, cancelled and re-issued credit cards, and a few month-long delays -- I finally received my 5B WAS award with the 160m endorsement.

Thank you so much to the hard-working folks at ARRL HQ for finally straightening this out. It's nice to meet a goal after 35+ years of hamming. Something that only 3,004 hams before me have done.

WAS on 30m, 17m, and 12m will take some doing, but, with time, it may happen. Although, right now, I'm more interested in building my DXCC totals.

Retrospective - 1997 WWDC Fireside "chat"

With this week's untimely death of Steve Jobs, I was thinking of the few times my life had intersected with Steve -- this was the closest I had come.

John Gruber recently linked to a video of this very special WWDC session. The video quality is horrible, but the talk is interesting. I remember this session well.

I was there.

I was sitting somewhere on the left aisle of the audience, about 1/3 back from the front, which was my usual spot for most sessions. It was my first experience in the "reality distortion field" of Steve Jobs. I must say, there was definitely something to it.

The moment in time this talk took place is worth noting. Steve Jobs was just an "advisor" and his opinion "didn't count." A couple of weeks after this talk, Jobs would sell all but one share of his Apple stock, which would precipitate a stockholder crisis that eventually lead to the ouster of Gilbert Amelio about a month later.

Jobs would step into the resulting power vacuum and assume control. But that hadn't happened yet.

It's most interesting to look at how Jobs answered the questions from the floor. He took each one seriously, and did not try to answer right away. It was more important to give a good answer, than give a quick answer.

There was certainly controversy at this WWDC. Apple had killed off OpenDoc, which developers had been anticipating for three years. While answering questions about Newton, Jobs pointed out the difficulty companies have supporting even one application stack, much less two. Three was almost out of the question. (And Jobs would kill off Newton as soon as he gained control that summer)

Jobs discussed many of the benefits of Rhapsody, but that concept didn't last a year. By WWDC 98, Apple abandoned the Yellow Box on Windows. The development tools were good, but perhaps 5-10 times better is something of an exaggeration.

Jobs wanted Mac cloners build whatever hardware they wanted, but wanted a lot more money for the MacOS license. Even when he took control, that wouldn't happen.

And while there was no revolution with Gigibit ethernet replacing hard drives, the network certainly plays a larger and larger role today. Most interesting near the end of this talk that Jobs describes a hand-held device that has cellular networking and a hardware keyboard -- he perfectly predicts the entry of the Blackberry, which would be announced 18 months later, and would dominate its category for nearly a decade. His vision extended even to products Apple would not produce.

AA4LR #1 Southeast Division, Low Power, ARRL 160m

View of the shunt feed wires going up the tower.

I can't believe it. Before the 2010 ARRL 160m contest, I noticed that a score over 100,000 in the Southeast division might possibly win the Low Power category. As a result, I put in a pretty full effort with 100 watts and my modest antenna. I scored over 100,000, and I hoped it would last through the judging.

When the claimed scores came out on the 3830scores mailing list, it looked like I came in second place to WA1FCN in Alabama by only a couple of thousand points. We both had 689 QSOs, but he had one more multiplier -- 79 to my 78.

Well, the results database has been published. Looks like I came out on top. While WA1FCN had more multipliers, it looks like more of his QSOs were thrown out in the adjudication. I lost nine, but he lost 24, which put me ahead almost 2,000 points.

Not my first division leader low-power win -- the other came in 1989 in the ARRL Sweepstakes Phone. That was right after hurricane Hugo, and a lot of Caribbean stations were off the air.

I still can't believe it.

40 Years of Radio

September 3rd brought forth some fond memories for me. It stands out in my mind because of the evening of September 3rd, 1971. I received my first radio, a Heathkit GR-81, Christmas 1970. My first logbook entries are from January 9th, 1971, since it took us a while to build, especially considering that the band "A" coil we got with the kit was defective.

For many months, I used the GR-81 with nothing more than a bit of magnet wire wound around my attic bedroom. This worked, but it wasn't very effective. I listened to some local AM stations, and a few shortwave stations. The GR-81 wasn't very sensitive on band "D", where most of the shortwave broadcast bands are, so I concentrated on broadcast band DXing.

With the summer ending and school about to start, I managed to take a trip to the electronics store and buy some wire. I believe at that time, I bought a 25 foot spool of very small speaker cord and completely unzipped it. In my youthful frugalness, I had computed that this resulted in a cheaper acquisition of 50 feet of wire than buying a 50 foot spool outright.

That 50 feet of wire went out the window of my attic bedroom, across the roof of the garage, and was anchored to a climbable tree on the other side of the yard. In retrospect, it couldn't have been horribly effective -- it was too low to the ground, being only 10-15 feet high for most of it's length.

However, it was outdoors -- this being my first outdoor antenna. The results were pretty dramatic, compared with the indoor magnet wire. That evening, I started at the top end of the AM broadcast band (band "B" on the old GR-81), and worked my way toward the bottom. I must have logged about 40 different stations, many of them new.

This experience made an impression on me. For the next several years, I always attempted to do this AM "countdown" around labor day weekend. In addition to signaling the start of the school year, it was also the start of the radio season.

It's hard to believe it's been 40 years. I still have that radio, and it's still in good working condition. And somewhere in my files I have that first logbook.

Why Scrum Works

At work, we have been using Scrum methods for over two years. It has really been amazing how well this system works for us, at least for development. I only wish we could apply this technique more widely to our organization.

Perhaps some background would help. My employer, when I arrived here eight years ago, was one of the most disciplined software organizations I have ever seen. We produced a software release to the market every year, on time, with good quality. Every. Year. Features being cut before they were ever started, because there would be no time to finish them. It was truly amazing. 

However, this advanced waterfall process was slowly destroying our product. There were two key issues: 1) we'd never plan anything risky, so the releases were getting blander, 2) we had no flexibility should something arise, since everything was planned out. We needed to do something else.

One of the key revelations about software development is that it is, to some degree, unpredictable. Even in very disciplined organization, you reach a point where the most extensive planning process cannot pin down every possible variable. The unexpected lurks in every project -- particularly for those projects which involve something new and unique. Those very projects you need to do to stay competitive.

Classic management would dictate more precision in the planning process, more and more research up front to prevent these unexpected events. But at some point, the up-front costs outweigh the worth of the project. Shouldn't we expend our efforts on building software, rather than building perfect plans?

Scrum does not solve the unpredictability of software development. Scrum embraces that unpredictability. Scrum gives software development teams the tools to manage and control that unpredictability, so that it does not derail a project. Part of the secret is not trying to plan everything. Strictly speaking, only one sprint is planned at a time.

So, why does this work? Why does planning just 2-4 weeks at a time work better than trying to plan it all?

There are three principles that make Scrum effective:

1) Customer Focus - when writing a story, we write it from the perspective of the customer. Completing a story means delivering a concise bit of functionality to the customer. With a completed sprint, the software ought to be in a ready-to-ship state. It's actually very hard to write stories this way. In the end, this process tends to break down large features into tiny slivers of functionality. The beauty of this process is that each bit of functionality can be prioritized against the other. Instead of doing months of work to finish a feature, we're focused on the high-priority aspects every few weeks. This can result in leaving some low-priority aspects of the feature on the table, but on the whole it gets the important aspects built and finished first.

2) Narrow Scope - nothing kills a software project as bad as feature-creep. You start working, and the list of requirements gets longer as you go, until the project will never end. You can't do this with Scrum. Each sprint is fixed in time. Each team has only so many resources. The only variable is the scope. If you discover new requirements, it isn't automatically part of the work. Most likely, you write it up as a separate story to be prioritized against the other stories.

3) Vertical Delivery - the hardest aspect of Scrum is working in a vertical fashion. You can't divide stories by discipline (eg design story, coding story, QA story), you've got to do all the design, coding, testing in the same few weeks. This forces one to think very small for each story. Vertical Delivery also affects your software designs. Many software products have inter-dependent layers (eg database, business logic, user interface). You don't have the luxury of perfecting each layer before moving on to the next. Vertical Delivery means you have to do everything in each layer to deliver the bit of functionality to the customer. The big architecture in the sky is out. Instead, you must choose a more evolutionary approach, where you have just enough architecture to get the job done for the story.

While it may seem cumbersome at first, these principles are actually a very natural process. Imagine an independent software development organization of just one developer and his cat. How would he get things done? Given the very small development team, he's not going to go off for months (or years) doing major features. Instead, he'd focus on delivering something to the customer, keep the scope narrow so he doesn't get sidetracked, and deliver all the components vertically.

Once you've got those basic principles down, the real magic of Scrum happens between sprints. Each sprint, stories are getting done, and little bits of functionality are ready for the customer. The work that gets done has a major effect on the stories remaining. Maybe we've gotten enough of the value out of Feature A, and we can now focus on Feature B. Perhaps there's some new requirement that's come up, and we really need Feature C in order to compete, or comply with a new law, or support a new platform. Prioritization occurs constantly.

Scrum keeps development teams focused on the most important work, delivering working software for customers. It continues to do so even in the face of constantly changing requirements and conditions.

You couldn't plan for that.