LM34DZ Fahrenheit Temperature Sensor

February 2nd, 2009 by Keith Neufeld

This started as notes I made to myself long ago for the LogoChip, but they apply equally to the Arduino A/D converters.

The LM34DZ is a temperature sensor in a TO-92 case available from All Electronics for $2.50. It has the handy characteristic of reading an output voltage that directly corresponds to Fahrenheit temperature in a ratio of 10mV per °F. That is, at 70°F it reads 70 * 10mV = 700mV.

LM34DZ Fahrenheit temperature sensor

With a direct output voltage (rather than the varying resistance that many thermal probes provide), it’s perfect for hooking to a microcontroller A/D input. So, how to convert the A/D reading back into Fahrenheit temperature?

Well, the sensor reads 10mV (or .01V) per °F. Microcontroller A/D converters tend to have 5V input and read 1024 steps over the 0-5V range.

1024 steps / 5V ≈ 205 steps / V

So

(.01V / °F) * (205 steps / V) ≈ 2 steps / °F

Thus you can get a “maybe close enough” approximation with code like

tempF = analogRead(lm34Pin) / 2;

With a conversion error of +2.4%, this’ll get you within a couple of degrees at room temperature — close enough to make some macro-level observations about whether it’s getting warmer or colder for a physical computing project. Since the stated accuracy is only 1°F anyway, that’s not too bad.

If you need a more accurate conversion, you’ll need to use floating-point arithmetic if you have it (which the Arduino doesn’t [correction: does]) or find a fixed-point arithmetic library if you don’t. Or if your integer variables are large enough (at least 17 unsigned bits for temperatures up to 127°F, 18 bits up to 255°F), you can rearrange the order of calculation like so:

tempF = (1024 * analogRead(lm34Pin)) / 5;

Scooba First Impressions

February 1st, 2009 by Keith Neufeld

I love how my Roombas help keep pet hair picked up with a minimum of effort; and I’ve been fascinated by the idea of the Scooba, iRobot’s wet-mopping robot, since it was announced. I recently picked up a used 5900 in very nice condition on eBay from a wonderful seller who even included a spare battery.

Scooba 5900

I want to start with a pictorial overview, since I hadn’t seen enough Scooba pictures to understand how different it really is from the Roombas, then proceed to a few comments about my experience with it so far.

Read the rest of this entry »

Motion Sensors for Occupancy Tracking

January 30th, 2009 by Keith Neufeld

This NewScientist article from last spring shows a very cool system of motion sensors for occupancy tracking. The sensors are installed more densely than in typical buildings, so they can detect occupants’ positions fairly precisely within hallways.

The most interesting part of the system for me is the video showing playback of motion through a building — you can clearly see where people were walking, where they ended up, etc.

This seems like a natural fit for a smart house — instead of just watching where there’s motion now, pay attention to where the motion has gone and remember that there must still be someone in that room (even if they’re not moving much now).

$10 Parallax motion sensors + blinders to narrow the cone of coverage + write open-source software for the capture and playback, anyone?

Project Idea: LED Puzzle Ball

January 30th, 2009 by Keith Neufeld

A long time back, I was over at Lawrence’s house and Gail had a number puzzle up on the whiteboard that she was using with her homeschool consortium gradeschool math class.

Number Puzzle

For the students, I think Gail drew the circles with pebbles in them and the younglings had to count the pebbles and write the sums of the nodes into the edges.

For adults, it’s a lot more interesting to start with the numbered edges and fill in the vertices with numbers that make the edge sums work. It’s not hard; it’s just a little bit of a twisty way of thinking.

And you have to keep your vertices balanced enough that you don’t “overflow” an edge. For example, if you started with one pebble in the upper left, then you’d have to have four in the upper right, and then zero in the lower right, and let’s just say that zero pebbles isn’t permitted. Any solvable configuration will have multiple correct answers, but they’re constrained by overflow and underflow of all the edges of the graph.

Puzzle Ball

All of which made me think that this concept could make for an interesting LED puzzle ball. Make a dodecahedron (or a smaller regular polyhedron, or even a larger geodesic shape) with LEDs along the edges and LEDs and buttons (up/down?) at the vertices.

Start it up, the LEDs flash and wink all over the place as the controller randomizes the configuration. Use the buttons to adjust the numbers at the vertices (maybe blue LEDs) so that adjacent vertices add up to the number of LEDs on that edge. As each edge is “solved,” its LEDs change from red to green. Once you have all the edges green, you’re done.

Aesthetics

