HT1621B Display controller Breakout Board

As a part of my work, I needed to drive an LCD segment display. Now, these displays are somewhat of a mixed breed between LCDs and 7 segment displays. They look sleek like LCDs, and are structured like 7 segment displays. However, they cannot be controlled just by toggling the segment pin of a particular segment high. They actually expect something of an “AC” signal to keep them on.

There are Arduino libraries that allow you to do this : You can find it here . However, if you are going to need 8-9 pins to control one character, you’ll find you will quickly run out of pins. Thankfully, these segments are very common, and so of course, there are controller ICs that will drive these displays, and let you offload the cumbersome task of generating the AC signals to drive those LCDs. The HT1621B is the perfect LCD segment controller IC for this job.

You just have to send messages serially to the HT1621B (in the right format of course), specify the necessary parameters, and the controller will take care of the rest. You can use the Arduino library for the HT1621B here.

HT1621B Breakout board

While working on this, I found it rather difficult to find an existing breakout board for the HT1621B, which is in the SOP48 package. I designed a board for it so that I could test it out. You can order the board with HT1621B controller ( if you are in India ) at the Amazon link here : .

If you want to get just the SOP48 breakout board, you can head over to OSHPark (link below).

Order from OSH Park

I hope this is useful !

Snooping on I2C – Making an OLED display work

As a part of one of my projects, I was trying to port the Arduino I2C OLED library to an ARM based platform. I had managed to figure out almost everything, the code seemed correct, the registers were all ported fine, timing wasn’t an issue, and yet there was only one problem : the display wasn’t actually showing anything.

To debug, I did the simplest thing first : tested the display with a standard Arduino Uno and the I2C OLED library. Worked like a charm. So the display was fine. Next up was testing the messages sent by the ARM chip and compare them against the messages sent by an Arduino. For this, I had the following setup.

First, I connected the display and the Arduino on the I2C SDA and SCL lines as usual via a breadboard.Further, I connected the I2C lines from another Arduino to the same SDA SCL lines from the breadboard, to snoop on the connections going on in the wire. I then wrote a small Arduino script to display the snooped messages.

The link to the script is here :I2C Snooping script for Arduino

When I repeated the exercise with the ARM chip, and compared the logs, I found that there were some flags that were being sent that were different. To reduce the chances of error, I dug through the code in the ARM causing the difference and fixed it. Now, the messages sent by both the Arduino and the ARM chip seemed exactly the same. Yet, the display was still just as dead. The issue was probably deeper than the byte level. The signal level then.

Luckily, my friend Mahesh at Electronut had a Saleae Logic Analyser that seemed to be the right tool for the job. I installed Logic from Saleae’s websiteΒ  (install the standalone version on Windows, the installers often don’t work on x64 systems). I then used probes to record the signals from both the Arduino and the ARM chip. Below are images of the capture. I also used the internal functionality to analyse the signals by specifying that they were I2C signals. See the difference ?

Arduino (working)

Arduino signals

ARM chip (not working)

Repeated Start

Yep, there is a difference in the signals after two bytes are sent. A little bit of reading quickly revealed that the errant signal was a start bit (see footnote for explanation). I edited the code from the I2C application code in the ARM chip, and sure enough, the display started working.

Why couldn’t the Arduino catch this difference ?
I was using the Arduino I2C library for snooping. The Arduino I2C code I wrote probably ignored the start bit, thinking it was just another packet. Basically, my snooping code did not distinguish between a long packet of data or when it started or ended, because I broke them down too fine, at the byte level, not recording higher packet size level markers.

Moral of the story ?
1. Tools are great friends. Arduino, Logic analysers, even the humble ammeter sometimes. Take the time to learn how to use them. If you can afford them, buy them. They will save you hours, if not days, of wasted effort and time and frustration.
2. Dig deep. Then dig deeper.

I hope this is useful to somebody when debugging. Cheers !

