One of my first posts showed how to control RC wall sockets with your computer. I use this system at home for switching my lights and my music amplifier (which is connected to the soundcard of the computer which controls the RC wall sockets). I’ve written an Android App for switching everything on and off and there is also the whistle control for those devices. These things are great but it always happened to me that I forgot to switch off the amplifier. So I wrote a script to automate the power switching of the amplifier. It is called turn_on_amplifier_if_audio_starts_playing. Now whenever I am starting a song via MPD or I watch a film with VLC or I simply use the computer as a remote sound card via pulse audio, the amplifier turns on immediately. After the music/whatever is finished, the script waits for 60 seconds and then turns the amplifier off. A nice feature of this is that all the actions are ‘edge’ based. If the sound card goes from idle->active, the amplifier is turned on. If it goes from active->idle, it is turned off. The advantage of this is that when I turn on the amplifier manually for listening to LPs, it stays on. In contrast, ‘state’ based actions would let the computer think ‘hey, I’m not playing anything, I’ll turn off the amplifier’.
There is also a conf file for upstart which can be placed under /etc/init for turning this script into a service.
The script works by checking every second the content of the file /proc/asound/card0/pcm0p/sub0/status . If it contains ‘RUNNING’, something is playing on the sound card. I admid, it is reeally hacky. But maybe it is useful to someone. I would much more prefer to have a hook which is called by ALSA whenever the state of the sound card changes. If someone happens to know about something like that, please leave a comment!
This post will show you how to modify a USB hub to enable per-port software controlled power switching
Recently I started working on automating the second stage backups on my server. In contrast to plugging in manually a hard drive and start the backup script by hand I wanted to have a cron job which does the thing automatically. For this to work, the hard drive needs to be connected to the system all the time.
My server at home is an ODROID embedded board. One of the reasons, besides many others, why I prefer this over a “virtual private server” is cost. The ODROID only consumes 1.5W in idle, which is equivalent to 4€ per year. When I added my second stage backup hard disk, I noticed that the power consumption increased by 2W. Note that this is the consumption when the disk is not spinning. This is quite horrible, because the disk needs to run only once a month for some hours. Thats where my hacker instincs said: “There has to be done something to make this better”.
My first idea was to use one of those manually switchable hubs as seen in the image below.
I would have thrown an AVR in there, connected it to one of the USB ports and replaced the mechanical switches by transistors. This way I could have switched the hard disk completely off. This looked doable but also a bit too complicated. That’s why I continued to look if the USB standard offers a similar functionality. And apparently it does! It is call per port power switching (PPPS). Nice! See http://tiebing.blogspot.de/2011/01/use-linux-to-control-outlet.html for an introduction on how to check if your hub is compatible.
However, although most of the USB hubs advertise that they are able to do PPPS, they actually are not supporting this feature. The reason for this is that the chipsets inside the hub usually support PPPS (and advertise themselves as so) but the manufacturer of the hub omitted the switches (to save costs) and instead connected the USB ports directly to +5V.
The USB hub I had (no-name china crap “ID 0409:0059 NEC Corp. HighSpeed Hub”) did not advertise itself to support PPPS. I cracked it open anyways to see what chip it used. It was the uPD720112 from NEC. And according to the datasheet, it does support PPPS. The trick to enable it was to tie the configuration pin GANG_B to +3.3V. After that the chip did advertise itself as PPPS compatible :) Of course PPPS was still not working as this hub is missing the power switches.
According to the datasheet, the output pins PPB(1:4) for power control of the ports are open-drain Nmos active low drivers which are 5V tolerant. This is exactly what you need for controlling a high-side Pmos switch. Nice! All that there was to do is to cut the VBUS connection to the USB port and add a transistor and a resistor. The circuit of all this is below:
A picture of the modified USB hub with one switchable port (note that this picture shows my first attempt using a PNP bipolar instead of a Pmos):
And a picture of the hub controller where I patched into with some enameled wire:
To switch the port on and off, I used the following program: http://www.advistatech.com/software/hub-ctrl-20060120.c.
A nice feature in the case of a hard drive connected to a switchable port is that you can make the power switching transparent to the user. This can be done by the help of autofs.
The auto.master file looks like this:
The contents of auto.usbdisk are:
#!/bin/bash ./hub -b 1 -d 4 -P 1 -p 1 sleep 2 echo "-fstype=auto :/dev/$1"
The auto.usbdisk file is a shell script and needs the rights 755. To explain what this script does: ./hub is the program mentioned above to switch the USB port power on and off. The parameters are:
-b 1: USB bus id to which the hub is connected
-d 4: USB device id to which the hub is connected
-P 1: USB hub port which shall be switched on
-p 1: switch the power on
The parameters for the bus and device id of the hub can be found with the command lsusb. After switching on the port, the script waits for two seconds until the hard disk is recogcnized by Linux. Then the location of the hard disk is reported back to autofs by the echo statement.
If you access /mnt/usbdisk/sda1, autofs will call the script above, which turns on power to the hard disk. After that, autofs will mount the file system and you can access the data. Pretty neat!
After a timeout (the default is 600s) autofs will unmount the file system. I haven’t found a hook to this event to also turn off the power of the usb port. Instead, I wrote a little script which checks if the disk is still mounted. If this is not the case, it is safe to turn off the power.
#!/bin/bash if [ $# -ne 4 ] then echo "Usage: $0 <disk device> <busid> <deviceid> <portnum>" exit 1 fi if mount | grep "$1 on" > /dev/null then echo "$0: $1 is mounted. Doing nothing" else echo "$0: $1 is unmounted. Turning power off on bus $2 device $3 port $4" ./hub -b $2 -d $3 -P $4 -p fi
The script is called at a regular interval by cron. The crontab line for calling it every 15 minutes looks like this:
*/15 * * * * power_off_unmounted_disks.sh /dev/sda1 1 4 1
To be honest, a fixed bus id and device id is not the most elegant thing. A script which finds the bus and device id of the hub automatically is still on my todo list.
So, in summary this post showed you how to enable per-port power switching to off-the-shelve USB hubs. In my case, I use it for switching off two hard disks, a USB TV receiver and a USB sound card. This saves around 10W, which is equivalent to 30€ per year. The best thing about this is that this does not create any overhead for me as the devices are all powered on and off automatically.
UPDATE: Finished scripts
You can get the finished scripts here:
hg clone https://bitbucket.org/befi/general
(The scripts are inside the subdirectory usb_hup_ppps_scripts )
How to use them:
ln -s /dev/disk/by-uuid/7865fdg67fh6fd7888dfg5d /opt/data_partition
The name here is important. The first part is the name of the partition, _partition needs to be fixed!
*/15 * * * * power_off_unmounted_disks /opt/data_partition
This can be done with as many disks as you like. Only the first and the last step have to be repeated to add another disk.
How to use all this? Well, simply access /mnt/data and the disk will be powered on and mounted. That’s all :) The crontab entry then takes care of removing the power.
To explain the scripts:
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: