QLF (version 1 and 2)

Monty_python_footOne of the limiting factors in making optimal use of a radio is the number of human appendages that interact meaningfully with the radio, hence the importance of a big knob on the front of the radio and hands to turn it. Morse code operators have known this since the dawn of time and have a Q-signal dedicated to the use of the left foot to send messages: QLF. This versatile expression is more often used in the interrogative, i.e., “QLF?”, or “Are you sending with your left foot?”

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.

teamspeak1And 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.

n1mmAnother 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.

footswitch_LRGBefore 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.

3pt5mmThe 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.

upperlowerIf 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.

logicboardsI 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.

keymatrixHowever, 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
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.

74hc4024I 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).

v1guts

v1box

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.

guzintas2The 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.

attinypinpout

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:

qlf2_mono

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:

pseudocode

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.

version2_exploded

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.

version2_in_box

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).

 

Postscript 1: In retrospect, an obvious source for the flipflop in the QLF version one would have been another 555 module. One 556 could serve both purposes. This is the sort of thing I think of after the project…

Postscript 2: With USB integrated into more modern arduino and work-alike boards and the boards becoming so cheap, the project could be done in software only, without having to dumpster dive an old keyboard control board. But where would be fun be in that?

VAQP 2013

VAQP 2013 didn’t go quite the way I’d imagined it would, but it was still fun. Getting N1MM set up the night before the event, I was surprised to see fields for an exchange number. I’m pretty sure this was a new feature, and I’m not sure how popular it will be with people who prefer more casual operation in state QSO parties.

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.

fishing for an antenna lineWe 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.

Significant Other: Firmware

It occurs to me that I’ll likely be writing about the Significant Other project for a while, so it now gets its own category on the blog. I’ll go back and fix the tagging on older posts to be consistent.

The main board and relay board prototypes are in a final enough state that I can begin to work on firmware. Rather than start from scratch, particularly as I don’t have a lot of experience with this type of project, I decided to look at similar projects with open source code for both ideas and potentially as a scaffold for this project’s firmware.

I have come across the K3NG cw keyer, which is as full-featured a keyer as you could ever want, and which is written in such a modular and generalizable way that it can be made to fit on a variety of chips, depending on their resources and which features are included in the build. The package also includes a serial interface, command-line mode, and debugging features that should make the development process as painless as it can be.

I hadn’t seen this project while I was planning the main board, but the hardware layout envisioned in the K3NG keyer was very similar to what I had come up with, so it took minimal work to get it running on my main board.

The K3NG code lives in a sourceforge repository, and one of my first concerns was how to manage the code base. Considering that the S.O. is a specific design (and perhaps one that only I will ever care about), it seemed reasonable to take the most recent version and start a separate repository — I guess this could be considered a fork. To keep things organized, I’ve deposited that code, some test programs for individual subsystems, and the schematic on GoogleCode.  As with other projects, I’ll update the repository whenever I’m working on any of these files.

I spent a few days reading and pondering the K3NG keyer code to get the gestalt. It is very well organized, and every feature can be enabled/disabled through compiler directives.  It may be poor programming practice, but I decided to thin out the code to make it easier to work with. I realize that having features commented out so that they are never compiled has the same effect in terms of final size of the compiled code that will be programmed onto the chip, but I felt that I needed to remove sections that are not part of the intended application for the S.O., particularly since I’ll be adding other features.

Consequently, with some reluctance, I performed some surgery, removing fun stuff like code practice, CW receive decoding, and the extensive winkey emulation functions. In developing this device, the code will become less general. For example,  instead of an expandable number of buttons, the S.O. front panel will have four. All feature selection will take place through these buttons and the LCD display, rather than via the paddles. This is consistent with the design goal of not being able to leave behind anything when heading into the field to operate — if you forget the paddles, you should still be able to have QSOs. To that end, the front panel buttons have been modified so it is possible to press two of them at a time — in a pinch, the front panel buttons themselves will be able to serve as a straight key or iambic paddles.

