My starting point would be the same: Have a camera monitor the phone’s screen, and a computer to control the phone’s keypad.
The difference I wanted to make was sending the key-presses using an RS232 or Bluetooth serial connection. This would eliminate the need for external hardware pressing the buttons, or the need for altering the cellphone by hot-wiring the buttons. This was a very simple task, all I needed was the AT Commands Online Reference. The phone I used (Sony Ericsson T610) supports the AT+CKPD command (Control Keypad), thus giving me the power to emulate the entire keypad over a serial connection.
The second difference would be on the graphical user interface. At first I thought it would be best to control the phone using the PC’s keyboard, but whilst developing I found out it would be better to be able to click the phone’s actual buttons using your mouse. I rewrote the key-press part, so when a mouse-click on the video-stream is registered, it translates the mouseX and mouseY to a certain button on the phone, and sends the corresponding key-press using the Bluetooth connection.
The end result: A live video-stream of the phone on your computer and being able to use your mouse to click the phone’s buttons within this stream. A demonstration:
Note: The original cellphone button pusher also is an amazing piece of art. I get why the over-enginereerd method is chosen, and it is quite astonishing how it all worked out. This article is purely to demonstrate how it can done in a simpler way.
As it’s still not possible to receive an email when new grades are published on OSIRIS, I wrote a script that periodically retrieves my grades. When a change in my grade-list occurs, I automatically get an email with a list of my last fifteen grades.
I am using this script with full satisfaction for some time now, which is why I’m publishing it.
Now that pong is fully automated, it is time to optimize.
First I switched to the game Doeo. The goal of the game is to move your mouse as fast over Doeos as possible. A fun game to use as an example for automation.
I also made a small performance enhancement (10 to 15 percent) by not using getRGB () from BufferdImage, but reading directly from an array. It does take some time to get everything into an integer array, but if that’s done, the for-loop is a lot faster.
After wrestling through the Java Sound libraries, I finally succeeded in writing a small hometrainer application. If you are cycling while watching a movie (something I do often), then this application will pause the video if you are riding too slow. Also, the current speed is constantly displayed.
The application constantly monitors the line-input, waiting for a pulse from the hometrainers’ flywheel. When the sinus reaches a (pre-defined) threshold, it gets registered, and I can calculate the speed I’m cycling at. For extra precision, I calculate with audio-samples instead of using the computer-time. This is because of the time it takes to fill the buffer. So far, I’ve been able to measure the speed fairly accurate.
A small disadvantage is that the computer on the hometrainer calculates the speed exponentially. This was apparently done to make the impression that the user’s riding very fast. For the sake of honesty, I wrote my own program in a way so that it works linear.
Out of curiosity, I’ve studied the inner working of my home-trainer. Without dismantling the bike, or disabling the functionality of the bike, I have succesfully connected the home-trainer to my Macbook, and can now calculate the cycling speed on my computer.
The home-trainer has a computer with a screen that displays all the information. This computer has two sensors connected to it: A heart rate sensor and a flywheel sensor. The flywheel sensor has a 3.5mm jack plug, which gave me the idea to connect it to the line-input on my soundcard (because a line input is nothing more than a A/D converter). This way it was not necessary to solder, or to create an interface.
After starting the audio recording, it struck me immediately that with every stroke of the pedals a small pulse was visible. Based on this I could calculate the distance for each stroke that is made, then I ultimately calculated the speed of the hometrainer on my computer.
Perhaps I will come around to make a GUI for my home-trainer, so I can automatically tweet the results of my workouts. Small detail: Java Sound is a really hard study. A quote I found:
There is no getPitch() method. You need to implement a spectrum analyzer for this. You might find a library online somewhere OR you can go to college, get an engineering degree, learn some DSP and still just throw your hands up in frustration and copy the implementation from a book
I didn’t succeed in getting the SMS communication to work. The compiler had various problems, and due to the time constraints we decided to simplify the task.
When a text-message with the word “Temperature” arrives on the Wavecom modem, the sender received an SMS with the current temperature.
Below are some pictures of the setup with the DB038 PIC board and the Wavecom modem (and RS232 to TTL conversion). On the photographs, the setup is connected to a computer for debugging purposes, it can also operate stand-alone. It is a completely embedded system.
After a short discussion with the teacher, we decided to use the thermostat I developed earlier in a new project that requires an embedded system to interact using SMS.
Meanwhile, all hardware is ready, and the thermostat that was previously written in assembly is rewritten in C. In addition, the thermostat also sends textual messages containing the current status. The only part that has to be developed is the SMS communication.
Below is a short demonstration video, using a computer to communicate. Ultimately, the messages displayed on the computer-screen will be sent using SMS.