Seems like it’d be coolest as a “wireframe” polyhedron rather than a solid (or solid surface).

I think I’d prefer SMT LEDs over through-hole. 3mm through-hole if absolutely necessary.

I think I’d like the edge LEDs to be strips of nine that light up fairly symmetrically from the middle out, i.e. something like

----o----              ----o----
---o-o---              ---oo----
--o-o-o--              ---ooo---
-o-o-o-o-          or  --oooo---
o-o-o-o-o         the  --ooooo--
-ooo-ooo-      boring  -oooooo--
-ooooooo-              -ooooooo-
oooo-oooo              oooooooo-
ooooooooo              ooooooooo

I’d like the whole thing to be constructed from PCBs, no separate case. There’ll need to be room for microcontrollers and/or LED drivers. Maybe instead of having the PCBs on the face of the polyhedron, have them edgewise so the PCBs’ outer edges are the edges of the polyhedron. Internally, PCBs could be held together by jumper wires soldered together at the board edges and carrying the signaling bus from one board to another.

Gameplay

I still haven’t decided whether solving the puzzle ball would be fun or merely tedious.

I remember a particular game mode in the old Merlin where you’d press buttons and all the adjacent squares would invert state, with the goal being to get all the lights on or off. I always enjoyed that game, and the way local changes impacted neighboring cells, which impacted strategy for dealing with those neighbors. I would hope that the puzzle ball would be fun in much the same way.

If each edge has nine LEDs (1 – 9) and the game is played with non-modular addition, then the average number of lit LEDs per edge will be 5.5, making the average number of lit LEDs per vertex only 2.75 — that is, on average, only a very few numbers that need to be tried at each vertex. That doesn’t sound like a very interesting game. I could increase the number of LEDs per edge to 20ish, making the average edge sum 10ish, making the average vertex 5ish, which seems okay.

Or should there be ten LEDs per edge and operate in modular arithmetic? Would that make the puzzle too easy, having more correct solutions?

“Organic Energy Cloud” Installation

January 27th, 2009 by Keith Neufeld

This has been a tough post for me to get around to writing, mainly because I don’t feel I have particularly good pictures of the process or the result, as I was working so intently during the installation that I really didn’t have time to stop and document. But here’s what I have.

Back in November, I made a small edge-lit plexiglass demo as a technology study for a large LED and plastic piece that came to be called “Organic Energy Cloud.” I’ve already written about the design and construction of the LED driver modules; all that remains is the Arduino code and the installation.

Assembly

Lisa Rundstrom installing LEDs on Organic Energy Cloud exhibit

That Friday, while I was connecting all the wires together and working on Arduino code, Lisa was hanging plastic,

A6276 LED driver board, wires, and plastic in Lisa Rundstrom's Organic Energy Cloud

placing LED controllers in it,

Wires and acrylic in Lisa Rundstrom's Organic Energy Cloud

routing wires, and hot-gluing the SMT LEDs onto the ends and bends of the plastic pieces.

Melty Disaster (Having Nothing to Do with Hot Glue)

I had been programming LED patterns into the Arduino, testing and fixing some bad connections, and occasionally alarming Lisa and her helpers by making everything go dark (Alarmed words from the ladder: “Did I do something???”) or light (“Whoa!, what’s that?”).

About 18:50, ten minutes before the show was scheduled to open, I was running wire from DC motors attached to a couple of bicycle wheels (it was a bicycle-themed show called rEvolve; more on that when we collect all the materials and get the web site up) to the breadboard, and the black jumper wire between the breadboard and the Arduino melted right in front of my face.

Arduino and Organic Energy Cloud bus/wiring

It turned bright orange, the insulation was dripping off of it, and I couldn’t figure out what tool I might have at hand that I could use to disconnect things without getting burned. It only lasted a second before it melted the wire, too — even had I jumped for the switch on the PC power supply I was using, the circuit would have opened from the wire melting before the power supply’s capacitors had drained.

After discarding the scorched ends of the jumper wire, I looked over the circuit carefully and couldn’t find anything wrong, and I still haven’t figured out what happened. The melted wire was the ground wire connecting the power supply to the Arduino via the breadboard. My wild speculation is that I bumped something that shorted, the wires warmed up and increased their resistance, and the ground wire became the resistor that now dissipated all of the circuit’s energy.

I hooked things back up and with great trepidation (and this time ready to kill power if needed) turned things back on, and they seemed to work. The Arduino booted and resumed its test pattern, the lights came on, etc. But I quickly found that I no longer had connectivity between the iBook and the Arduino.