For all I took out, the core keyer functions still take a good deal of space. I’ll have to see what the trade offs are in implementing a menu-driven interface and then in adding the clock, frequency counter, and antenna tuner functionality. Fitting it all in will take some doing — I hope it is possible. I’m sure that during development,  I’ll have to turn off some features to test others if I want to make use of the serial interface and debugging features.

TEAPOT: The electronically actuated pneumatically operated transmitter

the electronically actuated pneumatically operated transmitterA couple days ago, before the NAQP-CW, Pete K6BFA mentioned that before the start of the contest, some Boy Scouts would come over to the club station to talk about learning morse code. This wasn’t about working towards a radio or electronics merit badge: they wanted to learn the code for team competitions in which they are required to send messages to each other in the field using whistles.

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.

Significant Other Update: Logic Board

For a few months, I’ve been playing working on a design for a QRP accessory as a way of becoming familiar with both the arduino platform and homebrewing technique. The basic idea was to put everything except a transceiver in one box, so I couldn’t leave anything behind when operating in the field. I wrote up a design overview when I started, and it is more or less up to date. The schematic isn’t necessarily finalized, but I’ve also posted the most recent version.

The first item I built was a relay board, with latching relays to route the signal through a bank of capacitors and inductors arranged in an L-network, configurable on the fly for low or high-Z. The prototype built on vector board  has nice blinky lights to help me visualize how the relays are switching. I’ve also built a power module and RF module (which senses SWR and reads frequency) on copper clad board.

Over the  New Year’s holiday break, I laid out the logic board, which contains the microprocessor (an ATmega368), a real time clock, LCD display, a piezo buzzer, some buttons, and connectors for paddle input and keyer output. The logic board also sports a USB interface to make my life simpler — I don’t think that will show up in the “final” version, which I envision being laid out as two PCBs: one for control, one for relays.  In the prototype, the two boards are joined by a ten-conductor ribbon cable (with RF connections through shielded cable, not added yet).

The two blank areas on the logic board are where the power module and RF module will be pasted in this prototype. For now, I’m leaving them off and concentrating on the programming aspect of the project. I’ve got some ideas about the global operation of the device and its menu structure, but before I really start any detailed coding, I’d like to look through a few similar projects. An obvious place to start is the full-featured CW keyer described by K3NG at http://radioartisan.wordpress.com/.  I can’t imagine putting all those features into this project, but I think I’ll learn a lot from reading through the code.

Significant Other Power Supply

Initially, I hadn’t given the power supply for the Significant Other project too much thought: I was more focused on the microcontroller, relays, and so on. After going for maximum efficiency with these components, though, it began to annoy me that it would be very wasteful to use an LM7805 regulator to bring lead acid battery voltage (13.8V) down to something that all the chips and relays could use (5V). The LM7805 tosses out the difference in heat, and while at the low currents that I need that doesn’t amount to much power — certainly, not enough to require heat sinks — it goes against the grain of QRP. If you have to haul a battery up a mountain, you’d like it to last as long as it can.

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.

Sky House: Arrival

view south towards the Pacific oceanThe Nerkspedition to Sky House is underway. We arrived in LA a couple days ago and drove up the 101 to around San Luis Obispo yesterday. The final road to Sky House is a long, winding dirt road that hairpins its way up a mountain to a fabulous house that overlooks neighboring mountains, Morro Bay, and the Pacific Ocean. Most of the first day was spent getting everyone unpacked and settled.

Earlier today, I set up the FT817 for local repeaters in San Luis Obispo and Los Osos. No problem hitting them with full quieting from the top of the mountain, but not a lot of activity on them.

Even though this is the IARU World Championship weekend, I didn’t bother setting up for HF today given the solar activity: strong wake from a CME and an intensely south vectoring magnetic field. By report, the bands were pretty dead earlier except for sporadic E on 6m later in the day.

I’m hoping tomorrow will be better, so I tossed the 40m half wave dipole antenna into the trees at the top of the mountain. The wire comes down near a comfy chair next to the pool, and if conditions are better on Monday or Tuesday, I’ll give HF a try.

