Earlier this week, we got the great news that we have been accepted to the North Carolina Maker Faire. We’re absolutely ecstatic to get to share some of our projects with the public but it’s also been a great push to get some other projects done. I’ve had this particular project bouncing around my head for a couple of years now. I call it Dial-A-Song.

Much of the inspiration came from They Might Be Giants, who used to leave recordings of their songs on their answering machine, which could be listened to by calling (718) 387-6962. So, I wanted to combine a little of that with a phone tree menu to give the feel of calling in to a phone service to listen to music of your choice. Yes, it’s a little ridiculous, but why else would I be building it.

As a way of documenting the project and an extra push to keep working on it, I’m going to be writing up a build log in several parts as the build progresses.

So, first, the desired specs:

  • Completely enclosed in an old phone
  • Music plays over the headset speaker.
  • Raspberry Pi as the brains
  • Automatically index all music
  • Choose 10 random songs when the phone is picked up and make them available via the menu
  • Text to speech for the menu
  • Network capable for remote control

In part 1, I’ll deal with the phone itself. I really wanted to use an old pay-phone, but good condition models were well over $200, much more than I wanted to spend. So I went for the next best thing:

The Red Phone

Who doesn’t want a big red phone on their desk? Only important calls come over a red phone. I found this one on eBay for about $20 and it’s fully functional… now let’s gut it.

I started by removing the two large, flathead screws on the bottom metal plate. Once out, the entire top casing simply lifts off. As you can see from the interior picture, there’s really not much to these old phones. One PCB on the bottom, another beneath the dial pad, and the ringer assembly, which had to go. I would have loved to keep the ringer intact and actually use it but it takes up too much space and older phones like this run on a higher voltage than I would be working with. They typically run at 48V DC when idle, but a 90V 20Hz AC current is required to actually make the ringer work. So, out it came.

The main board had to go next, as it is really of no use. The only things from the phone I plan on using are the dial pad, the handset and the phone line input (for power and network). I was surprised to see how little was actually on the main board and that it was mostly there just to hook up all the other components of the phone… with removable spade connectors no less. This was definitely a hand-assembled product. The truly don’t make things like this anymore! The only active components on this board are likely for the ringer since it’s the only thing using AC current, making the small transformer and diodes a give-away to their purpose. No matter… to the parts bin it goes.

Dial Pad and Tone Generator

Next to come off is the dial pad assembly. Here’s where the electronics actually get a little interesting. The IC chip on the left is the HM9102C tone generator, responsible for generating the DTMF tones that make a “touch tone” phone system work. The IC reads the dial pad key presses and generates the corresponding tone that gets sent over the phone line. Each row on the dial pad represents a low frequency tone and each column a high frequency. So when a key is pressed, the chip creates a single tone from the two frequencies represented by the row and column of that key, hence the term “dual-tone, multi-frequency” or DTMF. But I don’t need this either – I’m just going to fake the tone sounds in software since they aren’t needed – so off to the parts bin with this board as well.

The dial pad, however, I do need. Fortunately, a little probing with a multimeter shows that it’s wired up like any other matrix keypad ever made. Even better, there’s already a python library for the Raspberry Pi that handles all the heavy lifting of reading the key presses. More on hooking this up in a future post.

Hang Up Relay

Next is the hang-up mechanism. It’s actually much more complex than I was expecting, as it includes 3 separate internal relays. The first (left most) has two switch contacts, one is open when the mechanism is down and the other when it is up. The middle relay opens the circuit when the mechanism is down whereas the right-most relay closes the circuit. Each obviously has a specific purpose, such as connecting the phone line to the handset speaker and mic. But I’m not sure which is which. Fortunately, I only need one of them and don’t really care which direction it goes. I just need to detect a state change via one of the Raspberry Pi GPIO pins and handle it accordingly in the software.

Phone Handset

Finally, for this post anyways, is the handset itself. I was a little surprised to see that it had a built in volume control (the wheel in the middle of the handle)… I’ll have to see if there is some way to actually make this work. Unfortunately, I won’t be able to use the volume circuit as is, or the speaker, because they are both designed to run on 48V DC. Whereas I plan to just connect it all to the 1/8″ audio jack on the Raspberry Pi. The major problem with the speaker is that, as a quick check with my multimeter showed, it has an impedance of over 100 ohms! It makes sense given the voltage it is supposed to run at but that is huge compared to the typical 4-8 ohms of modern speakers. So, instead, I’ll keep the wiring but replace the speaker with one from an old pair of headphones. Likely with both the right and left signals going to the same speaker.

That’s all for now. As this project continues I will post new articles following the progress. Stay tuned!

