Posts | Comments

Planet Arduino

Archive for the ‘phone hacks’ Category

[Max] had a rotary dial from an old telephone and — unsurprisingly — had nothing in particular to do with it. The simple answer? Use an Arduino Leonardo to turn it into a USB keyboard device.

Of course, the Leonardo can easily impersonate a USB keyboard, so that’s the easy part of the project. Interfacing to the dial requires an understanding of how the phone system works.

While today, TouchTone phones are most common, they were quite uncommon for many years. Early phones required you to have an operator connect your circuit to another person’s circuit. Unfortunately for the operators, the system was inherently unscalable and also cost prohibitive.

There were a variety of schemes tried and — supposedly — an undertaker who was angry that the operator was connecting his customers to her husband’s competing mortuary invented the dial telephone.

The details are pretty simple. A typical dial has two contacts. There’s a normally open contact that closes when you spin the dial to any position. It says closed until the spring returns the dial to the home position.

The other contact is normally closed and makes or breaks the phone line. Each time the dial rewinds past a position, the contact opens briefly. Of course, this is a mechanical system, so the software has to debounce the inputs, but that’s easy enough.

If you don’t have access to a dial, you could always print one. Sort of.

Music, food, and coding style have one thing in common: we all have our own preferences. On the other hand, there are arguably more people on this planet than there are varieties in any one of those categories, so we rarely fail to find like-minded folks sharing at least some of our taste. Well, in case your idea of a good time is calling a service hotline for some exquisite tunes, [Fuzzy Wobble] and his hold music jukebox, appropriately built into a telephone, is just your guy.

Built around an Arduino with an Adafruit Music Maker shield, [Fuzzy Wobble] uses the telephone’s keypad as input for selecting one of the predefined songs to play, and replaced the phone’s bell with a little speaker to turn it into a jukebox. For a more genuine experience, the audio is of course also routed to the handset, although the true hold music connoisseur might feel disappointed about the wide frequency range and lack of distortion the MP3s used in his example provide. Jokes aside, projects like these are a great reminder that often times, the journey really is the reward, and the end result doesn’t necessarily have to make sense for anyone to enjoy what you’re doing.

As these old-fashioned phones gradually disappear from our lives, and even the whole concept of landline telephony is virtually extinct in some parts of the world already, we can expect to see more and more new purposes for them. Case in point, this scavenger hunt puzzle solving device, or the rotary phone turned virtual assistant.

Last time, I talked about how my storage situation and my cheap nature led me to build an RC joystick controller with a cell phone app and an ESP8266. The key to making this easy was to use the GUI builder called Blynk to make a user interface for an Android or Apple phone. Blynk can communicate with the ESP8266 and makes the project relatively simple.

ESP8266 and Arduino IDE

The ESP8266 Blynk code is straightforward. You do need to set up the Arduino IDE to build for the ESP8266. That can vary by board, but here’s the instructions for the board I was using (from Adafruit; see below).


Depending on the type of ESP8266 device you are using, you may need a 3.3 V serial cable or some other means of getting the firmware into the device. For the Adafruit device I had, it has a 5 V-tolerant serial connection so a standard USB to serial dongle plugs right in. There’s also two switches on my device. To get into bootload mode, you have to push the one button down, hold it, and then press the reset button. Once you release the reset button you can release the other button. The red LED half-glows and the device is then waiting for a download.

Otherwise, things are just like usual with the Arduino IDE. You do have to be aware of what objects are available on the ESP8266 as opposed to a regular Arduino. There are some subtle differences, too. For example, the EEPROM object has some extra methods because the ESP8266 emulates an EEPROM (more on that later).

Virtual Pins and Processing

If you are getting started, you can just make a simple user interface with a push button and wire it to an LED on the board. That’s the Blynk “hello world” program. But for the joystick there are a few other considerations.

Instead of wiring a widget to a physical pin, you can use a virtual pin. Your program can then read and write these virtual pins easily. A “pin” in this context could be a bit, a number, or even a string.

To handle a virtual pin write (for example, a button push or a slider changing value), you write a function using the BLYNK_WRITE macro. For example:

// Flip S1
if (!param.asInt()) return;

The framework will call this code when the associated virtual pin (V5) changes. One word of caution: a button press gets two calls; one for the press and one for the release. You need to test the value if you want to only act on one or the other. That’s why the first line tests for the parameter value of zero and returns, thus ignoring the button release.

In addition to asInt() you can convert the parameter to other types, including float (asFLoat), double (asDouble), and string (asStr).

The BLYNK_READ macro lets you provide code that will run with the framework wants to read a virtual pin (that is, send data from the embedded system back to the phone). You can also call Blynk.virtualWrite to immediately update the value of a virtual pin.

The Code