Since the Arduino appeared to work except for the USB interface, my immediate guess was that the FTDI USB-serial chip had burned out — which turned out to be correct, and which I have since successfully replaced. I had brought another Arduino to use as a backup if anything happened to my first one; but with now five minutes before the official gallery opening, and early arrivals already wandering around, I didn’t feel I had time to swap out the Arduino, program the new one, and be confident everything was going to work.

Fortunately, I had a reasonable program running at the time, which picked a random LED out of the entire piece and then randomly turned it on or off:

  cont = FIRST_BANK + random(LAST_BANK + 1 - FIRST_BANK);
  led = random(32);

  if (random(10) > 3) {
    leds[cont] |= (long) 1 << led;
  } else {
    leds[cont] &= ~ ((long) 1 << led);
  }
  a6276_long(leds[cont]);
  a6276_latch(cont);

If that doesn't make sense, spend a little time thinking about how you would program a nice, random flickering effect with a bunch of LEDs.

Here's the whole program, commented-out test code and all, since even this was still supposed to be test code. That's what we left running all evening.

And the Show Goes On

Lisa Rundstrom's Organic Energy Cloud exhibit

Ready or not, the lights go out, the people come in, and the girls at the refreshments table start serving coffee and hot chocolate "with or without something fun in it."

Lisa Rundstrom's Organic Energy Cloud exhibit

This piece deviated far from its original conception, and also ended up not being fully realized due to scheduling and time issues, but it's only fair to show it with the bicycles, even though they no longer made sense as part of the exhibit.

Finally, here's a video of the cloud that was shot by Tom McGuire. Tom had already posted it to YouTube, but I found that the compression had blurred almost all of the detail. He graciously gave me a copy of the raw footage from his camera (which looked fantastic), and between iMovie and Vimeo, I think I managed to keep a little more detail in some of the closeups.

Aftermath

Lisa Rundstrom's Organic Energy Cloud by the light of day

The group opened the gallery for another show on the next Thursday evening when I had to be out of town, and we had to be cleared out of the space by that Saturday morning. Arriving at 06:00 Saturday gave me a chance to take a few more pictures with the space lighted, which show a little more detail of the components of the piece and of the space in which the cloud was installed.

Project Idea: Build a Better Looper

January 26th, 2009 by Keith Neufeld

Jeremy and I have been playing with my “new” Akai Headrush E2 looper pedal, which allows you to record an instrument (or whatever) into it; then it plays your mini-recording back for you over and over and over in a loop, and you can play along. You can also overdub, recording more stuff on top of what’s already there and building up a more complex mix in the loop — this is how KT Tunstall does solo performances of “Black Horse and the Cherry Tree”, which are just amazing to watch.

Akai Headrush E2 Delay/Loop controller, cleaned

However, Jeremy and I both have some issues with the feature set and the user interface of the Akai, and we’re thinking about what it would take to build a better looper — or at least, one more suited to our desires.

Feature Wishlist

Here’s what we want:

  • At least 60 seconds of loop time, which would be enough to play 12-bar blues at a fairly slow tempo. The Akai’s 17.8 seconds in low-fi mode is enough for KT to do two measures of rhythm and backing vocals, but not enough to record a full chord sequence.
  • Tap a Record footswitch to begin recording, tap again to end the recording and start looping. It doesn’t absolutely have to be the same switch; but some loopers out there use a potentiometer to set loop duration. We want duration to be determined by the duration of the phrase we played, as it is with the Akai.
  • Independently-addressable tracks or channels. The Akai lets you discard all of your mix except your very first pass and rebuild from there. We want to have (say) eight tracks/channels in the loop mix, each with a footswitch and red/green LED. Tap Record and the next unused channel winks green and records. Tap any channel’s footswitch to put it in (green LED) or out (red LED) of the mix. Not-yet-used channels are dark.
  • Independently rerecordable channels. To rerecord a channel, tap it out of the mix and immediately tap the Rerecord footswitch (which is separate from Record and a little further back or off to the side). That channel winks green and rerecords. Various loopers have varying levels of undo or redub, but none (that I’ve found) let you do this.
  • Ideally have stereo recording so I can loop with the full stereo chorus effect of my analog synths.

There’s room to negotiate on the exact UI, but that should convey the feature set we’re after.

How to Build It?

John suggested using an AudioPint and Pd, and I think I may prototype this with an Arduino to run the control panel and Pd on a laptop to do the audio. But ultimately I’d like to build at least two of these in nice stage-ready stompable enclosures, and I really don’t feel like using a general-purpose OS, for a number of reasons.

