The Crossed Bananas Display

orthagonalArguably, 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.

schema_and_boardSo, 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.

naked_board back_of_board
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.

chassic_back chassis_front
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.

top_inside rear_inside
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.

I posted the code for this project, the schematic and picture of the vector board layout at

[Update 17 May 2016]

Before Google Code evaporated, I moved the repository over to github, so all schematics, code, etc. can now be found at:

Burning ATmega328 bootloaders

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:

Error while burning bootloader. avrdude: stk500_getsynch():not in sync: resp=0x15

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.

Panel mounting power pole connectors


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.

chickletsAlas, 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.

bracketsFinally, 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.

The Business End of the RBN

RBNI 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
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.

plug07There 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.
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:

Screen Shot 2013-09-01 at 7.53.52


PK232 Reborn


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 or

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:

  1. 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;
  2. 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;
  3. 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.

schematicWhatever 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  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.

rms_nodesThe 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.


The 2nd Annual Skeeter Hunt


A few weeks after the Flight of the Bumblebees, and I was ready for the Second Annual Skeeter Hunt coordinated by Larry, W2LJ.  I had registered as operating from Virginia, but the evening before the event I looked over the list of participants and realized that there were already plenty of stations operating from VA. Likewise, West Virginia and Maryland had some coverage, but Delaware had no skeeters.  I remember that in getting my WAS-50 on LOTW, I had a hard time with Delaware. It’s a small state, there are a limited number of hams, and it seemed that not many used LOTW. So, I figured I’d give Delaware some coverage. Like the FOBB, I opted for a coastal location, this time Fenwick Island State Park.

The other motivation to drive to Delaware was that I had to cross through a lot of Maryland, allowing me to participate in the Maryland-DC QSO Party using the car radio. I didn’t have the log computer along, so I jotted my log on a pad as I went along and only operated voice. I had some nice strings where I worked the same stations from multiple Maryland counties.

I had scoped out Fenwick Island State Park on Google Earth, so I had some idea where I was going. After paying the somewhat punitive-feeling out of state price to park (eight bucks! Oh well, I’m here now…), I followed the beach goers seaward, hauling a  radio bag and a wrist-rocket tennis ball launcher. After reconnoitering the beach, I found that the “stand of trees” that I had seen on Google satellite view was a bunch of bushes about three feet tall. I hiked back to the car, got a telescoping mast, and tied it to a log that had been piled into the sand in front of a dune. As in the FOBB, I set up a 20m “untangleable dipole” and got to work.

I immediately worked a bunch of stations S&P, but had less success calling. As the afternoon went along, I heard more and more WAE stations in the QRP area. While I have a sharp audio filter on the 817, the front end is wide open. I had held off on working the WAE stations, but was pleased to hear F5NBU responding not with a WAE exchange, but “599 5W”.  I realize now that my strategy should have been to work more of the WAE stations (and that I should get an RF filter for the 817). Also, although I like the dipole, I might have been better served by lofting the 40m EFHW with tuner. In any event, I had a great time and as a side benefit, had the opportunity to explain ham radio to a bunch of curious beach goers. One guy asked me,

“Did you need to get special permission to put that [the antenna] up?”.  I replied, “No. It’s just like a very tall beach umbrella, without the umbrella part.”

Aside from the usual radio operating skills, two others came into play: 1) working the radio while explaining what I was doing to curious beachgoers; and 2) managing not to get sand in everything.

The bottom line: I worked 18 other skeeters, plus 3 non-skeeters in thirteen states plus Ontario.  My two DX contacts were France and Poland. While I had a number of homebrew components in the station (the antenna, the audio filter, etc.), the main rig was commercial, so I took the “3x” multiplier for field operation.

FOBB 2013

sidepluslighthouse_smWhile on vacation on the beach in Montauk, New York, I took part in this year’s Flight of the Bumblebees, a QRP event in which portable stations receive a bumblebee number in advance of the event, and work home stations and each other during a four hour period.  I wasn’t sure that I’d have time to play radio this weekend, as this was a family outing, but by the Sunday of the event, the family had enough sun and sand, and I was able to drive to Camp Hero to set up my station.

