2024-12-15
TL;DR: I built an off-center-fed dipole (OCFD) primarily for the 80, 40, and 20 m amateur radio bands. I also bought a uBITX V6 kit transceiver and set it up for digital operation. I’ve used this setup to make digital contacts across the contiguous US, eastern Canada, and western Europe, as well as voice contacts to elsewhere on the east coast. I expect this antenna system to provide me with plenty of fun on the HF bands for many years.
I upgraded my license from Technician to Amateur Extra in the fall, which increases my frequency privileges significantly and gives me access to the lower HF bands.1 These bands behave differently from VHF and UHF and propagate much further. It’s exciting for me to finally be able to operate on these bands with my own equipment, but I needed a new antenna system and transceiver to make it happen.
I knew I’d want something that I could hack on rather than a turn-key solution. As with all my projects, I want to use my desire to make the system work as motivation for overcoming the frustration of learning and failure. I also knew that in this case I wanted an antenna system that would perform decently well on at least the 80, 40, and 20 m amateur bands, which are the most popular. Any bands beyond that would be a bonus for me. I certainly didn’t want an antenna that was only good for one band, even if it could provide superior performance. These requirements led me to the OCFD. This design is well-known in the amateur community and meets my criteria easily.
Simulation is always my first step on a project whenever it’s feasible. It significantly reduces the cost of exploring the configuration space, and once I find a solution I like it gives me some confidence that it’ll actually work. I’m a big fan of the principle of doing the cheapest experiment possible to determine whether a given design path is viable. The caution I apply in exploring the space is generally proportional to my knowledge of the problem. In other words, it would be a mistake to spend a bunch of money and time on a design path in an unfamiliar area because it’s likely to be suboptimal, if it works at all.
RF projects are usually good candidates for simulation, and antenna
design is especially compatible with this idea. I used
xnec2c
on my previous antenna project, so I repeated that
here. I simplified the OCFD as a single radiating element parallel to
the ground with the feedpoint at a configurable offset from one end. I
estimated the ground
conductivity at 2 mS/m and modelled the ground as flat. I didn’t
consider the effects of vegetation (particularly trees) or my house,
which is within one wavelength of the feedpoint on most bands of
interest. I also neglected the true shape of the
antenna when suspended from two points. Still, it seems likely to me
that this model is sufficient for selecting total antenna length and
feedpoint offset, which are the two parameters that I can reasonably
change.
I definitely don’t fully understand the physics of the OCFD, but I’ll describe what I know so far. An ideal dipole antenna has some frequency at which it’s considered resonant. This means that the current distribution along the radiating element forms a standing wave at the fundamental mode, where both ends are nodes and the center is an antinode. This is a half-wave dipole at that frequency because a full wave has three nodes and two opposing antinodes.
In addition to the fundamental frequency, the center-fed dipole will also be resonant at the odd multiples of the fundamental. I prefer to understand this by looking at it graphically. If you overlay all of the standing waves for the fundamental and its first few harmonics, it becomes clear that the odd multiples all have antinodes at the center. This is important: points on the antenna where current is high have comparatively low impedance2 and may make good feedpoint locations for that harmonic. That’s our design criterion—find the feedpoint offset that optimizes impedance across as many harmonics as possible.
To be practical for my purposes, I set the fundamental in the lower portion of the 80 m band (~3.5 MHz). The people who allocated the amateur HF bands cleverly made them harmonics of each other, so this scheme of optimizing harmonics gets us good performance at frequencies where I can actually transmit. After a lot of staring at standing wave plots, learning about what offsets other hams have used, and many simulation runs, I settled on 20% as the feedpoint location with a total length of 42 m.
No feedpoint will be a perfect match everywhere, but I planned to purchase an antenna tuner which would give me some flexibility in feedpoint impedance. I don’t have enough knowledge to give a complete explanation of how the tuner works, but in general it seems like it’s a two-port network with switchable reactive elements. By adjusting the elements, it’s possible to transform the impedance of the feedpoint into the 50 ohms that the transceiver needs, within some limits.
I also planned to include a 4:1 balun that makes the 50 ohms from the transceiver (really the tuner) look like 200 ohms at the feedpoint. This gives even greater flexibility and is easy to model by just changing the characteristic impedance parameter in the simulation. To prevent the coax shield from radiating during transmission, I added a shield RF choke3 at the feedpoint as well. This presents a high impedance to common mode RF currents while allowing differential mode signals to pass.
In my experiments with simulation as the first step of a project, I’ve learned that it’s important to decide when to call the simulation phase complete and move on. The model is always imperfect, and excessive iteration will result in overfitting on those imperfections rather than generating useful insights about reality. I don’t have a good process for deciding when to stop simulating. At some point it just feels like I’ve learned enough and am ready to start building or at least experimenting in the real world.
It’s necessary to raise antennas off the ground for HF operation because the Earth’s surface acts as a reflector. We want our signals to mostly go towards the horizon for good range, and to make the geometry work out the antenna needs to be up at least a quarter wavelength or so. A common method for raising wire antennas off the ground in the amateur radio hobby is to attach them to tree branches with ropes. Assuming suitable trees are available, this is usually the best option because of its low cost compared to building towers. In my case, I have several trees that are tall enough and far enough apart that I can make this work fine.
The goal here is to somehow get a rope up and over the tree and then tie that rope to a pulley. Then you thread a second rope through the pulley’s wheel and raise it up. The pulley makes it much easier to raise and lower the antenna as needed at the slight cost of more rope.
I say “somehow” because there are several known approaches to installing tree ropes, and in general this is a deceptively difficult problem. The simplest solution is just to throw the rope by underhanding it with a weight on the end. This worked for me on my previous antenna project, but it’s only practical up to about 8 m elevation in my experience. Some amateurs use slingshots and claim that their maximum elevation is around 20 m, but I didn’t try that for this project. Homemade pressurized air cannons are a popular and effective choice—and one that I’ve used before on Field Day—but I have doubts about their safety. To minimize the effect of the rope’s weight on the flying projectile, these methods often incorporate ordinary monofilament fishing line for the initial throw. The final rope is then tied to the line temporarily so it can be pulled through.
I selected a more modern method that uses a drone to carry a fishing line up and over the tree. This solution was successful, but I don’t think it’s substantially better than any of the other methods I mentioned above. Here’s how the drone method compares:
All of these factors make me unlikely to use this method again, although I’m glad I tried it. If you decide to try this yourself, let me point out one item that might not be obvious: it’s important to keep the fishing line away from the rotors. The rotors will tangle it up if you give them the chance (ask me how I know). To address this issue, I taped together two used paper towel rolls and tied them onto one of the legs of my drone with some spare magnet wire. This gave me essentially a lightweight stick whose far end I could use to attach the fishing line somewhat further away from the rotors. It’s not a foolproof solution, but it works fine if you’re careful.
At one point I had successfully used this method to thread both trees and raise the antenna. However, a wind storm broke the connection between a wire and its insulator, which left me with a rope that was still technically over its tree but too high for me to pull back down. For the moment, the far end of the antenna is tied off around 2.5 m above ground level instead of ~15–20 m like I wanted, but in comparison to the “as-designed” configuration I haven’t noticed significant degradation in performance. Someday I’ll get around to rethreading that tree and get everything back where it should be. Maybe I’ll borrow one of those air cannons from someone in my local club or build something else.
Lightning is a notable safety concern in the ham radio hobby. The practical constraints that physics imposes on antenna design for HF essentially force amateur operators to connect long, elevated wires directly to equipment in their homes. If lightning should strike near the antenna, large transient voltages will appear on the feed line and cause costly damage to attached equipment. That’s bad enough, but a direct strike on an antenna could conceivably cause a fire or electrocute the operator. It’s important to consider these possibilities when designing an antenna system.
It seems to me, not knowing much about lightning safety going into this project, that this topic is highly contentious. Lightning science appears to be incomplete, which doesn’t surprise me much due to the difficulties associated with observing and measuring lightning strikes. Within the study of lightning, there seems to be even less science available related to the amateur radio hobby specifically. Most of the advice I’ve seen has either amounted to accumulated best practices or adherence to the National Electrical Code. Both of these options make me uneasy because there doesn’t seem to be much discussion about the reasoning behind these ideas. It’s important to me that I understand why something is necessary before doing it whenever possible, otherwise I feel like I’m just participating in a cargo cult.
I mention all this because I suspect that someone may read this and see “obvious” flaws in my solution. I’m certainly willing to accept being wrong here, but I believe that what I’ve done is sensible because I can trace all of my decisions back to first principles.
My grounding and lightning protection system is made up of two three-foot ground rods, screw clamps, copper ribbon, and a gas discharge tube surge protector. Conventional wisdom urges the use of a single eight-foot ground rod placed as close to the entry point of the feed line as possible, but I doubted that I could get all eight feet into the ground due to a rock layer about 1.5–2’ below ground level on my property. I couldn’t be sure whether that rock layer would be a problem for me nearer to the house, so I decided to play it safe and use two ground rods separated by about eight or ten feet4. Using two shorter ground rods is not optimal because—from what I gather—longer rods maintain greater conductivity to the soil around them, particularly when the ground freezes. The idea with multiple rods is to try to maximize the conductivity in spite of the shallower depth.
Both ground rods have screw clamps that hold copper ribbon against them. Copper ribbon is preferred because—again going on some best practices here—a lightning strike is a broadband event with enormous current, so conductors must have maximum conductivity even when considering the skin effect. The screw clamps mechanically adhere the ribbons to the rods, which is better than soldering because the Joule heating from a lightning strike would melt the solder and break the connection before fully discharging. On the other end of the ribbons, I drilled holes and connected them to the surge protector with the provided nut and bolt.
The surge protector is a clever device. It connects to the feed line and normally passes signals uninterrupted. However, the protector also connects the coax to a gas discharge tube, which acts kind of like an inverted fuse. The tube normally presents a high resistance, but a large voltage causes it to “fail closed” and transition to a low-resistance state. This is meant to shunt the high voltage to ground via the ribbons and ground rods. The tube, having done its duty and valiantly sacrificed itself, may be replaced.
Lightning strikes are relatively uncommon in my area, with the National Weather Service estimating 0–1 strikes per square kilometer per year. In addition to the protection I described above, a simple way to minimize damage is to disconnect the feed line from the radio during a storm that might produce lightning. I intend to do that when such a storm arrives, although those are usually confined to the summer months for me.
I don’t care much for single sideband (SSB) operation. Aside from usually requiring higher power than digital modes for the same distance, I don’t find much fun in voice QSOs. There’s nothing wrong with it, of course, but it’s not why I turn the radio on. I think it’s much more fun to work with low power and chat keyboard-to-keyboard. This is a smaller niche within the hobby, but there’s a lot of diversity5 in digital modes compared to voice.
I considered buying a standard high-end HF base station transceiver (e.g., the Icom IC-7300), but the price seemed excessive, and I wasn’t happy with the idea of having a literal black box that does all the RF stuff for me. On the other hand, I wasn’t interested in continuing with the HackRF jury rigging I did on my last radio project, and I wanted a bit more power anyway. The uBITX V6 is the right balance of power, hackability, and cost for me right now. It comes as a kit, but the assembly amounts to plugging stuff in and tightening some screws. It nominally transmits at 10 W, and for my antenna system I’ve found 9 W to be the average in practice. Crucially, the entire design is open source, so I can make changes as needed, at least in principle. One of the first modifications I made was to upgrade the firmware from the stock code—which is a bit slow—to an improved fork. The main controller is an Arduino Nano, so flashing is easy. Maybe in the future I can try to build a Rust firmware for it, perhaps with built-in support for popular digital modes.
The uBITX V6 supports Computer
Aided Transceiver (CAT) control by emulating a Yaesu FT-857 over the
Arduino’s USB port (at least with the firmware linked above—I think the
stock firmware also has support). This includes PTT control. Audio in
and out are available as 3.5 mm jacks, so I bought a no-name USB sound
card on eBay and hooked it up with male-male 3.5 mm TRS cables. (Note
that the headphone output of the sound card has to go to the microphone
input on the radio, and vice versa.) It took a little fighting with
Linux audio to get everything working, but now it’s reasonably reliable.
I recommend qpwgraph
and pavucontrol
to ward
off insanity here.
FT8 has become the default digital mode in ham radio. Its design is widely considered to be nearly optimal with respect to information theory and the HF channel model. This makes it excellent for logging contacts all over the world with low power, but the unfortunate truth is that I find it boring. It’s cool to make intercontinental contacts with less power than a string of Christmas lights, but due to the spartan and rigid QSO structure, there isn’t much room for human interaction. I don’t agree with people who say that FT8 is “ruining ham radio”, but it’s not for me outside of an occasional dabble.6 One thing I like about it is that it’s the best propagation analysis tool I know of, since you can put out a call on FT8 and then immediately see where you’re being heard on PSK Reporter. The popularity of the mode results in a lot of monitoring stations.
JS8 is a conversational cousin to FT8. It uses a similar encoding and modulation scheme but allows for messages of arbitrary length and content, giving it the keyboard-to-keyboard properties that I’m looking for while retaining nearly all of the excellent performance of its predecessor. JS8’s popularity doesn’t compare to FT8’s, but there are enough operators on the bands to have a QSO at basically any time. JS8Call, the de facto standard software for the JS8 mode, adds a networking layer to JS8 where stations can relay messages through each other automatically and store messages in each other’s inboxes for later retrieval. I’ve explored some of these features but still have much more to go. I think this kind of stuff is really neat7, and it could be legitimately useful for emergency communication.
Setting up JS8Call and WSJT-X (the standard software for FT8) is simple enough with the uBITX. CAT control works with Hamlib as described above, as does audio routing with the USB sound card and audio cables. After tuning in the levels, CAT control, and PTT, I saved the configuration in each program with a name so I can return to it later. Everything has behaved itself for the most part since then.
Fldigi is the software
for amateur digital modes. It’s also as old as the hills. CAT control
isn’t a big deal because it supports Hamlib, but I’ve had more trouble
with audio routing than I expected. Fldigi doesn’t know about Pipewire,
but it does know about Pulseaudio, so it uses Pipewire’s Pulse
compatibility layer. Okay, fine. But for some reason Fldigi (or
Pipewire?) doesn’t remember which audio sink I set it to use in
qpwgraph
, so it sometimes happily transmits my audio only
on the system speakers instead of into the headphone output of the USB
sound card. Lately it’s been behaving, but I dread rebooting for fear
that all of the delicate configuration state I’ve arranged will be lost.
I guess I need to try to learn even more about Linux audio.
Anyway, once you convince it to work right, Fldigi is a lovely interface to basically every digital asynchronous keyboard mode in use on the air today. I emphasize asynchronous because Fldigi doesn’t support FT8 and friends, which all depend on synchronized timing between all stations plus or minus half a second or so. But there are still plenty of async modes available, the most popular of which seem to be PSK31, RTTY, Olivia, and Hellschreiber. They’re all interesting to me, and I’ve had several QSOs using them with stations across the US and parts of Canada. I won’t describe the details of these modes here for brevity, but they’re covered quite well elsewhere. It’s a lot harder to get QSOs on these modes than FT8 or JS8 due to their relative unpopularity and the fact that they don’t have specific sub-bands (although they typically have well-defined calling frequencies). The best way I’ve found to play with these modes has been to find periodic digital nets that use them. I’ve also had fun using Fldigi just to decode digital bulletins from W1AW and weather faxes from the National Weather Service, like the one below.
There are still many more modes that I want to try. Thor and FSQ are on my list, although they seem to be firmly in the long tail of modes that see nonzero but infrequent use. After a while, maybe I can convince some ham friends to try new modes just to say we did. Also, Fldigi is part of a suite of software tools that seem to provide messaging and maybe networking capabilities on top of the Fldigi modem, so I’d like to try those as well.
I also want to make at least one SSTV QSO, although that requires other software. I did receive several SSTV transmissions on the amateur bands, such as the one below.
This antenna system has exceeded my expectation. At 9 W transmit power, I’ve gotten contacts to western Europe (~4800 km), the west coast of the US (~4000 km), and the Gulf states (~2000 km) on JS8 and FT8. Other digital modes have carried me similar but slightly lesser distances. I even tried out SSB and managed to get a contact with a Parks on the Air (POTA) activator near Washington DC, as well as check into a statewide ragchew net. A few hams on the other end have complimented my station’s performance with limited power, which is probably just them being kind but makes me feel like I’ve done well on this project.
The strange thing about this good performance is that I didn’t trim the antenna for resonance like I designed it. I cut it about 7% longer than I expected it would need to be (45 m instead of 42 m) and put it up for measurement. My nanoVNA showed SWR values that were lower than the model, which I attributed to the lossy feed line. I thought “oh well, I’ll get a measurement closer to the feedpoint later, but for now, let’s try this thing out.” To my surprise, it tuned up on several bands and I started making contacts. I’ve stuck with this configuration ever since.
I can’t explain why this system works. I suppose the tuner is doing me a lot of favors, or maybe I’m benefitting from the effect described here, where wires of certain lengths have favorable properties for tuning on the ham bands. (As it turns out, my 7% longer wire is quite close to a “good” value of 148’ or 45.1 m.) That analysis seems to apply to end-fed random wires, not OCFDs, so I’m not sure how to integrate it here. In any case, I’m not especially motivated to investigate further right now because everything’s working, but in the spring I’ll probably hook up the nanoVNA closer to the antenna and see how close it really is to resonance. Depending on the results, maybe I’ll be brave enough to trim some wire. My guess is that it’ll perform basically the same as it does now for practical purposes.
I have some ideas for new things I want to try on the air, in addition to my new normal routine of loading up JS8Call and trying to make a QSO or two. I’m sure this list will grow with time.
ardopcf
, but
so far Linux is smarter than I amI didn’t find much information on the web about where to buy certain components, so I’ve included a list below with the hope that this might help someone trying to build a related project.
Actually, the absolute increase in bandwidth privileges is small. The total bandwidth between VHF, UHF, and SHF—which Technicians and Extras both have full access to—is 198 MHz. Technicians get 0.850 MHz on LF, MF, and HF, while Extras get about 3.77 MHz. So by upgrading you only get about 1.5% more spectrum to play with, and if you consider the bands beyond SHF then the fraction is even smaller. The reason it’s a good deal is that the extra 1.5% lets you talk globally with low power, while the higher bands are limited to local communication outside of rare conditions, satellites, repeater networks, etc. Also, much of the HF spectrum that Technicians get is CW only, while Extras can operate most modes anywhere in the bands within the bounds of etiquette.↩︎
Recall that impedance may be viewed as the ratio of applied voltage to observed current. Points with low or zero current will have arbitrarily high impedance.↩︎
For those interested, according to my nanoVNA the linked choke attenuates common mode signals by about -5.6 dB at 3 MHz, with attenuation increasing to more than -20 dB at 30 MHz. Insertion loss increases from 0.1 dB to 0.4 dB over the same range.↩︎
As it turned out, both three-foot ground rods went in easily, which I guess is because the builders of my house excavated a slightly larger volume than the basement and foundation would actually fill. In the future I may take a chance and try an eight-foot ground rod instead.↩︎
Some of the modes on the linked page are voice modes, but the majority are digital (and some are even digital voice).↩︎
Someday I’d like to try moonbounce, which benefits a lot from the design of FT8. I think moonbounce is attractive to me because the Earth-Moon-Earth path is the longest that a radio amateur can reasonably use.↩︎
In particular, there’s a challenge on the JS8Call website to
relay a message across at least three continents and send an
ACK
all the way back. Maybe someday I can try to assemble a
team to do this.↩︎
I haven’t figured out why this is the case. I hope to one day have enough E&M knowledge that I can work this out from Maxwell.↩︎