In the days before the event, I put together  an “untangleable folded dipole” antenna made from 300 ohm twinlead, plus a matching box comprised of two toroids and two capacitors. The antenna was based on a design found on the blog of KI6SN, and I summarized the construction details for my effort on a Google-plus post.

After spudgunning two trees, we hoisted the folded dipole to a flat 40-foot deployment. The feed line is about 25 feet, so a short BNC-terminated coax extension was used. The antenna worked great and allowed us to work a Swiss station, and to score reverse beacon hits throughout Europe on 20m.  I swept the antenna with a MFJ analyzer at the end of the event, and noted that SWR was below 1.2 for the entire CW portion of the band, and less than 2 from below 20m to above the voice portion of the band. So, quite impressed with the folded dipole design. As advertised, it packed up easily and without tangling.

There are several physiological reasons why sending code with the left foot is not a good idea, although with practice it might be an option for some. For the rest of us, though, perhaps the left foot could be used for other purposes, leaving the hands free to operate the radio, and more importantly, convey items back and forth from the mouth during radio operation, supplying the operator with the necessary calories and hydration to make it through a contest.

And so was born the QLF Device.

Well, not really.

Several factors led to development of this project. First, our radio club had started using TeamSpeak for internet conferencing. We had run a few CW practice nets on HF, but most of the time, band conditions did not permit all of the interested members to participate, since our members are not just from the local area. This VOIP solution worked very well, and while we know it’s not radio, it’s a fine way to practice.

One issue that arose was that the software worked best in “”PTT” mode, where a key was depressed when the sender wanted to open his/her microphone. There is a VOX option in the software, but it often led to unintentional microphone keying during the session, feedback, and general interruption of the practice sessions. Any key can be designated, but metakeys (like ALT, CTRL, etc.) work best, since they are not likely to be used for anything else during the session.  A number of members remarked that it takes some coordination to depress a computer keyboard key with one hand, while working a straight key or paddles with the other.

Another need that has arisen in the past relates to contesting. Foot pedals would be helpful in two contexts: 1) for keying the rig’s microphone PTT during voice operation, allowing the operator to use a hands-free boom mike, and 2) for sending a “CQ” message during a contest.  In the former case, we’re looking for some kind of physical connection to either the microphone jack or ACC jack of a rig, in the latter case, since “running” a frequency usually amounts to repeatedly stabbing the F1 key of some contesting software (e.g., N1MM) to play a canned message or send a CQ message in morse code, what we want is a means of sending the “F1″ keystroke to a computer.

These thoughts were rolling through my head when I noticed that Adafruit was offering a foot pedal switch at a reasonable price ($7.95 for single units, less if ordered in quantity).  I ordered a few to check them out, and while awaiting delivery, sketched out the “design spec” for the QLF device:

1. The QLF should allow direct control by making or  breaking a connection for physical switching, i.e., for microphone PTT.
2. The QLF should send “keyboard” characters — at least two of them:  F1 and a meta character
3. When sending keyboard characters, the device should operate in three modes: a) PTT (continuous while pushed); b) One shot (no matter how long QLF is actuated); c) Toggle on/off (to avoid fatigue)
4. The QLF should provide adequate feedback for the user to know which mode and character are selected
5. The QLF should be dead simple to operate, even after 24 hours in the contest chair on a diet consisting solely of cheetos and lime diet coke.
6. The QLF should be relatively RF resistant
7. The QLF should not require its own batteries and shouldn’t consume much power
8. The QLF should be smaller than the rig it operates
9. The QLF should be cheap. Like, less then ten bucks or otherwise made of stuff in the junque box.

Before deciding on how to hook things up, a few dissections were in order, starting with the foot pedal. The construction of the foot pedal appears to be sturdy. It has a hard plastic upper portion, which seems thick enough to stand on and the bottom portion is metal. Although there might be enough room inside the pedal to stash some components, it doesn’t seem easy to open the case.

A grey wire about two meters in length emerges from the back of the switch. Slicing the wire open reveals three internal conductors: red, white, and black. There is no shielding on the cable, and no ferrite is present. If RF were a problem, it might be worth replacing this wire with a shielded cable (for example, a sacrificed USB cable) and slapping ferrite clamp around the wire on the end that attaches to the QLF device. So far, this hasn’t been necessary, though.