You can find the code on GitHub. It is quite straightforward: Two Servo objects control the pulse output. Their duration is set by virtual pins from Blynk. Because the joystick is set to output the microsecond count directly, there’s not much to that.

To make things more interesting, I arranged for buttons that could flip the X and Y axis and also reflect either axis (that is, invert the axis so instead of reading 1000-2000, it reads 2000-1000). Each of those is just a button push that calls a BLYNK_WRITE function. There’s a line of code that makes the buttons only operate on one of the two events you get from a button push and release.

Of course, once you can configure the joystick (including a recenter option), it is a pain to lose the configuration on each restart. So I decided to allow writing the configuration to EEPROM. That was the start of a lot of trouble.


The ESP8266 doesn’t have a true EEPROM. But the Arduino software emulates it with flash. When you want to use the EEPROM you have to inform the library how much memory you will use. It reads that memory from flash into a buffer. From that point on, all your EEPROM changes occur in the buffer. When you are done, you call end or commit and the library determines if you made changes. If you did, an entire flash page is erased and rewritten. If you call commit, you can make more changes (which then need to be written). If you call end, you are done.

By itself, that wouldn’t be a problem. However, watching the output on a scope, I noticed that when I would change configuration, sometimes–and only sometimes–the servo outputs would stall. The ESP8266 was still operating because the buttons that light LEDs would still work. I finally realized that any button that called for a EEPROM commit might hang the servo output. It wasn’t all the time, or even most of the time, but it was often enough to be annoying.

I tried a lot of things. Nothing completely fixed it. I finally resolved to have a “save” button so at least you know you might crash when you press it. Searching the Internet, this is a common problem. Since the simple code works, it seems as though the EEPROM code is disabling whatever timer interrupt the Servo object uses or not resetting the servo timer.

In the end, it mostly works, but any time you hit the save button, there’s a risk the servo output will die until the watchdog timer kicks in and resets the device.

Network Trickery

Of course, the ESP8266 has my local WiFi SSID and password plugged into it. You can set one up to act like a lot of modern devices where if it can’t connect it acts as its own access point so you can configure it. You could also just set it up as an AP and connect to it, assuming you can work out the Internet routing to get to the Blynk servers.

The problem is, I took the device into the office to show it off and realized that while my phone could connect to the corporate network, the ESP8266 wasn’t set up for it. I wasn’t carrying enough stuff to reprogram the device, but a solution dawned on me: I configured the hotspot on my phone to mimic the WiFi at home. With the same SSID and password, the joystick connected. Granted it was a little circuitous for the Blynk app to send data to the remote server, which sent it back to the phone which then routed it to the joystick, but it did work.

Final Analysis

Overall, using Blynk was pretty easy and worked pretty well. The EEPROM glitch didn’t seem to be a Blynk issue, so I can’t fault it for that. There were a few rough edges, though. For example, the LED buttons were inverted, but there was no simple way I could find to invert the operation of the buttons. That is, the buttons were on to send a high even thought that extinguishes the LEDs.

Using their server introduces some lag, but not nearly like I feared. If you have security concerns, you can run your own server, although I have not tried that. You still need “energy” for the app, though. I couldn’t decide how I felt about that. I understand that one has to make a living, and the joystick project fit in the free limits after all.

The other thing that would have been super would have been to be able to put the Blynk user interface in a browser. Blynk supports JavaScript, but as far as I can tell only as a remote platform, not as a host for the GUI. I understand that might cut into their revenue model, but it sure would be handy.

Speaking of which, you can field the Blynk embedded side into a lot of devices ranging from Arduinos, to MBed boards, to Raspberry PIs. You can connect via Ethernet, WiFi, Bluetooth, USB, and you can add your own connection methods.

This project didn’t even scratch the surface of the widgets you can use with Blynk. You can send e-mail, show video from a streaming server (like a web camera), or post to Twitter. There are gauges and sliders and lots of other things I didn’t need for the joystick.

If you don’t like Blynk, there are other options, although none of them struck me as quite as complete. For example, a quick scan of the Google Play Store shows quite a few similar apps. If you start weeding out the ones that won’t run on all the different platforms or work with Apple phones, you get a much shorter list. If you have experience–good or bad–with a different app, post in the comments.

Of course, you can always build your own phone app and communicate via standard networking. That’s actually not as hard as it sounds, but it isn’t as easy as using a tool like Blynk, either. Custom code can optimize what you are most worried about and will do exactly what you want. On the other hand, it would be a lot of work to support many different platforms, work on Google and Apple phones, and so on. For your application, though, that might not be as important as the control over the functions. That’s your call.


Filed under: Arduino Hacks, Featured, phone hacks

  • Newsletter

    Sign up for the PlanetArduino Newsletter, which delivers the most popular articles via e-mail to your inbox every week. Just fill in the information below and submit.

  • Like Us on Facebook