The Version A circuit laid out in Eagle CAD. Top of board view.
Back in October, I mentioned an open source keyer developed for the ATTINY 45 and requiring only a few components. The source code for the controller and an example schematic were uploaded to a repository. Subsequently, I decided to try my hand at producing a PC board. Rather than try some sort of printer-based method based on toner transfer, I wanted to try going a more professional route and having the PCB run off by a fab. Initially, I thought I’d have to go overseas and wait upwards of a month for my boards to come back, but I found a domestic fab that provides an amazing service for low volume prototype boards: OSH Park.
I had already laid the schematic out in Eagle CAD, which seems to be popular among hobbyists. Most of my components were available in off-the-shelf libraries, but I had to layout the piezo speaker as a custom part (although I started from another similar piezo speaker and just had to modify the dimensions). It took a while to get the hang of laying everything out on the PCB, laying down ground planes, routing the traces, and making the silk screen look nice, but after many hours with online tutorials, it all looked right. I ran some rules checks, and everything reasonable, as far as I could tell.
Next, I shopped around using the online check and quote tools available from a number of popular fab houses. To upload my design, in most cases, I had to send a zip file of the various Gerber layers — top copper, bottom copper, top silk, etc. But, for OSH Park, all I had to do was upload the Eagle board file itself. This makes a lot of sense, as the Gerbers are generated from that file, so all the information is already there in the board file.
The OSH Park site interprets the board file on the fly and provides a rendering of approximately what the board will look like when final. There are a number of options regarding cost, turn around, etc., but I opted to get three copies of my design for about ten dollars by agreeing to have my boards made as part of a larger run to take place in about two weeks from the date of submission. The way OSH Park makes prototype boards affordable is by merging multiple designs into one larger board and then cutting that board apart. Their cost is per square inch, and I had designed my board to be one by two inches — not bad considering that I used all through-hole components and did not go out of my way to pack them tight on the surface of the board. In fact, my design is a little generous in that I give a number of ground connection points, whereas only one is really necessary for the sake of wiring in external components.
The board as rendered immediately after upload at OSH Park.
From the time of submission until the envelope arrived, I was able to track progress of the order, so there was particular excitement on the day that I knew the package would be waiting in my mailbox. When I opened the padded shipping packet up, I found three little purple boards, just about identical to the rendering that was provided when I had uploaded the design.
The front of the board, with components added.
The back side of the board, before I started soldering.
The PC boards are excellent quality, with no alignment issues. The solder mask went where it was supposed to go, all the vias are functional, and the pads take solder well and have no tendency towards lifting. Components went onto the board without any fuss and when powered up, the board worked perfectly, the first time. Having verified that the design works, I’ve shared the board on the OSH Park website.
Now that this seems to be working, one option would be to run off more copies of the boards and do something with them — embedded keyers, stand alone kits, etc., but now that I’ve tried out designing a through hole board, I’m curious how much more compact the design would be with surface mount parts (and how much more difficult it would be to assemble).
As the days grow shorter with the approach of winter and activity shifts towards longer wavelengths, I took stock of my log and noticed that while I have racked up a reasonable number of contacts on 15, 20 and 40 meters, 80 meters lags far behind. I anticipate moving overseas in about six months, but before I go, I’d like to even up the score on 80 meters for this QTH.
My lack of contacts on 80m is a function of my antenna limitations — where I live, I can’t put a lot of metal in the sky. I have one outdoor antenna, a 43-foot vertical; the rest of my antennas are in my attic. My vertical antenna is, intentionally, not much to look at: a single, black wire that runs from the ground up into the top of a tree and is almost impossible to see from a few feet away. However, under the gravel of my backyard, there is a DX-Engineering radial plate. Eight radials spike out underground from that point under my property and into the adjoining forest. The antenna is fed by a coax line that runs underground from the house to that plate, where the center conductor feeds right into the antenna. The antenna was never very well tuned on any specific band, but it managed pretty well on 30 and 40 meters with either built-in or external tuners in the shack. With difficulty, it could tune 15 and 17 meters, and my LDG tuner could force it to work on 80 meters, but the amount of energy actually going out the antenna was pitifully small.
Winding the coil with the help of a vice, some PVC and a couple wood sticks.
So, I decided that for this winter, the vertical would become a dedicated 80m antenna. The attic antennas can handle the other bands. My first thought was to make an inverted L for 80m, but the far end would extend off my property and would increase visibility of the antenna, particularly in the winter when there are fewer leaves for cover. I decided to work with the vertical radiating wire that was already in position, but to interpose a loading coil at the base.
Pete, K6BFA, lent me his MFJ antenna analyzer, and I measured the impedance of the antenna at the point where I anticipated the matching coil would be located. I measured at 3.7 Mhz, a bit higher in frequency than where I intended to operate and the complex component of impedance measured 278j. Since the antenna is a shortened radiator, this would be capacitive reactance, so -278j. I calculated the inductive reactance needed to null it out as xL = Xc/2*pi*freq, or 11.9 uH.
I had made a coil form from Schedule 40 PVC labeled “one and a half” inches, but measured its outer diameter as 1.9 inches. I wanted to wind a coil big enough for the about 12 uH needed above, plus extra so I would have some for shunt inductance (which I guessed would be around 2-5 uH). I figured 18 uH would be enough to have room to spare. Using the formula of n-turns = sqrt(inductance((18 * coil diameter)(40 * coil length)))/coil diameter, all values in inches, I came up with a three inch long coil with about 28 turns. This fit nicely inside the box that I had, so I went with it. Note that the coil shown in the box in the picture was my first attempt, and the coil turned out to be too small. There is a learning curve for this sort of thing, you know.
The coil was mounted on nylon screws and coils were made rigid with epoxy. The coil wire itself was some 18 gauge hook up wire that turned out to be too large for my protoboard, so I am glad it found a good home in the matching coil. The top of the coil goes to the antenna. The coax comes in the side of the box, and initially, I probed the coil to find a good matching point tuning at 3.7Mhz, intentionally above the CW portion of the band, where I wanted to operate. I found the optimal spot to bring the complex portion of the impedance to zero, and then played with the ground lead, trying to find a point lower on the coil that would yield lowest SWR at 3.560 Mhz, the QRP CW watering hole frequency. After playing with the placement of these two leads for a while, I was satisfied with the resulting SWR curve, which is shown below.
I could have shifted the curve higher in frequency, but I really don’t operate much voice, so I made the decision to optimize the antenna for CW and digital mode transmission at the lower frequency end of the band.
Back in the shack, I verified that I got the same measurements and switched the antenna through to my K3. The rig read the antenna as SWR near 1:1, so I made a couple test transmissions and worked stations in Hungary, Italy and Jamaica. I then turned power to 5W and worked a station in NY. It’s anecdotal, but the antenna seemed to be working fine. After calling CQ at 5W, I checked the reverse beacon network and noted that I was greater than 10 dB above noise as reported by stations in W1, W2, W3, W4, W5 and W7, which seems much better than previously.
One more reference (added Jan 2020). K6STI contacted me to mentioned that he had developed a free Windows program that calculates nductance and Q for solenoids of solid or Litz wire. It accounts for self-resonance, form dielectric, wire conductivity, and lead length. The program includes an optimizer and measured accuracy data. You can download the latest version of COILS from http://ham-radio.com/k6sti/coil.zip. The text documentation that comes with this package provides some useful tables regarding inductance of solid and litz wire coils as well as links to other references.
While working on a new project, I had a choice of either plugging in the output of a free-standing CW keyer or embedding one into the project. I decided to go with the embedded keyer, but then had to either find or write one. K3NG has written a top-notch keyer based on the arduino platform. Its strengths are its modular design and extensive feature list; it can be compiled to run on a number of chips, with features only limited by the flash memory capacity of the targeted chip. However, it does have a certain minimal size, even when the number of features is stripped down to bare essentials. It would have been a reasonable choice if I could have used the same microcontroller for other functions, with a sizeable portion given over to the K3NG keyer, but in this case, I just want a dead-simple CW keyer.
I’ve used K1EL‘s K12 keyer in the past, as well as the N0XAS picokeyer, and this was more what I had in mind — a low power, small chip. After a quick search, I turned up the YACK (yet another CW keyer) project by Jan Lategahn, DK3LJ. He developed it for the ATtiny45, which has only 4k of flash and even less RAM and EEPROM storage. The project was not developed on the arduino platform, so the code has a much, much smaller footprint. Jan deposited the source code in a svn repository at Source Forge: http://sourceforge.net/projects/yack/. And, this isn’t a matter of trading off features, the YACK supports a number of keying modes, has many configurable features, a beacon mode and even does code practice. Pretty feature-rich, actually.
On that site, it is possible to download not only the source, but the compiled intel hex files for flash and eeprom. Naturally, I went for instant gratification, downloaded these, and flashed them onto the ATtiny using my arduino duemilanove as an in system programmer as previously (but this time, not having to mess with the fuse settings).
I stuck the programmed chip on a protoboard and tried it out. At first I wasn’t sure if it was working at all because it make no sound when powered up, but this was the way it was designed. Next, I tried closing the dit and dah paddles, and heard the expected tone on the piezo buzzer. Holding down either paddle resulted in tones of the correct duration, and holding both resulted in iambic mode B keying. So far, so good.
However, I could not get the keyer to work in command mode. Holding the command key just resulted in rapid clicking on the piezo, perhaps meaning that it was going into and coming out of command mode immediately since it sends an “e” when it exits command mode. Holding the button and closing one or the other paddles resulted in correct behavior: increasing or decreasing the sending speed.
I also noticed that a quick (less than a dit or dah length) tap on the paddles resulted in a shortened dit or dah being sent. This is not the expected behavior for keyers like this. Even if the paddle is released early, the generated tone should be of the correct length, one or three elements long.
Both these issues made the keyer unusable, but it seemed like at least the duration issue had been addressed in an earlier changelog entry, so I thought that perhaps the compiled file might not reflect the most recent and presumably most polished version of the project.
I recompiled the project from source (version 0.7) and noted that the resulting hex file was a bit different in size that the one I had previously used. I loaded both the flash and eep files onto the ATtiny and stuck it back in my prototyped keyer circuit. This time, it worked exactly as described in its documentation. Paddle clicks yielded dits and dahs of the right duration and the command button was fully functional. I ran through all the available commands, and each performed as advertised. I ran the keyer output to my FT817, which I had set to make a tone but not transmit when keyed. I had no problems using the keyer to send at various speeds. All good.
I made some minor tweaks to the code and revised the version to 0.75. This shouldn’t be taken as any sort of official version number, but I needed some way of setting this revision apart from DK3LJ’s original code. I didn’t fix any bugs or make any real improvements, I just optimized the configuration for my purposes. Mostly, this is a matter of taste, and of being used to certain conventions from other keyers. I left most of the user interface alone, though, since I thought Jan had made some very reasonable choices in how he set it up.
Here is a list of what I changed:
Power up message: Now, when powered on, the keyer sends a “73” to let you know that it is alive. This is tone-only, no keying. This provides a quick check that the battery is okay and that everything is hooked up right, which could be helpful to anyone building this circuit, or someone who is on their way out the door for field operation and wants to make sure their keyer is healthy.
Positive Transmit keying default: In most cases, people will want to positively key their rigs, but the default formerly was that the transmit line would go low to key and remain pulled up to VCC otherwise. I flipped this around, which let me use a cheap NPN circuit with open collector to key.
Side tone: For the project that I’m using, a 700Hz side tone is optimal — the keyer is followed by a filter with a 700Hz center frequency, so I changed it in the default settings. I actually prefer 800Hz, but the tone can be changed on the fly, so this isn’t really an issue.
Keying mode: This is entirely personal preference – I made the default keying mode iambic A rather than B, because I think it is easier for someone accustomed to Iambic B to send A rather that the reverse. People who are used to iambic A are thrown by the “extra” character that B generates.
Speed: I bumped the default speed to 15 wpm. Maybe 12 wpm is more inclusive, but 15 wpm works better. Also, anyone can increase or decrease the speed by holding the command button and pressing one paddle or the other. It is not necessary to send a character correctly to change the speed, so I think I haven’t really excluded slower operators.
Exiting command mode sound: Previously, the keyer sent an “e” to indicate that someone intentionally exited command mode by tapping the command button a second time or that the command mode had timed out due to inactivity. I found the “e” a bit short and thought it could be missed. Also, at times I forgot I was in command mode, and whatever else I was doing, it just sounded like an extra dit got in there, without making much sense. I changed the exit sound to “sk”, similar to the picokeyer, because it has a more characteristic sound and would not be expected in the audio stream except at the end of a QSO, so it is more noticeable.
Acknowledgment sound : After a valid command is given, the keyer used to acknowledge it with an “OK”. I changed this to “R” because it is shorter and “R” connotes “Roger, received.” This borrows a bit from the K1EL keyers. I only steal from the best.
After testing out my minor revision, I uploaded the project to a repository at google code. The project files include a schematic in Eagle format as well as a picture of the schematic as a *.png file. For those who would rather not compile from source, I’ve uploaded the compiled intel hex files on this server: main.hex and main.eep. I loaded the files into a stock ATtiny45, right out of the box. No need to mess with any of the fuses — the chip is factory configured to run on its internal 8Mhz clock, scaled to 1Mhz.
The last time I checked on mouser, these chips were a bit over a dollar each and the even more spacious ATtiny85s were a bit less — and that’s unit pricing — buy a bunch and the price falls off considerably. The rest of the components in the keyer are dirt cheap and easily substituted. Making a first-rate keyer these days is not an expensive proposition.
[Update 17 May 2016]
Unfortunately, the Google Code repository no longer exists, but before it went down, I migrated everything over to github, so project files are now over there: https://github.com/dhakajack/jackyack.
Also see my later blog post about design of a PC-board for this project.
The Tortugas-CW group has put together a nice kit that includes a touch-sensitive iambic paddle based on a design by VK3IL and incorporates an improved version of the YACK-based keyer. See Part1 and Part2 on Youtube.
Arguably, the crossed bananas display (CBD) was not the next most needed accessory in my shack. I mean, who needs a crossed bananas display, anyhow? Nonetheless, I built one, and it seems to be working.
The CBD is a tuning aid for frequency-shift keyed modes. At one time, these displays were particularly in vogue among RTTY operators. The original version made use of an XY-mode analogue oscilloscope. The demodulated sound from the radio was filtered at the mark and space frequencies and each signal was then fed to either the X or Y input of the scope. Ideally, the tones would be sine waves, and when one tone would be sent, the other would be off. Each tone corresponds to a “banana” or oval on the XY display. The oval is horizontal for one tone and vertical for the other. When the radio is perfectly tuned, the two tones are located right on the two filter center frequencies. When a RTTY signal is sent, or even while it is idling, there is rapid alternation between the two tones, so the vertical and horizontal ovals appear so quickly that they appear to overlap, hence crossed bananas. When the radio is a bit off frequency, the phase relationship changes and the traced ovals rotate and distort. When only noise is present, the tracing is a random jumble. It’s easier to see this in action than to describe it, so I made a video of how it looks on an oscilloscope and how it looks on my newly minted digital CBD.
I got thinking about RTTY and some other similar modes after working on the PK232 mentioned in earlier posts. The PK232 has a little bar graph that indicates when a signal is centered such that the mark and space tones fall where they should, be it for RTTY, AMTOR, PACTOR I, etc. A lot of the circuitry in the PK232 is dedicated to producing and sensing these tones and telling them apart from noise. The bar graph tuning indicator is usable, but let’s face it, nowhere as cool looking as the old style crossed bananas displays on an oscilloscope.
My operating position is already cramped enough, though, without tossing an oscilloscope on the pile, plus I need my scope for bench work and don’t have an extra one that can just relax in a corner until it is needed for RTTY. No, what I needed was a small, modern version of the crossed bananas display. This sounded like a good arduino project. The limiting factors would be timing of the audio samples and speed of updating the display.
My first thought for the display was an LED matrix, preferably one with minimal translational overhead. If the microcontroller could drive it directly or through a shift registers, that seemed like it would be lightning fast, and indeed it probably would be. Unfortunately, to get reasonable resolution, I’d probably need a pretty big array. 8×8 is chunky, but we’re already talking 64 LEDs.
So, with some concern about the data transfer and display/buffer update speeds, I took a look at some LCD displays. I found the ST7735R display at Adafruit. It’s 1.8 inches diagonally, with square pixels arranged in a 128 x 160 array. The display comes on a breakout board that makes it easy to work with, taking care of voltage conversion and making it an SPI device. The display includes a video buffer and Adafruit provides a library that abstracts most of the lower level functions. Adafruit also provides a general graphics library that provided methods for most of the things I wanted to do like drawing a pixel, erasing a pixel, writing text, blanking the screen, etc.
The sound coming out of the PK232 turned out to be biased around 7.5V, with swings of +/- 1.25 and 1.5 volts depending on whether it was being driven by the ACC output of my Yaesu FT-817 or Kenwood TS-450, which must output different levels. Each tone was capacitively coupled to an op-amp channel set up as an inverted amplifier with variable gain. A ganged potentiometer sets the gain between unity and 2x. I used an MC33204PG quad op amp. Of the op-amps I had on hand, it was the best single voltage nearly rail-to-rail chip. I used the third section of the op amp configured as a voltage follower to set the bias voltage at 2.5V for the mark and space op amp sections, so only one out of the four op amp sections was left to twiddle its thumbs. With that bias and input range, the output of the op amp would stay in a reasonable range, nearly 0-5V, consistent with the requirements for analog input on the ATmega328.
In principle, the XY display plots a point defined by an X-input and Y-input at a single instant, so one concern I had was that there had to be minimal separation between the mark and space voltage reads. I minimized this interval by setting the ADC prescaler to 16, trading off some accuracy for faster acquisition time. Without this tweak, the display was distorted due to delay artifact in the phase relationship of the two inputs.
Front and back view of the innards of the crossed-banana display
After displaying the self-congratulatory splash screen, the main activity is to read an XY pair, scale it, and plot it. Given the speed of this process, more than one pixel needs to be displayed at a time to create a reasonably bright display. The solution is to use a circular buffer and to draw one pixel, erase the next pixel in the queue, and crank the index forward by one. This only gets complicated if the size of the queue varies arbitrarily, which is exactly what happens if you twist the brightness potentiometer. The brightness pot is polled every now and then, and when its value changes enough, the size of the queue is modified up or down, resulting in more or less pixels displayed at any one time, and giving the impression of brighter or darker display. When this happens, the size of the queue changes, so there is some housekeeping to do to make sure that all the pixels are taken care of.
The design has one more control, but it’s inside the box in the finished project. The LCD display has a huge range of colors, but having a rainbow XY display was not appealing. I incorporated a dip-switch on the control board, with three bits dedicated to color selection and one to choosing black versus white background. I didn’t think color would be adjusted frequently, so I though it would be okay to leave this control off the front panel. I set my CBD to green dots on a black background, as close as I could get to the appearance of a classic oscilloscope.
The aluminum box, before painting, decals, etc.
My metal working facilities are limited, so this project went into the same sort of enclosure as the NEScafe filter, a cast-aluminum bud box. I bought these in bulk to save shipping at one point, so I suppose we’ll be seeing more of them in future projects as well. At first, it seemed that this box was way too large for this project, but when I started thinking about all the items in the project (LCD panel, control board, two pots, two RCA jacks, a switch, power pole connectors), I became concerned that it all might not fit.
Since I don’t have the patience to send away to an offshore fab facility for a one-off PC board (and since it would likely take more more than one to get it right), I laid the project out on vector board, with some forethought to how it would mount in the bud box and where the screen, controls, and various connectors would emerge. To fit everything in, I had to pack components tightly and cut out two notches in the board to clear wiring runs. Once again, small nylon spacers from Ace Hardware were my friend, providing stand-offs for the screen and for the control board. A layer of clear plastic provides some protection for the glass LCD display. The plastic is pinned at four corners by the control board stand-off screws, but also held in place with some double-face tape.
Contents stuffed into the box.
Since every project justifies one hardware purchase, my purchase for this project was a manual screw countersink from Carr-McMaster. It allowed me to use screws on the front panel, but have them flush with the surface of the panel.
The square window for the LCD was roughly cut out with a dremel rotary tool and then carefully finished with a flat file. The rest of the holes were made with a stepped drill bit, except the power pole hole on the back which I made by pin-holing the metal with a bunch of drill holes, widening with a nibbler, and finishing off with a small file.
Skip, VE6BGT, made a video about incorporating the crossed-banana-display into a beautifully constructed vintage RTTY station. In discussing his revision, the video shows a PC board that he made, which is way beyond my perf-board approach and may be of interest to anyone else approaching the project. I’ve linked to the video that focuses on the display, but that video is part of a series that begins with this one.
I followed the instructions to set up a breadboard as a platform to burn bootloaders onto some factory-fresh ATmega328 chips, according to instructions. Specifically, I set up the breadboard with a 16Mhz crystal rather than using the chip’s onboard clock.
I uploaded the ArduinoISP sketch my Duemilanove, made all the right cross connections to the breadboard, changed the “programmer” setting from AVR-ISP mkII to “Arduino as ISP” and made sure that the target was still set to Duemilanove at 16Mhz. Then, I hit “burn bootloader”. There was a pause of a few seconds, followed by the following error message in the IDE:
I found some similar issues and suggestions on the forums, and it seems the problem is the autoreset on the Duemilanove. The solution: before trying to burn the bootloader, connect the Arduino’s reset to 5V through a 120 ohm resistor. Now, when you select “burn bootloader” lights immediately start flashing on the host arduino and after a few moments, the IDE displays a confirmatory message that the operation was successful. Now the target ATmega328 can be popped off the breadboard and another one can be burnt. After burning bootloaders onto as many chips as desired, the whole assembly can be taken down and the 120 ohm resistor removed from the host arduino board.
I am strongly in favor of having a standard connector for powering everything in the shack, not only for the sake of EMCOMM deployment, but also to avoid having a rat’s nest of proprietary connectors strewn behind the operating desk. Consequently, whenever I build something, I include power pole connectors (see, for example, the NESCAF filter project). The quick and dirty way is to poke a hole in the box and run a power cable out for some length and then crimp on the power pole shells. This works okay, but is not all that neat. What I’d really like to do is mount the connector right on the box. That way, any power pole patch cord could run between the device and a power distribution strip.
Unfortunately, there is no reasonable way to mount a single power pole connector on a panel. There is a nice snap-in connector for two pairs of power poles, but if you want just one pair, which surely must be the most common configuration, there is no ready-made piece that will snap into a hole.
The only option offered commercially is slightly insane: a pair of aluminum brackets that trap the connectors above and below. Each bracket is held in place by a single screw hole, which gives them some tendency to rotate on the screw, although the plastic shells themselves more or less wedge everything into position when both screws are tightened down. To make this solution work, a rectangular hole must be machined into the panel and then screw holes must be drilled at the right spot. Worst of all, these little clips sell for an insulting $2.49 per pair.
As mentioned in the user comments on the powerwerx website, it’s crazy that no one, much less the primary retailer, has offered a product to make this easier. The obvious product would inset the pair of connectors into a round holder, so that the pair could be installed and perhaps screwed into place by drilling one large hole for the assembly. If ever there were a product that needed 3D printing, it would be a panel mount adapter for power pole connectors.
Alas, having no 3D printer, nor for that matter any tools that were really appropriate for the job, I went the primitive route and made my own power pole brackets out of aluminum. I had recently built a couple projects in plastic Radio Shack project boxes that come with both an aluminum and plastic cover. I had opted to use the plastic cover, which left me with a spare aluminum one, which measured out as 19 gauge. I don’t have a sheer, and this is a bit much for my aviation snips, so I made some measurements, scratched out the lines with an awl, and traced over the lines with a cutting wheel mounted on a dremel. I didn’t cut all the way through, but scored the aluminum deeply enough that it snapped on the lines with a bend back and forth. I then went over the edges with a sanding wheel to take off the burrs and smoothen the corners.
Working from one of the real brackets, I measured the dimensions to the neared 64th of an inch. I’d prefer metric, but I have the impression that it was originally laid out in imperial units, so I stuck to those. Luckily, the two cut-outs for the power pole shells are 1/4″ each, which is exactly the size of my nibbler. Two nibbles were enough to make the cut-outs deep enough, and nicely square.
Finally, I drilled a hole for the mounting screw and made sure that the brackets would actually fit correctly over a pair of power pole plugs. The brackets are not as uniform as those rolling off an assembly line, but the price (and availability) are right. Since they are all a bit different, when making an actual project, I’d drill and file the rectangle for power pole pair and then fit the brackets around them into final position in order to mark the exact location of each drill hole.
I had two projects this weekend, one involving microwave and the other involving HF. The microwave project is now firmly attached to the kitchen cabinet and works fine at reheating pizzas. The HF project took more doing. My goal was to set up my Softrock Lite II as a 30m reporting station for the reverse beacon network. I’ve found the RBN useful, and wanted a chance to participate in it from the server rather than the client end.
Last year, I put together a Softrock Lite II, a less than $20 kit that could be built for a single band. I built mine for the 30 meter band. I tried it out with a laptop and could resolve cw signals, but I realized that with a mono input, I would not be able to get any image rejection. The whole value of resolving the signal into quadrature components was lost. I tried using a Mac, which I knew had stereo input, but it was too much to expect this time-critical application to work well in emulation. In these attempts, I noted that there was a lot of noise around the local oscillator frequency, but I didn’t make much of it because there were so many competing issues. I did note that the noise was much better when the unit was run on battery, though.
The EMU-0204 USB sound interface
In the interest of running more advanced sound modes on my aging laptops, I thought it would be helpful to buy an external sound card that would not load down the CPU. In searching for the sound card, I had in mind both the Soft Rock Lite II project and the future construction of a SoftRock Ensemble Transceiver that I had purchased as a kit last year.
I purchased an EMU 0204, an external USB “sound card” ADC/DAC that can take a left and right input and sample at up to 192 kHz. The card has been around for a while and is known to work well under WinXP with system requirements commensurate with the state of the art about five years ago. The laptop I had in mind was the nc6000 that I had salvaged a few months back. The machine has a Pentium M CPU clocked at 1.8 Ghz, 1.5 gigabytes of memory, and is running XP SP3. The machine came with USB 2.0 ports, which are required by the EMU 0204.
I plugged in the EMU 0204, loaded up the drivers, and downloaded updates from Creative Labs. The rear of the EMU 0204 has two inputs: the left input is a hybrid XLR microphone and quarter-inch TRS jack, the other is a quarter-inch TRS jack. The asymmetry of the ports looks odd, but the primary market is musicians, who are more likely to want to plug in a microphone and an instrument rather than the I and Q channel of an SDR radio.
There is a standard 1/4″ jack on the front for headphones, two line out jacks on the back for left and right out, and a 3.5mm stereo jack on the back for external speakers. I plugged some old powered computer speakers into that jack.
The Softrock was built with a stereo 3.5mm jack as output, so I put together a Y-cable that took the tip and ring and distributed it to the tip of a left channel and right channel quarter-inch plug. I had 3-terminal jacks and plugs on hand, so that is what I used. I expected everything to work right off, and of course, it didn’t.
I fired up the SDR program “Rocky” and set the input to the EMU 0204, with sample rate 48 kHz. What I saw was a huge bump in the middle of the spectrum, at the local oscillator frequency. Clicking on it produced horrible feedback. I did see some cw signals buried, but everything was mirrored around the center frequency, meaning I had no image reject, just as if I had only one signal going in. I recalled that running on battery had made things better the first time, and that did clear up some of the noise, but the image reject problem remained.
There is an LED for each channel on front of the EMU 0204, and it is green when the sound source is in a good range for sampling, red when there is too much overdrive and the signal is going into clip. Even with the EMU-0204 dialed up all the way, the signal was never strong enough to turn on the green lights. I thought this was strange, but maybe the Softrock just didn’t have a lot of output, or perhaps the band was legitimately quiet, and there wasn’t any signal in the first place.
I closed Rocky and fired up audacity, which showed some signal on the left channel, but low level on the right channel. Plugging into another source (like my ipad playing music) showed that the cabling was intact. I wondered if perhaps one of the channels was out on the softrock board. I was able to confirm that the local oscillator was working and that the divider was supplying clock pulses with the correct phasing to the mixer. All the voltages on ICs checked out, so I became suspicious of the transformer that takes an input signal at the antenna and picks up signal to feed to the I and Q channels. I pulled the transformer, rewound it, and stuck it back in. No change. I traced the signal as best I could, made sure all the surface mount capacitors were passing signal, and came to the conclusion that the softrock seemed to be fine.
Then it occurred to me that the EMU0204 is meant for professional sound work and that it was expected balanced inputs by default. But surely, a typical electric guitar isn’t a balanced input. Then I realized that the EMU must detect an unbalanced line by seeing continuity between sleeve and ring. I revised my Y-cable, and now everything worked fine: solid audio levels on both I and Q inputs, barely detectable signal artifact at the LO frequency on the spectral dislplay, and strong image rejection. I made sure that I got the right/left side matched up with I/Q by sending a test signal with the K3 on a dummy load, and saw the signal detected at approximately the right frequency. I saw only a hint of the signal on the other side of the LO, which was reasonable considering how strong the signal was.
Connecting the softrock to a power supply created hash, particularly near the center frequency. Not unexpectedly, it was worse on the SS30 switched power supply than the Astron RS-30 linear supply, but I was surprised it was an issue at all on the Astron. I wondered if the problem could related to a ground-loop (the softrock’s antenna is isolated, but audio out ground has continuity with power), but playing with the EMU ground pull-ups did not fix it. I may play around a bit more with the power input and see if some line filtering fixes it. I’m not sure what effect adding isolation transformers on the audio out would have in terms of increased impedance at higher frequencies needed for SDR decoding. Meanwhile, since the softrock pulls less than 30mA, I can run it off one of the rechargeable batteries in the shack just about until the heat death of the universe (rounding up).
CW Skimmer, with list of identified stations, inset.
Even with this set-up, I was not able to run with Rocky set to 96 kHz sampling. Trying to do so resulted in some stuttering. I also managed to crash rocky by going beyond the band edges in the waterfall display. I had a much better experience using CW skimmer, by the same author. Presumably, it is a later iteration built on the same code base, but it works much smoother. Without changing anything else in the set up, its waterfall was much cleaner, even without cutting in the noise blanker and key click suppressor.
For both Rocky and CW skimmer, one of the set up parameters is the local oscillator frequency. I had chosen 30m because I thought I might only be able to sample at 48 kHz with my original setup, and the band is only 50 kHz wide. Softrock uses a 13. 5 Mhz oscillator, which is divided down by four, and then the third harmonic, 10.125 Mhz becomes the center frequency, so I figured that 10.125+/-24 kHz would get me all but the edges of the band. While building the softrock, I sampled the crystal output as 13.497 Mhz using a lab grade HP counter, albeit one that hadn’t been calibrated in years. Similarly, I measured the divided frequency as the expected 3374 kHz. Both readings were confirmed by my freqmite. Consequently, I calculated the center frequency as 10.122 Mhz, and I entered this into the CW skimmer.
I let the skimmer go for a while, identifying stations in order to compare its frequency read out with others on the reverse beacon network. Noting that I was a few kHz off, I aligned my center frequency to 10,123,150 Hz to bring readings into line with other stations, who I assumed were more calibrated.
N1MM, with telnet session open to CW Skimmer on another computer on the LAN. The band map has automatically populated with these spots.
CW Skimmer has an integrated telnet server, with a default port of 7300. I set up the skimmer to send its readings to that port. I then sent over to the laptop that I use for contesting and launched N1MM. N1MM can import spots from packet or telnet and add them to the bandmap. I created a new telnet shortcut to the laptop running the skimmer, opened the telnet session, and was pleased to see that N1MM began correctly importing stations identified by the skimmer.
Going back to the skimmer computer, I downloaded the Reverse Beacon Network aggregator. To run it, I also had to download the Microsoft .NET 4.0 framework, which required a reboot. I unpacked the aggregator into the cw skimmer directory, as instructed and launched the skimmer. Next, I launched the aggregator. Setting up the aggregator was mostly intuitive, putting in my name, call sign, etc., but getting the skimmer to submit hits to the RBN required going back into the skimmer and checking the “Allow SKIMMER commands” box.
One of the RBN Aggregator’s set up screens
The aggregator talks to the cw skimmer on the localhosts’s port 7300, but makes data available to port 7550. I was able to re-establish a telnet session from the contest computer to the aggregator using that port, and the bandmap populated correctly.
At this point, I was able to see AI4SV listed as a skimmer station on the reverse beacon network search page. After letting the skimmer run for a while, I searched for stations reported by AI4SV (i.e., I set the “DE” to AI4SV) and got a list. I noticed that there was an annotation in the aggregator that my frequency spots had been adjusted by 0.1 Khz to correct for slight skew versus the majority of reporting stations.
Here’s what it looks like to be on the *other* side of the reverse beacon network:
Last month, Hank (K1DOS) came over and demonstrated how he could send and receive mail through an FM packet connect from his car using a computer and a little TNC. I agreed it was pretty cool, and he pointed out that I could do much the same the the PK232 gathering dust on a shelf in my shack. I had, in fact, forgotten that I had one, but this provided the impetus to try to set it up.
I received this unit a year or two ago from Bill Hook (W3QBC) at the NIH Amateur Radio Club. He said he didn’t have much use for packet any more and handed me the box and a pile of manuals and notes that documented how he had upgraded it module by module since the mid-eighties.
I was aware that packet had been popular before home internet became common, and I had seen videos of on-air BBSes being run over VHF links. Also, I knew that until fairly recently, people used packet for spotting DX. My only formal connection with packet, though, was using APRS for position reporting. My VX-8GR handheld has an integrated GPS and on SOTA activations, I’ve brought it along to squirt status and position updates so AI4SV-9 could be tracked on sites like aprs.fi or findu.com.
The PK232 is a fantastically successful product thanks to the excellent engineering that went into it. The design was so open-ended that the 1980s device was expandable over a decade and half of upgrades and is still useful today. Despite that, these boxes are commonly seen at hamfests for a few dollars. In many ways, digital sound card modes displaced these hardware solutions, but there are still some things this box can do that a sound card cannot:
Pactor – This is a proprietary mode. The PK232 can only handle pactor level one which is darn slow, but this is good enough to use the Winlink system to send and receive email over HF;
It can serve as an interface to operate rigs in FSK mode, which may produce more accurate tones than a sound card. Also, operating in FSK mode on my TS-450 makes available the narrow CW filters that I have installed;
With the PK232 doing the heavy lifting, there are minimal demands on the host system. In fact, all you really need is a dumb terminal and knowledge of a few commands from the PK232 manual, which is online as a pdf. It is pretty amazing that the heart of the PK232 is a Z80 chip, the same CPU found in the TRS-80 model I.
The replacement battery is centered, above.
I received the PK232 without any cables, so my first step was to make a power cable with a 2.5mm barrel connector at one end and power pole connectors at the other. I was relieved to see that LEDs came on when I plugged it in. Reading through the manual, the LED pattern suggested that the PK232 had remembered some previous settings, which suggested that an internal CR02032 3V lithium battery was still powered. I wanted to reset the unit, so I opened it up and was going to pull the jumper that allows it to reset. When I got in there, though, I saw that the lithium battery looked fairly corroded. I tried to yank it, but it was soldered in very securely. I measured the voltage across the battery as 2.1V — still enough to retain memory, but perhaps not reliable for long. My only option for removing the battery was to clip its holder near the base, which I did. I found that I could then replace the holder with one from my parts bin by soldering it to the stubs of the original clip. This left me with a battery holder at a strange angle, but it means that I can replace the battery with ease in the future (should this unit survive a few more decades).
Getting LEDs to glow is always a good sign, but to know if anyone was actually home in the PK232, I needed to get it talking to a computer.
A few old school serial cable adapters.
The PK232 was designed to connect via RS-232 serial cable to a computer or terminal. The manual provides a long list of text commands to put the PK232 into various operating states. At this point, I didn’t have any of the original software for the PK232, so my only option was to type these commands directly. It took me a while to dive deep enough into the junk pile to find a bona fide RS232 cable plus the various adapters needed to take it from a 25pin male connector on the PK232 to the 9-pin male connector on my toughbook laptop. Luckily, I did have a computer with a real serial port and didn’t have to deal with the additional variable of getting a USB-serial converter to play nicely with the PK232.
The PK232 came up in its default (and strange) serial configuration of 1200 baud, 7 data, even parity. Using Windows hyperterminal, I sent the device a “RESET” command and then changed the terminal parameters to a more reasonable 9600 baud, 8 bit, 1 stop, no parity. I then sent an asterisk so the PK232 autobaud detect could synchronize. This worked, and left me at the “cmd:” prompt sent by the PK232.
The PK232 has a switch on the front that allows selection of two radios, and there are ports on the back that correspond to these radios. These ports are bare pins with 0.1 inch spacing, like the headers on an Arduino board. Each radio gets five pins: ground, sound in, sound out, squelch and PTT. Additionally, there is a 3.5mm audio input jack for each radio.
Before messing around with the 5-pin headers, I used the 3.5mm jacks to test the receive function of the PK232. I took sound out from the TS-450, set the PK232 to RTTY (Baudot mode, 45 baud, 170 Hz spacing) and found some strong RTTY signals. It took just a bit of fiddling with tuning to get the signal centered according to the PK232 signal display and to get the sound output/PK232 input sensitivity in the right range, but once I did, the PK232 did an excellent job of decoding the signal and rejecting random noise between signals.
Now that I was convinced that the PK232 wasn’t brain dead, I set up a loop back test by routing the Radio number one “audio out” to the “audio in”. I set the mode to VHF and packet and was able to “CONNECT” to myself and to echo text in “CONVERSE” mode. This assured me that a number of circuits were intact, at least for packet, so I went ahead and built a cable for my Yaesu FT-817nd. Ben (NN9S) had donated a CT39A data cable for the Yaesu, so my biggest issue was how to physically connect the wires to the pins at the back of the PK232. I soldered a 5-pin row of female SIP headers to a small piece of vector board and wired it up. Maybe not the most robust connector, but adequate for my purposes. For a little strain relief, I added a dab of hot glue where the cable comes in.
The “MHEARD” command lists stations heard over time.
Testing that packet works must have been much easier in the past: the manual recommends tuning around on “common packet frequencies” until other stations are heard, and then attempting to connect to one. I listened for quite a while and didn’t hear anything on these frequencies. A little internet search shows that there are some packet networks in my area (e.g., the Virginia Digital Network) but I didn’t hear anything on the radio. It occured to me, though, that there is one reliable, high activity service that regularly sends AX.25 packets: the APRS system. I tuned to the US national frequency of 144.390 and heard bursts every few seconds. Reassuringly, the PK232 decoded the APRS messages, although it took me a bit of reading through a very helpful primer and the original specification to make heads or tails out of the short messages. I left the radio on overnight so the PK232 could build a list of which stations were heard, and particularly, which station were heard directly, i.e., without digipeating.
Listening is great, but I was eager to start transmitting. I figured that I could test out my set up using APRS. I could hear two large “backbone” stations directly, one in Tyson’s Corner Virginia (NV4FM-5) and the other in Southern Maryland (KV3B-1). There were also some smaller home stations in Virginia, but I figured that it would be best to start with the larger stations. I only have 5W output, but both stations should be in the “beam” of my 2m antenna, a 5-element antenna that was originally built for satellite work,but which is now on a tripod jammed between the rafters of the attic.
There was an immediately problem, however. When my rig should have been transmitting, nothing happened. The indicators on the PK232 lit up correctly, so I knew that it thought it was transmitting, but the radio was inert. I double-checked that the wiring was correct. By grounding the PTT line at the PK232, I was able to trigger the radio’s transmit, so the problem appeared to be in the signaling between the PK232’s microprocessor and the PTT line.
Whatever was going on, it was clear that the transistor responsible for taking the PTT line low (Q5) was not doing its job. I did a quick internet search to see if anyone else had run into the same problem and there was a report of a similar failure that was fixed by replacing Q5 (an MPS 6561 NPN) with a 2n2222. I pulled Q5 and tested it — it was bad. However, replacing it didn’t fix the problem. I traced the signal forward from the microprocessor to a 7406 inverter chip (U38). The PTTW signal into the chip was working correctly (pin 11), but the output of that particular inverter (pin 10) was always low, whereas it should have been the opposite of pin 11. I wasn’t sure if the chip was dead or if something downstream had effectively shorted to ground, pulling the pin low regardless of how it was driven. I thought that some of the downstream transistors and/or diodes were likely components, so I worked through the transistors, testing them one at a time.
I don’t know what happened to this unit, but something blew a number of these transistors — I suspect that PK232 might have been been zapped either due to an electrical storm, or perhaps by being connected to some high voltage tube gear with negative keying. In any event, I made my best guess at replacing the bipolar transistors with what I had on hand. Next I tested Q3; it showed no voltage on any leads, keyed or not. It was an MPS 6521 and also tested bad. The 6521 is an NPN transistor with higher gain, so I replaced it with a 2n4401. Q4? Yup. Also bad. It was a 2n3906 — at last, something that I actually had in my parts inventory. I replaced it with the same. At least Q10, a 2N3904 was not blown. I was beginning to wonder if my meter was flaky, but all the measurements were repeatable. In yanking the various transistors, I was able to test the diodes in place (29, 30, 33), and they looked good. The inverter chip itself, however, still looked dead on pin 10. I chopped out the IC, cleaned up the pad and stuck in a new 74LS06. Now, it worked correctly, with pin 10 moving high/low in opposition to the state of pin 11. Everything downstream also checked out and the PTT line now correctly triggered the radio.
I squirted a test APRS message to NV4FM-5: I set the unproto path to “TEST VIA NV4FM-5” and squirted an empty message, just hitting the carriage return in converse mode. I was lucky that it was picked up. Next, I set unproto to “AP817X VIA NV4FM, WIDE1-2” and sent a location message. I saw the message forwarded and was able to find it on aprs.fi. I set the repeat time to 30 minutes and noticed that not every packet was making the relay — either due to collision or perhaps marginal power since I was QRP. I had similar mileage with KV3B. I think the problem is more likely due to collisions with signals that I can’t hear, but that these centrally located stations with large antennas can hear. That, plus FM-capture effect, may mean that I need a more powerful radio to inject messages with higher confidence. I may also need to understand APRS and the local landscape better to optimize my messaging.
The 5-pin header is jumped over to the former modem connector; the ground is taken from the CW phono jack at left.
Next, I wanted to replicate Hank’s trick of sending mail via packet. He had helped me out by installing RMS Express and Paclink when he visited, so at least I didn’t have to worry about that. I looked at a map of packet nodes and saw that there were some in the region, but perhaps not close enough to work with 5W. I tuned the rig in packet mode to their frequencies and set my HT to the same frequency as a monitor. I heard by packets go out, but never got a response. Knowing that the PK232 sends and receives packets correctly, I have to assume the problem is just reaching the RMS node with my signal. To confirm, I brought the same computer out to my car, plugged into the car’s serial cable and used the Kenwood B2000’s built-in AX.25 TNC to confirm that with more power (and higher elevation — the roof of the local metro station parking lot), I could reach these machines.
So, short of building an amplifier (a project on my list) or getting a more powerful 2M rig (not currently on the list), I’m not going to be able to work the VHF RMS nodes from the house. However, I did manage to send email using the FT817nd by using the EMAIL gateway for APRS. By setting the destination to “EMAIL” and sending a correctly formatted message, a short text string can be sent to any email address. I haven’t tried it yet, but there is also a APRS-Winlink gateway. I’m less keen on this approach because it would take multiple APRS squirts to send a single message. APRS is really meant for short messages related to local, real-time tactical information, so tying it up with email doesn’t seem like a good policy.
I created another cable for radio two, my Kenwood TS-450. The PK232 manual provides wiring diagrams for quite a few rigs including the TS-450. I could have gone into the mic jack, but felt it was preferable to use the ACC2 port, which provides output sound independent of front panel AF gain setting. The PK232 documentation and some experience reflected on the internet indicate that the TS-450 is susceptible to RF on the ACC2 port, so rather than use sound input, the common advice is to drive the TS-450 through the FSK line. This also makes the TS-450 narrow filters available in FSK mode.
The relationship of mark and space tones, center and dial frequencies for a typical RTTY 170Hz split – from the Kenwood TS-450 manual
The ACC2 port is a thirteen pin port, but the only lines that are brought over from the PK232’s radio 2 port are PTT, ground, and radio sound out. There is 5-pin DIN connector on the PK232 which provides a ground, FSK and R-FSK control lines. It also provides output for mark and space tones that are meant to drive an XY oscilloscope for RTTY tuning. Unfortunately, I didn’t have any connector that would fit this DIN, so I rerouted these lines to the header for an external modem. I don’t think I’ll ever add an external modem — if I had one, it would probably replace the entire PK232 unit. I made an adapter and brought these lines out to a small box with RCA phono plugs for these functions. At some point, I may add an oscilloscope (because it looks cool), so perhaps the mark/space lines will get used. I wired a female phono plug into the ACC line, so I could use a phono cord patch between the breakout box and the ACC2 port.
I confirmed that I could send and receive RTTY using the terminal. To operate in pactor mode, however, I had to alter the TS-450’s mark/space width from 170Hz to 200Hz. This can be done by holding down the “M.IN” button while turning the unit on, and adjusting menu setting 37 using the multi-knob. The radio retains this setting through power cycles.
The Winlink site has a real-time map of HF stations on the air. The map lists their call signs, center frequencies and capabilities in terms of pactor level. Using that map plus knowing propagation conditions, I was able to pick out some stations likely to be within range. With the radio set up in FSK-R mode, the dial shows the mark frequency, which should be 200 Hz above the space frequency. Therefore, I set the dial frequency 100 Hz above the channel center frequency indicated in RMS express. I had an outgoing email queued up, so I could confirm that this worked by looking at my gmail account afterwards.
I set power to 50W and adjusted my carrier level just below the point that ALC would kick in. After listening to make sure there was no activity, I clicked on “connect” within RMSexpress. The radio sent a few phasing bursts, followed by reply tones as the two stations synched up. The RMSExpress screen indicated progress of the session, and the email was spooled out. A few seconds later, the email was in my gmail account, sent over HF from here to a station near Norfolk, VA. Not a globe spanning connection, but proof of principle. It was early morning, so this was an 80M connection. I’ll have to try it again later in the day on the higher bands.
An observation: when it comes to audio connectors, people who need their connectors to work when they are running back and forth on a stage under hot lights and yanking their equipment around by the wiring — these are the people most likely to have evolved sturdy connectors.
The photo at right shows three quarter-inch stereo plugs. The first, I bought in bulk via mouser. They are pretty cheap: thin metal tables, tight spacing in side the connector, and the strain relief is molded plastic that is part of the barrel itself. The middle ground is from Radio Shack, probably a few years back. The barrel is phenolic plastic and there is no strain relief.
At bottom, a much sturdier metal shell that screws together and compresses the connections. This connector is from Guitar Center, and has some heft. I think it was a couple dollars more than the Radio Shack connector, but there is no question in my mind that it will last decades longer. While I was at Guitar Center, I also bought a few shorter mono-cables as patch cords and about thirty feet of two and three-conductor shielded audio cable.
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.
An observation: when it comes to audio connectors, people who need their connectors to work when they are running back and forth on a stage under hot lights and yanking their equipment around by the wiring — these are the people most likely to have evolved sturdy connectors.
