For the QLF project, I had to get my code onto an ATTINY 45, which wasn’t so difficult, but also to free up the RESET pin to act as a digital output, which a bit more doing.
My experience with microcontrollers, aside from some PIC activity a decade ago, has been confined to the Arduino, a prototyping platform that hides some of the complexity of creating projects built around some popular Atmel microcontrollers. There are many tools for developing code, transferring code to these chips, and setting the fuse options on these chips, but all I had on hand was my trusty Arduino, so I used it as a middleman to program the ATTINY 45. There are plenty of other options available to get the compiled code (a hex file) into the flash memory of the chip, for example, the USBtiny or the tiny AVR, or the over-the-top Atmel STK600 programmers.
While the ATTINY45’s were on order, I worked out the code using the Arduino itself – this is, after all, its job in life: to serve as a rapid prototyping platform. The circuit was laid out on a solderless prototyping board and jumped over to the Arduino for testing. I realized that I’d need to change some of the pins later, but otherwise the code within the Arduino IDE is the same, whether developing for the ATmega328 on my Arduino Duemilanove or for the ATTINY. There may be differences in the way the code compiles for the different chips, but all that is abstracted away.
With all of the code working when tethered for life support to the Arduino, I needed to migrate it over to ATTINY 45. I found instructions on how to use the Arduino as an in-system programmer (ISP) and how to connect it to the ATTINY on the High-Low Tech website. Their procedure worked for, using my Duemilanove board and version 1.0.1 of the Arduino environment. However, I have a couple comments on their recommended procedure — I didn’t see a place on their website to provide feedback, but it is possible that they’ll have corrected these items in the future:
1. The general idea of connecting the “ISP header” from the Arduino over to a target can be used to program a number of chips, including the ATTINY. The idea is to connect power, ground, MISO, MOSI, SCK, and RESET from one chip to the other. MOSI goes to MOSI, MISO goes to MISO (rather than crossed wiring). The picture shown on the instruction page is correct, but the pin numbering for the ATTINY described below the picture isn’t. It should read:
ATtiny Pin 7 to Arduino digital output 13, physical pin 19 (or SCK of another programmer.
ATtiny Pin 6 to Arduino digital output 12, physical pin 18 (or MISO of another programmer)
ATtiny Pin 5 to Arduino digital output 11, physical pin 17 (or MOSI of another programmer)
ATtiny Reset Pin (1) to Arduino digital output 16, physical pin 16 (or RESET of another programmer)
2. That tutorial recommends installing ATTINY-specific definition files into the Arduino IDE, and points towards a file found on github, https://github.com/damellis/attiny/. This file provides a mapping of the pins on the ATTINYx5. A number of basic arduino functions like the ability read and write to pins will work on the ATTINY, but not the tone() function. Instead of using installing the file from github, I found another core on Google Code, arduino-tiny. This provides not just a pin definition, but a number of libraries like serial, wire, and the tone function that I needed.
3. The 10uF capacitor shown in the picture will not be needed for all versions of arduino; having it probably doesn’t hurt anything, though.
So, to reiterate the main points of that tutorial, the major steps are:
Write code for the ATTINY. Make sure it compiles. Save it.
Close the arduino IDE, add the core definition files to the hardware subdirectory, relaunch the IDE.
Upload the “Arduino as ISP” sketch to the Arduino. This comes with the Arduino distribution.
Connect the Arduino to the ATTINY — six wires.
Select the ATTINY from the “Boards” menu.
Select “Arduino as ISP” from the “Programmer” menu. No change to the serial port settings, please.
By default, without an external clock, the ATTINY will run at 1 Mhz. To get it run faster, make sure that 8Mhz is selected in the board menu, and choose the “burn bootloader” option. It doesn’t really burn a bootloader, but it does set the fuses appropriately in the ATTINY. This operation also wipes out the flash memory in the ATTINY.
Load ATTINY code that you want transferred.
Hit “upload”. The code should transit the Arduino and end up in the ATTINY.
If you want to modify the code, no problem – just edit and upload again.
Physical pin 1 of the ATTINY is typically used for RESET, but to use it for I/O, bit 7 of the high fuse (RSTDISBL) has to be set. Once this happens, the chip cannot be reprogrammed by the ISP method described above — it essentially becomes read-only, unless the chip is restored using a high-voltage programmer – an item that I don’t have on hand (although one can be made with some common parts thanks to various plans online plans). Once I was sure that the program behaved as desired, I looked for a way to manually set the fuses (short of using avrdude from the command line — I’m not quite there).
I came across a program called “hexloader” that can both upload hex files and set fuses without requiring anything beyond an Arduino in terms of equipment. Unless you modify the hexloader sketch, by default it uses other pins to connect to the ATTINY. Arduino digital pins 4, 5, 6, and 7 connect to ATTINY physical pins 7, 1, 6, and 5, respectively. Refer to the picture on the gammon.co.au website.
To change the fuse settings on the ATTINY, open the serial monitor and make sure that the line termination character is set to “newline”. Also, make sure that the serial speed matches up with the hexloader program. A menu will display in the serial monitor; choose “F” to access fuses. The low, high and extended fuse settings were 0x62, 0xDF, and 0xFF.
Adding a high bit in the 7th position to the high fuse, the desired high fuse setting is 0x5F. You could also consult an online fuse setting calculator to see what options are available.
Follow the menu settings to commit this change to the fuses. Once this is done, the hex loader program reports that it can no longer enter “program mode” — which makes sense, since the chip is no longer programmable.
One 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.
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:
The QLF should allow direct control by making or breaking a connection for physical switching, i.e., for microphone PTT.
The QLF should send “keyboard” characters — at least two of them: F1 and a meta character
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)
The QLF should provide adequate feedback for the user to know which mode and character are selected
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.
The QLF should be relatively RF resistant
The QLF should not require its own batteries and shouldn’t consume much power
The QLF should be smaller than the rig it operates
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:
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.
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.
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.
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).
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?
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.
A 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.
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.
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.
Conjunction of Venus and Jupiter above the Grande Place
I had a couple hours on Friday to do a little shopping before meeting up with friends for dinner in Brussels. We had planned to eat near St. Catherine’s, so I took the metro there a bit early. My first goal was Elak’s electronics, which is one of the best hobby electronics stores on the planet, as far as I’m concerned. Part of the store is given over to computer components, but the rest of the store is discrete components: walls of switches, transformers, project boxes, batteries, etc. There is a center counter area where they maintain an impressive assortment of ICs as well. They carry the entire velleman kit line, plus related accessories.
The only drawback to the store is that it is in a corner of Brussels where the streets do not conform to any sort of rectilinear plan. I always get lost trying to find the store, and having a Google map in hand only makes things worse. It is like that part of Brussels does not obey the normal rules of time and space. Sometimes I try to get to it from the De Brokère metro, sometimes from Ste. Cathérine’s, but no matter what, I end up getting spun around and asking directions. When I get there and think about the path I took it all makes sense, but as soon as I leave, the store randomly pops up in some other universe.
At least I can recognize the outside of the store when I do find it: the wall next to it has a mural with an elephant and a gorilla. The other place that has a reasonable selection of more common components is MB Tronics. When I last visited them, they had a storefront on Chausée de Louvain not far from the Meiser traffic circle, but I believe they’ve moved the store in the last year a couple blocks to the east. MB’s store hours are not quite as fixed as Elak’s, and the store does shut down during part of the summer for vacation, so Elak’s is always a safer bet.
I ended up buying a set of machine screws and a package of assorted ceramic disc capacitors. I’ve bought this screw set before, and had used them up making various projects. The screws are just the right size for most small projects, particularly the kind that you build in an altoids tin. The capacitor assortment is much better than you can find at Radio Shack. The Radio Shack bag-o-capacitors is full of unhelpfully small value components, whereas the Velleman-brand assortment has a full range (in searching the web, I note that they are also sold by Fry’s Electronics stateside). I am sure that these caps are not top-of-the-line low variance components, but they are great for prototyping.
On the way back to the restaurant, I stopped by a game shop, Wonderland, that is only a few minute walk from Elak’s. This store sells primarily French language versions of “Euro” table top games: Settlers of Catan, Dominion, Carcassonne, etc. I don’t think that I saw any Z-man or Rio Grande games, but that’s not a criticism as the store wouldn’t have had room for them. The games were predominantly board rather than card, and I wish I had had more time to look through their inventory. Next time I visit the store, I’ll make sure I have more time, and I will also be sure to have more room in my suitcase. They get extra credit for having zombie dice on the counter. While I’m certainly loyal to my local supplier (Area 42 Games), Wonderland may carry some games that haven’t made it over the Atlantic yet.
At the end of February, the Vienna Wireless Society held its annual hamfest, Winterfest, and this partially accounts for my absence of blog entries in recent months, as I was coordinator for the event. We had more than 100 vendors in our indoor area, another 40 in our tailgating space, and about 700 people were attracted to the event. I could go on at length about the event, and maybe I will at some point, but for now I’d like to post about the items that I picked up at the event. I’ve mentioned my acquisitions to a couple friends and want to show some pictures.
As soon as the event opened, my eyes landed on a Heathkit SA-2040 Tuner. I have an LDG AT100Pro automatic tuner and it does a great job, but for the Collins gear, I wanted a fully manual tuner. The automatic tuner makes excursions in and out of good match, and I just don’t want to subject the finals of the S-line equipment to variable and out-of-range vSWRs. I’d rather map out the setting for the band segments that I use and then manually adjust.
I had, in fact, been looking for a few months at several models of manual antenna tuner on ebay, eham, and the other usual places. The SA-2040 was high on my list. Typically they run over $100, plus shipping. When I found one at Winterfest, I was happy to see that it was less than $100, in good shape, and already had the modifications that I was considering — a knob with a thumb wheel on the roller inductor, a switch to select multiple coax outputs, and a switch that takes the input to ground. I had a lot of administrative work to do at Winterfest, so I bought it as soon as the event opened and stuck it in my car for the day.
When I got home, I took a look inside it. Truthfully, when I got home, I crashed on the couch for the day and didn’t get around to looking inside the tuner for a few days, but either way, I did look inside, and saw that it’s in fine shape. The roller inductor and capacitors are heavy duty and in pristine condition, with no evidence of arcing. The modifications look solid, and I couldn’t spot anything troubling. I screwed it back together and then started trying to figure out how I could possibly fit it on my bench.
The SA-2040 does not have an SWR meter, so I needed one. Luckily, I had ordered one several months ago from Ten-Tec as a kit: the 1225 SWR/Wattmeter. I had a good experience putting together the model 1320 QRP transceiver from Ten-Tec, and it has held up well as I’ve lugged it all over the world making contacts. The SWR kit was also a first-class affair — packed well, parts grouped meaningfully in several bags, all parts present with appropriate excess on wire, and a great manual. The wattmeter consists of a metal cabinet, a large cross-needle display, a range switch, and the option of average or peak-reading for both forward and reverse power.
The organization of the manual was excellent, with the usual check it and then check it again double column for checking off completed steps. There was no ambiguity in the instructions, all the landmarks were obvious, and I didn’t need to do any sort of clever interpretation or fall back on the internet to find exceptions, modifications, etc.
Calibration requires no equipment beyond a digital VOM. One trimmer pot controls internal reference voltage, and other pots are used to set the forward/reverse fudge factors for each power range. Having built the WM-2 QRP watt meter, I’d say that this one was slightly easier to calibrate. This SWR meter was a more complex build with more parts and more mechanical connections, but that is commensurate with its additional features (and I’m certainly keeping the WM-2 as well).
So, the 1225 Wattmeter was assembled over the last week and is now inserted inline between whatever rig I’m using (the first coax switch) and whatever antenna is selected (second coax switch). One fun feature of the 1225 is the RGB backlight, which can be adjusted to any color with trimmer pots. I’ve set mine to a dark blue.
The other item I bought was not radio equipment. Near the end of the hamfest, I walked by a table and saw a TRS80-Model 100 “laptop” computer. I’ve always thought this computer was way ahead of its time, and that it represented an important milestone in engineering, so when I saw one marked down to $50, I bought it.
This computer is powered either by wall wart or four AA batteries, has a full keyboard, boots instantly, and has a number of I/O ports including an RS-232 and the venerable S100 bus. I verified that this one is fully operational. I’m not sure exactly what I’ll do with it, but I think it was a good purchase.
A couple months ago, Ben, NN9S, suggested developing a morse code keyer that would run on android devices (see his write up and video). Since then, we’ve been designing hardware and software to get the job done. The software lives in a repository on the Google Code site, and is moderately functional, but far short of ready for general release. On the hardware side, we’re still batting around ideas. Here is a brief history of the ground we’ve covered with regard to hardware design, and some idea of what’s coming next.
We considered all sorts of options such as having the device’s left and right channels run into a standard keyer, using the USB port directly, and some other more exotic alternatives (bluetooth anyone?), but we eventually settled on the idea of having the android device output a sound, which could be used directly to modulate a signal, or could drive a switch of some sort. The simplest configuration would be the device plugged into the androidomatic keying adapter (AKA), and the AKA plugged into the radio’s key jack. Presumably, most people would want to be able to also key their rig using a straight key, paddle, or bug, so we assumed that the AKA and some other sending device would connect to the key jack via a Y adapter of some sort.
Android devices encompass a gamut of hardware platforms including phones, pads, netbooks, and dishwashers. Well, soon. At home, my only android devices were a Nexus S phone and an Optimus T phone, so that’s where I started in terms of characterizing the platform. Two essential tools were the android app “FuncGen” and the multiplatform audio editor “Audacity“. FuncGen runs on the android device and can generate various waveforms with all sorts of parameters, whereas Audacity test files (e.g., *.wav files) can be generated on a desktop computer and transferred to the android device for playback using apps like media player or winamp. The phone’s output can also be recorded via Audacity to analyze fine timing events (for those of us without fancier equipment).
Using FuncGen at full media volume to generate a 1000hz sine wave, the Nexus S put out about 1.85V peak-to-peak (654 mVrms) into a 20-100k load, and the Optimus T put out 1.9V peak-to-peak (671 mVrms). The output impedance of the Nexus S was about 14 ohms, and the Optimus T was near 17 ohms. I calculated the maximum power transfer at around 7.9mW per channel for the Nexus S, and 6.4 mW for the Optimus T.
Output voltage at maximum volume into a fixed (20k) load was flat for the Nexus S from 20Hz to 3000 Hz, with only slight attenuation (down less than half a decibel) at 10kHz, and down almost 2 dB at 20kHz. The Optimus was more sensitive to frequency and was ideally flat from 300-3000 kHz, with more marked attenuation at 10kHz (less than 1 dB) and 20 kHz (down almost 5 dB). Both phones demonstrated a log-linear relationship between the number of clicks on the media volume scrollbar and the rms voltage output (e.g., for the Nexus, if full volume was 707 mV, one detent down was 477 mV, the next was 317 mV, 224, 150, 100, 70, etc.) — meaning that the voltage drops off fairly quickly to relatively low levels.
The first hardware design considered was literally a VOX keyer circuit. A quick websearch turned up a nice design by N1HFX. This straightforward circuit is based on a 1458 op amp, which is essentially two 741C op op amps in one package. The circuit was meant to work from very low voltages generated by a microphone, so the first op amp acts as an inverting amplifier, and the second as a comparator. The 741C op amp is a dual voltage op amp, so to run this from a battery, the positive input of the first amplifier is raised to half Vcc by a voltage divider; likewise, the set point for the negative input is a bit above half Vcc. The output from the second amplifier will be a square wave at the same frequency as the input wave, and ranging from about 1V to (Vcc-1V). Since this drive would only be half-duty cycle, some smoothing is necessary before driving a transistor. A simple RC circuit sets the degree of smoothing, and a diode prevents back-discharge of the capacitor into the amplifier. Since the circuit was designed for voice, the RC values were chosen for a relatively long time constant; however for purposes of keying a rig for fast CW or even Hellscreiber transmission, a low time constant is preferable.
Based on the N1HFX design, we prototyped a similar circuit, with the following exceptions – for cost/availability, we used an RC 4558 op amp, which is a workalike to the 1458. Because the phone’s volume is adjustable, and the output is relatively high, we used a fixed resistance ratio for the comparator set point. The smaller RC values used were just large enough to smoothen output wave. We added some bells and whistles including a power indicator LED, and another LED to indicate when the keying circuit was closed. It was probably overkill, but to further protect the phone, we stuck an optoisolator between the rig and the rest of the circuitry. In retrospect, all of these LEDs are nice looking, but consume many orders of magnitude more power than the keying circuit itself, and they might as well be omitted — in our final designs, we just key the rig from the switching transistor.
Another design that we considered was based on a circuit described by Robots Everywhere in their implementation of an earphone jack-based serial port on android devices. Their write up made us wonder if android phones could put out digital levels through the ear phone port — boy, that would certainly make our job easy. As it turns out, some can and some cannot. The Nexus S can sustain a very flat positive or negative voltage without breaking a sweat: at 20Hz, the output waveform is very square, at 1000Hz, there is some ringing. The Optimus T, however, looks like it’s output is capacitively coupled. At low frequencies, it’s not very square at all — the output capacitor bleeds voltage until the next half cycle. The take home is that around 1000Hz and above, both phones can generate some semblance of a square wave.
The Robots Everywhere design centered on an LM324 single voltage source quad op amp, but used only two of the four op amp subunits. Our next design was aimed at getting away from timing issues related to signal rectification and need for a “filler” capacitor prior to the switching transistor.
Since the phone can generate a stereo output, our next circuit used the left and right channel to generate square waves180 degrees out of phase — effectively get a halfwave rectifier for free by doing it in the software. These waveforms were fed into op amps like in the first design, with amplification occurring in the first stage and inversion in the second stage for each channel. When the positive portions of two channels are then brought together through diodes, the result is just about a flat positive voltage, about about 1V under Vcc (due to the diode drop). This voltage is applied to the gate of a 2N7000 enhancement mode N-channel FET, which has a threshold voltage of just under 3V. The gate capacitance itself further smooths the small defect at the edges of the two square waves. The 2N7000 could be directly connected to the rig, but we again used an optoisolator, since the design required the use of a battery anyhow.
Both the dual and quad op amp designs resulted in some prolongation of tone sent out the phone’s earphone port. The best we got with the dual was about 4-5ms, and the quad op amp design yielded around 3ms extra duration. We could compensate in software, ending the signal earlier, but it would be preferable to avoid that complication. For morse code, this extra delay would probably be unremarkable, as a single code element at 30 wpm is 40 milliseconds, so +/- 10% is probably tolerable. At fast code, it becomes significant, though — at 60 wpm, a single element is 20 milliseconds. Since we had plans to implement Hellscreiber keying as well, with a minimal on-time of 8.163 milliseconds, this delay was not acceptable.
In addition to the timing issue, we realized that it would be preferable to not require a power source for the adapter. Luckily, one solution address both problems — using a transformer to step up the voltage enough to directly bias a switching transistor. This approach was inspired by the interesting work done by the “HiJack” team exploring power harvesting from the iPhone’s earphone port. They designed a miniature power supply using the AC from the iPhone’s audio output as driving voltage. A similar approach was taken by Wolphi, in connecting the iPhone to microphone input for his excellent PSK31 appplication for android. His circuit was, in turn, based on a circuit proposed by KH6TY. Similar solutions have also occurred to hams in the past developing interfaces for sound-based keying of Hellscreiber, including a design by K9JRI that includes a voltage doubler.
In considering transformers for stepping up voltage, we did try the nearly microscopic one employed by the HiJack team. Unfortunately, it was too far off in terms of impedance matching to function well. We ended up going for the most accessible transformer, a 8:1000 ohm audio transformer from Radio Shack. This transformer gives about an 11-fold voltage step-up, so some losses in rectification are tolerable. In principle, germanium diodes or even synchronous rectification could reduce these losses, but there is enough head room to not worry about it. The currents involves are minuscule, so there is no problem is using tiny (read: cheap and available) signal diodes like a 1n914. A 0.01 uF capacitor does not entirely smooth the wave, but it ensures that the voltage is never below about five volts, and the 2n2222a transistor remains saturated when the transformer is energized. The additional duration introduced by this circuit is around 300 microseconds. I tried adding a voltage doubler per the K9JRI circuit mentioned above; the voltage was marginally increased and the duration increased slightly as well to around 1 millisecond. Since the extra complexity did not add much, I’ve opted to stick to the simpler design, which can be built from easily obtained parts for less than ten dollars (much less, if you mail order and/or buy in bulk).
The transformer-based designs have the benefit of providing galvanic isolation between the android device and the the keying circuit and rig. One downside to transformer-based designs is that they need relatively high volume output from the phone. The design above required that media volume be set within three clicks of maximum on the Nexus S. The dual op amp design worked down to 9 clicks below max, and the quad op amp design worked down to 12 clicks below max. Both devices tested put out about the same voltage and power, and hopefully most android devices are in the same ballpark, but if there were a particularly underpowered device, or if this circuit was used in some other context where lower output were available, a design with active components might be necessary. The other drawback to
We are now trying to figure out ways to miniaturize the design, and of course, the most limiting factor is the transformer. If anyone spots a suitable transformer let me know. I guess the idea one would be 16 ohm on the primary, and 2000 on the secondary (or 4000 on the secondary, with a center tap — allowing us to get rid of two diodes).
[Update 17 May 2016]
The androidomatic keyer has not had a lot of love lately; Ben and I have been busy with other projects and developing for android requires more sustained attention than we can afford for now. However, I’d still like to see this work preserved. When the GoogleCode repository blinked out of existence, I moved the software archive over to github, where it now resides: https://github.com/dhakajack/androidomatic-keyer
For several years, I have been putting together a Collins S-line station, and earlier this week, I fired it up for the first time. This station was the top of the line, when it was produced in the 1960s, and although there have been plenty of technical innovations along the lines of improved frequency stability, image rejection and DSP, these units still sound great. Now that winter is approaching and the basement is growing chilly, I was more motivated than ever to get this tube equipment on the air.
I have had these radios packed up for quite a few years, not really wanting to ship them all over the world as we moved. Last year, I started putting them back into order. I started by looking through the archive at the Collins Collectors Association and joining their email list. Between the archive and routine access to people who know these rigs inside and out, I came up to speed in no time. I didn’t see anything too amiss on my inspection of the rigs, aside from some carbon residue near the rectifier tube in the power supply. This is a common defect in these supplies — some arcing occurs from the rectifier tube to the metal cabinet, so I wasn’t too worried about that, but realized that the rectifier socket would need to be replaced by a ceramic one down the road.
I took a lot of photos during the survey phase to provide some insurance that I'd be able to reassemble the radio after working on it. The underside of the 32S-3 transmitter showing extensive point-to-point wiring. The "black beauty" capacitors are prominent. They and the surrounding silver-colored electrolytic capacitors were replaced.
The most likely items to fail in rigs of this age are the electrolytic capacitors, so I went through each unit and replaced all electrolytic capacitors, plus any paper capacitors and some of the less reliable “black beauty” oil-filled caps. There is some debate about whether it is better to replace preemptively or only when there is evidence of failure, but I leaned towards the preemptive side. While I want to preserve the original engineering, I also want these units to perform well and get some actual on-the-air use. The other obvious thing that can fail are the tubes. Of course, I can’t just run down to the corner store anymore and use their tube tester. To put that statement in context, these radios are just slightly older than I am.
There are a lot of patch cords that run between the station components, some audio, some RF. These and the power plugs and control connectors had degraded to the point that I wanted to replace them. I rebuilt the connecting cords and power cords using the original plugs and sockets, but for everything else, I visited Joel at RF Connection in Gaithersburg, Maryland. Conveniently, his store is about five miles from where I work, and it is packed with every connector, cable and adapter known to man. He also stocks a lot of the materials used in restoring Collins equipment, including replacement feet. Yes, I replaced the little rubber feet, because they also had degraded over time.
This was my favorite capacitor to replace -- deep down in a metal pocket that I couldn't disassemble. It was like soldering a ship in a bottle.
After inspecting the units, I took each out of its cabinet and to greater or lesser extent stripped them down. All the tubes came out and everything got a thorough cleaning. All the pots got a shot of deoxit, and other bits of mechanical tune up were performed. I replaced the burnt out panel lights with long life replacements from D.A. Buska Engineers, LLC. These LED lamps should last just about forever, which is good because it is something of a hassle to replace bulbs. It involves my wrist bending in ways that seem unnatural. However, I would think twice about using the LED lights again if I did another restoration. Their light is harsher than the original incandescent lamps, and there is some barely perceptible flicker.
After putting everything together came the smoke test. Since these rigs had been off for more than two decades, I approached this cautiously. I tested each unit separately, bringing power up slowly using a variac (auto-transformer). The power supply came up to voltage and all the supply outputs tested nominal. The receiver also powered up, and when I hooked it up to an antenna, it seemed reasonably sensitive. The band calibrator seemed to work, and put the dial right on WWV. I flipped through the different bands, and could hear signals on all of them.
The top side of the transmitter. The front of the radio and the main tuning dial are in the rear, the final amplifier cage is in the foreground. A bunch of the tubes have already been removed at this stage.
The transmitter was more complicated. When I got to about 80V on the variac, a thin wisp of grey smoke wafted upwards from the power amplifier section of the transmitter. I couldn’t find where the smoke was coming from, but the take home message was clear — I needed some professional help.
Even if I had not hit this snag, I would have sent the radios in for some professional servicing at this point. After such a long period on the shelf, they were in need of a laboratory realignment, which is beyond what I can do with my current equipment. I also wanted someone who really knew Collins equipment to look them over.
I contacted Peter Wittenburg at Collins Rebuilders. He is located near Annapolis, Maryland, which is close enough that I could carefully pack the rigs in my car and drive them up. It was definitely the right call — the radios got the love and attention that they deserved from an expert. Peter swapped out the rectifier in the power supply, fixed a fairly major problem in the receiver’s permeability-tuned oscillator (not for the faint of heart), replaced a few tubes that had seen their day as well as a few other discrete components that were not up to spec. He ran the rig through its paces and gave me a nice report, that shows by and large, the rigs were seaworthy.
An Astatic D-104 microphone.
While he was performing his analysis and repairs, I picked up an Asiatic “lollipop” microphone with the proper Collins connector at a hamfest. I had previously borrowed a variac for testing, but decided to purchase one for fulltime use in the station. The Collins equipment was made for a time when the line voltage was lower than the present, and higher voltages will shorten component life. The whole station is now plugged into an isobar strip that itself is plugged into the variac, which maintains voltage at 117V RMS. The station is turned on/off with the isobar rather than each unit’s power knob, as those knobs are all but irreplaceable and are prone to mechanical wearing.
Over last weekend, I made sure that my attic antennas were tuned up, presenting less than a 2:1 vSWR across their useful ranges, as the tube equipment is not tolerant of (read: smokes when confronted with) less well-behaved loads. The ionosphere was revved up as high as it has been in the last decade or so, which boded well. I made my first contact on 40m with WB8PPH (“wb8-pumpkin-pie-headquarters”), who was running a special event station for the Circleville Ohio Pumpkin Festival. I had a few more contacts with PA, IA, and IL and then Sweden, England, Croatia and the Czech Republic on 20m, and Cuba, Honduras, Mexico and finally South Africa on 10m. The received sound quality was golden, and I received favorable reports concerning my audio quality as well.
Interconnections for transceiver operation.
The rigs can be run in transceiver mode, where the transmitter is slaved to the receiver’s VFO, or they can be run independently, with the both the receiver and transmitter VFOs in action; this is what you would have to do to operate split, for instance, as there is no other RIT/XIT function. Separate operation is also the way to go for CW operation. In transceiver mode, you would hear nothing when zero-beat to the incoming signal (naturally), and the offset in CW mode is 1.3 khz, which is impractically large. To operate CW, I picked a clear frequency and used the “cw-spot” function on the transmitter to send a low-level signal to the receiver, allowing me to adjust them to the same frequency. I did one round of calling (straight key, natch) and had an immediate reply from Northern Ireland and Bulgaria. I had a little difficulty getting the vox-balance right to accomodate semi-breakin operation (some hangtime after transmit so the relays aren’t constantly clicking, but not so much that I miss the reply). According to the overseas stations, there was no problem with key clicks or chirps, so I guess we’re okay on that front as well.
I’ve never been a big fan of sideband, but I got a big kick out of working stations with this rig, and I think I might be spending more time behind the mike this winter.
While the ATTINY45’s were on order, I worked out the code using the Arduino itself – this is, after all, its job in life: to serve as a rapid prototyping platform. The circuit was laid out on a solderless prototyping board and jumped over to the Arduino for testing. I realized that I’d need to change some of the pins later, but otherwise the code within the Arduino IDE is the same, whether developing for the ATmega328 on my Arduino Duemilanove or for the ATTINY. There may be differences in the way the code compiles for the different chips, but all that is abstracted away.