The three wires allow the switch to be used to either open or close a circuit. Red and black are normally connected, but depressing the switch breaks that connection. If you use red and white, you get the converse case, which is likely of more use. My plan was to terminate the switch wire with a 3.5mm connector so that I would have maximum flexibility in connecting devices to the switch, depending how I wired the jack connecting to the device (i.e., a radio or the QLF device). Since red is common to both configurations, I connected it to the barrel, and soldered black to ring and white to tip. This means that I can use the cheaper mono jack or stereo jack to access the red/white combination.

The next step was figure out how to make the action of stepping on a switch send one or another character to a computer, presumably over USB, since PS2 connectors are now passé.  Again, I started with some dissection to understand how keystrokes are normally sent from keyboard to computer. Actually, there are plenty of fine descriptions of this on the internet, so it wasn’t so much a matter of understanding as needed to harvest the brains of a few keyboards for use in this project.

Starting from an existing keyboard seemed reasonable because 1) the number of trashed usb keyboards on this planet exceeds the number of rats; 2) USB is complicated, and developing a device to duplicate the functionality of a keyboard seemed like a difficult and potentially expensive way to start.

If you rip apart an USB keyboard, there are usually three layers: the keys, a rubbery mat, and a matrix of conductors printed on plastic sheets. Conductors from the upper plastic sheet are brought into contact with the lower sheet when keys are mashed down. The conductors all lead back to an edge connector, and a small logic board attaches to the plastic sheets at that point. Usually, there are about 25 to 30 pins that join the board to the plastic. One sheet connects to about eight of the pins, and the other sheet to the rest. The USB cable itself also connects to the board — two data lines, a positive, a reference ground, and a shield ground.

Without really knowing too much else about how all this works, it was clear that connecting some of the pins to other pins would send characters to the computer… but which pins? One internet how-to site recommends tracing the keyboard key layout onto the plastic layers and then obsessively tracing each one back to the edge connectors to create a complicated map. That should appeal to anyone who has enjoyed mapping a maze of twisty passages, all alike.

I opted for plan B — a program that runs on the computer and displays which character is being pressed. I downloaded keyposé, a program that is free for private and academic use. It ran fine under Windows XP SP3. The program was developed to assist in creating software demos.  When this program runs, it will indicate which key is pressed, whether on the computer’s main console keyboard or on another one attached to a USB port.  The beauty of this program is that it shows which meta keys are being pressed, or even which combos are pressed.

I initially mapped the keyboard logical module pins by noting which character appeared when I connected every permutation of pins, i.e, pin 1 and 2, pin 1 and 3, pin 1 and 4, etc. This yields a matrix which has both some blank spots and some redundant spots.  After I did this with three keyboards, I came to the conclusion that this mapping is not standardized, even for a given manufacturer, so this process of figuring out which pins are important cannot be avoided.

However, there is a short cut. Since we’re only trying to fire off the F1 key and some other meta key, why bother mapping all the keys?  First, concentrate on finding the two-pin combination that produces F1. If possible, see if either of the pins involved can be paired with another pin to produce a meta-character. If so, this makes life easier later on and saves on part count since one pin can be common.

How smart is it to take a piece of wire and start strumming it across the connector pins, while the logic  board is plugged into your valuable laptop via the USB cable? Well, I can only give you my experience — nothing blew up. Most laptops are smart enough to shut down a USB port when the current draw exceeds specification.  Even so, it might be a good idea to use an older laptop or to connect via a USB hub for testing.

After using a piece of copper wire for this purpose for a while, it occurred to me that they keyboard itself might have some resistance between leads rather than a dead short, as some of the runs of ribbon-thin conductor are pretty long. I measured between 30 and 70 ohms resistance on average for short and long runs, so some small value resistor might serve the purpose better than plain wire, but using a wire didn’t seem to harm anything when I did it.

Since the solution is now to make a connection between different pins to send either “F1″ or a meta-character (I settled on “CTRL”, but any would do), the next step was pretty obvious – to use a transistor as a switch between the appropriate pins.  To get all the functionality of the different “modes”, though, would require some circuitry upstream of the switching transistor. My first inclination was to use a microcontroller, but that seemed like overkill and probably not the cheapest way to get what I wanted. Instead, I opted to use a couple old workhorse components. Power for the circuit is derived from the USB cable itself. The USB standard guarantees up to about 500mA available, and we won’t come near that.

