In August 2010, one of the Mid-Atlantic summer lightning storms did some damage — the strike was nearby and not direct, but it fried my Astron power supply, a Panasonic tough book, and my Kenwood TS-450SAT radio. The radio would power up and the display looked normal, but I had no audio and suspected that the front end and perhaps switching diode had been zapped. At the time, I didn’t feel up to tackling the radio repairs, so based on eham reviews, I contacted KI4NR at LPC Wireless and mailed the rig off to Florida.
Meanwhile, I checked out the Astron and concluded that the voltage regulator IC was dead. After replacing the chip, the supply was as good as new. Next, the computer: it had been interfaced to the radio via a G4ZLP cable, a work-alike to the original IF232 from Kenwood. As mentioned previously, I had modified the cable to also serve for CW keying of the rig. The computer powered up from battery okay, but did not work on wall power. A small board with the voltage regulator and battery charging circuits had been fried. I found the same model Toughbook on Ebay for a good price — broken screen, no hard drive or battery, and was able to combine the two into a functional unit.
LPC had sent me pictures of both the damage and repair, which are displayed in this posting. When received by LPC, the lightning protection diode had vaporized and the PC board was charred. They repaired the lightning damage, but also performed factory calibration, enabled transmission on the 60m band, and replaced the backup battery, which was close to the end of its life.
The only item that didn’t work right was CAT control of the rig, but at first it wasn’t clear where the problem was: in the computer port, the interface cable or the rig itself. Swapping computers didn’t seem to matter, so the next step was to order another G4ZLP cable. Even with a pristine new cable, I was not able to establish serial communications to the rig.
Not having CAT control was a minor inconvenience. For normal operation, it wasn’t a big deal to type in the frequency, but for contests, it slowed me down a bit to not have the band map automatically populated. Similarly, for digital modes, it made operating awkward.
Looking at the schematic for the digital board within the TS450/690 service manual, there is an inverting buffer right after the physical connector to the cat cable. This chip is all there is between the outside world and the microprocessor that runs the radio. I reasoned that if the microprocessor had been cooked, nothing would work, so it was very likely that the 7404 chip had been cooked by the electrostatic discharge. The chip is designated SN74AS04NS, so an “advanced schottky” version of the chip.
I couldn’t find that exact version of the chip, so I ordered the “next best” version: SN74ASO4D. According to the data sheet, the two are electrically equivalent and have the same pin out. Both have 0.05″ pin spacing, but the dimensions of the ICs are slightly different: the D model is 1.75 mm shorter, 1.6mm narrower, and from side to side the “arm span” of pins is about 2mm less. I was hoping, though, that this would be close enough.
I removed the old 7404 by cutting the pins near to the chip body and then removed the remaining leads with a soldering iron. This left behind some clean, well-tinned pads. When I aligned the new chip, it was apparent that the replacement chip was not wide enough to span from pans on one side to the other. Since the new chip had the same pin spacing, I taped it in place and soldered one side of the chip, leaving a gap of 1-2 mm to the free pads.
After experimenting for a while, I settled on using a very fine tipped soldering iron and made the connections using individual strands from stranded copper hookup wire. I did my best to check continuity, closed the radio up, and connected the newer interface from G4ZLP. I fired up Ham Radio Deluxe and defined a new radio, with communications set to the correct COM port, and serial parameters of 8 data bits, no parity and 2 stop bits. The radio synched up immediately and displayed the correct frequency. After brief testing, it appears that the CAT control is operating correctly.
I then went back and tested the original CAT cable from G4ZLP, and it appears that it had also died in the electrostatic discharge. Opening up the serial cable end connector, there is a small circuit board, covered by white rubber or silicone. I peeled a bit of it back to reveal a small circuit board with surface mount components. I didn’t consider it worth fixing, since I do have another cable that works fine.
Although it was something of a pain to replace the cable and the 7404 chip in the radio, the sacrifice of these two components was far preferable to having the damage go one chip further and take out the radio’s microprocessor.
In 2011, I got together with Ben (NN9S) and Tymme (K9TYM), and we participated in the Indiana QSO Party from Tymme’s house, just outside Bloomington, Indiana. None of us were experienced contest operators, but we managed to set up a multi-multi station in short order and kept it on the air for the duration of the event, giving out QSOs for Monroe County.
We couldn’t pull the team together last year because of jobs and travel schedules, but we entered this year as a Rover team. My 2009 Hyundai Sonata is outfitted with a Kenwood B2000, similar to the TS-2000, but without a front panel. The main radio unit is housed in the trunk, with a remote head mounted on the dash.
Over the last year, I’ve gradually modified the car for this operation, with power connectors running down the left electrical channel to the trunk, and audio, keying, RS-232 and antenna control cables running along the right electrical channel. One of the radio’s antenna ports is dedicated to a 2m/70cm antenna, while the other is used for HF: either a screw driver antenna or MFJ hamsticks.
I took a few days off of work for the event and camped on the way out and back to Indiana from Virginia. Before leaving, I lightened up the car a bit by removing the passenger side seat. The seat is held down by four bolts, easily removable with a socket wrench, plus some electrical cables that had to be disconnected. In place of the seat, I screwed in a RAM Mount for my panasonic toughbook laptop, with power from the car’s accessory power port and rig control via RS-232. This allowed the computer to be operated from either the driver position or the rear seat. Similarly, the microphone reached to the rear seat.
Either passenger in the back could operate the microphone, and the passenger behind the driver typically also fulfilled the role of navigator. The other passenger in the rear seat operated the computer, and the driver either drove, or while parked, operated CW using paddles mounted on the center console behind the shift lever. An autokeyer with rate adjustment was installed into the front dash.
We followed a counter-clockwise loop, starting near Tymme’s house in Monroe county. Our plan was to aim for county borders that were along an efficient route. In the weeks before the event, we roughed out a plan using Google Maps and Street View to try to find places that would be safe to pull over and operate and ideally far from sources of electrical interference. We also tried to find locations with some elevation and good prospects for pitching an antenna into a tree or setting up a support pole.
We got off to a wobbly start because we did not make good time from Chicago to Bloomington, and we got a little turned around in Bloomington. Consequently, when the contest started, we were still on the way to Tymme’s house. This wasn’t a major set back, as we just started operating mobile on voice until we got there. As soon as we pulled it, storm clouds were gathering, and the decision was made to shoot the 80m antenna for the evening’s operations before the sky let loose. While Ben and Tymme disappeared into the woods to shoot strings into trees, I operated CW from Tymme’s driveway.
Before long, we were underway, first way point: the Monroe/Lawrence border. Our circuit continued with operations in Orange, Dubois, Martin, Washington, Scott, and Jackson counties. We had surprisingly few contacts in Martin country, which I thought would be a highly sought location, and I’m not sure why — we had a remote, high location; maybe propagation was just off at that point in the day.
As the first person to operate phone when we got to the Orange/Dubois border, I learned that “Dubois” isn’t pronounced the way I thought I was. In Indiana, it rhymes with “noise” rather than “quoi”.
We continued operating the entire duration of the contest, driving through pouring rain for the last few hours. The rate began to drop off in the evening, a reflection of the poor efficiency of mobile antennas on the lower bands. Looking at the clock and the map, we reckoned that we would need to get back to Monroe country quickly if we wanted to have a chance to use the 80m full-length dipole that we had spent some time setting up earlier in the day. We nicked Brown county on the way back to Tymme’s, but unfortunately didn’t land any QSOs. In retrospect, I think we should have written off getting back and tried to get a couple contacts in Brown country, but we were also constrained by our over all travel plans — we had to be back in Chicago by 6 am the next morning, so we were keen to get back to Tymme’s by midnight and catch a few hours of sleep.
Tymme took the wheel for the last hour or two of the contest, flying through Indiana back roads like Luke Skywalker in the trenches of the version 1.0 deathstar. I’m pretty sure Tymme turned off the targeting computer and just followed his instincts home. Surprisingly (to me), when we got to Tymme’s house, he didn’t stop driving, even though the driveway had run out. Tymme continued to sail over lawn and into the forest behind his house, with the car slicing through waist-high grass. He stopped when he got to the tree supporting the 80m dipole and we hooked up the feed line to the radio in the car’s trunk.
Aside from some boozy yokels on 75m, we didn’t hear much activity, but once we started calling CQ, we had a pile up of responses. When we had wrung out sideband, we switched down to CW and a similar hot run. In the last half hour of the contest, I was pleased to work many calls that I recognized as QRP stations.
During the 12 hour event, we reckon that we worked 30 states/provinces and 48 sections. This is actually fewer states than we had worked in 2011. I believe that this could be improved in future efforts if we used higher antennas and paid more attention to the 7Q contest. Here is the breakdown by band and mode:
band mode qsos pts mults
3.5 cw 33 66 8
3.5 lsb 24 24 6
7 cw 135 270 47
7 lsb 127 127 44
14 cw 12 24 5
14 usb 13 13 8
21 cw 2 4 0
total 346 528 118
Doing some quick calculations after the contest, it appears that Ben has now achieved the first rank of “worked all Indiana” between Operations Sizzling Pork and Rolling Pork.
On the way home, I attached the 10m MFJ hamstick to the trunk mount and worked CW. Conditions were great, with solar flux up around 150. I logged QSOs to the following countries: Honduras, Nicaragua, Argentina, Cuba, Guadeloupe, Brazil, Canary Islands, Mexico, Paraguay, Puerto Rico, the Balearic Islands, and South Africa.
This year, we had some nice mini-pileups, which made it an exciting event. After getting back to Virginia, I called up records from dxsummit to see if and when we were spotted (thanks, by the way, to everyone who did spot us). I would have guessed that we had been spotted at some additional times, so maybe this records isn’t all-inclusive of spots, or perhaps people are just good at finding fresh stations to work:
N9IO 3530.0 NN9S inqp 0347 05 May United States
K3CT 7225.0 NN9S QSO Party 0012 05 May United States
KB9NW 7244.9 NN9S 2244 04 May United States
I hope we are able to build on our effort in INQP 2014. The first item on the plan for INQP 2014 will be operation from Brown County.
I have a few CW rigs that have lousy filtering. Rockmites and other low part count direct conversion rigs naturally don’t have much in the way of selectivity, but this is also (unfortunately) true of my unmodified Yaesu FT-817nd. I should probably invest in the an IF filter for the 817, but for other rigs, it makes sense to have an external audio filter that I can use across projects. A natural choice would be the New England QRP Club’s NESCAF filter.
The NESCAF filter is designed around a family of versatile switched capacitor filter chips. The grand-daddy of the family is the MF10, but more modern versions exist (e.g., the pin-compatible LMF100 or the LTC1060) and have better performance. Each of these chips has two 2nd order filter stages, which can be configured as low pass, high pass, all pass , notch, or band pass depending on how it is wired up and what external components are used. One stage can serve as input to the other to create 4th order filters.
In the case of the NESCAF, the chip is configured as a Butterworth filter — maybe not the sharpest band edges, but minimal ripple in the pass band. Referring to the MF10 datasheet, it looks like the NESCAF implements this through two sequential mode 1 filters with a Q of 10. The filter bandwidth is controlled by two ganged 50k ohm potentiometers, with a section devoted to each filter stage. The center frequency is driven by dividing a time base by 100. A 555 timer outputing 70 kHz will result in a 700Hz center frequency. The 555 rate is controlled by a panel-mounted potentiometer. The center point of that potentiometer is set an onboard trimmer potentiometer. Output from the filter is amplified by an LM386. Some builders make this an onboard trimmer set to yield a gain of 1 relative to the input signal, but I made it panel mount to allow adjustment of volume.
Power input is nominal 12V and the LM386 uses this level directly, with only a couple of capacitors for smoothing. The rest of the circuit operates at 9V regulated by an 78L09. The MF10 chip is used in single-supply mode via a resistive voltage divider.
This design is sold as a kit through the New England QRP club, but schematics are openly available. To try it out, I decided to build my version on vector board, which was great in terms of character building, but next time I would certainly save a boat load of time and get their PC board.
The dual-ganged bandwidth pot takes up a lot of room in a case, so ideally the project would be housed in a deep enclosure. I had a bud box on hand, so I used that. The project schematics call for a 4.7k resistor on the power indicator LED, but that value results in such a dim LED that it would only be useful in a dark room. I knocked the value down to 1k in one build and 1.5k in another, and both worked fine. The marginal power cost is insignificant to me — I’d rather have a reasonably bright LED to let me know that the unit is powered.
I had no difficulty machining the cast aluminum case with titanium coated bits, but a stepped drill bit made it a pleasure to bore out the holes for pots and switches, leaving a burr-free hole with minimal effort. The rectangular hole for the power pole connector is still something of a pain. I drill a few holes, enlarge them, and then refine it with some tedious file work. It amazes me that there is no elegant way to panel a single power pole pair. There are snap-fit panel mounts for 2×2 and larger arrays, but I would think the most common requirement would be a simple pair. The only solution I have found so far is to order very overpriced metal retention brackets that clamp on both sides of the socket. With a single screw in each bracket, they have a tendency to tilt, which gives the project an unprofessional look.
For once, I remembered to drill first and paint later. In this case, two layers of white spray paint. I made the lettering by printing text on water gilde decal paper using my laser printer. I filled the sheet with words, numbers, abbreviations, etc., that I thought I might need in future projects, since the paper is somewhat costly. After applying the decals and letting the cure for half a day, I went over everything with two coats of clear matte acrylic spray and then assembled the project.
As a functional test, I played back a recorded session of PSK31 signals and output to a computer running MixW. I made a video of this session and also took the photo at left. In that photo, events at the bottom of the waterfall are the oldest. So, proceeding upward, I had the filter off with audio bypassing it entirely. When the filter was turned on, signal was lost until I turned the AF gain up to the point where the level was similar to the source volume. The filter was already set to narrow bandwidth and the curvy line resulted from me dialing down the center frequency. Towards the top of the waterfall, I had opened up the bandwidth and then dialed up the AF gain to greater than unity, oversaturating the waterfall.
For the 50th anniversary of the Vienna Wireless Society, the club operated under a special event call sign: W5O. As usual, there was a good turn out of club members for both the picnic and on-air activities. We put a couple rockmites, FT817s, and a KX3 on the air, and accumulated 62 contacts in our log in total running predominantly CW, but some phone as well. We had multiple contacts with other operators also participating in the QRP TTF, but also the Florida QSO Party, and one SOTA station. In the next couple weeks, we should send out our QSL cards to confirm the contacts.
In the days before the event, I put together an “untangleable folded dipole” antenna made from 300 ohm twinlead, plus a matching box comprised of two toroids and two capacitors. The antenna was based on a design found on the blog of KI6SN, and I summarized the construction details for my effort on a Google-plus post.
After spudgunning two trees, we hoisted the folded dipole to a flat 40-foot deployment. The feed line is about 25 feet, so a short BNC-terminated coax extension was used. The antenna worked great and allowed us to work a Swiss station, and to score reverse beacon hits throughout Europe on 20m. I swept the antenna with a MFJ analyzer at the end of the event, and noted that SWR was below 1.2 for the entire CW portion of the band, and less than 2 from below 20m to above the voice portion of the band. So, quite impressed with the folded dipole design. As advertised, it packed up easily and without tangling.
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.
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?
VAQP 2013 didn’t go quite the way I’d imagined it would, but it was still fun. Getting N1MM set up the night before the event, I was surprised to see fields for an exchange number. I’m pretty sure this was a new feature, and I’m not sure how popular it will be with people who prefer more casual operation in state QSO parties.
The contest ran from 10 am to 10 pm on Saturday and 8 am to 8 pm on Sunday. I spent Saturday with the Vienna Wireless Society, operating from the Annandale Swim Club. We got to the club at 9 am and it was probably unrealistic to think that we’d have antennas up, rigs configured, and N1MM networked by 10 am.
We had some technical difficulties — our spud gun line broke a few times, the reels jammed, and trees claimed a lot of line and a few spuds. At one point, while I was working on another antenna placement, I noticed the other antenna hanging team trying to get one of our fouled lines out of a tree using the tools at hand: a lifeguard chair and a pool net.
It took a couple hours to get the antennas deployed. With the contest starting at 10 am, we started operating from the parking lot. I popped the tarheel antenna on my car, tuned to 40 meters, and Kevin WB0POH began working stations. By the time we had the indoor stations set up and configured, he had worked fifty contacts, including the bonus station, K4NVA. I think all his contacts were CW, so worth twice the points to boot.
I’m not sure why, but we were not able to get the two logging computers to talk to each other. We tied them both into the club’s router, which should have worked like a hub. Both computers received DHCP addresses, and as far as I could tell, could see each other on the network. Not wanting to waste any more time, I set up the voice station to start with an exchange number of 500, while the CW station continued to build on Kevin’s earlier contacts. I’m sure hearing our SSB exchanges in the 500 range early in the day put the fear of god into our more competitive neighboring clubs. Heh.
The CW station was set up in a different room from the SSB station, and we had a counter and some stools as operating space. After sitting for a while, I got rid of the stool and used the counter as a standing desk. It felt good to dance around while working CW, and I think I might try for this sort of set up in the future as it keeps the blood flowing. Ian, N0IMB, took some video of TS-450 I was using. Unfortunately, the video does not capture my dance moves. You can’t hear the dits and dahs on the video because I’m wearing headphones.
We broke down our field stations and took down the antennas on Saturday night. The next morning, I set the home station up again. I had brought a number of station items to the field, so I had a little rewiring to do before I could get on the air Sunday morning at around 11 am. I worked intermittently until the end of the contest at 8pm that evening, but had a number of fairly large breaks to take care of family, do chores, etc. I entered as single-op, all bands, low power (100W), CW-only, non-assisted, one radio.
Propagation was so-so, and I kept hoping that after a break, it would improve. It wasn’t just my imagination: conditions were much better on Saturday. Looking at the space weather data, a CME thrown on Friday hit the ionosphere Sunday morning, just when I was starting operation. The K-index bumped up to five and stayed there the rest of the day. Conditions did seem to improve as the day went on, but this perception may also be a matter of more people joining the contest for the last few hours.
I spent almost all of my time on 40m, using the attic dipole rather than the outside 40m vertical that does better in DX contests. I had good coverage of New England earlier in the day, and worked westward into Wisconsin, Kentucky, and Arkansas. Operating NVIS, I had a reasonable chance of operating other VA stations, including VWS club member Kevin, WB0POH.
Twenty meters was not as helpful as I’d have liked — at one point, Europe opened somewhat, and I worked a succession of stations in Poland, Germany and the Slovak Republic. Later in the day, I had a brief opening to the west coast: WA, OR, and CA. Otherwise, 20m was my direct line to Florida. I did reach two stations on ten meters, but probably ground wave.
In the last hour and a half, I did good business on 80m, where I mostly ran into stations that I had worked on other bands.
I was surprised in the contest how many times I was called by stations that I had already worked. As a matter of course, I worked them again. Maybe conditions were marginal on some of those calls, and maybe they just wanted an insurance contact. I didn’t hear anyone else operating from Fairfax City (FXX) — at least not on CW — so maybe my exchange was in high demand.
My final tally was 166 contacts (some dupes), with a paltry 26 Virginia City/County, 23 State/Province, and 3 DX entities. If I calculated correctly, I may have nosed over 20,000 points. Not a great performance, but not too bad considering time and conditions.
As for the club log, I’ll have to more or less manually merge the databases from the two workstations that we used into one file for submission to the Sterling Club which runs the VAQP.
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.