Intermission (queue muzak organ music)

Kept you waitin’, huh? So why would I start again to blog after 10 years of silence? I decided that with all the clankers around, I’d rather add some organic home-grown hand-made text to the primordial soup of the T1000 while I still have the time. But in all seriousness: I don’t want this web to die, so I’ll try to fight the second eternal september. This time it’s not humans flooding the net, but bot and my way to go about it is not to go out with a wimper! So I start publishing my little hacking adventures again.

Checking dmesg I get this:

[   35.439555] amdgpu 0000:c1:00.0: [drm] REG_WAIT timeout 1us * 100 tries - dcn31_program_compbuf_size line:141
[   35.439872] ------------[ cut here ]------------
[   35.439875] WARNING: amd/amdgpu/../display/dc/hubbub/dcn31/dcn31_hubbub.c:151 at dcn31_program_compbuf_size+0xcc/0x230 [amdgpu], CPU#0: kworker/0:2/180

And I found a bug report on github that reports the same error and this kernel ticket, and I actually got nerd sniped by the problem, and started to tinker with patching my kernel to try and fix the issue, but then I remembered. I don’t have time for this and neither do you.

So just:

sudo nano /etc/default/grub

add “amdgpu.dcdebugmask=0x410” to kernel boot parameters, like so:

GRUB_CMDLINE_LINUX="amdgpu.dcdebugmask=0x410"

and regenerate grub config

sudo update-grub

That’s it. You’ve thrown out a bit of battery life for a working screen, an excellent trade-off for the time being. I hope I saved you some time.

This short post shows how to replace the motors of a Syma X12S quadcopter and highlights some difficulties to look out for.

Replacing the motors

The Syma X12S quadcopter has two pairs of motors, two spinning in one direction and two spinning in the opposite direction. Both motor pairs are placed diagonally in the quadcopter mount positions (see items 04 and 05 in the exploded assembly drawing below). This design concept accounts for the spin moment of each rotor, assuring an equilibrium on the overall spin moment.

Replacing any part of this quadcopter model is straight forward, even for people that are not so technically gifted: The only tools needed are a small Phillips screw drive and basic soldering equipment. To get access to the motors you only need to remove three parts. First, the rotor blades of the motors need to be removed:

They are simply pushed onto the motor shaft, creating a frictional connection. So just reverse the process by pulling them off again. Do not pull on the blades, as they bend and break easily. Instead grab the rotors at the hub.

Next, the bottom cover plate needs to be removed, which is held in place by four screws:

Then, remove the chassis parts that cover each motor, which serve as a rotor blade protection and landing gear. Only remove the one(s) on the motor(s) you want to replace. This is probably the most delicate step: Theses parts are kept in place by two tiny clips each. Removing the part without breaking the clips requires a little patience and a steady hand – I ripped one off right away. If you break one of the clips, the part will not be held in place anymore after reassembly (later in this guide). Applying adhesive or a tiny drop of hot glue will fix this.

The Picture above shows the motors ready for removal. They are simply pushed into the chassis (no adhesive is applied) and the two wires are soldered to the PCB. When replacing the motors, make sure to swap it with the correct motor type (The “normal” or counter-spinning motors can easily be distinguished by their wire coloring).

Finally, reverse the steps above to reassemble the quadcopter again.

Difficulties to look out for

Never rotate the rotors manually

Rotating the motors manually (with your hand or by blowing on the blades) should be avoided. Manually rotating electrical motors induces voltage in the circuity. Although most (good) circuits have protection against this phenomenon, it is good practice not to do so.

Motor cable length

The length of the cables is just enough to push the motors into the mounting positions in the chassis after soldering the wires. However, twisting them is not possible then, which makes the bottom cover plate not fit that easily anymore. So ideally, install the motors first and solder the wires last.

Rotor blade form

Your quadcopter does not lift off after repairing?

Since there are two different motor types spinning in different directions, it is clear that they need different rotor blade forms to create lift (see the exploded assembly drawing shown earlier in this post). The shipped rotor blades came in two different colors (black and white) so I thought that each color marked one of the two rotor forms – why else would there be two black and two white rotors? Well, this was not the case. The rotor color has nothing to do with its form! That was quite confusing to me. So make sure to fit the right rotor blades on each motor.

In this post I will explore how to stream 720p (or any quality for that matter) from one computer to another using ffmpeg and netcat, with a latency below 100ms, which is good enough for many games. TL;DR; If you don’t care about the technical details, just jump to the end of the post to try it out yourself.

The problem:

Streaming low-latency live content is quite hard, because most video codecs are designed to achieve the best compression and not best latency. This makes sense, because most movies are encoded once and decoded often, so it is a good trade-off to use more time for the encoding than the decoding.

One way to save space or bandwidth is to compress different parts of a movie with varying quality. For example, the h264 encoder will compress fast moving scenes more than a slow scene, because the human eye will not be able to see all the detail in the fast moving scene anyway, while the viewer might inspect the image of a slow scene more thoroughly. But to do so, the encoder has first to find out if it is currently encoding a fast- or slow-moving scene.

There are essentially two ways to find out if the content is fast- or slow-moving: The most commonly used method for non-live content is a so called two-pass encoding, in which the encoder first analyses the whole movie and then, in a second pass, encodes the movie using the information acquired before. Unfortunately this is not possible for live content. The second way to do this is to look ahead for a few frames in the movie material and then to decide adaptively whether this is a slow or a fast scene. Since it is not possible to look ahead in live material, the encoder has to buffer some frames before encoding them, so it can know what’s coming up next. This buffer however introduces latency in the ballpark of seconds rather than milliseconds, which makes it impossible to create an interactive live-stream using this technique. This also is a simplified example, since modern encoders can use multiple reference frames if the past and future of the current frame to reduce the redundancy of image data. These frames are called GOP (group of pictures) and those will play a significant role to get to a sub-second latency stream.

Because a low-latency live stream cannot afford the time to analyse the video material up front, live streamed content will always look worse than any other encoded content, and this can only be countered by using more bandwidth.

I found some blog posts that explain live-streaming in depth and most of them used the mpeg2video encoder, but most of them “only” wanted real-time encoding, but not necessarily low-latency. I achieved quite good results using mpeg2video, with the lowest latency of all the codecs I tried out, but also wanted to explore if I could achieve better image quality. So I tried out the x264 encoder using the “zerolatency” tuning. While the “zerolatency” tuning did help, I still had a huge latency, far from playing any game on a live stream. So I did a little digging and found a thread on the x264dev forums, which I resurrected from the internet archive, in which a lot of additional x264 flags are discussed. The most important one to bring down the latency was to use the smallest possible vbv-bufsize (which is the encoder buffer). Another good advice is to use so called intra-refresh, which means that there aren’t any full key frames anymore, but instead contents of a key frame are transmitted in blocks over time. This means that there is not a burst of data to send for each key frame, but instead parts of the image are refreshed over time. To figure out if some option would improve the latency or not I needed a way to measure it.

I wrote a quick script in python that would output the current time in milliseconds to measure the latency:

#!/usr/bin/python3
import time
import sys
while True:
    time.sleep(0.001)
    print('%s\r' % (int(time.time() * 1000) % 10000), end='')
    sys.stdout.flush()

Using this script, I would then encode and decode the stream on my desktop at the same time. Making a screenshot of both the original desktop and the streamed desktop next to it gives me the total system latency.

On the the real desktop the time is at 6884, and on the right the streamed desktop it is at 6794. In this example the stream has a latency of about 90ms

In this way I could measure if any changes I made really improved the latency of my video stream without the network overhead. This would not always be totally accurate, as ffmpeg might take a snapshot of the desktop just before a new image is rendered by the Xwindow system, but should not be too far off. Using this measurement tool, I made a lot of changes to the encoder options, but at some point I hit a brick wall. I couldn’t get the latency down any further: The client side was buffering the stream as well! I used mplayer to playback my video stream and tried out all kinds of flags like -nocache and -framedrop. While all of them helped a bit, mplayer performed best when using the -benchmark flag… Which seems to bypass anything that is not part of the actual video decoding process, which is exactly what was needed. After figuring out good settings for the encoder and decoder, I also tried out other transport streams like RTP, but mpegts was the faster in my tests. I guess it would be possible to achieve even better latency using ffmpegs UDP stream instead sending the stream over TCP using netcat, but the UDP stream would break down after a few seconds, even on the local loopback, throwing around cryptic error messages about circular buffers… The solution: =============

Using h264 (okay latency, better image quality, low bandwidth, high cpu usage)

The examples given here require at least 3000kbits/s or 3Mbit/s bandwidth.