This is about the best location that I could ask for: the very tip of Long Island: surrounded on three sides by salt water, no neighbors or noisy interference (except occasional low-flying planes and helicopters), and a flat plane in all directions. Camp Hero is a former US Air Force Base, but is now a New York State Park. It is a little less traveled than the rest of Montauk as there is a small cover fee to enter the park, and there is no beach. The park is surrounded by cliffs with warnings that the edges may be undermined and that people should keep back from them.

birdWhen I got to the parking lot on the Atlantic side of the park, I took it as a good sign that a giant (now inactive) radar dish was keeping watch over my site. I struck on foot to the NE along a path that parallels the cliffs. It was tempting to set up on what must have been a missile placement, but I kept going, past various bushes until I came to an area that had a conveniently placed wood fence. In the distance, the Montauk lighthouse alternately faded and resolidified in the mist.

I managed to carry in everything in one trip: a push up mast, antenna, radios, chair, operating table, batteries, water, etc. Earlier this year, when W7SUA moved to Arizona, I had purchased a push-up mast from him, and that mast was used to support the center of the “untangleable folded dipole” that I had made earlier this year for the W5O operation at the QRPTTF event.  I attached the mast about six feed down because the top gets pretty thin and I wasn’t keen to guy the pole. In fact, I got away with duct taping the pole to the fence at two points and called it a day. I tied down the two ends of the folded dipole to form an inverted V. The antenna had given me about 1:1 swr when flat topped at QRPTTF, and it did likewise in this configuration — which is good, since I didn’t bring a tuner.

I set up the FT817nd using a 2Ah battery as a support and a 7Ah battery as a back-stop. As usual, the palm paddle key mounted magnetically on the 817. Since the 817 is wide as a barn, with no roof filter, I ran the speaker output through my recently built switched capacitor audio filter based on the New England QRP Club’s NESCAF design. I cranked the filter over to “narrow” and peaked it on my side tone. After that, the filter made all the difference in the world in pulling out close-in signals. Thankfully, there were no other major contests that weekend except the NJQP, which was inside the skip zone, so front-end overload was not an issue.

equippileI slathered myself in sun block, downed a liter of water and settled in about half an hour before the event. I had a test QSO with with Mark, K4NC, who said that he was also getting ready to try QRP in the FOBB. I wished him luck and was glad to work him again a few hours later during the contest proper.

In four hours, I logged 69 contacts, although three were duplicates. It may be that those stations didn’t copy all my info on the first pass or that like me they were logging by hand in a notebook, so I happily worked them a second time.  Of the 66 stations worked, 40 were fellow bumblebees. I noted that a couple stations were on the event listing as bumblebees, but gave their power in the exchange, so I assume that they were folks that had planned to get into the field, but had to work as a home station on the day of the event, likely due to weather.  Contacts included 27 US States, including all three continental west coast states. In Canada, I had two contacts to Ontario, and my best DX was with France grâce à F6BZG.  Most of the non-bumblebee stations sent 5W, and the lowest power in my log was 2W K4MU and 3W AA7EQ.

20 meters yielded a fairly steady rate, and having carried in 9Ah worth of battery, I was not adverse to calling CQ all afternoon. I had a couple lulls, but was happy enough with 20 meters that I didn’t feel compelled to dig into my bag for the 15 meter end-fed that I had also brought along. Twenty seemed to be in good shape all afternoon.

I worked W7CNL‘s 4W station from Idaho just under the wire at the conclusion of the contest – this was a 339/339 exchange, and we were both struggling as the clock counted down.  Thanks, W7CNL for hanging in there!  FOBB was a FB event.

Guitar Center

Quarter Inch PlugsAn 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.

FD 2013

meatonforkOnce again, the Vienna Wireless Society participated in ARRL Field Day from Burke Lake Park in Northern Virginia. For the last three years, I have captained the non-40m CW tent. The plan this year was slightly updated to move the stations closer together, while maintaining adequate antenna spacing.

sunnySpiderI had a few secret weapons this year. First, with the move up the hill, I was close to the spider beam mount that I was able to use it to work 20 meters, and for a bit of the contest, 10 meters. The 40m station typically runs 15 meters, so I did not use the beam on that band. When the spider beam went up, I also tacked on an AO-50 omnidirectional 6 meter antenna, so we picked up a few contacts on that band as well, but far fewer than I had hoped. The other trick I had up my sleeve was to roll out a newly minted K3 rig. I had put it together about two weeks back, just in time to test it out in the NAQCC sprint for May. In addition to the stock 2.7 kHz roofing filter, the K3 has 200 and 400 Hz roofing filters for CW.

