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.

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.