We love our MakerBot Replicator 2 at Maniacal Labs HQ but eventually you get tired of printing off Portal Companion Cubs, Tardiss (Tardii?), gears, etc. It’s actually a lot more fun to create things that solve a real problem!

I recently got a new Nexus 5 phone and Nexus 7 tablet, both of which have the ability to utilize wireless charging pads. Since I’m lazy, this sounded like a good idea (I know, first world problem). The official Nexus wireless charging pad is $50, which seemed a bit excessive for what you get, so I found another from Amazon for $20 less. It works great but I wanted to be able to charge my devices while having them propped up at my desk, so they can still be useful. This called for a custom stand that held the charge and the device at an angle. I’d never designed anything near this complicated, but it seemed like a good time to learn how!

Queue 123D Design. Not being a professional at these things, I can’t really afford the fancy tools for such things, but I’ve found that 123D Design does a good job (though keyboard shortcuts would be welcome). A lot of caliper use, 2D sketching, and extruding later I wound up with this:

Nexus Wireless Charger Stand Design

Nexus Wireless Charger Stand Design

Not bad if I say so myself 🙂 But, first, a test print to check the sizing!


I made this quick little frame to make sure the charger would fit perfectly and it was a good thing I did because the hole was slightly too large and the corner radius was too small. Oops. Good thing too; the test print only took about 5 minutes whereas the full stand would take over 6 hours! Always to test fit prints!

So 6 hours later, I had an awesome little wireless charging stand.

The charging pad fits snugly into the recessed slot and includes a strain relief groove for the USB cable on the back.

It should work with other Qi Wireless compatible devices, depending on their size and placement of the charging coil. The bottom of the pad is situated 20mm from the bottom edge of the device and it should fit device with case, up to 14mm thick.

Mine, is definitely not the first wireless charging stand I’ve found but I could not find one for this specific charger. You can find the 123D Design and STL files over on Thingiverse. Any suggestions for updates are welcomed. If you don’t have a 3D printer and want one of these stands, let us know, we just might print one for you!

Stick a Pin in It

I’ve been working on a side project that uses some of the WS2812 based LED strips, just like the “NeoPixel” strips from Adafruit. Unfortunately, I began having problems with the strips in that they suddenly stopped responding to any control signals being sent to them. My suspicion was either a broken solder point or a dead pixel. Since they function by buffering the data and then sending it along to the next pixel in the line they have that old style Christmas lights problem of all lights after a broken light will not function.

As they were already installed in what was to be their final setup, this brought about the issue of getting access to the control signal at various points without tearing it all apart and removing the waterproof epoxy coating that covers the strip. I had set the problem aside for a while but then happened to walk by some sewing supplies in my house and noted a pin cushion… but I wasn’t seeing pins. I was seeing logic probes.

It seemed too simple to work, but I grabbed a pin and some alligator clip wires, and tried using the pin to inject control signals at various points along the strips… and it worked! Not only did it work through the waterproofing epoxy but in the wires between segments of LED strips as well. I could easily press the pin through the wire insulator, make a connection, and never really risk creating an exposed wire.

In the end, it turned out that the very first LED in the run at somehow fried its control chip. The was easily confirmed by using the pin to connect the data pad just after that pixel to the control signal and, sure enough, the rest of the strip lit up. So, quickly swapping that segment of LEDs fixed the problem and I was up and running again.

While the original idea was somewhat specific to these type of LED strips, I was quite impressed with how well it worked on regular hookup wires. I will definitely be using this trick for troubleshooting in the future. Sometimes you don’t need expensive tools, just some sewing supplies 🙂

PCB Fail

Ever since first trying KiCad and OSH Park I have been a little hooked on being able to throw together a custom PC, have it professionally manufactured, and shipped to me within a couple weeks. We’ve used KiCad and OSH Park on all of our prototypes here at Maniacal Labs but Dan and I use them constantly for our own projects as well. It’s quick and cheap, but I recently discovered the hard way not to go too quickly.

I was designing a PCB for a custom LED strip controller for a costume piece I’m working on. Nothing overly complicated, just an ATMega1284p, a button, rotary encoder, OLED screen, and a few capacitors and resistors. I had already breadboard the entire circuit and was confident it would work, so I decided to throw together the PCB and get it ordered.

Since I already had a design for an ATMega1284p breakout board I had design and used, I started with that, removed the parts I didn’t need and added in the button, encoder and screen. But re-using this design was also where I went a little wrong. KiCad has a feature called a “net name” where you can just drop a little tag on a component pin, name it, and all other tags with the same name will be connected automatically in the PCB routing. It’s a really great way to de-clutter your schematic.