On the host:

ffmpeg \
    -f x11grab -s 1280x720 -framerate 30 -i :0.0 \
    -c:v libx264 -preset veryfast -tune zerolatency -pix_fmt yuv444p \
    -x264opts crf=20:vbv-maxrate=3000:vbv-bufsize=100:intra-refresh=1:slice-max-size=1500:keyint=30:ref=1 \
    -f mpegts - | nc -l -p 9000

For further x264 options check out this guide. If you want to change them for your scenario, you always have to make sure that your

vbv-bufsize = vbv-maxrate / framerate

so in this scenario, for 3000 vbv-maxrate, I chose a vbv-bufsize of 100 at 30 FPS.

On the client:

nc <host_ip_address> 9000 | mplayer -benchmark -

Note: always use the -benchmark flag on the client-side. -framedrop might help as well, especially on slower clients. Using mpeg2video (lowest latency, low image quality, high bandwidth, lower cpu usage) ————————————————————————————-

Using mpeg2video, I could achieve almost no noticable latency, but the bandwidth requirements go through the roof, so this is only an option when you have either very fast WiFi or a LAN.

On the host, using about 16Mbit/s:

ffmpeg \
    -f x11grab -s 1280x720 -framerate 30 -i :0.0    \
    -c:v mpeg2video -q:v 20 -pix_fmt yuv420p -g 1 -threads 2 \
    -f mpegts - | nc -l -p 9000

Increasing the -q:v setting will lower the quality and save some bandwidth and vice versa, setting it to a lower value will increase quality and bandwidth. Setting the quality to 2 gives a perfect image, but uses something around 150Mbit/s!

The client is the same as above in the x264 example.

Extra tips:

If you have the spare network bandwidth and CPU time, you can double the frame rate to 60 and you’ll get another latency drop. Using mpeg2video and 60 FPS I achieved essentially zero latency on the local loopback device, so all that is left is network latency. Also, you can try out the ultrafast setting of x264, but this only made the image look worse while not helping too much with the performance.

If you want to try to tweak this setup even further, you can pipe the host directly into the client instead of using the network, using the -quiet option of mplayer to see what the encoder is up to.

All for nothing

After all those tweaks, tests and setting everything up, streaming my desktop in 720p over WiFi to my laptop works very well. Unfortunately the input lag of the projector is extremely high in the “normal” mode and the so called “fast” mode or “gaming” mode cannot be turned on when using VGA as signal input. So I’ll have to wait until the HDMI cable arrives… bummer.

# Create a new full-hd modeline setting using cvt
cvt 1920 1080 60
# copy the cvt output after the Modeline and add it to xrandr
xrandr --newmode "1920x1080_60.00"  173.00  1920 2048 2248 2576  1080 1083 1088 1120 -hsync +vsync
# make the mode available to the VGA output, in my case VGA-0
xrandr --addmode VGA-0 "1920x1080_60.00"
# now set the mode for the VGA output
xrandr --output VGA-0 --mode 1920x1080_60.00

The difference between the original modeline and the new one is the vertical refresh rate: The projector proposed 60.02 Hz via EDID, and the new modeline is just a tad slower, using 59.94 Hz. I was connecting a ThinkPad T60 to the projector, so the problem might also be the RAMDAC of the laptop, something about blank phases, who knows.

That little ARM machine is a beast in the size of a cigarette pack, featuring a total of eight CPU cores, an ethernet port and most importantly an USB 3.0 port to connect an external hard drive. It also comes with a plastic case, with a small fan inside and a PSU that is strong enough to power external hard drives connected to the USB ports. I ordered the smaller “Lite” version, which has a slightly lower CPU clock rate, but costs a lot less than its bigger brother.

In this post I’ll guide you quickly through the installation process of the ubuntu image on a micro SD-Card, how to make use of all the space on the microSD card and how to secure this little fellow a little after the installation of the image.

Installing the Operating System Image

Download the latest Linux image from their site and unpack it using xz:

$ xz --decompress IMAGE_FILE.img.xz

The actual image file will of course be called something like ubuntu-14.04.1lts-lubuntu-odroid-xu3-20150212.img.xz and not IMAGE_FILE.img.xz.

Then plug in the SD Card into you linux computer and check out were it was mounted using dmesg.