Schematic: QLF version 1.0

A single SP3T switch selects the mode (PTT, one-shot, or toggle on/off) by directing the appropriate high output signal to the gate of a 2N7000 N-channel MOSFET. This switches the MOSFET on, and current flows through the pins connected to the MOSFET’s source and drain. I had measured the voltage on those pins before connecting, and the higher voltage should go to the drain, and lower or ground to the source. If you get this backwards, it’s not a problem, but the MOSFET will conduct all the time, and this will be apparent because the keyposé program will show that the character is being sent constantly.  Since there are two characters that potentially could be sent, a second switch directs the appropriate pins to the source and drain terminals of the MOSFET.  The state of this version 1 QLF device is always obvious from the position of the switches, one for mode, one for character.  Since the gate of the MOSFET is brought high whenever a character is sent, an indicator LED is also attached to the gate. When the LED glows, a character is being sent; this provides some useful feedback to the user about what is going on during normal use.

The PTT function is the most straight forward. When the foot pedal is depressed, the base the 2N3906 PNP transistor pulled to ground and current flows from +5V on the collector to the emitter, and through the mode select switch to the MOSFET described above.

The one-shot function is desirable because sending multiple key strokes quickly to a program like N1MM results in a string of CQ messages being generated, one after the other. Similarly, holding down the character on a keyboard could result in repeated generation of the character. Since neither case is what the user usually intends, the purpose of the one-shot is to emit a single keystroke, even if two switch closures happen very close together (i.e., switch bounce), or if the switch is held down. You can stand on the foot pedal, but you’ll only get one keystroke when this mode is active.

To achieve this functionality, a 555 timer is used in monostable mode, with its output (pin 3) connected to the gate of the 2N7000 MOSFET via the mode select switch. The 555′s trigger pin (2) is normally pulled high. It connects to the switch through a 0.1 uF capacitor. When the switch closes, that capacitor is grounded and pin 2 sees a transient dip in voltage — enough to satisfy the op amps inside the 555 that something important is going on. The 555 fires off, and the duration of its output on pin 3 is determined by the combination of the capacitor and resistor connected to pins 6 and 7; specifically, the duration in seconds is 1.1 * R * C.   I  went with a 0.1 second pulse because this should be long enough for the logic board to register this keystroke and not so long that it starts repeating. The tolerances of electrolytic capacitors are not precise (particularly when they have been sitting in the junque pile for an indefinite period), so best not to choose to low a value for the capacitor. The LED provides a direct read out that the one-shot is functioning as designed.

Finally, there is the toggle on/off mode. This mode is meant to spare operators some foot fatigue. Rather than hold down the pedal for their entire long-winded transmission, the pedal can be pressed once at the beginning of the session to key the computer (and/or rig), and then again at the end to unkey it. What is needed here is a T-flip/flop circuit – a circuit that can remember its state, and every time it is poked, change to the complementary state.

I grabbed the cheapest, simplest IC that I had on hand for this purpose, but many substitutes would also work here. There are plenty of references on the internet about how to make other kinds of  flip-flops (e.g., a JK Flip-Flop) replicate the function of a T-flip-flop, but I used a 74HC4024 ripple counter which internally has a series of T-flip flops. I pulled down the reset line of the counter to take it out of the equation, and then just drove the clock input from the output of the 555 timer. Now, every time the 555 emitted a pulse, the first flip-flop in the counter would change state, high or low. That flip-flop’s output was connected to the  2N7000 MOSFET through the mode-select switch. The rest of the functionality of the counter was not used, which seems like a waste until you learn that the cost of the chip, new, is 37 cents.

The general solution for connecting to the pins on the logic board is to use a DPDT switch. However, if a pin combination can be found such that one pin is in common for both F1 and a meta key, a cheaper SPST switch can be used — the common pin goes directly to the MOSFET, and the switch just selects which of the other pins connects to the other side of the MOSFET.

