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  I can’t imagine putting all those features into this project, but I think I’ll learn a lot from reading through the code.