$ dmesg | tail
... some other output ...
[ 6060.833668] sd 8:0:0:1: [sdX] Attached SCSI removable disk
[ 6077.944503] sd 8:0:0:1: [sdX] 60874752 512-byte logical blocks: (31.1 GB/29.0 GiB)

You will see something like sdb or sdc in the output, make sure that you got the letter right; I will use sdX as a placeholder. As you can see I bought a 32 GB SD Card so I would never have to worry what I install on the machine, because there will be more than enough room for it. Also make sure you’re buying a quality SD-Card with fast write rates for better performance.

Now you can copy the image onto the SD-Card.

Warning: All the data on the SD-Card will be lost forever in this process so make sure this SD-Card does not contain any bitcoins or wedding photos you might miss later!

dd if=IMAGE_FILE.img of=/dev/sdX bs=128k

Depending on your SD-Card this process may take some minutes and dd will not give you any indication of the progress so be patient.

Before you can actually boot from the microSD card, make sure the correct boot mode is set. The ODROID XU3-Lite can either boot from a microSD card or from a eMMC module. There is a tiny switch on the board, to set the the boot mode as explained in the ODROID wiki, which I found a bit confusing to be honest. Set the switch as shown in the picture below.

Now you can insert the microSD card and plug it is and it should boot up in about 20 seconds, and automatically connect to your network using DHCP.

Now you can login your new system using SSH from your linux computer (in my case it had the IP 192.168.1.87, but you might need to login to your router to find out what IP the ODROID received):

ssh root@192.168.1.87

As always with new SSH connections:

 Are you sure you want to continue connecting (yes/no)?

Enter “yes” to proceed. The default password is odroid

First, let’s check how much space I have left on the SD card.

root@odroid:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/mmcblk0p2  4.9G  4.4G  313M  94% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
udev            747M  4.0K  747M   1% /dev
tmpfs           998M  4.0K  998M   1% /tmp
tmpfs           200M  2.6M  197M   2% /run
none            5.0M     0  5.0M   0% /run/lock
none            998M   72K  998M   1% /run/shm
none            100M   20K  100M   1% /run/user
/dev/mmcblk0p1  129M  5.1M  124M   4% /media/boot

Only some hundred megabytes? Well, thats because the image I flashed onto the SD card also contains the partition layout and the contained file systems, which is as small as possible, so people can use this image also on smaller SD cards. So let’s change that.

First off, partitions are not the same as file systems! So we need to resize the partitions to match the SD card first, and then resize the filesystem to match the partitions.

Resize the partitions

Since the image was about 6 GB in size, but I bought a 32 GB micro SD card there is a lot of space to be gained. Doing this on a live system is far from a good idea, but since this is the stock system, I don’t care; There’s no data to be lost. Never do this on a system with data you (or somebody else) care about.

root@odroid:~# fdisk -l
 
Disk /dev/mmcblk0: 31.2 GB, 31167873024 bytes
4 heads, 16 sectors/track, 951168 cylinders, total 60874752 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000c4046
 
Device Boot              Start         End      Blocks   Id  System
/dev/mmcblk0p1            3072      266239      131584    6  FAT16
/dev/mmcblk0p2          266240    10915839     5324800   83  Linux

So we’ve got 2 partitions here. The first one (/dev/mmcblk0p1) contains the bootloader and the second one contains our ubuntu linux system. By the way: If you ever wondered, mmcblk0p1 stands for Multi Media Card Block Device 0 Part 1. Makes it a bit easier to remember. Let’s write down the total size of the SD card in cylinders somewhere.

So let’s fire up parted to and first check the partition numbers using print.

root@odroid:~# parted /dev/mmcblk0
GNU Parted 2.3
Using /dev/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.           
(parted) print
Model: SD SD32G (sd/mmc)
Disk /dev/mmcblk0: 31.2GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number  Start   End     Size    Type     File system  Flags
 1      1573kB  136MB   135MB   primary  fat16
 2      136MB   5589MB  5453MB  primary  ext4

Then we set the unit used by parted to cyl, so when we resize, we can enter the number of total cylinders of the card we wrote down earlier when using fdisk.

(parted) unit cyl

Now we can resize the partition 2 (which contains the ext4 filesystem) to use all the available space:

(parted) resizepart 2                                         
Warning: Partition /dev/mmcblk0p2 is being used. Are you sure you want to continue?
Yes/No? yes                                                               
End?  [170559cyl]? 951168
(parted) quit