A few items were thrown into the design for good measure — decoupling capacitors on the ICs, as well as one across the switch leads. That latter capacitor was meant to shunt high-frequency RF from the switch line – but I don’t know if it actually helps. The capacitor on the reset line of the counter chip is not a decoupler – it’s job is to transiently go positive when the circuit is energized, putting the counter in a determinate state at power up. This assures that initially, if the device is put into toggle on/off mode, it will be off. (One corollary of this  logic is that if the device is later switched into toggle mode, it might be in the “on” state, since the counter will receive one-shots from the 555 every time the pedal is down, even when other modes are active).

Finally, I added a 56 ohm resistor between the logic board pins, since this would come closer to the real resistance of a keyboard. I have no idea if this is important or not, but resistors are cheap.

I felt good about this solution, so I transferred the circuit to vector board and stuck it in a cast aluminum case strong enough to survive the zombie apocalypse. To get it into a case, I made a sandwich, with the keyboard logic board on the bottom, some spacers, and the vector board on the top, with various screws to hold things in place. The most expensive part of the project was the $5 box (not counting the cost of the pedal itself, since it can be used for other purposes in addition to the QLF).

In developing version 2 of the project, I wanted to try a microprocessor solution to the same problem. The motivating factors (aside from, wouldn’t it be cool?) were:

1. To save on hardware costs. The electronics in version 1 were all cheap, but as often is the case, most of the cost came from the mechanical items — toggle switches and the case itself. A smaller case with cheaper switches would be preferable.
2. Flexibility – rather than “coding” everything in wiring, a microprocessor-based QLF could be “reprogrammed” to some extent by popping the chip, re-flashing it, and sticking it back in.
3. Lower part count – in principle, the core functions could all be done in one rather than two chips, without outboard resistors and capacitors to handle timing, trick the chips into triggering, etc.
4. Better user interface, in this case blinky lights and sound. Not absolutely necessary, but nice touches.

I started roughing out the design using an Arduino Duemilanove, but my intention was not to include this prototyping platform in a final product. After all, even an older Arduino costs above 20 dollars. The ATmega328 used on this board also seemed like overkill – much more memory and ports than needed, and in a 28pin package, larger than I would have liked.

Instead, I went with the ATTINY45, a chip that costs less than a dollar, and which can be programmed via the familiar Arduino IDE with minimal additional effort (described in the next post). The challenge in using the ATTINY chip was to achieve all the desired functionality using a chip with a limited number of pins devote to input/output.

The vision for the version 2 design was to have two push button switches, one for mode and one for character. Pressing the mode button would cycle through the three modes available: PTT, one-shot and toggle on/off. To keep track of this, we’d need some indicator, since switch position would no longer tell use what mode we are using. The character select would toggle between F1 and meta-character, and again, we’d need some indication of which character was active. As in the previous design, we would also need some way of reading and acting on the pedal switch state.

One frill I wanted in this design was an audio indicator for mode and character, since the QLF might not be visible from the operating position. The tone function is part of the standard Arduino library and it is easy to drive a piezo speaker using a single digital output.

The ATTINY series chips have 8-pin chips, and the models differ in amount of flash memory: ATTINY 25, 45, and 85, have 2k, 4k and 8k, respectively. Two chips are devoted to power (Vcc, GND), and one is used to reset the chip. Of the remaining, two pins are connected to a crystal to provide an external clock, leaving three pins. This is clearly not enough for everything described above. However, between the chip’s versatility and some design tricks, a solution was found.

First, the external crystal was dropped from the design. The ATTINY can use an internal RC oscillator for a time base. It is less precise, but nothing we’re doing here requires exquisite timing. Depending on how the chip’s fuses are set, the RC oscillator can generate a 1 Mhz or 8 Mhz clock. I opted for 8 Mhz, but 1 Mhz probably would work, and would take less power.

Refer to the version 2 schematic for the following discussion:

Next, the three switches (pedal, mode, character) were multiplexed onto one analog input. The switches connect in common to one side of a voltage divider, and each switch connects to ground through a resistor with a specific value. The values were chosen (see spreadsheet) such that even with maximum tolerated deviation of the two voltage divider resistors, the resulting voltages would fall into non-overlapping ranges as detected by the chip’s ADC (1023 values, from 0 to 5V).