It seems to me that this might be a good project for a DSP or an FPGA, but I don’t know enough to make a choice. Any suggestions? (I know I don’t need the full power of a DSP.)

What I’d love to find in one IC would be:

  • Dual 16-bit ADC and DAC capable of 44.1kHz
  • Address and data buses capable of addressing enough external RAM for the audio (say about 1G for stereo * 16 bits * 44100 samples/second * 60 seconds * 8 channels) without my having to worry about DRAM refresh circuitry
  • A processor that I can program for the very simple, core task of summing/averaging samples from the active channels to feed to the DAC
  • ~32 I/O pins to manage the control panel, and/or I2C or SPI to use offboard I/O chips
  • Ideally a USB interface for uploading samples to a computer, but this would be an extremely low priority

Does such a thing exist? Is that necessarily an FPGA? Can I get a development environment for < $500 and a chip for < $30?

Read the rest of this entry »

“Trash” from Cluster Computing Install

January 26th, 2009 by Keith Neufeld

After installation of the most recent rack of cluster servers at work, the high-performance team left a box of “trash” sitting around. Mel from Operations thought I might be interested and brought it to me, and he guessed right.

The box had all the usual detritus from the installation of new computers — manuals that I put in recycling instead of the landfill, warranty cards, used twist ties . . . and this:

In bags

Lots of plastic baggies containing things looking vaguely interesting.

Opened and sorted, I have:

Coils of remote LED indicator cables

Closeup of remote LED indicators

23 LED remote indicator assemblies with bicolor orange/blue LEDs at one end of 4′ cables and barrel connectors at the other,

Rackmount cable management clips

Lots of plastic guides to clip into the corner of a cable management piece and hold a cable in position, complete with installation instructions!,

Rack brackets and screws and feet

A pair of rackmount ears that I can modify to fit my refurbished 1U rackmount APC UPS, a very nice set of rubber feet that I think will replace the missing originals on my secondhand Akai Headrush delay/looping pedal, and a bunch of M5 machine screws for rack rails I don’t have.

Not bad for free.

Repairing Roomba Scheduler

January 20th, 2009 by Keith Neufeld

Over the holidays, I tried to fix my Roomba Scheduler. I ended up deciding not to try to trace from the battery connector to locate what part had shorted/burned when I connected a rebuilt battery with reverse polarity, I found an eBay seller with remanufactured main boards, and I ordered one for $20.

Refurbished Roomba Scheduler main board

Yesterday I had time to swap it out and get Roomba working again.

Board Replacement

I had the new board completely mounted and half the connectors wired up when I noticed the first problem:

Original and replacement Roomba Scheduler main boards with different dirt sensor jacks

My Roomba has two dirt detectors, and J9 has two rows of pins, one row to each piezo assembly. The refurbed MB had a single-row J9, apparently from an earlier model with a single dirt detector.

I debated a bit about contacting the seller, but decided it was a waste of his time and mine to ask for a replacement board when I had everything I needed already at hand. I desoldered J9 from my original board (tedious heat-tug-heat-tug-heat-tug that demonstrates how good J9′s plastic is because it didn’t melt and how good the PCB is because the only thing I ruined was one of the test points), and had a much easier time desoldering the single-row J9 from the new board.

Roomba Scheduler main board with dirt sensor jack removed for replacement

Then I got frustrated trying to get the solder out of the through holes. I had some success adding solder to the holes and applying solder wick, but there were three holes I just couldn’t get. Finally I gave up and pulled out the PCB drill bit set — a #68 bit spun gently by hand turns out to be just the ticket for cleaning the solder out of these holes. (Never again will I try to wick solder out of empty holes.)

Roomba Scheduler main board with dirt sensor jack replaced

I cleaned the two-row jack’s leads with a wire brush, soldered it in, took a picture from an angle that looks like I still have the single-row jack in the board, and reassembled Roomba.

Attempt #1

I was delighted to see it turn on when I pressed the power button. I knew that should be what would happen, but it was still gratifying to see it actually happen.

Prematurely. Gratifying.

I took it to the living room to vacuum, hit Clean, and it just burped. It burped when I hit any button. Grrrr.

Diagnostics and Cliff Sensors

The first page I found when searching for why it was “burping” was What is Roomba saying to me?, which says that the “eh” sound means there’s a faulty cliff sensor.