However, my original breakout board design had a net named “RST” which was for the ATMega RESET pin, that gets hooked up to the FTDI & ICSP headers and pulled to VCC through a 10k ohm resistor. The problem came when I added in a schematic component for my OLED screen (a great one from Adafruit) which has a pin labeled “RST”. I needed this pin, so when I created its net name I, of course, named the net for that pin “RST”. A quick look at the design seemed enough to convince me that everything looked okay. So, after only about 25 minutes work, I sent the design to OSH Park to be fabricated.

Fast forward to yesterday. I got the boards back, solder everything on, power it up (the chip was already flashed), and… nothing. No screen display, no serial output. I tried flashing the firmware again only to find that my computer could not communicate with the chip. So, I did what I should have done in the first place. Went back to the PCB designs and used the “highlight net” tool to see what was hooked up wrong.


I quickly realized that RST on the OLED screen was connected to ATMega RESET pin. You can see the offending net brighter than the rest. The OLED RST pin is supposed to be only hooked up to PD7 on the ATMega so it can be reset from firmware. Without having a schematic for the OLED it’s hard to say, but my suspicion is that the OLED RST pin is pulled to ground internally to default to a reset state and expects to be pulled high by the micro-controller. Therefore it was was holding the ATMega RESET pin low and preventing it from booting.

Fortunately, the fix was simple enough. Scrape away the offending PCB trace (as seen in the screenshot) and solder in a wire from the ATMega pin PD7 to the OLED itself. You can see my fix in the top image.

So, lesson learned. Always, always, double and triple check your schematic and PCB nets before sending a design off to be fabricated. Better yet, don’t design a board in less than 30 minutes and then order immediately if it happens to be 1am. Wait until the morning. You might notice a mistake or two 😉

I’m in the middle of designing a new Maniacal Labs product (more on that in another post) and have been working with a library intended for the ATMega328 but need it working on an ATTiny4313. If you ever feel cramped for flash space while working on an Arduino project, try out the ATTiny series of chips and you will quickly feel like 32KB of flash is downright massive! The ATTiny4313 is a decently capable chip, with only 5 less I/O pins than the ATMega328 but a somewhat less proportional 4KB of flash. Right away, this library was going to be trouble since a bare minimum sketch compiled down to 4667 bytes. Practically nothing for a ‘328 but more than 500 bytes more than the ‘4313 could handle and that was without actually doing anything!

Much of the problem comes from that fact that the Arduino platform enables easy programming by abstracting the complicated stuff behind single methods. It may look like less code but is, in reality, more code than is needed for many tasks. For example, the blink example from the Arduino IDE:

    void setup() {                
      pinMode(13, OUTPUT);     

    void loop() {
      digitalWrite(13, HIGH);  
      digitalWrite(13, LOW);   

This compiles to 1076 bytes. Now let’s do it the “hard” way:

    void setup() {
      //Digital 13 is PB5, set as output
      DDRB |= _BV(PINB5);  

    void loop() {
      //set the pin HIGH
      PORTB |= _BV(PINB5); 
      //set the pin LOW  
      PORTB &= ~_BV(PINB5);    

This compiles to 674 bytes, a 37% decrease!! On a chip like the ‘4313 those 402 extra bytes comprise nearly 10% of the total flash available! To further understand what all the DDRB and PORTB stuff is about, take a look at Arduino’s article about direct port manipulation. If you want to up your Arduino/AVR game, it’s some great stuff to learn.

So, I’m sure you’re asking why there’s such a huge difference. It’s simple really… take a look in the Arduino core file wiring_digital.c and you will find that digitalWrite() is really this:

void digitalWrite(uint8_t pin, uint8_t val)
    uint8_t timer = digitalPinToTimer(pin);
    uint8_t bit = digitalPinToBitMask(pin);
    uint8_t port = digitalPinToPort(pin);
    volatile uint8_t *out;

    if (port == NOT_A_PIN) return;

    // If the pin that support PWM output, we need to turn it off
    // before doing a digital write.
    if (timer != NOT_ON_TIMER) turnOffPWM(timer);

    out = portOutputRegister(port);

    uint8_t oldSREG = SREG;

    if (val == LOW) {
        *out &= ~bit;
    } else {
        *out |= bit;

    SREG = oldSREG;

Wow, lots of magic going on there, right? A large part of what’s happening is converting an easy to remember pin number (like D13) into the actual port register and register bit. The rest is mostly code to protect you from yourself, like disabling interrupts and PWM output. Much of the time, this should be of little concern but the bright people who wrote the Arduino core included it to ensure as little barrier as possible. That’s wonderful when getting started but, as you can see, wastes a lot of program flash.

So next time you find yourself running out of program flash, think about digging in a bit, looking at some datasheets, and learning to do things the hard way.