For indicators, one digital output was devoted to a single LED for mode: off for PTT (default), on for single shot, and blinking for toggle on/off mode. Another digital output was devoted to which character was selected. A design decision was made to indicate F1 on one LED, and the meta-character on the other LED. This design used complementary transistors to assure that one of the two character LEDs was always lit. Another option that would have saved  a few parts would have been to use a single LED with it off state representing F1 and on state representing the meta-character. This seemed like more to remember, though, versus having the name of the character written next to the LED on the case.

Two 2N7000 MOSFETs are used in this design, one to switch on each pin pair on the keyboard logic board. A digital output from the microcontroller is directly connected to the gate of each MOSFET.

With this layout, the design was still a pin short — the one needed to drive the piezo element for sound. This was a workable design, but to get that last pin required special effort. I’ll describe how the ATTINY was programmed from the Arduino IDE, and how I freed up the RESET pin to use as an output in the next post because it does get a bit more hairy.

Sound is used in this design by beeping one, two or three times in a high tone to indicate mode, and once or twice in a lower tone to indicate which character is selected.

Here is some pseudocode for what’s going on inside the ATTINY:

The code that I actually wrote for the project can be found in a repository on Google Code.  If this code is loaded on a chip that has not been modified to use the RESET pin as audio out, the code runs normally, but of course there is no sound output. The code compiles into less than 4K, so it will fit on an ATTINY45. Without the sound-related routines, it would fit on an ATTINY25. Counterintuitively, when I went to buy chips for this project, ATTINY25 was more expensive than the 45, and the 45 was just a couple cents more than the 85.

The version 2 board was smaller than version 1 and fit in a smaller a marginally cheaper aluminum case. Overall, this is a less expensive approach, but not by too much (see spreadsheet). The main cost drivers are the mechanical components in the first design, but purchasing the items in bulk and/or from ebay brings the prices down considerably. The cost of assembly also depends on what is in the junque bin. In both designs, most of the components are very common, and there is considerable latitude for substituting other values.

I did attempt a third version — one that doesn’t require gutting an old keyboard, but this approach hasn’t really paid off at this point — except as an example of what not to do. I’ll write up that experience, but first, more details on programming the ATTINY45 (next post).

The contest ran from 10 am to 10 pm on Saturday and 8 am to 8 pm on Sunday. I spent Saturday with the Vienna Wireless Society, operating from the Annandale Swim Club. We got to the club at 9 am and it was probably unrealistic to think that we’d have antennas up, rigs configured, and N1MM networked by 10 am.

We had some technical difficulties — our spud gun line broke a few times, the reels jammed, and trees claimed a lot of line and a few spuds. At one point, while I was working on another antenna placement, I noticed the other antenna hanging team trying to get one of our fouled lines out of a tree using the tools at hand: a lifeguard chair and a pool net.

It took a couple hours to get the antennas deployed. With the contest starting at 10 am, we started operating from the parking lot. I popped the tarheel antenna on my car, tuned to 40 meters, and Kevin WB0POH began working stations. By the time we had the indoor stations set up and configured, he had worked fifty contacts, including the bonus station, K4NVA.  I think all his contacts were CW, so worth twice the points to boot.

I’m not sure why, but we were not able to get the two logging computers to talk to each other. We tied them both into the club’s router, which should have worked like a hub. Both computers received DHCP addresses, and as far as I could tell, could see each other on the network. Not wanting to waste any more time, I set up the voice station to start with an exchange number of 500, while the CW station continued to build on Kevin’s earlier contacts. I’m sure hearing our SSB exchanges in the 500 range early in the day put the fear of god into our more competitive neighboring clubs. Heh.

The CW station was set up in a different room from the SSB station, and we had a counter and some stools as operating space. After sitting for a while, I got rid of the stool and used the counter as a standing desk. It felt good to dance around while working CW, and I think I might try for this sort of set up in the future as it keeps the blood flowing. Ian, N0IMB, took some video of TS-450 I was using. Unfortunately, the video does not capture my dance moves.  You can’t  hear the dits and dahs on the video because I’m wearing headphones.

