This article shows you how to transfer your contacts from iPhone to Android without using googles sync server
Recently I got my first Android phone. As for most of the hacking affiliated people I felt a bit more comfortable with Android that with iOS. How long have I dreamed of having a phone with full access to the source code, with full access to the system. The manufacturer does not force me to buy his over-priced hardware to develop applications for the device. I can install every application I like to install. There are at least 100 more reasons why Android ‘feels’ better than iOS.
However, as I started to move my personal data from one device to the other, I noticed that also Android produces a feeling of discomfort. The system is designed to back up all the data on google servers. This includes contacts, photos, sms, emails, wifi-passwords (they can come in handy for google the next time the street view car passes by )
So either you lose control over your device or you lose control over your data. The best solution to that problem for me is to use an Android phone and try to avoid as much as possible the Google services.
But… already the transfer of my contacts proved to be more complicated than I thought. The usual way to do so is to sync your iPhone contacts with Google and get them beamed to your Android device automatically. That’s exactly how I don’t want to do it. And apparently, there isn’t an easy solution to avoid Google to get all my contacts. The fault here is more on Apples side as they don’t offer a way of exporting the contacts on your phone.
For solving this issue I wrote a little python script which takes the iPhone address book database and transforms it into a vCard file, which should be readable by most of the email client, etc. Oh, and yes, Android offers a direct way of importing vCard files without going through google servers.
What you need to do:
- Download the address book database from your iPhone via ssh: /var/mobile/Library/AddressBook/AddressBook.sqlitedb (You’ll find many guides on how to do that)
- Download my python script from here: https://bitbucket.org/befi/general/src/d741cbdcf9e6/iphone_addr_book_2_vcard/iphone_addr_book_2_vcard.py
- Execute the script in the same folder with the AddressBook.sqlitedb with no parameters
- Use the generated ‘contacs.vcf’ as you like
You might want to adapt the phone number types starting at line 46 of the script. Just play around with the script and check the output (vcf file is in ASCII). Please note that this script only processes names, birthday, telephone numbers, email addresses and addresses. The script is tested with iOS 4.0.1.
This post will show you how I was able to repair my SONY DSC-T9 camera.
Last week I enjoyed some nice holiday in france. Just when I arrived at the “Cote d’azur” my camera stopped working. It was really frustrating not being able to capture that nice blue water down there.
What was even more frustrating is that the camera I am talking about was my “Sony DSC-T9″. Now why should I worry so much about a 6 year old point-ant-shoot camera? Well, the camera does an excellent job at taking macro pictures with flash. I newer saw a camera as good as my T9. To give you an example:
This is a mosquito sitting on my jacket. I was outside in a park, took my T9 and photographed it. The result is pretty amazing (click on the picture for seeing the original size)
Also the compactness of the camera is impressive. The optics are placed vertical inside the camera body with a prism at the top (this prism acts as a 90° mirror which allows to place the camera inside in the vertical direction). Altogether a nice camera.
Now back to the problem. The camera suddenly took a long time powering on and then showed the error message E:61:00 along with a very blurred image.
By googling the code I quickly found out that this has to do with the focus mechanic and is not user serviceable. It didn’t say it’s not hacker serviceable though…
So the first thing I did when I got back from holiday was to open the camera. This is what I found:
On the left you see a very densely packed PCB with a lot of brown flex cables going in and out. These flex cables are often used in cameras as connectors and also as flexible PCBs. They are really fragile. So if you start working on your camera, try to bend them as little as possible. Also take care of the connectors of these cables. To remove the cables, you have to lift the black plastic parts which are pressing the flex cable into the connector. These plastic parts are also very sensible.
On the right side of the picture above you see the optical system in black. Luckily it is connected by just two flex cables to the left of it. I opened the connectors and could remove the whole unit. On the following picture you see the back of the unit. Surprise, more flex cables. How I love them! (attention: irony).
Now let us look at more details of the optical system. We find three motors here, zoom, focus and shutter. How did I find out which motor is for what? Simple: I removed the motors and moved the optical system by hand. With the camera turned on I could see in live the reaction on the screen.
Here is a close-up picture of the focus motor:
We see two coils and four pins on the motor side. Most probably this is a bipolar stepper motor. Mounted on the axis is a thread rod. This rod moves the green slide seen in the picture below:
As you see the technique is very simple. But still, this camera (and probably most other ones) is a masterpiece of engineering.
By playing around with the removed motor I noticed that turning a rotor felt a bit “sandy”. Like if there is something stuck in the bearing. As it is not possible to disassemble the motor further, I needed to do a little trial and error. My first guess was that adding a drop of oil would solve the problem. Unfortunately that was not the case. So then I tried bending the metal of the motor a bit to change the relative angle of the two bearings of the axis. With success! Afterwards the motor was turning with no problem. After putting everything back together, the camera worked as it always did
Maybe some extra info for the curious on how the focus system of this camera works. One interesting thing to notice was, that there is no “end switch” on the focus slide. So the camera cannot really know where the position of the lens currently is. And in fact, it does not need to know. The camera even does not know how far away the object to focus is. Hm, so the camera knows nothing? Yep, but it can “learn” the right focus point. The principle is known as edge based auto-focusing. The camera takes an image patch (usually the marked rectangle on the screen which you point on the object to focus) and calculated the edge image on this patch. An edge image can be seen more or less as a high pass filtered version of an image. Image areas with strong difference in intensity (eg edges) are getting a high value, whereas constant areas (eg surfaces) get a low value.
Now what effect does an unfocused lens have to an image? It acts more or less as a low pass filter. Sharp edges get blurred. High (spatial) frequencies are filtered away.
So, what needs a camera to do to find the best lens position? It just has to shift the lens until it finds the position where the edge image has the most edges in it. This is exactly the point of focus.
You can now probably explain to yourself why the autofocus is so bad at low light. The reason is, that a dark image has relatively low intensity edges, if any. That’s why most cameras have a LED light to brighten up the image patch under examination.
Another little info on that point: Most cameras offer a button for taking close-up shots (the symbol of that button is often a flower). What this button does is also very simple. It shifts the range of the lens move further away from the image sensor. This lets close objects get inside the focus range. The procedure of finding the focus is then the same as in normal mode. Why isn’t the range of the lens move extended to include close and far objects at the same time? Because then the autofocus would take much more time to finish. That is not really desired for a point and shoot camera.
This post shows you how to add a gyroscopic controller to a RC helicopter for yaw control. The remote control protocol was reverse engineered and the helicopter electronics replaced by a home-made version.
Not so long ago very cheap RC helicopters began to get quite popular. One prominent example of those is the PicooZ. It comes together with an infrared RC which is also responsible for charging the battery of the helicopter.
The PicooZ is a classical helicopter design with a main rotor for lift and a tail rotor for counteracting the momentum of the main rotor. In other words the tail rotor is responsible for avoiding that the helicopter spins around its yaw axis. And exactly there lies the problem of these cheap RC helicopters: The do spin around anyway.
The reason for this spinning is that they do not have a closed-loop control system. They just power the tail rotor proportional to the main rotors power. The only way for you as a user to avoid spinning is to counteract by steering command. So ok, maybe there is a closed-loop control system. Your eyes are the sensor, your brain is the controller and your finger is the first part of the actuator… phew, quite complicated.
The idea of this post is to replace the electronics of the helicopter with a homemade version. This version will be able to measure the yaw angular velocity by using a piezoelectric gyroscope. The gyroscope signal is fed into an AVR executing a PID controller which controls the tail rotor.
Lets take a look at the home-made helicopter PCB:
On the picture you see hanging on the left the battery. The big black component on the bottom is the IR receiver with two small SMD transistors left to it for controlling the two motors. The central part is the AVR and on the right side is a potentiometer for setting the gyro zero position. As you see, the PCB itself is very simple. Unfortunately I lost the design files of the board during the move to a new PC (does Eagle nowadays still has that “projects” folder as its default file save location? How many times I have forgotten to copy that dir… ). But by using the pin out in source code you should be able to rebuild such a board with no problem. Just remember to use the thinnest possible PCB material for saving weight.
The gyroscope (ENBC-03JA) was mounted on the back of the PCB (I’ve had this one lying around. You’d probably want to use a lighter one):
As modeling the dynamics of the system would be a bit too complicated, I’ve created a little test stand by the use of my desk lamp and some rubber band:
The main rotor is fixed to the desk lamp. The rubber band is fixed to the helicopter and by spinning the band a few turns, a constant torque can be applied to the helicopter. This torque emulates the torque of the running main rotor during flight. This setup allowed me to tune the PID controller until it was stable enough.
After the controller was working, I had to reverse engineer the RC protocol. Therefore I attached the IR receiver to my good old HP1630G logic analyzer and tried to figure out the meaning of the protocol. It took me a while until I found out the checksum function but from there on the rest was relatively easy.
The last thing to do was to combine RC input and PID controller for having a working helicopter. The following video shows you how the helicopter performs. Note how stable the helicopter keeps the yaw angle when it comes near to the camera. At that moment no yaw command came from the RC, thus the angle kept constant.
You find the source code for the ATTINY45 in one of my repositories. Just execute
hg clone https://bitbucket.org/befi/picooz
This post will show you a simple application of the USB enabled remote control.
The major problem of all kinds of physical remote controls is that they are usually not ready to hand when you need them. If you have to move to get to the remote control, you could as well directly switch on the device. Thus the whole concept of ‘remote control’ is becoming a bit useless. Therefore this post will show you how to create a non physical remote control.
The idea of the non physical remote control is very similar to the clapper switches. But instead of clapping you simply whistle. Whistling has some advantages over clapping. The first and most obvious is that you do not need your hands for whistling. You can continue doing what you are doing and control devices in parallel. The second more important advantage is the expressivity of whistling. You can vary your whistles in the rhythm, the length and the tone whereas you can vary claps only in the rhythm. This expressivity allows you to encode specific commands like “turn desk lamp on” or “turn ceiling light off” and so on.
To whet your appetite, here is a video showing the non physical remote control in action:
So how does this work? Actually it is very simple. A microphone captures audio inside my room. This audio is transformed by a FFT into its spectral components. The FFT gives you the information of the magnitude of the captured frequencies. Inside this frequency representation of the microphone signal we have to look for whistle signals. And in fact, whistle tones have two properties making them very easy to detect. First, they are loud. Thus the magnitude of whistle frequencies will be quite high. Second, whistle signals are very close to single frequency signals (like a perfect sine signal). The following three images will give you an impression on the spectrums captured from the microphone. The x axis describes the frequency, the y axis describes the magnitude of the frequency component.
The spectrum of a whistle sound with no background noise looks like this:
As you can see the whistle sound should be easy to detect. The sharp spike indicates that the whistle is very close to a single-frequency sine.
If we add a little music as background noise, the plot looks like this:
Still, the whistle is clearly visible.
Having a high detection rate is nice. But also the false positive rate should be as low as possible. Lets take a look at a graph of someone talking near to the microphone:
Here we see several spikes. To avoid the highest spike from being detected as a whistle, we introduce a uniqueness ratio. This ratio is defined by the maximum value divided by the second maximum value. In case of the voice graph the uniqueness ratio would be very low, approximately 1.5. In contrast to that in the case of whistling with background music, we have a uniqueness ratio of >8. This filter is very simple but yet effective. The independence of amplitude values let the filter work on loud whistling and soft (far away) whistling without adapting the filter parameters.
You find the implementation of the whistle detector in my mercurial repository in the folder linux/whistle_control . To check out the repo, execute
For running the code you need to have installed the fftw3 development headers (libfftw3-dev for Ubuntu) and the ALSA development headers (libasound2-dev for Ubuntu).
Please note that this code is not really polished. It is a 1h quick hack but it should give you the basis for more advanced implementations. Currently the program only distinguishes between two commands. The relative frequency of two whistle sounds determines which command is executed. low to high => command 1, high to low => command 2. However, this should be easy to adapt to your needs.
Radio controlled sockets are a great way to save power in your home. Devices consuming more power on standby than the sockets do can easily be switched off with a remote. For example my desk lamp from a swedish furniture store consumes 10x more power (in the off state) than a radio controlled socket.
Even if the sockets consume more power in standby than the attached electronic device, they offer the luxury of turning stuff off and on without even moving. In short: They are really handy.
However, if you’ve installed the sockets, one sentence will often reoccur: Where the f*** is my remote?
The goal of this post is to show you a way of adding USB support to remote controlled sockets. This opens up a whole new world to remote controlled sockets. Plug this kind of remote into a computer and you can do amazing things.
This first post will show you how to do the hardware modifications to the remote control. As remote controls are usually different on the inside depending on the manufacturer, the results presented here cannot be applied to all remote controls. But if you buy the same model that I have used you should have no problems.
- Remote controlled sockets set
- AT Mega 8
- Nokia CA-42 Data cable
The Nokia data cable contains a pl2302 USB-to-serial chip from prolific. The data cable is a very cheap way to get to PCBs having all necessary parts for doing serial to USB translation. You could, of course, use any other flavor of serial connection.
The remote control uses the SC5262 chip (datasheet). This chip is capable of sending address and data bits over the air by pulling the /TE pin low. The D0 pin is used for the On/Off information sent to the socket. D1-D3 are unused. A0-A3 are used for channel selection and A4-A7 are used for device selection. The addresses are not binary encoded. One pin of the channel bits is pulled to GND by the channel selector switch on the back and one pin of the device bits is pulled to GND by pressing the appropriate button on the remote. This button press also sets the D0 pin appropriately and pulls /TE low which starts the transmission.
- Prepare the microcontroller with a serial boot loader (Refer to my post on that topic)
- Connect the microcontroller to the remote control board (Connections to the SC5262 chip are in the photo gallery)
- Flash the software into the microcontroller
You see my quick and dirty approach on the images below.
Now let’s take a closer look at the second point, connecting the microcontroller to the remote control board.
The first step is to remove the SMD components seen in the first picture under the yellow cables. The pins D0 and /TE should now be unconnected (and will be later connected to our microcontroller). Also the channel select switch should be unsoldered. This allows you to have software control over the channel.
The second step is to mount the microcontroller to the back side of the board. The “dead bug” technique worked well for me but feel free to use any other method you like. The connections from the AVR to the SC5262 are found in the picture gallery above.
The original remote control is powered by 12V. I found that using 5V from USB as a power supply works as well. The range of the remote control is a bit lower but still sufficient. It’s up to you: Use 5V and no battery for being maintenance free or use the battery and get a better range. The supply voltage of the microcontroller has to match with your USB -to-serial adaptor. In case of the Nokia cable, the AVR has to be powered with 3.3V. Oh, and not to forget: Connecting the Grounds of AVR, Remote control and USB-to-serial adaptor together.
Now, if you have connected the serial wires to the AVR, you are ready to flash the software. If you have not yet done it, clone my repository: hg clone https://bitbucket.org/befi/remote-controlled-socket
You find the software for the microcontroller in the subdirectory uc/remote_controlled_socket. The programming of the software is done the same as described in in my post about the serial boot loader. Just type make, reset the microcontroller and within two seconds type make program. Congrats, you now have your USB enabled remote control!
Ok, it’s time to test our remote control. Plug the module into your computer. First, set the baud rate of the serial interface:
stty -F /dev/ttyUSB0 19200
The remote control is now ready to receive your commands. The characters ’1′ – ’4′ are used to switch a socket on. Characters ‘A’ – ‘D’ are used to switch it off:
echo 1 > /dev/ttyUSB0
echo A > /dev/ttyUSB0
The following video shows the remote control in action:
One great thing about AVR microcontroller is that they can “program theirselves”. This is not unusual for nowadays microcontrollers but for a legacy like device like an AVR it is really nice to have.
The idea is: When the AVR wakes up from reset a special program is started, called the boot loader. This program usually waits for some kind of action like a pulled up pin or data reception via the serial port. If non of these events occur in a specified time, the boot loader hands the control on to the main program.
For many applications it is nice to be able to change the program running on the microcontroller without the need of a special programming hardware. The boot loader presented in this post will enable you to do so.
- Check out my repository using mercurial ( hg clone https://bitbucket.org/befi/remote-controlled-socket )
- The folder uc/avrprog_boot_v0_85 contains the boot loader
- Type make to build the bootloader
- Insert the ATMega8 into your AVR-MK2 programmer and type make program and the boot loader will be flashed and the fuses of the AVR are set accordingly (clock is set to 8MHz)
The makefile uses avrdude to flash the chip. If you use a different programmer than the MK2 you can change the parameters in the Makefile.
Ok, now we have a AVR with a serial boot loader installed. What next? Take a look at the folder uc/analog2usb in my repository. You’ll find an example program which reads values from the ADC and outputs them via the serial port.
What is interesting about that example is the Makefile. You can flash the program over the serial port into the microcontroller without using a programmer.
- Attach a Serial-To-USB converter to your microcontroller. This should give you a /dev/ttyUSB0 device unter Linux
- Reset the microcontroller and within 2 seconds execute make program from the analog2usb example
- Voilà, your AVR is now programmed via serial
To explain what has happened here: After reset the AVR waits for two seconds for the programming byte “S” via the serial line at 19200 baud. If the “S” character is received within two seconds, the boot loader emulates a AVR109 serial programming dongle. After that avrdude is called to flash the main program into the chip.