Footnote :
The I2C OLED display requires instructions in a specific format. It is generally in the form of “Address, command” i.e. address of the setting to be changed, followed by the actual setting to be changed.

Now, I2C is a serial communication protocol and specifies how low lying signals are to be generated for reliable communication. The way to distinguish between two data frames is by letting the lines idle for a specified time, then pushing out a start bit. The ARM chip had a method to wait for pending transfers to complete. By calling that method, it assumed that this package transmission was complete, so the next time I called the method to send data, it emitted the Start bit again, as is polite between microcontrollers that are gentlemen and gentlewomen. Since the OLED actually expected a long packet, all I had to do was restructure my command to make sure it didn’t insert unnecessary breaks between packets.

Hacking MP3 Players – Adding sound to Arduino

I’ve been wanting to add sound to quite a few of my projects, and have always found it way too cumbersome, too expensive or too expensive to add sound to my installations / projects, so a little while ago, I decided to try and hack a cheap MP3 player ( purchased from a roadside vendor) and trigger it from my Arduino to play pre-recorded MP3 tracks in sequence.

Here’s a picture of the MP3 player I am talking about, and what it looks like when opened up :

MP3 Player MP3 Player MP3 Player hacked

How the MP3 player works :

The MP3 player has 5 buttons: Play/Pause, Next, Previous, Volume Up and Volume Down.

As shown in the image below, each button consists of two pads, an inner pad and an outer pad. There is a metallic contact like a dome, covering the two pads, but not making contact. When you press the button, the metallic dome touches both path simultaneously and causes them to “short”. A short lasting for about 70 milliseconds will cause the action associated with that button to trigger. Note that a “short” of a small duration will not cause any trigger, and one of very long duration will cause multiple triggers, so it is important to time the delay right.


Each of the 5 buttons therefore has two pads, which must be shorted to trigger the five actions available. However, note that the pads on all the buttons are not unique i.e. there aren’t 10 unique pads, but merely 4 unique pads, scattered in different unique combinations. These 4 pads lead to 4 pins on a 16 pin IC, which I have drawn in the illustration above. The pins used are 6,7,8 and 16. To begin hacking the MP3 player, we must first solder 4 wires, either from the pads or from the pin on the IC (I find the latter easier), and extend them into multiple pinouts, so we can use them later.

In the illustration above is a table, which is a mapping of the combinations of wires which must be shorted for each action. So, to cause the MP3 player to pause/ play, we must short the pads / wires linking to pin 7 and 8 on the MP3 IC.

When we touch the buttons, those actions are easy enough to trigger. The question is, how do we short two pins (of which none might be ground), so as to simulate the MP3 function ? The solution is simple, really, we use relays. A relay is nothing but a mechanical switch that flips one way when powered on, and flips back when powered off. This is because each relay (drawn in the illustration) has a coil that creates a magnetic field when powered on, which flips a switch mechanically. The “COM” terminal which is normally connected to the “NC” (normally closed) flips and makes a connection to “NO” (Normally Open) when powered on, and we can use this to short a wire connected to COM with a wire connected to NO. Thus, each relay will short _two_ pads when powered, and will correspond to one pin on the Arduino that will power it on.

So, we’ll use a digitalWrite call from an Arduino to switch “ON” the Relay coil, thereby causing the wires to short. There is a slight problem, though. Chances are, your relay won’t trigger with the 5V that the Arduino supplies on its digital pin, and you’ll need to raise it to a level of 9V or 12V to trigger the relay coil. So, we’ll need to a buffer in between, here I have used the ULN2003. The complete arrangement for one MP3 function is mentioned in the illustration above.

This should mainly cover how to go about hacking the hardware of an MP3 player to work with an Arduino Uno. However, to make things a little easier on the Arduino side, I also wrote a simple library that lets you control the MP3 player just by specifying the pins on the Arduino that are connected to each relay.

Here is the link to the Github for the MP3 player library :

