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