Alright, so now the partition ends at the end of the SD card.

Resize the file system

Now we can resize the filesystem to the size of the enlarged partition using resize2fs:

resize2fs /dev/mmcblk0p2
resize2fs 1.42.9 (4-Feb-2014)
Filesystem at /dev/mmcblk0p2 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 2
The filesystem on /dev/mmcblk0p2 is now 7576064 blocks long.

So let’s check the space again:

root@odroid:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/mmcblk0p2   29G  4.4G   24G  16% /

Bam. Now with so much space available, lets fill it with pictures of squirrels. Sometimes I’m overwhelmed by the sheer awesomeness of linux.

Create local user and Disable root user login:

As seen before, your home server can be easily accessed using the default root login, which is not so nice. So lets add another user to login with and also make sure nobody can ssh into the server using the root user.

First add a new user and put that user into the sudo group, so this user can issue all kinds of system commands.

$ adduser USERNAME
$ usermod -a -G sudo USERNAME

Now, before we block ssh access for the root user, make sure you can login to the server and execute sudo using the newly created user, or you have locked yourself out of the system!

Now edit /etc/ssh/sshd_config to disable the root login, using any command line text editor (I’m using nano in this case):

$ sudo nano /etc/ssh/sshd_config

And now set PermitRootLogin to No:

PermitRootLogin no

Once you have saved the file, you can restart the ssh server to make the changes take effect.

$ sudo service ssh restart

That’s it, happy hacking!

I was almost at the point to buy a playstation or xbox controller to use with my tablet, since they seem to be supported out-of-the-box. But actually I still have an old USB controller lying around, which would be more than good enough for playing some games. Interestingly my gamepad did in fact work partly, but only the left analog stick and one or two buttons, and the rest did not. My hacker spirit told me that this must be fixable somehow.

So I started hacking around and added support for my old USB gamepad for my android tablet. In this post, I’ll show you how I did it and how you can to add support for any gamepad to your phone or tablet as well!

First of, your tablet or phone needs to be rooted to make the changes needed to support your gamepad. But just about any device is rootable by now, so a quick search will tell you how to root it, if you haven’t done that already.

Prequisites:

• rooted android device
• USB-OTG cable (to connect the gamepad)
• ADB
• A linux computer
• evtest (utility program to read raw gamepad input)

Make sure to install evtest and the android debug bridge (adb), which should be available for most linux distributions.

I recommend using ADB wireless to connect to your device, so you can transfer files and type in shell commands while the gamepad is plugged in. I personnally use the open source ADB Manager for that purpose.

And by the way: I am not responsible if you break anything, bla bla. Changing stuff on your android device might as will break it, so proceed with caution. Also, the commands in this how-to are specific to my tablet and gamepad and you have to change them accordingly to your device and hardware.

Finding the keycodes

Android maps all gamepad keys to some internal actions. For example some gamepad key with the number 289 is mapped to the action BUTTON_X for some specific keyboard, gamepad or hair-dryer. Here’s the documentation of the keymap files, which will tell you a lot about how those are composed. Those keylayouts are inside /system/usr/keylayout/ on your android device. So all we need to do to make your gamepad compatible with android, is to create a keylayout that tells android what keys of the gamepad mean which action inside android. That means we have find the keycode and axis ids of all the buttons and map them to the android actions.

First plug in your gamepad into your linux computer. After doing so, run dmesg in a terminal to find out the vendor and product id of your gamepad. This will be important later.

$ dmesg
usb 3-1: new low-speed USB device number 10 using xhci_hcd
usb 3-1: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes
input: Mega World USB Game Controllers as /devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1:1.0/0003:07B5:0315.0008/input/input24
hid-generic 0003:07B5:0315.0008: input,hidraw3: USB HID v1.10 Joystick [Mega World USB Game Controllers] on usb-0000:00:14.0-1/input0

In this output, the important part is 07B5:0315, which are the vendor ID 07B5 and the product ID 0315. Your output might look different depending on your kernel version. If you can’t figure out what’s what, you can also run lsusb to get a more readable output.

$ lsusb
Bus 003 Device 005: ID 8087:07dc Intel Corp.
Bus 003 Device 010: ID 07b5:0315 Mega World International, Ltd
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

To find out the key codes you will have to install and use the program evtest

To get the raw keycodes, we have to read the signals directly from /dev/input. As there are many devices inside /dev/input, you will have to try out which device is actually your gamepad. Normally it will be the last event device, in my case thats /dev/input/event18.

$ evtest /dev/input/event18

Now press some buttons to find out which button has which key code. Pressing a button will yield some output like that:

Event: time 1428772902.008207, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90001
Event: time 1428772902.008207, type 1 (EV_KEY), code 288 (BTN_TRIGGER), value 1
Event: time 1428772902.008207, -------------- EV_SYN ------------
Event: time 1428772902.120190, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90001
Event: time 1428772902.120190, type 1 (EV_KEY), code 288 (BTN_TRIGGER), value 0
Event: time 1428772902.120190, -------------- EV_SYN ------------

Write down the keycode for that button, in the case above thats 288 for the A-Button, so we can later put it inside the android configuration. For me the following configuration came out. I wrote down all the Buttons that are mapped to something in android.

Also wiggle the analog sticks first horizontally then vertically to find out the axis of each stick. In my case those where axis 0/1 for X/Y left and 2/5 for X/Y right. Using the documentation from the android website and by looking at the other keylayout files on my tablet, I created a configuration file like this:

#
# Mega World USB Game Controllers
#
 
key 288   BUTTON_A
key 290   BUTTON_B
key 289   BUTTON_X
key 291   BUTTON_Y
key 292   BUTTON_L1
key 294   BUTTON_R1
key 293   BUTTON_L2
key 295   BUTTON_R2
key 296   BUTTON_SELECT
key 297   BUTTON_START
key 298   BUTTON_THUMBL
key 299   BUTTON_THUMBR
 
# Left and right stick.
axis 0x00 X
axis 0x01 Y
axis 0x02 RZ
axis 0x05 Z

Before you put that configuration file on your device you can optionally use the validate keymaps tool from the android sdk to make sure you didn’t make any mistakes creating the configuration.

The configuration should now be saved to a file that includes the vendor ID and product ID of your gamepad. In my case the vendor ID is 07B5 and the product ID is 0315 so the name my configuration file is Vendor_07b5_Product_0315.kl

Android uses the file name to make sure to only load specific configurations for specific USB devices, so make sure those are correct.

Adding the configuration to your device

After saving the key mapping to Vendor_07b5_Product_0315.kl, we need to upload the file back onto the device. We’ll use adb for that. As described earlier, I recommend using ABD wireless so it’s easier to make changes to the configuration while the gamepad is plugged in.

We put the configuration on the sdcard and move it afterwards to the correct position on the device, because we don’t have root access over adb (so we can’t move the configuration directly into the appropriate system folder)

$ adb connect
$ adb push Vendor_07b5_Product_0315.kl /sdcard/

Before you can move the file to the correct location you must remount the /system partition, to make it writable. This may differ from device to device. Check where your /system is mounted using the mount command before. In my case /system is mounted to /dev/block/mmcblk0p20, so I remount that device read-write-able.

Also make sure to allow the adb shell to become root on your tablet once you have entered the su command.

$ adb shell
$ su
$ mount -o remount,rw /dev/block/mmcblk0p20

Now we can copy the key layout from the sdcard into the keylayout folder:

$ cp /sdcard/Vendor_07b5_Product_0315.kl /system/usr/keylayout/

And really important, you have to change the permissions of the file to 644 or android will not load it after the gamepad was plugged in!

$ chmod 644 /system/usr/keylayout/Vendor_07b5_Product_0315.kl

Now you can connect your gamepad to the android device and play some games to check if everything worked out. If something went wrong, you can always upload a new version of you keymap to the sdcard, move it to the system folder, change the permissions and replug your gamepad to make more tests.

Once you have tested that everything works, make sure to remount the /system partition back to read-only.

 $ mount -o remount,ro /dev/block/mmcblk0p20

And now I can finally play GTA: San Andreas on my tablet using my really old cheapo USB Gamepad, which is incredibly better than the touch controls. Great.

I am a big fan of using foam rollers for myofascial release, especially after workout.

There are a lot of foam roller products for myofascial trigger point treatment out there, but I am too cheap to buy a piece of recycled plastic pressed into a cylindrical form for 20 EUR or higher. This is one of the easiest DIY projects possible, so make your own!

The standard foam rollers of different sizes can be replaced with almost anything that has a similar form and supports your weight. I used PVC tubes from a hardware store nearby. Just chose your preferred diameter, cut of the flange (using a Dremel or a standard saw) and you are done.