I relocated the Roomba Discovery models’ diagnostic tests page and ran through the individual sensor diagnostics. On test 2, outer cliff sensors, only the starboard-most sensor worked properly; the outer port sensor showed “cliff” all the time. On test 3, both inner sensors showed “cliff” all the time.

Gathering more test materials and retesting, I found that only the outer starboard sensor’s IR LED was lighting my infrared sensor card (apparently no longer sold at Radio Shack, but apparently formerly part number 276-099 and/or 276-1099), and the cliff-sensor IR LEDs were dark. Further, shining the virtual wall’s IR LED beacon into the cliff sensors caused the diagnostic LEDs to flicker, indicating that the cliff-sensor IR detectors (phototransistors or photodiodes) were working properly, so the problem definitely seemed to be in the LEDs.

Testing Roomba Scheduler cliff sensor IR LEDs

All three of the dark LEDs individually checked good with the diode tester on my multimeter. Tracing the cliff sensors’ LEDs, I found that the three dark ones were all powered in a single series circuit, fed by the red (anode) and orange (cathode) wires in the top row of J24 at the port end of the main board.

My meter’s diode tester didn’t use a high enough voltage to overcome the forward voltage drop of the series string, so I hooked my bench power supply to a 1KΩ resistor and the series chain. All the LEDs now glowed on my IR sensor card, so the LEDs weren’t faulty (which I had assumed anyway) — the problem was with the driver.

Robot Reviews Forum and Q4 LED Driver

Searching online for advice, I quickly found this forum post titled “Cliff sensor failure apart from one” complaining of exactly the same problem. “Gordon,” a very knowledgeable contributor, indicated that the dark LEDs were all driven by the same transistor, Q4.

I found Q4 on the board and it was twisted, so I straightened it without particularly thinking. (This fact isn’t relevant yet. Just wait.)

Gordon indicated which MB test points correspond to which Q4 pins, provided an apparently reverse-engineered and incredibly helpful schematic of the cliff-sensor LED drive system, and indicated that the Q4 and Q37 bases should have a 1kHz square wave on them, with a corresponding signal on the collectors.

I put the scope on Q4 and its base was oscillating nicely, but its collector stayed high. This made me suspect a faulty Q4, so I quickly and cleanly desoldered it and checked it in my out-of-circuit transistor tester. The tester said it was good with a β of about 220, which wasn’t what I wanted to see. I wanted it to be broken.

Transistor with detached leg

And then while I was straightening the leads and pondering what to do next, the emitter leg felt loose and I pulled it out with my fingers. Removed, it looked rather like a dessicated cricket leg you’d find in a corner.

Roomba Scheduler with replacement cliff sensor LED drive transistor Q4

I don’t have SS8050s on hand (that I know of), but they’re all over the MB and appear to be used as general-purpose transistors. I found a 2N3904 with the same pinout in my parts bin (if you think all TO-92 transistors with the same part number have the same pinout, you haven’t shopped enough different manufacturers), tested about the same β, installed it, and the IR LEDs all glowed.

I could have pulled an SS8050 from my original MB, but (1) I wanted to keep it intact, and (2) I wanted to demonstrate that another transistor would work. And so it did!

Sweet, Sweet Success

Roomba Scheduler powered up and ready to run

Roomba powered up again, but this time it didn’t burp (I mean “eh”) when I hit buttons, and it went straight into cleaning mode. Woo-hoo! I took it to the living room and let it clean, and it ran the course and picked up all the cat hair.

Today I emailed the eBay seller just to let him know what had happened. I wasn’t upset and I left him all positive feedback because the board he sold me fixed my problems within my abilities, plus I may have broken Q4 myself while straightening it, plus I had some fun tracing the problem. But I thought he should know what happened so he could check future boards more carefully for customers less fascinated by the process of repair.

He replied:

wow, yes you went above and beyond what I would expect. Thanks for helping out, i’m sorry you had to do so much.

sounds like the glass is half full with you.

There may be some truth to that.

Replacing a Dead Arduino FTDI USB-Serial Chip

January 19th, 2009 by Keith Neufeld

During the installation of “Organic Energy Cloud”, right after one of my fly wires turned bright red and dripped off the breadboard, I stopped being able to upload programs to the Arduino. As it was five minutes before the gallery opening, I didn’t want to take the time to replace the Arduino with a spare (that I’d had the foresight to bring along); and the Arduino was still operating with the last program I had loaded, which fortunately was sending a random twinkling pattern to the LEDs.