As for weather, we enjoyed both heat and humidity on Saturday and were surprised by chilling, drenching thunderstorm on Sunday. Good times.

I’ve stopped hearing CW in my car creaks and the howling of my home’s air ducts, but my brain is still not entirely recovered from the continuous operation of the station over that 24 hour period. Thanks to Leon, NT8B, I did catch some sleep during the event, otherwise I would be even more posty-toasty.

Some preliminary results (some contacts logged separately, e.g., our VHF activity, also all of the added point categories like GOTA, solar power, etc., are not included):

Band Mode QSOs Pts
1.8 LSB 3 3
3.5 CW 185 370
3.5 LSB 66 66
7 CW 424 848
7 LSB 477 477
14 CW 376 752
14 USB 45 45
21 CW 34 68
21 USB 121 121
28 CW 38 76
28 USB 27 27
50 CW 3 6
TL Both 1799 2859

Things that were planned and worked out well:

  • Rain gear: Packed a poncho and umbrella despite a clear forecast. Similarly, packed long sleeve shirts and a sweater despite heat and humidity in the 90s.
  • Trash bags: Plastic bags enabled us to keep the station up, even when sideways rain was splashing through the mesh sides of our operating tent
  • Plastic sheeting stashed in the club’s field day bucket, someone years back had thought to buy some large plastic sheets. Not long after rain started, John Righi realized that he could drape our tent with the sheets to keep water out.
  • The spider beam: It is a pain to put up, but works well.
  • N1MM: Prior planning and testing with N1MM lead to a smooth operation
  • Poison Ivy on the main antenna support tree: Recognized, avoided.
  • Food: Yummy, and plenty of it.

groundrodThings that did not go entirely according to plan:

  • The deep-dwelling ground rod: An 8-foot ground rod, hammered in 4 feet deep proved difficult to extract. With many helpers, a hydraulic jack, a vise grip to provide purchase on the rod, and a thick wood log to increase surface area under the jack, the rod was recovered, averting plan B, which involved a hack saw.
  • The tree-loving guy line: one of the supports for the 80m dipole was particularly long, and an overlooked knot in the end became fouled on a high tree branch. Pulling only lead to comical moonbouncing around on the lawn. The solution: tying the line to a pick up truck and running for cover. The 3/8″ line held, a tree branch came down, and the problem was considered solved.
  • The logging computer, an old Panasonic Toughbook, decided that its track pad would no longer function when we set it up at the station. The touch screen still worked, so we weren’t entirely out of luck, but we had to scramble a bit to find an external mouse. I’m still not sure what happened, as the pad had worked right through the WVQP a week ago, and up to the previous evening when I was setting up the database for field day.
  • It turned out that we did not have a satellite station for field day, so between HF stints, Ben Gelb and I monitored satelite passes and attempted to jury rig a station from my car, which is outfitted with a computer controlled TS-2000. Ben was at least familiar with the software, whereas I was reading the TS2000 manual right up to the first pass. We had a 70cm yagi, the car’s 70cm/2m vertical, and a small 70cm magmount antenna. We ran HRD’s satellite tracking program, and set up a waterfall using Ben’s digicube dongle, while the TS2000 provided duplex audio for both up and downlink. We did manage to find the satellites each time, but had some difficulty setting the T/R offset and tuning around in real time during the pass. We heard both CW and SSB transmissions on the birds, and even succeeded in hearing our own CW signal, so at least we knew that we were making it in. This set up may have worked on a quieter day, and I think it needs only a bit of tweaking to get it right…maybe next year, with some practice in between.

Things to consider for next year:

  • We worked absolutely everyone that we heard and were often the first station through pile-ups. Maybe we could go entirely QRP next year? Bigger score multiplier, less inter-station interference
  • Check that we have plastic sheeting for every operating position.
  • Check wireless routers for RF emission. I’m not sure this was a problem, but something blanked out our satellite receive capability on one pass, and having eliminated other sources, we suspect a wifi router may have been the culprit.