Now for the back area, foam rollers exist in the form of two spheres connected in one point.

The small version can easily be replicated by putting two tennis balls into nylon tights and tying a knot at the end. This might sound/look a little strange, but seriously it works well (although the tennis balls are almost a little too soft).

For higher durability, add a few more nylon layers.

You can probably think of a bigger and harder version and probably find a lot of (even better) alternatives for foam rollers.

Happy foam rolling!

This post shows how it is done and why I still would not recommend it anyway.

Please note the difference between a broken glass screen/digitizer and a broken display! The display is the actual electronic part, while the glass screen/digitizer is… well, just a glass screen glued on top of the real display. A broken display can also be repaired (=replaced), but since the display essentially “is” the mobile phone (with most parts soldered onto it as SMDs) it makes no economic sense — buying a new phone would be the right way to go here.

Also be advised, that these instructions can — if not applied correctly — lead to a (completely) broken and unusable phone. You do this at your own risk!

Replacing the glass screen/digitizer

Technically, replacing the glass screen/digitizer is very easy: all you need is the replacement part (make sure it ships with the necessary adhesive included!), a hairdryer, tweezers, alcohol (~70% ethanol) and a deck of cards (you probably get the wrong impression now, so please read on 😉 ).

Simply put, the display is mounted into the casing with some industrial grade adhesive. The same adhesive is used to merge the glass screen/digitizer with the display (with a layer in between). This adhesive effect can be reduced by applying moderate heat.

Start by removing the back cover and the battery. Then gently apply (moderate) heat with the hairdryer at the top front, but be careful not to heat it up too much. Then start fiddling a card from your card deck (I used a laminated business card) between the glass screen/digitzer and the case. In this initial step, it might be better to use a razor blade (be careful!) just to open the first gap to insert a card. Only use non-scratching tools (like a card) from here on to protect the display. Also make sure to start at the top front on the left side (see figure below). This is the least sensitive region of the screen.

Now work your way downwards to the bottom of the screen with the same procedure: heat up a small area of the screen and then gently push down the card a little further. Be very very patient and careful during these steps! It takes quite a long time to completely remove the glass screen/digitizer (it took me about an hour) and only a little too much pressure or not enough heat will break the display underneath, in which case the phone will be trash. Often, you can barely hear/see the display crack. If you are not sure if your display is still functional just put the battery back in and turn it on — if it is broken stop right there and save the trouble of dismantling the phone any further.

Once you reach the area with the three buttons at the bottom, work your way around them. you will notice that the touch buttons are also glued to the glass screen/digitzer and connected via a flex cable. This is the most tricky part, as it is too easy to rip them off.

Now, remove the black rubber seal from the fringe.

Then remove all the adhesive that is left on the display and clean the display with ethanol and a (antistatic) cloth.

Once the display and the surrounding fringe are completely free of adhesive, place small stripes of adhesive tape (the one that was shipped with the replacement part) around the display. Fill as much surface around the display with adhesive as possible. Tweezers can be of great help here.

Finally, remove all protective foil from the adhesive tape stripes and the one at the bottom of the replacement glass screen/digitizer. Make sure the display is completely free of any dirt particles and the three buttons are in place and carefully place the new glass screen/digitizer onto the display, beginning at the top using the notch for the speaker as reference point. Once the glass screen/digitizer and display are aligned perfectly, apply moderate pressure to merge both parts.

Please do not ask why the replacement is pink!^^

Still working… and why it is not recommended

This repair method is quite tricky and can easily destroy your phone. I also broke the display of the first mobile phone I tried to repair.

Also, on a new device, the adhesive layer between the glass screen/digitizer and the display covers the whole display area, not only the fringe. Most standard/cheap replacements (like the method shown here) are applied with adhesive tape, rather than the liquid adhesive that also covers the display area. With the lack of that adhesive layer between glass screen/digitizer and display, a thin, empty gap between both remains. Pressing down on the screen with a little more pressure locally produces strange artifacts, much like pressing on the screen of a notebook. This by the way is an easy method to find out if the glass screen/digitizer was replaced in a cheap manner on a second hand device.

While this mobile phone model is not waterproof to begin with, this repair method reduces it’s water resistance even further. The cheap adhesive tape seals the phone even worse than the original adhesive.