slt plus board with a missing L1 toroidImmediately before leaving for California, I noticed that both my winkeyer and SLT+ antenna tuner had developed rattles. I have to assume that this happened during my last flight back, which had involved a bumpy segment on a regional jet from Reno to LAX. Either that, or the TSA got more curious than usual and looked inside them. The winkeyer was missing a screw and the rest of the screws were loose, but there was no internal damage. For the SLT+, however, L1 had fallen off the pc board. I rewound the toroid and soldered it in while I was packing my bags for this trip and as an extra measure tacked all the coils down with hot glue.

Field Day CW Totals

We’re still assembling the total number of contacts from FD 2012 because the SSB and CW stations were not networked, but here are the totals for the two CW stations. I’d say we hit our goals and then some.

 

The 80/20/10 station

Mhz Contacts
3.5 279
7 304
21 15
Total 599

The 40/15 station

Mhz Contacts
7 430
21 115
28 4
50 1
Total 550

So, our CW total for the event was 1159 contacts. The results from the SSB, VHF/satellite, and GOTA stations and all bonus points should be out soon.

RAC Canada Day 2012

While the emphasis is on working stations in Canada (10 points), other stations do count (2 points), and this year there was more of an “everyone works everyone” flavor to the event. I worked stations from BC to the maritimes, but also a few French, one Netherlands, and one Romanian station. I heard a Brazilian station calling, but he couldn’t hear me.

In addition to working this contest for fun, it was also a test that the outside vertical had survived the storm. Right after the storm, the antenna had more slack in it than usual because the counter weight was resting on the ground. Apparently, a few branches that the antenna had once draped over are no more. I tightened up the support rope and the vertical seems no worse for the wear.

Field Day 2012

Ray, K2HYD at the operating position of the 80/20/10 tent. Hap, K7HAP is at the second position on the laptop, and Byron, W4SSY, supervises

To make everyone’s life easier, we stuck mostly to the plan developed for last year’s event, although I made some effort to simplify the set up where possible. This year, the main rig was a TenTec Omni VII, a radio with clearly marked controls and big tuning knob. Most people could sit down at this rig and be on the air in a matter of minutes without reference to reading material, nifty or otherwise. Instead of three antennas, we went with two: a moxon for westward gain on 20 meters, and a G5RV for all band coverage. The Omni had no difficulty tuning the G5RV for any band that we tried (10, 15, 20, 40, 80).

One major difference from last year is that we did not shut down in the wee morning hours. Both of the CW stations pounded brass for the entire 24 hour period of the contest. We had more operators than the previous year and divided the shifts carefully to assure that at least one person would be at the key all the time. It also helped that several of us brought our own tents this year for quick cat naps. We were all a bit punchy by Sunday morning, but after several cups of coffee, we powered through the rest of the event.

The CW tent is near a busy intersection and more accessible to other parts of the park, so we had a number of visitors drop by the 80/20 tent.  Some of these visitors turned out to be hams eager to put their hands on the paddles, and a few of them racked up an impressive list of contacts and we made sure to invite them back for next year. The more operators we have, the more pleasant staffing becomes. We might even be able to put someone on VHF CW for part of field day next year.

The 20 meter moxon (left) and G5RV (right) supported by a 40 foot military push-up mast, guyed at 3 levels.

Our computer wasn’t fully networked in at the start of the contest, so I don’t know how all the stations did. I have fuzzy recollection that we had around three hundred contacts on 20m and another 300 or so on 80m. We also worked on 15m for a while on Saturday evening, when the 40/15 station had gone to 40m and our 20m operation had been interfering with the SSB 20m station. I’m eager to see the final numbers after all the logs are merged.

One item to consider for next year — is it time to bring an SDR radio to field day? Would a graphic view of the whole band give us an advantage? Would a Flex radio (or other similar radio) play well with the other radios? I like the feel of a big tuning knob and I am used to zipping up and down the band by ear, but that’s all a matter of habit, and if there is better technology, we should consider it. Maybe it would be worth a test drive at some other event before field day 2013.