So I left it be and made a mental note to check it out later. Since the ATmega was still working but I had no communication with the board, I already had a guess that the FTDI FT232RL USB-serial chip was burned out. And I happened to have one on hand that I had ordered for testing LED puck USB control — which has been waiting for a year and can afford to wait a little longer.

Diagnostics

Arduino with broken FTDI FT232RL chip and TX and RX lights stuck on

I hooked it up this morning and found that the TX and RX LEDs stay on solid (which my CoolPix doesn’t capture well) — not a good sign.

Arduino IDE with no USB serial connection available

And the IDE’s serial port selection menu doesn’t list the USB serial connection as an option, further confirmation that the FTDI chip is toasty.

Removal

Removing SMT chips would be a great job for a hot air pencil. Since I don’t have one, I blobbed solder across all the leads on one side, then heated the solder mass with the iron while gently prying up that edge of the chip. It came up quickly and with little resistance, and I repeated the trick on the other side, then mopped up the excess solder with solder wick and brushed off the inevitable flux with rubbing alcohol.

Arduino Diecimila with FTDI FT232RL chip removed, closeup

I pulled the pads for pins 27 and 28 completely off the board, but they were unconnected and are for an optional 12MHz external oscillator not used in this design. I also noted the bridge between pads 25 and 26, but it appears to be by design — the pins are both tied to ground anyway, 25 being AGND and 26 being TEST that must be tied to ground for normal operation.

Replacement

I tried using the blob-and-drag method to solder the new chip in place, but ended up using the SparkFun blob-and-wick method instead.

Arduino with replaced FTDI FT232RL chip

After cleaning the flux again, the resulting board looks pretty reasonable (although I managed to get the chip on crooked, dang it). And the serial lights aren’t solid any more,

Arduino IDE with USB serial connection available and selected

and the board now shows up in the list of connection, and I can download programs to it again. Hoo-rah!

Fixing a Buzzing Clock Radio

December 31st, 2008 by Keith Neufeld

I’ve been using this clock radio for at least twenty-three years, and I love being able to read its huge 2″ digits when I wake up during the night and my eyes are blurry and unfocused. It’s having a little trouble here competing with the sunlight streaming in the side window, but it’s nice and bright at night when I need it.

Spartus clock radio

Lately it’s picked up an annoying habit of buzzing at, you guessed it, 60Hz. The intensity and timbre of the buzz vary, sometimes coming and going at the same time I can hear the furnace fan starting up and shutting down, sometimes apparently at random.

Listening carefully has led me to believe that the buzz isn’t coming from the speaker end of the clock, but rather from the power supply end. Speaker buzz would suggest bad filter capacitors (and one could certainly forgive twenty-five-year-old electrolytics for needing to be replaced); but power supply buzz makes me think of transformer windings coming loose and needing to be re-epoxied, metal brackets near the transformer working loose and needing to be tightened, and that sort of thing.

Today I had time to open it up and — I think — fix the problem.

Spartus clock radio, interior

Most of that is radio circuitry, and I don’t even use the radio. The clock part appears to be two ICs underneath the raised pushbutton circuit board. The transformer is in the “basement level” between the two posts to the left of the display’s ribbon cable.

Transformer with loose mounting screw

Right away I could see something I suspected was at least part of the problem. The transformer’s forward mounting tab was bent at other than the proper 90° angle from the body, only one edge of the mounting screw’s head was in contact with the tab, and there was a lot of slack between the tab and the mounting boss.

After removing the main PCB to make room to get a screwdriver in there and straightening the mounting tab with pliers, I got the screw tightened down properly. I could tell that the screw hadn’t worked loose over time but had been assembled this way at the factory: I could feel that I was tapping new threads into the mounting boss as I turned. Expecting the plastic to be fairly brittle after twenty-plus years, I worked gingerly, and successfully tightened the screw without breaking the plastic.

Transformer with loose crimped tab

While turning the screw, the entire end of the transformer’s cover was rocking from side to side, and a different angle revealed the reason and a second likely suspect for the buzzing sound (of which I carefully took this out-of-focus picture). The mounting cover had an edge bent out away from the laminated core and a loose tab.

After a little work tightening things with pliers and pressure, the cover seemed to be pretty well fastened. I checked the power supply electrolytics with my Capacitor Wizard since I had the clock open anyway, and they all tested good. I reassembled the clock, retesting for buzz several times along the way, and so far the buzz appears to have been banished.

The transformer problem was clearly a manufacturing defect; and it’s interesting to think that it took over twenty years to manifest itself. Here’s to the next twenty!