We broke down our field stations and took down the antennas on Saturday night. The next morning, I set the home station up again. I had brought a number of station items to the field, so I had a little rewiring to do before I could get on the air Sunday morning at around 11 am.  I worked intermittently until the end of the contest at 8pm that evening, but had a number of fairly large breaks to take care of family, do chores, etc. I entered as single-op, all bands, low power (100W), CW-only, non-assisted, one radio.

Propagation was so-so, and I kept hoping that after a break, it would improve. It wasn’t just my imagination: conditions were much better on Saturday. Looking at the space weather data, a CME thrown on Friday hit the ionosphere Sunday morning, just when I was starting operation. The K-index bumped up to five and stayed there the rest of the day. Conditions did seem to improve as the day went on, but this perception may also be a matter of more people joining the contest for the last few hours.

I spent almost all of my time on 40m, using the attic dipole rather than the outside 40m vertical that does better in DX contests. I had good coverage of New England earlier in the day, and worked westward into Wisconsin, Kentucky, and Arkansas. Operating NVIS, I had a reasonable chance of operating other VA stations, including VWS club member Kevin, WB0POH.

Twenty meters was not as helpful as I’d have liked — at one point, Europe opened somewhat, and I worked a succession of stations in Poland, Germany and  the Slovak Republic. Later in the day, I had a brief opening to the west coast: WA, OR, and CA. Otherwise, 20m was my direct line to Florida. I did reach two stations on ten meters, but probably ground wave.

In the last hour and a half, I did good business on 80m, where I mostly ran into stations that I had worked on other bands.

I was surprised in the contest how many times I was called by stations that I had already worked. As a matter of course, I worked them again.  Maybe conditions were marginal on some of those calls, and maybe they just wanted an insurance contact. I didn’t hear anyone else operating from Fairfax City (FXX) — at least not on CW — so maybe my exchange was in high demand.

My final tally was 166 contacts (some dupes), with a paltry 26 Virginia City/County, 23 State/Province, and 3 DX entities. If I calculated correctly, I may have nosed over 20,000 points. Not a great performance, but not too bad considering time and conditions.

As for the club log, I’ll have to more or less manually merge the databases from the two workstations that we used into one file for submission to the Sterling Club which runs the VAQP.

Before they came over, we thought about how people learn code, and figured that for their purposes, they could use traditional tools for learning morse code (like the LCWO site, MorseResource, and various programs for PC or smart phone), but they’d be best served by practicing with actual whistles.

This got the gears turning, and more out of curiosity than practicality, I decided to make an electronic whistle blower that could be driven by audio output from any of these practice tools. I had thought through a similar problem in developing the androidomatic keyer, although unlike the androidomatic keyer that was meant to operate without external power (other than the audio signal itself), for this project it was reasonable to use a nominally 12V power source since the contraption would require some kind of air compressor that would have similar power requirements.

