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.
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.
I don’t think that it’s a spoiler to reveal that this is a simulation game, not only of American football, but of what it is like to play the kicker position.
I am bringing a lot of emotional baggage to this review, so in the interest of full disclosure, I should mention that I lived in Buffalo, New York from 1988 to 1997. You can’t live in Buffalo without being a fan of the Buffalo Bills, and you can’t be a fan of the Buffalo Bills without suffering. In particular, during the period that I was there, the Bills went to the Superbowl four times in a row. And lost four times in a row.
Despite sitting through too many games to count, consuming the yearly output of the sun in suicidally hot Duff’s Wings, nearly freezing to the aluminium benches in Rich Stadium in -40 degree weather, and knowing all the stats on every player during that period, I don’t know the first thing about football… except that Scott Norwood missed the final kick in Superbowl XXV, and to this day, if there is just one thing that I and everyone else who still lives in Buffalo can remember about football, it is that one 47-yard field goal that went sailing to the side of the uprights and cost Buffalo their one true chance at victory.
So, when this story relates that kickers are held in low esteem by their teammates and everyone else in society, I can believe it.
This is a stylish game that starts off strong, but which I could not get through, even with the walkthrough open on the same screen. I see where the author was going with this and think it’s a great idea, but I couldn’t get far enough to see most of the story.