Author: Jack

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.

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

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.

[Update 5 June 2016]

KC9ON has put together some nice kits based on the same code base, but with added features, a code practice oscillator and a small keyer board.

[Update 03 April 2024]

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.

I posted the code for this project, the schematic and picture of the vector board layout at https://code.google.com/p/crossed-bananas-display/.

[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: https://github.com/dhakajack/crossed-bananas-display

[Update 03 April 2024]

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.