Some friends and I have been talking about dong a camping trip, and I decided this would be a good opportunity to try some portable ops with an end-fed half wave antenna. I’ve been doing a lot of reading on the subject, especially AA5TB’s excellent explanation of the theory behind a resonant EFHW antenna. I set out to build a coupler, something light and durable that I could throw in a bag and not worry about; ideally I wanted to tune 40 and 20 meters. The 30m band would be a bonus, but as I don’t yet have the hang of CW I wouldn’t get as much use out of that band.
I decided to cheat a little and build AA5TB’s “mini” 17-40m QRP coupler design. I recently picked up some polyvaricons from the De Anza College Electronics Flea Market, but I had no idea what the specs were; Googling for the markings turned up nothing useful. I decided to just build it and see what happened. As it turns out, I can tune 30-17, which isn’t bad for using unknown parts.
Math
28 turns on a T50-2 core gives 3.84uH of inductance, according to the calculator at toroids.info. At 14.250MHz (center of the voice band, my target), that’s 343.81Ω of reactance. To achieve resonance we need to match that with capacitive reactance; solving for C we get 32.5pF. At 18.139MHz, 437.65Ω; 20pF yields resonance. At 10.140MHz, 244.8Ω which yields a resonant capacitance of 64.1pF. I can just barely reach the top of the 17 meter band, so this tells me my polyvaricon doesn’t go much below that. I can go well below the 30m band but not quite get to 40 meters, so my guess is this is a 20-120pF unit. I’m not sure what range the built-in adjustment trimmer adds, but I couldn’t get enough range to tune both 40 and 17m.
Performance
To test performance, I picked up some nice wire from HRO, 26AWG black “polysheath”. I don’t know what the insulation is made of, but it’s strong, pretty flexible, and relatively smooth (but not Teflon slippery). I cut about 34′, soldered on a banana plug, and tossed it up in a tree, roughly in an inverted L formation. I dispensed with the counterpoise, hoping I’d get close enough to resonance that counterpoise currents wouldn’t be a big issue. Tuning was straightforward, once I remembered to switch the FT-817 to the rear antenna jack (oops). Twiddling the varicap knob for maximum noise got me pretty close, and keying up at 2.5W for the final adjustment got me somewhere under 1.2:1 — my meter isn’t great at low power. I didn’t have time to try working any stations, as the ‘817 battery was nearly dead by the time I was done finding the “sweet spot”, but I heard a half a dozen states including Kansas and Washington. Next time I have a free hour, I’ll try some PSK and update this post with the results.
With the last bit of my battery I decided to try shortening the antenna and trying to tune 17m; I didn’t have as much luck with this band. I suspect this is because I did a bad job of estimating how much to shorten the antenna. I could easily cut another antenna for 17m; they pack down so small with the 26AWG wire, why not? I expect that with a resonant wire, finding a match on 17m would be trivial.
Photos
Conclusion
In all, I’m impressed with how easy it was both to build the coupler and to find a match. The end result is compact, flexible, and stealthy – the rope used to anchor the wire was far more visible than the wire itself! I could improve it by adding a ground lug, for attaching a clip-lead counterpoise. I’m a little disappointed by the fact that I can’t tune 40m; I may try adjusting the polyvaricon’s trimmer to give more margin in the 17m band, and then add a ceramic capacitor in parallel… without doing the math, I don’t know how successful this would be. Measuring the variable caps might make a good future post!
Just a quick post to share my excitement that I was finally able to get a Hitachi HD44780-compatible LCD to work with my Amforth code! I’ve been working on this (very intermittently) for a month or two, and it’s really gratifying to see it finally functioning. I’ve been wanting to add a display to a couple of my projects for some time, and now I can! The code isn’t perfect (for example, it takes two executions of the initalization routine to get the LCD to respond), but I’m happy with any kind of progress.
Some photos:
The code definitely still has a few bugs, but it’s available if anyone wants to have a look.
For the past few years, since I earned my General class license, and later, my Extra, my radio ops have been almost nonexistent because I lacked of space for an HF antenna. During most of this time I was an apartment dweller in an urban environment, with all the limitations that entails. For the most part I only operated when I felt like setting up my Buddipole, either indoors in a loft area, or in the front yard. Needless to say, not an ideal situation. Recently, however, my girlfriend Denise and I purchased a house in Berkeley, which has an unfinished attic.
The attic was promising; nothing outside for the neighbors or YL to find unsightly (personally, I find antennas beautiful, but I seem to be in the minority), and the space was going unused anyway. However, life intervened and many more pressing projects came up. When I found myself with free time, I started looking into antenna modeling and researching what others had used for indoor antennas. Unfortunately I ended up being a victim of “analysis paralysis”, and was bogged down trying to tweak my models to get a better pattern, or closer resonance, or what have you.
A friend from the FreeNode #hamradio IRC channel, Rik van Riel, AB1KW, helped me break out of this pointless over-analysis. He suggested a simple dipole, run in whatever layout I could manage, in the attic of my house. I had considered something along these lines but discarded the idea, because I thought the pattern from such an antenna would be useless. Rik pointed out that even a crappy pattern is better than no pattern – logic I couldn’t refute.
I had a couple spools of Category 3 cable in storage, and decided to use this for the dipole. After stringing the cable along the rafters in a vaguely Z-shaped layout, I stripped each wire in the bundle and twisted them together so there wouldn’t be any weird capacitive effects between the strands. At the feed point, I brought the cables down from the ceiling with crude cardboard spacers to form a poor man’s ladder line. The feedpoint ends were stripped and connected to a 1:1 balun, which was in turn connected via a very short (<12″) coax cable to the tuner. I considered just using a PL-259 coupler for this, but I had the short jumper on hand. Even with a terrible mismatch the power lost in the jumper is insignificant.
Next, I had to run the feed line. My house was built in 1892, and has lath-and-plaster walls which do not have insulation between the lath and the exterior siding. In a stroke of luck, there was already a hole in the plaster where my Comcast cable connection enters the house. “Easy,” I thought, “I’ll just snake a cable fish up to the attic and pull the coax down inside.” A nice theory, but it was not to be. First I purchased a cheap metal cable fish, which almost immediately folded over and looped around inside the wall, without making it up to the attic. One trip to Home Depot for a fiberglass fish pole later, and I discovered that the section of wall I was “fishing” had a fire stop, which meant there was no way to access the attic without drilling. I ended up running the feedline out the eaves, down the side of the house and through the wall next to the Comcast drop. All in all, a bunch of time wasted, but at least it’s finished! Here’s my rig, set up on a corner of my desk.
How does it perform? My LDG Z-11pro can tune it on 80 meters through 6 meters at a completely usable 2:1 or better! In fact, almost all of the bands tune at under 1.2:1. Unsurprisingly, 160m is a bit of a tall order, and seems to tune around 4:1; I’m sure all I’m doing is heating up my tuner on that band. So far I’ve only made 6 contacts: TX, WY, NH, WA, CO, and British Columbia, Canada. Additionally I’ve heard Cuba on 40m, Belgium on 30m, and Hong Kong(!) on 30m. With luck I’ll find some free time this weekend to devote to making contacts.
Many thanks to Rik van Riel, and to many others on FreeNode/#hamradio, for the advice and encouragement. Apologies to Shel Silverstein for the post title.
Lately I’ve been learning a lot about Forth, the stack-based programming language. This endeavor started because I was having trouble with my AVR-based memory keyer project. I was trying to interpret the output from a rotary encoder, and not having much luck. My friend Alex, who has done quite a bit of embedded development, suggested I try amforth (a native Forth for the AVR microcontrollers). He uses Forth to prototype his designs because it allows him to muck about with hardware interactively, and get very small pieces of code (“words” in Forth parlance) working in isolation before joining them together into a larger word which accomplishes useful work. I was skeptical, especially with how arcane Forth appeared at first, but it’s been a fun journey so far. I have of course gotten wildly off track of my original project, but I’m OK with that.
Amforth was kind of a headache; I would add a new word (new words in amforth are written to the AVR’s program flash memory) and suddenly the ATmega168 would start randomly resetting and spewing garbage to the serial port. I puzzled over this until I realized the default configuration of words compiles to just under 16KB – which is exactly how much flash the ATmega168 has. I immediately pulled up Atmel’s page to find a distributor with stock of the ATmega328 (the ‘168’s 32KB big brother)… only to discover that no one has any in stock. (Arrow Electronics claims to have 100, but also mentions a 14 week lead time.) I did eventually dig up an ATmega644P which was for another project, but I haven’t tried amforth on it yet.
I talked to my dad, Bob WB0POQ about my Forth adventures, and he mentioned a Morse keyer program he’d written in Forth. He gave me a copy of the code to look at, and I decided to see if I could improve on it, using things like compiling words. You can see my work-in-progress here. Right now it doesn’t do much other than compile a representation of valid Morse characters into memory, and print them back out. I’ve recently discovered gforth’s key input mechanisms, so keyboard input is my next step. I’m not sure if I’ll be able to do sound output from gforth, or serial port toggling for that matter. My dad was using a DOS-based Forth interpreter, which gives him direct access to things like the PC speaker and serial port memory-mapped I/O. I’m sure these things can be accomplished under Linux, I just don’t know how yet.
For the interested, I highly recommend the web-ified version of Leo Brodie’s Starting Forth, which seems to be the de facto beginner’s guide to Forth. It’s a little goofy, and due to its age, talks about things like magnetic disk storage with reverential awe, but it’s a fun read and a great introduction. Another great book, also by Leo Brodie, and also free, is Thinking Forth, which is available on SourceForge in several formats. If you feel like supporting the author (I did), you can also buy it on Amazon.
While on a recent trip to my home state of Minnesota, my dad, Bob WB0POQ helped me build this dual-rail, adjustable voltage power supply, based on a design I found on the web. As you can see below, it turned out pretty well. I couldn’t have done it so cleanly, nor with only a single iteration, without my dad’s advice and assistance. We both had such a good time, that we’ve informally established a policy of working on projects whenever I’m in town.
2A circuit breaker (thus 2A max total out of all the rails)
I could probably get away with a larger breaker, as the transformer is rated much higher. Still, you can do a lot with 2A, and this isn’t intended to power a 100W transceiver (I have a nice fixed, switch-mode supply for that).
I plan to add a HD44780 LCD display to show voltage and current on each rail, controlled by (of course) an ATmega168. I’ll add some voltage dividers for the voltage sensors, and some 0.5Ω resistors and an LM324N for the current sensors. Definitely more details to follow on this aspect of the project.
Tonight I decided to try to get switch input, in the form of my Bencher paddle, working with this ATmega. Switch input is tricky due to a phenomenon known as switch bounce, contact bounce, or chatter. Wikipedia has a useful entry on the topic. This tutorial has a nice oscilloscope screenshot depicting switch bounce.
I first tried the simplest possible solution, to prove to myself that it wasn’t going to work. Interrupt service routines, without debounce:
Since INT0 and INT1 are set up to trigger on any logic change on the pin (e.g., from high to low, or vice versa), the naive expectation is that the LEDs attached to PD4 and PD5 will light on a logic low (button pressed) and extinguish on a logic high (button released). Here’s what actually happens.
Here’s the updated ISR (just one shown for brevity), with debouncing added.
ISR(INT0_vect)
{
volatile int count;
volatile int i;
for (i = 0; i < 5; i++) {
if (bit_is_clear(PIND, PD2)) {
count++;
} else {
count = 0;
}
}
if (count >= 5) {
PORTD &= ~_BV(PD4);
} else {
PORTD |= _BV(PD4);
}
count = 0;
}
Essentially we check the pin state 5 times, incrementing a counter each time. If the inputs are bounces, the count should never get that high (it is reset each time we see the opposite logic state). Legitimate inputs hold the logic level for much longer, by comparison. When a legitimate logic low is seen, the LED attached to PD4 (in the case of INT0) is lit. Otherwise it is extinguished. Here’s the results.
Perfect! Next up: sidetone generation, translating Morse input into ASCII characters, and interfacing with a rotary encoder.
I have an STK500 and some ATmega168-20PUs, and I’m delving into pure-C AVR development — that is, non-Arduino. It involves a lot more busywork code, but the tradeoff is vastly more flexibility. Unfortunately, a combination of not knowing the STK500’s software clock frequency, and having fuse bits set incorrectly, caused some frustration and wasted time. For the record, the STK500’s default software clock frequency is 3.686400MHz. Once I figured this out (reading the fine manual was quite illuminating), fixing the math I’d used to set up the timer interrupt was easy.
Setting the UBRR0 register to configure the serial baud rate tripped me up for a bit, too, as the variables in the formula used for setting UBRR (shown below) were overflowing. Casting fcpu and the baud rate to unsigned long fixed the problem. (Note in my case, the prescale was set to 1; there’s a fuse bit on the ATmega168 which toggles a divide-by-8 prescaler internally. This fuse bit is disabled on my ATmega.)
UBRR Formula
(fcpu/prescale)/(16*baud_rate)-1
So far I’ve been able to make an LED blink at a predictable frequency, and produce output on the serial port. Not much, but I’ve learned a lot implementing even this small bit of functionality. Learning how to set up interrupts is the first part of accepting paddle input. Setting up timers is critical for PWM output, which I’ll use to generate a sidetone.
There’s a million and one memory keyers on the market, both in finished and kit form. I want to build my own, not because of any perceived cost savings, but just because I can. My dad, WB0POQ, and I worked on an Arduino-based keyer, but his goal was to get finer control over the length of individual elements; that is, setting a particular WPM speed, and then shortening or lengthening the dits or dahs until it “sounds right”. Since I’m still new to Morse code, I’m not so choosy about the sound, but I would like to be able to push a button to send CQ. I’ve had this project in mind for a while now, essentially since I started getting somewhere with my CW transmitter project. I plan to build it around an ATmega168, because I have some on hand, and I want to write it with raw AVR C, not the Arduino libraries. Not that there’s anything wrong with the Arduino, but writing AVR C should give me a bit more flexibility (more interrupts, specifically) and it’s a new challenge.
The features I’m planning are as follows:
Adjustable WPM, from 5 to 35 or so
Message memories, 10 seems like a nice round number
7-segment display of selected memory slot, or numeric Morse output
Low power, so I can run it off of a 9V battery
Sidetone, via PWM output from the ATmega, possibly to a piezo buzzer
Adjustable sidetone pitch
On/off switch, or some way to put the ATmega in a sleep mode
I found a great deal on some rotary encoders, so I plan to use one of those in this project. They incorporate a normally-open SPST button, so I won’t need any additional buttons to trigger sending of stored messages. I might still add a switch to indicate whether the rotary encoder should be interpreted as setting the WPM speed, or as selecting the memory slot. Maybe I could interpret varying-length presses on the encoder button to switch between modes.
Interpreting input for the message memories looks to be an interesting challenge. The hard part is telling the difference between an inter-element space (that is, the space between the dit and dahs in the letter “Q”, for example), the space between characters (e.g., between each letter in “QTH”), and space between words (e.g., “QTH IS”). Right now I’m thinking of storing the current timer value at the end of each paddle input interrupt handler, and checking it at the start of the handler. If the elapsed time is more than 3 dits, then the delay should probably be interpreted as a space between characters. More than 7(?) dits, and it’s probably a delay between words. I’m just musing, I haven’t tested this theory.
I’m actually still learning Morse code, and have never had a CW QSO, so my feature list may be missing something important. What features do you find useful in a keyer? Leave me a comment!
The meters work! Upon the suggestion of gordonjcp, I used a couple AA batteries and a potentiometer to dial the meters to full scale, then measured the drop across them, the supply voltage, and the resistance of the potentiometer. Using Ohm’s law I can calculate the meters’ full-scale deflection current. In summary, I have a 245µA meter and a 1mA meter, both work like a charm and should be quite useful in future projects. I think I’ll turn the VU meter into a QRP power meter, based on the design in EMRFD. Check out NT7S’ excellent page documenting his build of this handy piece of test gear.
Update: Gordon points out the VU meter is likely to be a 250µA model rather than 245µA.
While browsing for bathroom fixtures at Urban Ore in Berkeley, I happened across these meters in the Electronics section. They’re in great shape, though I haven’t tested them. I’m still pondering the best way to do so, as I suspect the S-meter might be an ammeter on the order of <100μA. The VU meter’s terminals are marked with positive and negative polarities, so I suspect that one is a voltmeter. The best part? $4.00 each.
If you know anything about these meters, please pass it on in the comments.
