REF - 3/4" Al - 9' 9" - 117"The components I purchased - DE - 3/4" Al - 9' 2" - 110" (Gamma match)
- D1 - 3/4" Al - 8' 9" - 105"
- D2 - 3/4" Al - 8' 8" - 104"
- D3 - 3/4" Al - 8' 7" - 103"
- Misc - 1/2" Al - 50" - Swaged to 5/8" last 6" (2) - Hy-Gain bracket adds 1 1/2" - 101 1/2" total
- Boom - 1 1/4" Al totalling 24 feet in three sections with 1" thicker wall inner tubing
Saturday, August 23, 2025
Hamfest Special - Mystery 6m Beam
Sunday, February 23, 2025
The Challenge of a New QTH
A decade ago, my wife and I spent four years in Floyd County in one of her church postings. We loved the area, and imagined we'd retire there.
In November we took the first step. Bought a house in Floyd County near Rome, GA. House is on the top of a small mountain - Ward Mountain, rising 300 feet above the valley floor below. From the front porch, there is a gorgeous view to the West. On a clear day we can see 35 miles to Lavender Mountain, which is practically in Alabama,
The house is a little smaller than we'd like at 2100 square feet, but there's over 11 acres of land. A small office outbuilding with one room and a tiny bathroom has become the ham shack.
We've owned the house in Gwinnett county for 30 years. Now we are transferring things to the new house. There's a lot to do. We'll sell the Gwinnett house in the next months. In the meantime, I'm focused on building up the Floyd QTH when I have the energy.
Antennas are the first order of business. I first put up an 80/40/20m Trap Dipole. It's up about 12m in the trees. I erected a 160m Inverted-L with two elevated radials. It's a bit noisy, so receiving antennas are likely needed to make the most of that. I plan for three beverage antennas. A 6m dipole barely 4m up in the trees offers me an option on that band.
I've also put together the HF4B. I've mounted it on a 19 foot pole lashed to a deck post. It needs adjustment to work well. It's OK on 10m, but 15 and 20m aren't quite right.
I'm planning to put up a tower. I'll need to take down the tower in Gwinnett first. My plan is 70 feet of Rohn 25, with the A3S/A743 on top. 35 feet below that will be an A3S, pointed at Europe. This would give me a stack toward Europe, plus coverage in other directions with the top antenna. Horizon is unobstructed in every direction except to the NorthEast, where the two additional summits of the Ward Mountain chain are. Those peaks are just 100 feet and 140 feet higher, but they are 1 km and 2 km away, respectively.
I'm already seeing good results with the 80/40/20m trap dipole. There are benefits to being on the top of a mountain. Even a simple tower should be awesome.
For 6m, I'm on the lookout for a 5-6 element beam. The Cushcraft A50-3S i've been using in Gwinnett just doesn't have enough gain to work the intercontinental paths.
On the office building, I've already moved in an operating desk with desktop shelves, and another luncheon table that serves as a workbench. The main part of the floor is a little more than nine feet square, And almost six feet of the rest of the building is split between the tiny bathroom and the rest of the floor. The desk and workbench are a bit of a squeeze.
A wire shelving rack takes up some of the space opposite the tiny bathroom, and gives me room to store things. I don't know how I'm going to get a whole basement of ham gear into this little building.
Such is the challenge of a new QTH.
Tuesday, October 15, 2024
Forty Years of Personal Computing - 16/32-bit Dreams
Back in the days when we were fooling with 8-bit computers, we dreamed about 16 or 32-bit processors. Digging through my notes and records, I found a couple of items. These projects were contemplated, but never built.
MC68008
When Motorola introduced the MC68008 in 1982, I toyed with the idea of putting one on the SS-50 bus. In my notes, I mapped out the signals required. It might have worked, but it was an awkward fit. The MC6800/MC8609 had synchronous memory access, but the MC68008 was asynchronous. Plus, the MC68000 family really wanted a 16-bit bus.
While I never built anything -- it was more of a thought experiment -- it might have been one of the first applications of a 32-bit processor running on a bus designed solely for an 8-bit processor.
A couple of years later, I spent a lot of time programming the 68000 processor when I started doing Mac development in August of 1984.
NS16032 / NS32016
![]() |
NS32016 chip set samples, plus a couple of Dynamic RAM and Refresh Controllers |
In 1982, National Semiconductor introduced the NS16032 -- later re-branded as the NS32016. NS32xxx refers to the 32-bit nature of the processor, and the trailing 16 refers to the bus width. It was clearly a competitor to the Motorola 68000, which was introduced in 1979. The NS32016 family was actually a collection of five devices:
- NS32016 CPU - Central Processing Unit
- NS32081 FPU - Floating Point Unit
- NS32082 MMU - Memory Management Unit
- NS32202 ICU - Interrupt Control Unit
- NS32201 TCU - Timing Control Unit
Together, they form the processing core. Depending on the type of system, you might not need much more than the CPU and TCU, provided you didn't need floating point, memory management, or prioritized interrupts. This made for an extensible system based on a common processor core
National Semiconductor also offered a Direct Memory Access Controller -- the NS32203.
Clock speeds of 6, 8 and 10 MHz don't seem fast by today's standards, but where competitive back in 1982. This chip needed a minimum of four clock cycles to access memory -- the same as the Motorola 68000.
Architecture
Design Ideas
- DP8419 - Dynamic RAM Controller
- DP84300 - Programmable Refresh timer
- DP84412 - Dynamic RAM Interface
These chips made it very easy to construct a memory array with dynamic memory chips. The designs involved 64K bit dynamic memory totaling 256 to 512 KB. It all depended what I could fit on an S-100 board.
The presence of a memory management controller made virtual memory a possibility. The rest was a small matter of software. In my initial designs, I planned to use the Pertec 8" floppies for virtual memory. Perhaps slow, but possible. In mid-1985, I mapped out the Pertec FD400 internal interface boards as part of this effort.
Other than a bunch of schematics and a painted chassis, I never built anything. A good thought experiment, perhaps. Even with working hardware, the operating system software would have taken years to get going.
And the NS32xxx series wasn't without problems. Part of the reason this chip set never caught up is it was full of defects. National went through several iterations over years to resolve the defects, missing their window to catch the MC68000 family or the Intel 8086 family.
Monday, September 30, 2024
Cycle 25 is Kicking Butt
Don't know why I didn't write about this when it happened.
August 9th, the daily Sunspot Number (SSN) was 382. That seemed enormously high. I couldn't remember a single time when the SSN was that high. So, I did some digging.
I downloaded all the SSN data, converted into an Excel spreadsheet and did some analysis. The SSN hasn't been that high since 1991. That's 33 years ago!
The SSN has only been this high a total of ten times in my lifetime (since February 1961) -- Five in 1979, Twice in 1989, and Three times in 1991.
Of course, none of this compares with Cycle 19, where daily SSN values were well over 500 for many days. But those values all happened 1956-1959, well before I was born.
Cycle 25 is shaping up to be much better than Cycle 24, which was really lousy, and possibly better than Cycle 23. The smoothed SSN has already exceeded the maximum value for Cycle 24, and it is far from over.
We've already seen a huge change in the bands in the last couple of years. 20m is open 24 hours, and 15m much of that time. 12 and 10m is open every day. I'm hoping we might see some 6m F2 openings. Enjoy it while you can. We should have two more years of these conditions before the cycle starts back down.
Wednesday, September 11, 2024
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
- 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
S & P
{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
{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
{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
{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
- 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.
Practical Messages
{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
Friday, June 28, 2024
The Great LoTW Outage - Continues.
Update July 1, 2024. LoTW is back up! It is running slow, but it is available. Thank goodness.
--
When I wrote the article back in May, I hardly thought that LoTW would be down a month later.
Sadly, the outage continues.
My suspicions were correct, however, that this was something more than a simple networking problem. The ARRL has since admitted their network was viciously and uniquely hacked. I can certainly understand their caution to make sure that every system linked to LoTW is given a clean bill of health before turning the system back on.
Earlier this week, on Tuesday there was apparently a brief period of time when LoTW was accessible. A couple of my ham buddies managed to upload some contacts. They'll have to wait for confirmations when the rest of us can get in.
I do hope it is soon. I'm really missing this service.