The most exotic component in the keyer (aside from the whistle, which is also not typically found in my projects) is a normally closed 12V solenoid valve (Adafruit, #996). This is a brass valve, which is listed as a fluid-control valve, but seems to work just fine for air.  The valve has 1/2″ threads on each side, and I had no problem finding connectors for it at my local hardware store. Per a chart on the Adafruit website, the solenoid draws 3A at 12V. The website also recommends putting a 1N4001 snubber diode across the solenoid leads, so that’s just what I did.

The solenoid is driven by a vox circuit built around a 4558 (741c equivalent) op amp via a STP16NF06 N-channel power mosfet (incidentally, the same one that is used in the Texas Topper QRP amplifier). The top of the MOSFET sticks out of my box because I threw the whole thing together quickly the morning of the contest and didn’t want to bend the transistor down. Also, I wasn’t sure how much heat it would need to dissipate, so I gave it some breathing room.

Compressed air is provided by a 12V air mattress inflator — a glorified waffle fan. These are usually bundled with air mattresses or rafts, but I bought this one as a replacement at Walmart for about $12. The rest of the assembly is a matter of plumbing. I obtained some 1/2″ plastic connectors and modified one to fit onto the pump, and with some careful glue-gunning, embedded a whistle in the other. Originally, I inserted a T-joint and played around with improvised pressure relief valves and/or a balloon to serve as a capacitance vessel because I was worried that the abrupt shut off of flow would strain the compressor. I guess there is enough leakage in the pump itself that this is not a problem, though, because it works fine to simply connect the pump to the solenoid valve. The pump comes with instructions that it should not be used continuously for more than about 15 minutes without some cool-down period. That seemed fine for my application, which is deafening after a few minutes.

I had supposed that morse code sent by whistle would need to be slower than we’re used to hearing on the radio, but as you can see in the demo, the solenoid has no problem keying at a 20 words per minute. I assume that people could achieve a similar effect by tonguing the whistle like a recorder.

We had a good session with the scouts, and the TEAPOT was a hit, leading to a brief discussion of electronic projects, robotics and flame throwers. After our session on morse code, they  popped into the radio room, where the club had already started the NAQP contest, so they also got to see morse code being used to communicate.

So, I started looking at more efficient (and lighter) means of powering the unit. The design I selected allows for two options. First, two AA batteries will fit inside the unit. Building them into the case assures that I can’t forget them. One of the goals of the SO project is to avoid unpleasant surprises while setting up the station in some remote location.  Since the unit draws so little current, I’d hope that a pair of AA batteries would last quite a while in field use.

Since radios are made to work from 13.8V sources, this is the other acceptable power input. The unit will be built with dual powerpole connectors, so that even if the battery has a single powerpole, it can be plugged into the unit, which effectively replicates the plug, so the radio can also be plugged into the unit. Even if the radio is greedy and pulls power from the battery causing the voltage to sag, the power regulator should cope with anything down to about 7.5V. If the lead acid battery gets that low, it’s probably toast anyhow.

Getting 5V from a 3V source requires a switching power supply, which could be a problem for a radio project since the switching happens at frequencies in the hundreds of kilohertz range. The LT1302-5 chip that I used in this project does not oscillate at a specific frequency, but is variable, and has the potential to produce RFI over a broad range of frequencies.

I followed the datasheet for the 1302 and built a “typical” supply using available parts. Layout is fairly critical, and I did my best to port their suggested PC board layout to manhattan construction. I didn’t have a 20k resistor, so I went with a 22k. I didn’t have any particularly low ESR electrolytics, so I used ones regular ones, etc. It seemed to work anyhow.

For testing purposes, I ran the power supply with a small load next to my FT-187nd, which was connected to a dummy load with cable that was unshielded for several centimeters. Within the ham bands, the only places I heard hash were on 160m and 80m, and even there, it only seemed to be around a couple frequencies. I had originally built the supply with a 10uH commercial inductor wound on a solid core. To limit EMI, I tried replacing this with an equivalent value hand-wound toroid (45 turns of 28Ga on a T50-2). This brought the noise level way down, and I couldn’t hear it when the antenna run was a couple cm away from the toroid. I suppose I could put the power supply in its own metal compartment, but it’s probably enough to just keep the RF path away from it in the layout.

Getting the right combination of bypass and charge-holding capacitors and discharge resistors is a bit empiric, and I’m not sure I did an optimal job, but I got out the voltage that I wanted. When connected to the oscilloscope, I noticed a periodic ~50mV spike that I thought could be a problem down the line for the microprocessor, so I borrowed a low pass filter from a similar project, the power supply in the Norcal 2030. I again had to substitute a bit — I think the filter inductors came out of an old TV. With that filter in place, the voltage is completely smooth as far as I can measure.

The two power supplies are connected by wire “OR”ing them together. The LT1302 senses 5V distal to a Schottky diode, but putting a diode after the higher power supply means that the voltage prior to its diode must be about 5.3 volts. To get that value, I used an LM317 and selected specific resistor values for its feedback network. The LM317 needs a small load to stabilize, so for the prototype, I threw in an indicator LED that lets me know when the high voltage supply is in use.

When the high power supply is active, it pulls up the LT1302 shutdown pin, which turns off the up-conversion. Without all that switching action, the voltage on the toroid side of the diode should be that of the AA batteries. This means that with the higher power supply active, the diode in the lower power supply is reverse biased and no current flows through it. This should mean that the unit can hot-switch between onboard and external power.

The prototype was a little smooshed because I had originally intended to only build the LT1302 circuit on that piece of copper clad board, and then I added the filter, and finally the 13.8V supply.

The real test of this supply will be whether it makes the other components happy.