So if the glass screen/digitizer shows only small cracks with the touch functionality still working and the display still readable, better use the phone as it is. On the other hand, if the glass screen/digitizer is severely scattered, this might be a cheap solution to make the phone working again.

You have been warned!

At the end of last year I went to a sports and health fair, where I wanted to have a closer look at the available natural running shoes, especially the ones from Vibram (FiveFingers) and Leguano. Both type of shoes were comfortable and seemed to be of good quality. However, with an above the 70 EUR price range, they are quite expensive for a shoe that aims to be like no shoe at all. In fact, they are more like a pair of high quality socks with a special thin rubber layer glued to the sole (whereas the Vibram FiveFingers also seem to have some supportive structure integrated, which is kind of a contradiction to the barefoot philosophy). Making a custom fitted version should not be that hard, so I decided to make my own.

Since most ideas already exist somewhere in the internet, I found several youtube videos, where they were making their own pair of Vibram FiveFingers fakes. Actually, I find the separate toe sections quite annoying — not only because you can only wear them barefoot or with special socks, but also because it takes practice and more time to put them on. Not separating the toe sections makes the building process very simple.

All that is needed is:

• a pair of high quality socks (designed for sports),
• one of the available liquid rubber products (Plasti Dip, FlexiDip, Sugru, latex milk, etc.)
• a piece of cardboard big enough to place your feet on it, a pen and two plastic bags

For my version I used a Plasti Dip spray, but I would expect latex milk to give an even better result.

First place your feet on the cardboard and draw their outline with a pen on the board. The outline should be the shape of your feet seen from above. Hold the pen vertically while drawing around your foot, making the contour slightly bigger than your actual foot. Do not pay too much attention to the details, just roughly match your foot’s sole. The surface of these two cardboard outlines will be transferred to the sole of your socks in the next step.

Do not try to simply put on the socks and spray/paint the sole. The liquid rubber paint will soak into the textile and onto your skin. With latex milk this is no problem, but Plasti Dip should not come in contact with skin until dry. Also, several layers need to be painted. During the painting process, each layer needs to dry, which would leave you waiting with the shoes on.

Now, put each cardboard outline into a plastic bag (this reduces the friction, makes the cardboard easier to place in the socks and prevents any cuts in the textile) and then carefully place them into the socks. Make sure the socks fit the cardboard perfectly, as the bottom of the socks will be painted and eventually become the sole of your new shoes.

Now you start to build up the sole of your shoes by applying the liquid rubber to the sole of the socks layer by layer. Give each layer enough time to dry (see the liquid rubber product’s user instructions). Obviously, the more layers you add, the thicker the soles of your shoes become — it is up to you.

When the sole is dry and has the desired thickness, you are done. Remove the cardboard and plastic bags and try on your new shoes.

Do not expect anything similar to “normal” shoes. These are just socks with a rubber sole. They are great (and quite durable) in all situations, where you would like to have a barefoot feeling while still wearing shoes. Unlike Vibram FiveFingers and Leguanos, they do not protect your foot from sharp objects on the ground, so be careful where you use them. And just as with all “barefoot”/natural running shoes, I would not recommend walking with them on hard surfaces (e.g. asphalt).

QCAD is a great free and open source CAD software. Although limited to 2D design, it is my favorite tool for drafting, construction and simple sketches. It is well documented overall, but one issue I could not find a solution for, was how to label dimensions with symbols, special characters or certain font styles (bold, italic, super-/subscript).

This blog post provides a simple trick to get it done.

If you try to label the dimension of an angle with a symbol (like “α” or “β”) for example, QCAD will only show a question mark (“?”) as a place holder:

To get QCAD to display symbols, special characters or certain font styles (bold, italic, super-/subscript) in dimension labels, the desired label in the label text field must be provided in a certain text format:

\fFONT|b0|i0|c0|p0;LABELTEXT

For example (α in italic monospace for an angle dimension label):

\fMonospace|b0|i1|c0|p0;α

Super- and subscript font styles are also possible by using:

\SSUPERSCRIPT^;

or

\S^SUBSCRIPT;

SUPERSCRIPT – text in superscript; SUBSCRIPT – text in subscript

E.g., for the italic “lABz” length dimension label in the above illustration that would be:

\fMonospace|b0|i1|c0|p0;l\S^ABz;

It may not be the most user friendly way to format text (the normal text tool in QCAD does a far better job), but it works.