In the call to MP3Player, you just need to specify in the brackets which pins are connected to the relays corresponding to (Play , Next, Previous, Volume Up, Volume Down ) in order, and you should be up and running in no time !

If you are using only one button, you might want to skip the ULN2003 and use a simple transistor as switch instead as shown here (, but if you are going to use more than one button that is not advisable, since one of the pins that are shorted go to ground of the Arduino, and if you use another button with a different pad going to ground, those two will continuously trigger, messing up with your flow and possibly messing up the player itself.

If you have any questions, you can write to me at and I’ll be happy to help you out !

If you want to go get some Arduino supplies, you can get it from here :

Cheers, until the next hack !

ArduDroid and Arduino Micro / Leonardo

At a recent workshop, I was teaching how to connect an Arduino to an Android device, using Bluetooth. To make things interesting, I threw in a mixture of Arduino Micro and Leonardo devices, just to make people familiar with them and get them out of the comfortable Uno habit. We decided to use ArduDroid to quickly prototype, since it seemed to be easy enough for beginners to use. Quite a few teams managed to make it work successfully, and a few teams were stuck.

While debugging, one thing I observed consistently was, that they weren’t getting any output on the serial monitor. And then it hit me, but of course ! They were using Micros and Leonardos ! Micro and Leonardo boards handle serial communication differently, they separate the USB CDC communication and the hardware UART communication. Well, I looked around, and did not really find too many people who had posted about this issue, and just a couple of them talking about fixes (the fix is pretty trivial of course) .

Anyway, I quickly put together a fix, so if you are using ArduDroid with a Leonardo or an Uno, you should be able to use it just like an Uno with the modified code.

Here’s the github link to the code for this :

Controlling TiM LED Matrix boards with Arduino Uno

I have a TiM LED board from my helpful maker friends at Wyolum to play with, and was wondering what cool application I could make out of it. I was thinking of games, animations and the like, and started to put things together, just to test waters and see what it would look like.

Well, first roadbump. There were a couple of things missing. They weren’t so big as to cause major inconvenience, but it definitely would help visual applications if I added them. I am talking about row manipulations, allowing us to manipulate the board as a whole (or a collection of rows) , rather than as individual pixels.

Well, having had some experience with programmable RGB LED strips before (though those were LPD8806 based, not WS2811 based), I quickly added the helper methods, and put together a quick sketch using the ever-so-useful Arduino Uno. I made a quick video of it, I am going to keep playing with it for a while, something cooler just might be on it’s way ; )

Here is the github link to the sketch and the library :

And here is the video :

Making LEDs dance to music

I am working onΒ an installation at Amsterdam, trying to transform an ugly vandalised building into an open-air exhibition space, and make it interactive to make the area lively and the project engaging to pedestrians and vehicles.

Part of this involves having LEDs dancing around the building, encouraging the viewers to move around the building. For this, I ordered myself a strip of flexible RGB LEDs from China. These are based on the LPD8806 ( you can find a tutorial here ), run on 5V, do not need continuous refreshing and each LED is individually controllable. Guess what that means ? Yep, you can hook it up to an Arduino and start programming, just like that. I came across the FastSPI2 library, which does a great job of letting you control these strips (they support different chips like the WS2801 and others too) through a very easy interface.

With the LEDs and Arduinos in hand, I set about trying to find a fun enough experiment to do. I had wanted to map out motion data to visuals since a while, but then sound is a good option too, I thought. With that in mind, I tried finding a way to sync visuals to music. The Pink Panther track comes to mind very quickly, because of the simple beats and the associated visual movement being easy to imagine. With suggestions from my Japanese friend Takuma about using MIDI instead of MP3 , with this little script from my Spanish friend Alex to map the timings of the music track to usable text data, and with help from my Dutch team-mate Steven to figure out musical notation and editing, I was able to put together this little demo below. It is very basic, and I hope to put in more effects and visuals soon ! The code is on Github here :

Dancing LEDs from Ankit Daftery.