Building an Annoy-a-tron Clone
This project is entirely open source and developed by me. Feel free to look at the board designs and source code and use them for any non-commercial purposes.
Software source (Github)
Hardware design (EasyEDA)
In an attempt to go completely through the development process on a mass-producible product I set out to create my own Annoy-a-tron clone. An annoy-a-tron is a small battery powered device that beeps at random intervals. The idea is that they are extremely difficult to find due to the unpredictability of the beeping and the short duration of each sound. You can then hide one somewhere you know your victim spends a lot of time and drive them crazy as they struggle to find the source of the sounds.
I had built one of these in college and recently came across it while moving. Shockingly, it still worked, but was quite rough around the edges and I thought it would be fun to see how much better my current build would turn out.
In this article I walk through the various stages of development along the way as I worked my way from very rough prototype to final product.
Essentially, the device consists of only a few components:
- A small microcontroller — Some might use a 555 timer here instead, but I wanted to have randomly spaced pauses, and potentially some jumpers/switches to control various settings and wasn’t sure how to achieve that without a microcontroller. Also, I have much more experience with software than hardware so it seemed like a smart move. I selected the attiny85 because of my familiarity with AVR and it’s extremely low power sleep mode.
- A buzzer — Pretty much anything would work here as long as it’s small and low-power. Cheap buzzers need to be driven with a square wave instead of simply supplying them a constant voltage, but that’s not difficult to do with a microcontroller.
- A coin cell battery — My original design from college used a cr2032 which holds about 4x the energy of the smaller cr1220s. My goal was to run this off the smaller battery this time, and hopefully even extend the battery life.
Prototype progression
My first attempts at a prototype was just made with whatever parts I had around, without much of an eye to optimization. Essentially I just made a PCB that had the microcontroller, a plug I could connect an AVR programmer to, and an output that I could connect a buzzer to.
As you can see, it’s a couple inches wide, one-sided, and doesn’t have a battery at all. It did however allow me to test all my software plumbing, get a Makefile working, and test that I could make a buzzer work.
After proving that I could successfully get a program onto the microcontroller and that it was able to generate the square waves required to drive a buzzer, the next step was to try and build an all-in-one prototype. This used a homemade 2-sided board that had the footprints of the components I hoped to use in the end, but since I didn’t have them yet I had to kludge it together with what I had on hand.
You can see that a lot of it is held together with hot glue, the battery holder doesn’t fit, and it’s quite a bit larger than it needs to be. Nevertheless this was a big success. This was the first version that could run off a battery, which is a big step forward, and I was able to remove the ISP header entirely saving a lot of space.
Previously the ISP header had been used to reprogram the microcontroller, but the header is quite large relative to this tiny project so it really wasn’t an option to leave that on the board in the end. I came up with a new way to update the program by using an SOIC-8 test clip. Essentially I wired up this test clip to my programmer so that I could simply clip it onto the microcontroller on the board and reprogram it without any additional circuitry.
For the next prototypes, I had already more-or-less proven out the circuit and software aspects of this product. The code worked and the battery powered everything they needed to, but I had never made a version with the actual parts I would be using in the end. After an order from lcsc.com, I had several different battery clips and buzzers to try out. I built two test devices: one with a tiny 5mmx5mm SMD buzzer and one with a more traditional large cylindrical buzzer.
The model with the SMD buzzer was insanely small and sounded great when on bench power, but was extremely quiet when running off the battery. After a little more debugging, it turns out that the buzzer pulls way more power than the larger ones and I think the battery simply couldn’t supply enough power at once to produce a good enough volume. Even if it had been able to, I probably wouldn’t have gone with this buzzer either way though. The increased power consumption would cut down the battery life of the device, which is quite important on a product like this.
Replacing the SMD buzzer with a different, lower power version brought the beep volume way up. The package was quite a bit larger, so it required rethinking the board layout. To keep things small I stashed the microcontroller underneath the buzzer. This actually worked pretty well and made for a slick, polished look, but makes it impossible to reprogram without taking the whole thing apart. Luckily, the software was basically finished at this point, so that’s okay. I was also able to simply iterate on the software using one of the previous prototypes and move forward under the assumption that this construction could be used for the final versions.
With all the components tested out and working, I wanted to make a top-to-bottom prototype before ordering professionally made PCBs so I could double check that my exact board design works. This time I used a Dremel to cut the board down to size and I did my best to put all the bells and whistles on that I could by hand.
This is as far as I’d ever gone before, and the results were great. This was a totally usable device, but it still had that home made feel. No silkscreening on and un-plated vias and through-holes on the board really limit he professionalism you can get at home. I sent off my designs to JLCPCB.com and anxiously waited.
The boards came in looking great. With all the testing I had already done with my home-etched versions I wasn’t too surprised that they worked, but it was still a relief. With the final PCBs in hand, I had everything I needed and from there it’s just a matter of assembly.
They assemble very easily, and produce a device that looks like something you might buy. What a huge upgrade on the old model I made back in college!
Testing
Once I had a prototype up and beeping I needed to test a few things. Most are relatively simple, but there were two features that are difficult to test:
- How do I confirm that it’s randomly beeping in the way that I expect.
- There is a switch on the buzzer that allows the user to toggle between starting to beep immediately after the battery is inserted, or to wait two weeks before the first beep for added sneakiness. How do I measure that time period?
To test the distribution of the gaps between beeps and how long the time delay actually waits for I designed a little test rig at my computer. Essentially I taped a beeper to a large microphone and wrote a piece of software to listen to the audio and scan for beeps of the specific frequency. That software is written in python and can be found on Github. It works by computing a spectrogram and checking if the highest response is near to the 4kHz frequency and strong enough to assume it’s that beep. Without a filtering system like this, it’s very difficult to run long-scale tests without ever making noise within earshot of the microphone. This system worked great and allowed me to measure the length of beeps and the pauses between them extremely accurately even for long periods of time.
