
The Most Annoying Sound
"The contacts in these off-the-shelf charger cradles broke, can you replace them?" Asked my client, and immediately continued: "And while you're at it, can you put a speaker in there, to make a very annoying sound if the rechargeable unit is taken away for too long?"
An Unusual Request
I was not fazed by this upside-down assignment; that's just this client's style, not an attempt to belittle effort. It was the "very annoying" requirement which set me on a mental journey, navigating between the philosophical, the comical, and the practical: What does it mean, exactly? Is it within the scope of my role as an embedded developer? In what ways can it be achieved? And, most importantly, how to do it within the confines of this specific little embedded project?
Of course, devices which annoy users are ubiquitous, but it's usually a side effect, not the anticipated result of a design choice. A famous exception may be the little prank gadget called "Annoyatron": it makes occasional random beeps from a hidden location, driving the victims mad for being unable to find it and make it stop. But that's quite the opposite of what my client wanted: He needs the end users to know exactly what's causing the sound and how to make it stop (i.e. put the unit back in its cradle). It should simply be annoying enough to guarantee their motivation to do that.
Some of you may be familiar with Jim Carrey's short but memorable interpretation of "the most annoying sound in the world" (from "Dumb and Dumber", 1994). Wouldn't it be funny to get a sound sample of that, and play it back from the cradle? Why yes, verily. But keep in mind we're discussing a real project offer here, and no one's paying me to be funny (or for usage rights). So, I need to figure out, first, what are the realistic constraints and options. I got a sample device from the client and examined it up close.
Getting Real
I'll gloss over some details. The cradle is powered by a single USB 2.0 cable. The spring contacts were indeed broken, and I could quickly see why: the mechanical designers of the product simply did not consider with what abandon people handle physical objects in real life. I called the client and said I can replace the contacts, but sooner or later they will break again. He said "fine". Next up, I opened up the cradle. It was made out of two big plastic parts, with a PCB sandwiched between them. And I mean sandwiched! Contrary to the "Que sera, sera" design attitude regarding the contacts, the plastic parts held, hugged and squeezed the PCB from almost every angle - in addition to regular mounting screws. This meant that, planning my own replacement PCB for the cradle, I had very little spare room, literally millimeters, for any extra functionality. Talk about annoying!
At least I didn't have to weigh too many options: the space constraints meant I'll simply have to make do with a flat little Piezo buzzer. And a good thing too, because most people find the sound of these buzzers annoying by default. A little MCU will handle the timing and the PWM output to drive the buzzer. Now, let's consider the philosophy and psychology of Annoying.
Basically, for something to be annoying, it has to meet two criteria: first, it should be continuous or repeating; a single, short event might be frustrating, but we won't consider it "annoying" unless it continues to affect us. Second, it should either be inherently aversive - given the victim's culture, personal preferences etc. - or demand our attention (or other valuable resource) while we're trying to spend it somewhere else. Context is very important: the very same sound - say, the ring of a doorbell - could be perceived as a blessing ("the couriers are finally here with my PCBs and my components!") or as a curse ("Donation collectors bothering me again while I'm trying to finish this project"). Since I don't know what the end users will be doing around the device - in other words, what their context is - I must resort to the "inherently aversive" to make sure they'll respond. What, then, makes a sound objectively unpleasant?
First of all, high-pitch sounds are generally thought of as being more attention-grabbing and, therefore, usually annoying. "High" here refers, more or less, to the frequency scale of human speech; think a couple of Kilohertz. Second, square waves are perceived as shriller than smooth sine waves. Again, that's perfect for my little Piezo, which has a resonant frequency of 4KHz. Lastly, there's the matter of people's ability to "mask out" or get accustomed to sounds. To prevent our poor end users from doing that (they don't even have to make an effort - it's a low-level feature of perception), one obvious way is to add an element of unpredictability or randomness. But just as a reminder, there are other ways, too. Think, for example, of the difference between consonant and dissonant chords.
The Compromise
Evidently, there's a rabbit hole here that goes at least as deep as budget allows. But my budget was very limited; this project was not meant to become a new shelf product, only a 20-30 piece job for a very particular use case. To make it profitable, I better not go after The Most Annoying Sound Ever - instead, I should just find a quick and simple "annoying enough" solution.
While random frequencies and intervals are effective, and easily produced even in the cheapest MCU (because pseudo-random is more than enough for this job), I figured I'd still have to do some testing to find a good mix of parameters, and this will take time. Instead, in the spirit of the dissonant, I went for a simple "expectation breaker": a sequence of four beeps, the first three having the same duration and the same interval between them, but the fourth appearing "too soon" in comparison, is longer, and in a slightly different frequency (the dreaded 4KHz). This is super easy to program, and my personal impression was that is works great.
So, the moment of truth arrived. I made the replacement PCBs with the extra components and the new spring contacts, installed them in the client's cradles that were brought to me, shipped them back and got the money. Only one thing was missing: feedback. Weeks flew by and not a peep from the client. Is it working? Are people complaining? Are they putting the units back in the cradles? I still have no idea. There must be a word for this kind of situation, but it eludes me right now ;-)

- Comments
- Write a Comment Select to add a comment
To post reply to a comment, click on the 'reply' button attached to each comment. To post a new comment (not a reply to a comment) check out the 'Write a Comment' tab at the top of the comments.
Please login (on the right) if you already have an account on this platform.
Otherwise, please use this form to register (free) an join one of the largest online community for Electrical/Embedded/DSP/FPGA/ML engineers: