Sunday, July 31, 2016

Play table

Using proximity sensors for playing midi tones combined with LED visualization


The aim of this project was to create a table sized device with multiple proximity sensors that can play midi tones. Each sensor had a few LEDs to show hand distance above the table. This table could be used by one or more persons at once.

Hardware setup

First I created a prototype from a cardboard to test sensors and some logic behind. Than I ordered a customized plottered sticker with a design which was painted with bare conductive paint. Afterwards I drilled some holes and connected the touchboard with 7 arduino Nanos. Each arduino was connected to 13 LEDs diodes. At the end I added two potentiometers. One for controlling volume and one for changing notes setup.


Programming consists of two parts. Master(touchboard) program that reads values from proximity sensors and sends messages to slaves(arduinos). Second program for slaves that reads messages from master and toggle LEDs.
Using Arduino IDE for programming was helpful, even more that the touch board has got already built in midi library, so it was quite simple to use it. For communication I created a simple protocol to distribute proximity from master to slaves . There is no delay between real distance and lit up LEDs (baud rare is set to 9600 )

Protocol example:

Lesson learned

My very first idea was to control the volume for each sensor by distance. I tried to use separate midi channels, but it didn't worked. So I have to come up with another solution. I decided to use thresholds for the distances.

During the testing version with cardboard I've had some small issues with touchboard. Sending messages out using TX like in any other arduino didn't work here. Later after reading official docs. I've noticed that this board has two serials. So I have to use Serial1 instead (minor issue but didn't find anything mentioned about it anywhere).

Update 2016-11-20


I've got in touch with Julian who is a musician. After every session of testing we had, he gave me tips for more features or small changes, so he can play something on the table. We've come across few refactoring cycles, some optimalization (the memory limit can be achieved very easily).

New features

Play table provides a USB MIDI output interface. This feature allows us to master the output from the table using a MIDI protocol.

I solved the previous issue that each sensor can use it's own volume by setting a different channel. I've used this feature for two sensor modes which use distance like a trigger to launch single tone or chord.

During testing sessions, we came up with 3 more different sensor modes:

  • chord mode: plays an chord in full sensor range
  • multi chord: toggling multiple chords based on the distance above the sensor
  • arpeggio mode: play tones in tempo that is dynamically changing by the hand distance above the sensor
  • arpeggio auto mode: same as arpeggio mode, but with auto-play after user touches the sensor

Lesson learned

After few sessions the painted sensors were little blurry because the paint would fade away because of touching. I was thinking about adding new thin layer, but transparent spray paint solved this problem for good. The resistance characteristics did not visibly change. So if you are planning to use bare paint you can freely use transparent spray paint to preserve the conductive paint from blurring.



Sunday, June 26, 2016

Creating fake SMS with Android

How to crate fake sent and received SMS

Android fake SMS

I was curious about how hard it can be to create fake SMS. So I decided to do a small research. I found a simple app that allows you to create a fake SMS. The interface is very straightforward. User can set a type of message,date and time. The only thing you have to agree with, is to set this app as a default message application. At this point, I was sure it is possible to do this without root permissions.

My first idea was to send some fake intent to pretend the system received a new SMS. I did some searching but any of it works. Lots of answers were pointing to "android.provider.Telephony.SMS_DELIVER" which is the system intent action for broadcasting. But since android 4.4 (KitKat) there is only one app, that is selected as default messaging app and can receive this intent. Broadcasting of this intent is allowed only for system applications. The permission for reading/writing SMS is also allowed only for default messaging app. There is a blog post that describes all these changes from Android 4.4.

After reading above mentioned blog post I updated my application so it can be used as default message app (I've just updated the manifest and created all necessary receivers with empty body). Then I realized, I don't need to send and broadcast, I can simply write a SMS through content provider URI. Following these steps allows you to create fake SMS.

  • to make an application as a message application, you need to create receivers and service
  • add permissions to manifest: WRITE_SMS, READ_SMS, RECEIVE_SMS
  • at the start of an activity (or writing new SMS), you have to request a user to set this application as default application
  • don't forget to check out if user has a right to use permissions to read/write SMS (request user for required permission)
  • just write a new message getContentResolver().insert( Uri.parse("content://sms/inbox"), values);

Now you can create a fake SMS generator for your friends, family or even favourite transport service :) .

download source code here


Monday, February 29, 2016

Self playable game on smartphone

Connecting Android to servo motor via USB OTG


I recently put together a Lego phone holder that can be rotated in one direction (y-axe the longer side of phone). The end of the holder is attached to a servo motor. Servo motor is connected to Android smart phone with USB OTG via motor module. Motor module is controller that can control up to 24 servo motors and runs on 5 volts.


The module controller part has already burned its own protocol. It was a combination of rotation and speed separated by new line symbols.

Second part was Android application that sends messages via serial protocol to this servo-module. I used an example of USB serial communication with Arduino and rewrote it for my device.


For this exercise I chose a game that I made about year ago. It is a simple game that uses accelerometer to move the rocket through gates. Leaning device to sides allows you to control the position of the rocket. The goal is to run through as many gates as you can. The speed is increasing within entered gates.


My first idea was to detect the values of maximum rotation to both sides. Then to use this values and dynamically calculate all rotations of holder. But after few changes in my holder construction I realized that my configuration is a little bit different each time. So I created a calibration method that runs at start up and detects the limit values by itself. Then during the game the values are recalculated from these limits. For better understanding please watch the video below.


The practical usage of "self playable holder" is literally none. But if you look at it as an exercise, it is a nice introduction to connecting an android to servo motor.


Tuesday, February 9, 2016

Avr clock

Wall clock made of avr mcu and led display using internal timer


The main goal was to try numeric LED display with MCU, so to make it a little bit more interesting I decided to create a clock that shows time in digital and analogue way. I used Atmega16L MCU because I needed 26 I/O pins (12 for numeric display, 12 for 2mm LEDs and 2 for buttons). The clock has got two buttons - one for adding hours and one for minutes. 2mm LEDs around edge shows seconds while numeric display inside shows hours and minutes.


I bought my display from ebay without any data sheet, but it is almost the same for all kinds of displays. You can easily find the right combination of pins. Four 7-segment digits are controlled via 12 I/O pins. Each digit is made of 8 parts (7 for number, 1 for dot). The other four pins are ground for each number. So to light up 4 different digits you have to toggle between all of them quickly.


A timer is a simple counter. The ATmega16 has two 8 bit and one 16 bit timer. The 8 bit counter (uses 8 registers) can count up to 2^8 = 255 while the 16 bit counter (uses 16 registers) can count up to 2^16 = 65 536. After reaching the maximum value for counter it simply overflows back to zero.

Lets say the MCU works on 1MHz frequency, that means it does 1 000 000 ticks per second, but the counters can only count up to 255 (8 bit timer) or 65 536 (16 bit timer) then it overflows. To set the counter properly you have to set the limit (prescaler) and also setup bits for right mode. All of the necessary configuration can be found in data sheet.

I used 16 bit timer with CTC mode (clear time on compare - when reached predefined value it is automatically set back to zero) with external interruption. The main thread is used for logic and redrawing while second thread (external interrupt) is used for counting time. There is a nice youtube tutorial for avr timers and also a avr timer calculator can be handy.


Using an internal timer might not be a best solution for a precise counter, because the error can be up to few percentage. So the clocks will lose its accuracy very soon. To avoid this error you have to use an external timer (e.g. Crystal Oscillator - more to come later on).


So I decided to use an external timer DS1307 RTC (real time clock) module. I've found a RTC library, removed buttons and added the timer.

the numbers have better visibility in the dark than in light room