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

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

PPS

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.

powerpoleDimensions

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&cwskimmer
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.

agg_setup
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