Friday, November 1, 2013

Oracle SQLDeveloper 4 on Debian/Ubuntu/Mint

Oracle SQLDeveloper is one of those tools you just kind of need around, but with its slew of bugs around so once its setup, you try not to touch it. Occasionally, Oracle releases a new version (or an early preview) with some of the bugs fixed and this appears to be the case with version 4 Early Preview.

Unfortunately, these early previews are no longer distributed as general gzip archives to work on any Linux/Mac distro, there's only a RedHat RPM installer for the Linux platform. Thankfully, this is easy to fix using the utility we known and love as Alien.

Conversion of RPM to DEB

Start by ensuring you have the Alien utility installed.

~$ sudo apt-get install alien

Then after downloading the RPM package from Oracle, run it through the alien utility.

~$ sudo alien sqldeveloper-
Warning: Skipping conversion of scripts in package sqldeveloper: postinst
Warning: Use the --scripts parameter to include the scripts.
sqldeveloper_4. generated

Great, now we have a Debian package. Let's continue to install this one.

~$ sudo dpkg -i sqldeveloper_4.
Selecting previously unselected package sqldeveloper.
(Reading database ... 571042 files and directories currently installed.)
Unpacking sqldeveloper (from sqldeveloper_4. ...
Setting up sqldeveloper ( ...

That was it, we have now installed the latest early release of SQLDeveloper no thanks to Oracle.

Sunday, October 6, 2013

Fixing a Toyota remote car key

So I recently purchased a used car. It's in pretty good condition, but the master key with it's remote lock/unlock functionality, had seen better days - in fact, it could only unlock, not lock.

Apparently these keys can't just be cloned so the car dealers have to install an entirely new key system which will cost in excess of US$500. Not having anything to loose, I set out to try and fix the key instead.

The key looked like it had been chewed on by a dog or something, and then attempted fixed by melting the plastic and adding some epoxy. I took it apart and located a small plastic container housing the electronics and battery.

The lithium battery seemed in fine condition, considering it was some 8 years old.

With a scalpel, I cut open the rubber membrane around the button to get to what was underneath. To my surprise, there was a little button loose in there - so it was pretty obvious why it did not work!

Obviously I would not be able to solder anything this tiny, with the rubber membrane in place, so it had to come off.

With the membrane cut off, the small board and the tiny button were revealed. I see a 433.94 xtal, so it obviously uses the ISM band. The IC is a HCS361 which is interesting to read about. I have never seen such a tiny button before, with SMD contact soldering terminals around 1/2 mm. in size, so this was a challenge. Thankfully, I had a brand new pointy soldering iron tip. First I tagged the button in place under a magnifier, with a bit of glue on a needle. This way, there was less of a risk pushing the button out of alignment with a large, clunky soldering iron tip. With the temperature control of my cheap soldering iron turned up as high as possible, I carefully added a tiny drop of tin on the tip, and touched the four terminals between the board and the button.

One terminal had to be redone, but otherwise a visual inspection under the magnifier revealed a nice solid solder. The true test of the fix however, was obviously to put the battery in and try out the mechanism - thankfully, everything now seemed to be working! The electronics could be repaired, however there was no hope for the physical key parts. As an avid user of ebay, I had a peek in their global store repository and lo and behold, I found both a compatible Toyota plastic key house replacement and some matching rubber membranes, for about £10.

The ebay parts arrived from Spain after about a week so it was time to assemble the electronics with these new parts.

Assembly went super easy, all I had to do was to cut out the trunk button from the rubber membrane, which was not applicable to my car nor key. 


All that's left to do now, is to go to a locksmith and have the key cut according to the old master. My already good car deal just got even better! :) Lesson of this experience; sometimes it pays to question status quo and dare to take things apart!

Sunday, August 25, 2013

How to pimp a greenhouse

My wife got a luxury greenhouse this spring and while I certainly enjoy the crops coming out of it, it's not exactly aligned with my own geeky hobbies. While unfortunately it's not in the cards for me to invest in a solar system generating green electricity for my entire household, I *can* at least construct a system for a 14m2 greenhouse. The goal is to build an off-grid system for lighting the greenhouse at night using energy provided by the sun in the day, as cheaply as possible.

Sourcing components

There are many small solar system packages complete with panel, charger and battery; but the price typically starts up around US$200 and that's without the light. For me, part of the fun in something like this, is doing it yourself with cheap COTS components. After some browsing around, ordering and waiting for things to arrive, I ended up with the following:

2x 5W amorph solar panels from local hardware store (US$45).

No-name Chinese 10A MPPT charge controller from ebay (US$10).

12V, 4Ah AGM scooter battery from local hardware store (US$25).

2m RGB LED tape, 30 LED per meter, IP67 from ebay (US$25).

RGB LED driver with wireless controller from ebay ($15).

Lots of things were in the open here. Perhaps the panels would not be good enough to charge the battery, perhaps the charge controller did not really use MPPT, perhaps the battery would not be large enough to hold the power needed by the LED's etc. While I did some preliminary calculations, in practice things might not always pan out the way you think, so I bought the parts primarily because they were cheap and would appear to do the trick - I figure I could always improve insufficient aspects later on. Total cost landed around US$120 - not too bad at all.

Preliminary checks

I received the charge controller about 10 days after ordering, which is pretty typical from China to Denmark. It felt really light and cheap, so I popped the hood to take a look at it inside.

Ok well, we're not seeing any sign of inductors for the DC-DC step. I think I see a quad op-amp (battery level monitoring?), some Schmitt triggers (hysteresis?), 3 noname power FET's (chargers), a few transistors and a bunch of discrete components - but definitely nothing to convince me this is an MPPT charger. This was confirmed by measuring the voltage over a connected panel, noticing that the voltage got pulled down to that of the battery, *not* kept at the maximum power-point which I determined manually to be around 18V.

Had I payed more for the device, I might have been disappointed, but at US$10, even a naive PWM charger is a good deal. The charger is rated for 10A, but I will barely be pushing 1A, so the circuit won't be particular stressed at all.

At maximum current draw (white color, all LED's turned on), the 2m LED strip consumes 0.7A/8.4W, and with a single color lit, it consumes 0.4A/4.8W (on average since blue uses more than green which uses more than red) so I chose to test the battery by putting a dummy load on using a computerized RC charge/discharge controller I had laying around.

It's worth nothing, that the battery was not actually full when I started this test, I had probably discharged it some 10%. With that in mind, the relatively small 4Ah battery still manages to provide 4½h of 500mA before it drops below 11.5V - which represents a relatively deep discharge cycle down to around 40% with 1.7Ah left. That should be good enough for the LED lighting to last all evening. The charge controller draws just 15mA when idling (not charging nor discharging the battery) so that shouldn't be a problem either.


Using some spare aluminum bands, I constructed an element that fits perfectly between two of the support rods of the greenhouse.

During the construction, I tried using various sized wires and actually came short of some decent 4-pole wire with enough copper to conduct the current without too great a loss in the wire. My original idea was to have controllers and battery some 2-3 meters away from the solar panels and LED light, but that would've resulted in about 1W being dissipated in the wires. So instead, I attached the LED driver and the charge controller directly to the back of the constructed element, losing an order of magnitude less power. The battery I hung in an aluminum band, which got bend to clamp perfectly around the battery and hold it firmly in place. I also left space for a second battery which I might add if capacity becomes an issue.


After placing the 2m LED strip to the rim of the ceiling using the adhesive tape on the back, it was time to light it up. Apart from a small mix-up between two of the colors, everything worked perfectly. However, it was not until nighttime it truly came to its right.

Admittedly, some of the colors can look a bit corny and signal "red light district", but toned down a bit it adds to a very cozy ambiance in the yard at night - I'm especially fond of the warm-yellow/orange and green/teal glow. Of course, it can also do plain white. With the brightness seen in the above pictures, the LED tape uses about 0.5A/6W. It's a testament to the efficiency of LED lighting, that I worry if it's too bright late at night, but I will have to wait and see whether the neighbors complain or not. ;)


I've learned, that when playing around 12V systems with currents approaching 1A, keeping wires short (or using excessively thick ones) seems paramount for efficiency. It would've been nice if I could have afforded the Philips Hue system, which can be controlled from any smartphone and is hackable to do cool things like adapting the brightness to the time of the day, flash blue when there's a Facebook message etc., but I really find this Philips product too expensive for what it is, so chose the cheap approach instead. At a mere US$120 I am more than happy with the solution and so is the wife btw. Time will tell if I need a better panel (30W mono panel can be had cheap on ebay) or an extra battery. One obvious improvement I will probably look into, is adding a dusk-relay, to ensure the LED strip can only be lit when it's dark enough, to prevent the LED's from stealing juice from the solar panels during the daily charge cycle.


After a few days of testing, everything continues to work as intended. The greenhouse is typically lit from around 21:00 when it starts to get dark, to midnight. If I were to guess, I'd say the LED could stay on most of the night, but have yet to actually try this (and thus, test the load cut-off feature). Interestingly, on a late-summer day at the end of august, the system seems to stop charging in the early afternoon where it reaches 13.25V. This is promising, as it suggests being able to catch up on more gloomier days, but over a longer period.

Tuesday, August 6, 2013

Talking to a Kamstrup 685-382 electricity meter

My utility company provides me with ways to see historic consumption of electricity up to a few days ago. However, by that time I have long forgotten when, what and why I did to consume as I did. In order to save power and money on the utility bill, one needs to have some way of monitoring and discovering usage patterns *immediately* as they take place! When I saw you could buy cheap US$50 used industrial strength electricity meters in the form of the Kamstrup 685-382, I decided to buy a few of those. The idea was to have it installed as a secondary meter in my house and try to hook up some sort of communication interface, connected to a low power computer responsible for data acquisition, analysis and presentation.

It has to be said up front, that I am far from the only one looking into this. On a Danish engineering discussion forum, I came by other people experimenting with the Kamstrup 382, except that none of the info I came by there seemed to apply to my version of the meter. So be advised, there must be several (incompatible) versions of the 382 in production and what I write below, may or may not apply to your version of the meter!

The Kamstrup 685-382 meter

Kamstrup is a Danish company with a primarily focus on designing, manufacturing and sale of metering solutions to utility companies around Europe. One of the more dominant meters seems to be the 382, which appears to come in countless versions and revisions, and is still being sold. The picture below shows the two older ones I got a hold of.

Physical characteristics of the 382

The meter is a 3-phased electronic meter, capable of measuring voltage, power, consumption etc. for your entire household. It can be augmented using expansion cards like wireless M-bus etc., but in a vanilla version, it only has an optical input/output port and this is the one I am going to focus on in the following.

The optical interface

Somewhere in the 80's, these kinds of industrial meters started getting support for an IR optical interface, then known by IEC61107 classification and later by IEC62056-21. This optical interface would allow direct RS232 (legacy low-bandwidth serial port) communication with the outside world, primarily for maintenance and service purposes. There are many ways to get a hold of such a physical connector, they can be purchased online (be hold, Kamstrup wants US$230 for theirs) or made from scratch if you can handle a soldering iron.

After shopping around for a while, I decided I was not willing to shell out that much money on so few components, so I started playing with components on a breadboard, hooked up to an USB-to-Serial interface. However, then I found this little gem from an old Elector magazine, and hooked it up, it worked right off the bat. I would play with simpler versions (electrically the rs232 physical requires negative voltages and is not directly compatible with classic 3.3V/5V TTL levels) but this design was the first that I build up (who doesn't have an 741 op-amp?!) into an actual physical connector, so it will remain what I shall use throughout this blog entry.

In order to test the hardware, I tested using the simple IEC61107 standard, which the Kamstrup 382 were supposed to support. Now, one thing to note when you do your own physical optical reader is that you might very well experience cross-talk, that is, receive the very same data bits you are sending. This happened in my case anyway, and the solution was to lower the sensitivity of the receiving diode and/or the transmission power of the emitting diode (thanks for the tip PHK). Since we are dealing with half-duplex synchronous communication, I added cross-talk compensation to the software, so it can work between with flaky DIY optical interfaces.

Yay, so after confirming the hardware works, we're ready to play! Next up, KMP connection and protocol stuff.

Kamstrup's definition of "openness"

Several places in Kamstrup's material (PDF example), they refer to their KMP protocol as being open:
"12.1.2 Open data protocol
Companies who want to develop their own communication driver for the KMP protocol can order a demonstration program with "open source code" in C# (.net based) as well as a detailed protocol description (in English language)."

Notice that this small section, in no uncertain terms, mentions "open data protocol" as well as "open source code". However, after bouncing a few emails back and forth with Kamstrup, it turns out that their understanding of "open" differs somewhat from the established official meaning of the concept:.
Open-source software is software whose source code is published and made available to the public, enabling anyone to copy, modify and redistribute the source code without paying royalties or fees.

Kamstrup told me that I would have to ask permission from my utility company and sign an NDA, before they could hand any software or protocol documentation over to me. Now, a protocol or API can not be copyrighted or patented, so my bullshit alarm got triggered with a strong suspicion that Kamstrup is a practitioner of security through obscurity... it would later become apparent why Kamstrup might have gotten tempted by this erroneous strategy (hint: bad bad security).

Protocol sniffing

So, since we get no help from Kamstrup, we're just going to have to sniff out the protocol ourselves. This is not trivial and requires 3 things; something to sniff, a sniffer tool and a whole lot of patience and thinking.

What to sniff

Even if I now own several of Kamstrups meters, purchased used, I was pretty sure they were not going to provide me with the software that goes with the meter and allows for reprogramming and data acquisition. Nowhere on Kamstrup's official website is there a download link for software or the like, so once again we appear to be dealing with an obscurity thing. However, in one of their published documents I was able to find information about a software utility referred to as MeterTool. On page 6 in this document, there's even an FTP address with credentials information leading into Kamstrup's software library. I downloaded and installed the application on an old Windows laptop and tried connecting to my meter via the optical cable, and bingo, it worked!

Sniffer tool

There are countless ways to sniff the traffic on an RS232 port. You can just guess your way around when it comes to connection settings, but I took a look at the waveform with a cheap oscilloscope (find the duration of a bit and take the inverse value to get a frequency which again is easily converted to baud/bps). The connection settings used were 1200 baud, using 8 data bits, even parity and two stop bits.

Very few people (incl. me) have a digital storage oscilloscope with enough memory to capture and interpret live RS232 data capture, so I ended up using a freeware/shareware serial port monitor to capture entire communication sessions while performing some defined action (shaking hands, getting data, logging in etc.) in the MeterTool utility.

Patience and thinking

Ok this was the hard part, and the part I never really finished and probably never will. After recording various traces with the sniffer utility and noticing the values from the MeterTool, the detective work could commence. At first, it didn't make much sense to me at all. The protocol was not ASCII based (like IEC61107) and it quickly became obvious that it was not simply enough to look for various word sizes and interpret these as binary blocks either.

Entropy and mutation analysis

Eventually I realized that the password when logging in (to reprogram stuff) had to be between 0 and 65535 (thus, 2 bytes in size) and when I did successive traces trying "1", "2", "3"... and so forth, a pattern started emerging. I noticed that a certain byte was decreasing, while another one (at the end) increased. Exploring the boundaries of this 2 byte range, told me that the last two bytes were probably some kind of check-sum and the stuff I saw mutating in the middle of the byte stream, were probably the raw data itself. The funny thing was, I did not see just 2 bytes mutate as one would expect with a value range between 0-65535, instead I saw 4 bytes mutate. From then on, I had a strong suspicion that I had to interpret everything by double-byte.

Another odd thing I noticed about the data, was the limited entropy associated with most of the bytes. Most bytes would hold a value between 0x30 to 0x46 (16 different mutations), indicating that a logical byte was split between two physical bytes on the wire (16 * 16 = 256). This corresponded nicely with the former findings; it explained why I saw 4 bytes mutating when poking inside a 2-byte range and it also meant that the two byte check-sum was really only one logical byte.

Knowing a little about the difference between two physical and one logical byte, meant that now it was somewhat easier to try and interpret, coming up with a mapping mechanism between the MeterTool and the meter. Indeed, this was trivial when looking at some of the trace data from the "authorization" attempts from before. Turns out that that if one interprets the bytes in pairs as ASCII characters, it corresponds to the 4 MSB's and the 4 LSB's of a logical byte:

Physical byte Logical 4-bit nibble ASCII
0x0 0x30 '0'
0x1 0x31 '1'
0x2 0x32 '2'
0x3 0x33 '3'
0x4 0x34 '4'
0x5 0x35 '5'
0x6 0x36 '6'
0x7 0x37 '7'
0x8 0x38 '8'
0x9 0x39 '9'
0x1a 0x41 'A'
0x1b 0x42 'B'
0x1c 0x43 'C'
0x1d 0x44 'D'
0x1e 0x45 'D'
0x1f 0x46 'E'

As you can see, in spite of having a full 8-bit binary data-link layer available, Kamstrup divided a byte into two logical 4-bit (0 - 15) nipples, and lets each nibble be represented by using a full physical byte from the ASCII alphabet 0123456789ABCDEF.

Example: Two physical bytes of 0x31 and 0x32 would map to the ASCII characters '1' and '2'. These are to be interpreted as the upper halv of a hex byte and the lower halv. So '1' becomes 1, l-shifted 4 times (or multiplied by 16) and then '2' becomes 2 which is added to 16, making 18.

This is a peculiar way of representing data, and I have no idea why it's done like this... if you recognize this encoding, please let me know. :)

Time to write some software

My end goal is to have a small and cheap logging solution, analyzing various consumption aspects of my household, so a cheap Android stick which I've written about before, seems like an obvious target. This suggested that I write some software using Java. Though professionally I write Java almost every day, that language is a particular poor choice when it comes to near system-level programming dealing with raw bytes (no support for unsigned bytes!). Furthermore, for unfathomable reasons, SUN Microsystems never bothered to include serial support into the JRE or JDK. Since raw C seems a unnecessarily low level in comparison, and how C# for all practical purposes is a nice middle-ground, I chose that as an implementation language. Yeah I know, purists will yell Microsoft fan-boy at me, but in my opinion C# is a nice iterative non-ivery-towerish improvement over Java. On top of that, it's an open standard, it has great Android support, provides support for unsigned bytes as well as an encapsulated rs232 API.

So in order to work with the odd byte mapping we discovered before, we can write some mapping methods. This is what I came up with:

 protected byte ToKamstrupValue(byte value)
  Debug.Assert(value >= 0x0 && value <= 0xA);
  return (byte)(value + (value < 10 ? 0x30 : 0x37));
 protected byte FromKamstrupValue(byte value)
  Debug.Assert(value >= 0x30 && value <= 0x46 && value != 0x40);
  return (byte)(value - (value < 0x3a ? 0x30: 0x37));

 protected byte[] ToKamstrupPair(byte value)
  byte[] quad = new byte[2];
  quad[0] = ToKamstrupValue((byte)((value >> 4) & 0xf));
  quad[1] = ToKamstrupValue((byte)(value & 0xf));
  return quad;
 protected byte FromKamstrupPair(byte[] pair)
  Debug.Assert(pair.Length == 2);
  return FromKamstrupPair(pair, 0);

 protected byte FromKamstrupPair(byte[] pair, int startOffset)
  Debug.Assert(pair.Length > 1);
  return (byte)((FromKamstrupValue(pair[startOffset]) << 4) | (FromKamstrupValue(pair[startOffset+1])));

Comparing payload content vs. the two checksum bytes, hinted at a relationship; whenever a byte value in the payload increased, one of the two checksum bytes would decrease. Furthermore, the entropy (or lack thereof) suggested use of the same nipple mapping as described earlier. The problem just got reduced to finding a checksum algorithm resulting in a byte and it wasn't long before the right candidate was found to be 8-bit LRC (Longitudinal Redundancy Check):

    protected virtual byte Checksum(byte[] data)
        byte checksum = 0;

        foreach(byte value in data)
            checksum += value;

        return (byte)((checksum ^ 0xFF) + 1);

For ease of use, I have encapsulated data-link aspects behind an IMeterConnection interface, and interpretation aspects behind an IMeterProtocol interface. It then becomes very easy to use the library to talk to the meter:

    using(var connection = new SerialMeterConnection{
            PortName = "/dev/ttyUSB0",
            BaudRate = 1200,
            Parity = Parity.Even,
            DataBits = 8,
            StopBits = StopBits.Two,
            Handshake = Handshake.None,
            Encoding = new ASCIIEncoding(),
            NewLine = Encoding.ASCII.GetString(new byte[]{SerialMeterConnection.LF})
        using(var protocol = new MeterProtocolKMP382(connection, logger))
            foreach(var entry in protocol.Registrations)
                Console.WriteLine (entry.Key + ": " + entry.Value);

A small video demonstrating the conversation between the software and the meter:


It was a fun exercise, but it took a long time to figure out how to interpret the data. Meanwhile, I have had ½ a blog entry sitting idle for at least a year - the eternal problem of a tinkerer with a day job. The relevant driver source code has been released under a BSD license available through GitHub, for others to play with. The most interesting part probably being MeterProtocolKMP382.cs. This is just the underlying driver with runnable example code, the source for my complete Android meter acquisition app is not anywhere close to being done and next step is to attack my two other Kamstrup meters (water and heating).

Now back to the rather abysmal security aspect. A two byte security code is obviously not enough in this day and age, indeed it takes just about 24h to brute-force your way to the security code of this meter. This code, as far as I know, gives you the option to reprogram the meter in a variety of ways - meter no., customer no. etc. I have chosen not to include this brute-force code even if it is just a simple loop waiting for a timeout to continue trying next password. I used this approach to guess the code of my meters (12345, which appears to be the default), but I'll leave that as an exercise to any reader who would be interested (you can find a LOGIN command in source code).

As always, feel free to comment and/or fork the project, adding more features. There *are* fields which I have not been able to interpret and I have not sought to investigate programming commands, although the process is the same as described in the above.

Wednesday, February 27, 2013

Installing Linux Mint on a Macbook Air

In late 2011 I bought the Apple Macbook Air 13" (model 4,2 with 128GB SSD) to replace my aging road-warrior Dell 420. As much as I was impressed by Apple's hardware and the Macbook Air in particular, I was never taken by their software or the OSX that comes with the Macbook Air when you buy it. So within a week or so, I started experimenting putting Ubuntu (my then favorite OS) onto it. Things may have improved by then, but it was quite a task to get Ubuntu installed and set up properly - much more difficult than setting up Linux on a non-Apple laptop. The end result was a functioning but fragile setup, where each update to Ubuntu (new kernel in particular) would require me to reboot into safe mode and manually edit various files. As chef Ramsay would say, what a f...... nightmare.

After 1 1/2 year and a dangerously outdated system (so many Java vulnerabilities), I decided it was time for a re-install. This time around however, I chose to try out the new favorite kid on the block, namely Linux Mint 14 with the Cinnamon interface (Unity on Ubuntu was OK, but at the end of the day more limiting than facilitating). I did prepare myself mentally for having to go through a week of cursing and sweating, but as it would turn out these concerns were entirely unfounded.

Installation procedure

First I booted back into OSX recovery (Command-R during boot) so that I could re-install OSX such as to have a completely fresh system and up-to-date firmware. The restore functionality build into the Apple hardware works very well, and remains a solid advantage to that OS - if only it was possible to provide alternative OS images this would be a killer feature. Anyway, after re-installing OSX I then wanted to re-partition to get some space for Linux. However, it turned out that you are not allowed to commit these actions in the recovery (at least I kept getting an error message) so I had to do it from the DiskUtil while booted normally into OSX. In here, I shrunk the OSX partition down to around 25GB, leaving just 2-3 GB of free space on OSX and a good 95GB for Linux partitions. That way, I could still occasionally boot OSX, but I knew from experience that I would never purposefully use OSX for my daily work. If you plan to actually use OSX from time to time, you should probable give it a bit more space than I did.

While still in OSX, I then downloaded the Mint 14 image I wanted as an ISO file.
Part of the trouble with the Macbook Air, is that it does not readily boot from an optical drive and it uses UEFI rather than your traditional BIOS. So one has to use a USB stick that talks UEFI, or install Windows via bootcamp (special Apple support for dual-booting Windows and OSX) and piggyback off this partition. Last time I installed Ubuntu, I used the latter method, but this time around I wanted to give the former approach a try - Windows takes an enormous amount of space after all, and I already have OSX eating up precious space. It turns out that it is pretty easy now days, I simply downloaded an application for OSX called Penguintosh specifically made for he purpose, used the tool to write my Mint image to a USB device and rebooted. While booting up, hold down the C key, so that you get to choose which device to boot from. Select the last orange USB icon and double click it.

Soon you should have a Mint live image running. From within this live image, it's trivial to start installing Linux Mint to disk, since you already prepared the partition. Once installed, GRUB will give you the option of booting into Mint or OSX.

Tweaking Linux Mint

Generally very little tweaking is necessary, in contrast to my experiences with Ubuntu. Screen, sound, trackpad, keyboard backlight, function keys etc. all just seems to work. If however you are not happy with how the trackpad operates, you may tweak it with the synclient utility. For instance, I noticed that two-finger scroll is disabled, but it can be enabled with the command:

~$ synclient VertTwoFingerScroll=1

You can explore countless settings for the trackpad this way, but it won't be permanent until you modify the xorg settings. I had some trouble succeeding with this the official way (messing with xorg settings file), so I simply ended up adding an entry in Cinnamons "Startup applications" applet.

In the same category, you may also want to change the scroll direction to match what you have been used to in OSX (I am now used to this inverse "natural scroll"). Once again, this is an xorg setting that you can also invoke on-demand:

~$ xinput set-button-map 11 1 2 3 5 4 6 7 8 9 10 11 12

As with the previous command, you can just let "Startup applications" handle this by adding "xinput set-button-map 11 1 2 3 5 4 6 7 8 9 10 11 12" as an application.

Another little detail I did not like, was how function (fn) keys were default over the classic F (F1-F12) keys - as a developer I rather depend on these and would prefer to control sound, brightness etc. with a combo using the fn keys. To change this, create a file in the path "/etc/modprobe.d/hid_apple.conf" with the content "options hid_apple fnmode=2".

~$ echo "options hid_apple fnmode=2" > /etc/modprobe.d/hid_apple.conf

Strangely, Cinnamon does not (yet) have any way to organize Linux groups, but you can just use the classic Gnome tools for this, by installing:

~$ sudo apt-get install gnome-system-tools

Then of course, there are all the applications. One of the first things I install is usually the handy plugin to Nautilus (yes it also works in Linux Mint's Nemo fork of Nautilus) which allows for image resizing directly while navigating your files:

~$ sudo apt-get install nautilus-image-converter imagemagick


While still not as easy as installing Linux on your average laptop, this recent experience of installing Linux Mint 14 onto my Macbook Air was a very nice experience compared to all the hoops I had to go through with Ubuntu. I've come to appreciate the responsiveness and functionality of Linux Mint 14 (and it's Cinnamon UI) so much that I also plan to replace Ubuntu with Mint on my main workstation. There may still be tweaks I need to perform, but the out-of-box experience is very usable. The only real problem I've run into, is the lack of VPNC support in the network manager. Installing "network-manager-vpnc-*" has no effect in the Cinnamon interface, so if you want to connect to Cisco VPN networks, you are going to have to do it the old-fashioned way, with a command-line.

Naturally, if you have tips or tweaks in this regard, feel free to drop a comment about it below. :)

Sunday, February 3, 2013

Rikomagic MK802IIIS (4'th gen Android-on-a-stick)

I am a bit of tinkerer... I like taking things apart, understanding how they work (to some degree) and come up with new combinations of what can be done. So when I saw the $54 MK802IIIS "Android on a stick" device with 4'th generation specs, I had to own one. Think of it as a tablet, without a display or battery, that you hook up to the TV instead.

What makes the MK802IIIS so interesting?

First and foremost, the device is obviously readily usable as a media player. It makes it possible to upgrade any TV with HDMI input, to a "smart TV". This is especially interesting these days, where TV-on-demand services like NetFlix, Hulu, HBO etc. are delivered via custom applications on a limited subset of TV's or via proprietary boxes. Since this stick is based on the popular Android platform, all you really need to do is visit the Google Play store and install the appropriate application from the content provider. Why Google hasn't pushed this cheap and simple approach rather than their vaporware Google TV is beyond me.

Secondly, and what I personally find the most interesting about the device, is the price and form factor, which makes it superior to other popular tinkering platforms such as the RaspberyPI, Beagleboard and Arduino stuff. You get dual-core 1.6GHz (no you don't, more about that later) Cortex-A9 CPU, 1GB of RAM, 2xUSB host ports, WiFi, microSD card slot and HDMI out. For all of this, you would have to pay at least $100 if you went with the more traditional tinkering kits I just mentioned - and I still don't think you would be able to get the same performance as the MK802IIIS provides. Some will rightly claim that the MK802 is much more limited when it comes to interfacing, but remember that USB-RS232 and USB-GPIO adapters can be had on ebay for about 10-15$ and that opens up a whole wide world for interfacing with your surroundings.

Initial impressions of hardware

The device feels like decent quality, with a generous amount of extra cabling/adapters coming along with it. Indeed, it does not take long before you have the unit connected to a free HDMI port and feed it power through one of the 3 USB ports (designated for power). The stick feels a little brittle sticking out from the HDMI port, so I would definitely recommend that you make use of the provided HDMI extension cord, to ensure you don't harm the TV's HDMI connector.

Taking a peak inside the device, reveals a small double-sided multi-layered board with 4 Elpida EBJ10UE8BDSO-DJ-F chips (256MB DDR3 SDRAM @ 1066MHz), a Hynex HY27UF084G2B chip (4GB NAND flash), the Rockchip RK3066 SoC (dual-core ARM Cortex-A9) and a tiny WiFi board.

One of the most interesting aspect of such a small device is its power/performance envelope, which I measured to a ridiculously low 0.7W in idle and 2W during a heavy load. To put this into perspective, your average Internet router uses up 12-15W 24x7.

Initial impressions of software

The device is surprisingly fast at booting up from a cold state, taking just some 45 sec. before it is ready for action. USB mouse and keyboard is immediately recognized, which means the USB host mode is functioning. Google Play is pre-installed, so getting access to all the software available is a breeze, as long as you set up a Google account. The device appears to pretend it's a tablet, so you will get mobile versions of webpages as you browse around, and tablet versions of applications (i.e. NetFlix). It takes a little getting used to navigating the Android UI without touch, but the experience is helped by the snappiness and responsiveness of the device, which feels a great deal better than various set-top boxes I have tried in the past.

On a 50" screen with native 1080p support and the MK802IIIS output set to 1920x1080 @ 60Hz, text and edges looks a little more pixelated than I would've liked though, leading me to suspect there's some scaling going on between Androids frame buffer and the actual display. Taking a screen dump in Android supports this theory, as the resulting image is not 1920x1080 pixels but only 1280x720 (click the image above to inspect it full-screen).

Since true 1080p is not possible, there's no reason to set the HDMI mode higher than 720p (1280x720 @ 60Hz in Screen settings). I tried to capture photographic evidence for why I think it is a bad idea to go 1080p, but it is not easy to get the lighting and focus right. The first picture below is 720p while the second one is 1080p, click the images and inspect the aliasing.

Notice the jagged edges of the 1080p (the last) image, particular visible when you look at the "home button". This leads to a disappointing conclusion; the device output is always 720p format and 1080p is a scaling after-through. The advertised 1080p is non-sense and I would argue Rikomagic's marketing department went a little too creative here.

Media playing

There is some rudimentary media software on the device, but nothing special to write home about. Luckily, we have plenty of media options on Android. Playing YouTube with Google's official app is a very nice experience, except for one major problem; there's no way to go full screen!

Once again, if you have a large physical screen, you can get away with consuming some YouTube content in a window without it being too annoying. However, there is a fix for this, which is to go download a legacy version and install the apk file manually outside of Google Play. If you do this, you will lose the latest official version and if you want this permanent it might be a good idea to ensure that the automatic update feature is disabled for YouTube.

The interface is a little different and I find it's not as easy to explore and discover content, but as you can see below, it does allow full screen mode.

NetFlix also appears to be working well, albeit the streams are definitely not HD quality. Apparently NetFlix does not allow for HD content to be decrypted in software on Android devices (except a few devices with the OMAP SoC, due to a deal between Texas Instruments and NetFlix). A little research reveals some details:
Specifically, TI's OMAP 4 platform, complete with M-Shield security technology and TI's quad-radio WiLink 7.0 connectivity combo solution, met the Netflix requirements for mobile content streaming, something that most Android phones haven't been able to do.

The speed of the UI is impressive though and the whole layout is actually superior to other set-top boxes I have seen with proprietary NetFlix software - for some reason I like this NetFlix tablet software better on my TV than I do on a tablet! One potential issue could be those relying on closed captioning, because the subtitle is rendered with a relatively small font which I was able to get used to on my 50", but people with smaller TV's or non-20/20 eyesight might find this problematic.

It's hard to judge the video quality, but my guess is that it's middle-tier non-adaptive 2-3 Mbit/s which NetFlix qualifies as "better than DVD quality". It's definitely a decent quality, but it would obviously be nice if NetFlix would allow HD playing on Android. I've heard rumors that there are unofficial NetFlix HD players available in the more shady Android hacking regions of the Internet, but I have not explored this in depth

Thankfully the very popular XBMC software has now been ported to Android and can be downloaded as a binary package as a pre-release (it will probably make it into Google Play before too long). This player works like a breeze, accessing all the media on my NAS and allows for tons of plugins for consuming online media streams. The great thing about XBMC is that it is developed in the open and there are lots of plugins for it, so consuming iTunes podcasts, live TV streams and DLNA content are just a few possibilities. The two screenshots below are taken from the popular TWiT Tech News Today show and demonstrates how cheap and easy it now is to pull this kind of high-quality Internet content onto your TV.

Playing SD content over DLNA/UPnP from a local NAS (containing my digitized DVD collection) works really well, even if the picture quality is not quite as good as what my other DLNA players achieve. You definitely don't want to watch SD content in 1080p mode, where the 480p to 720p to 1080p double up-scaling amplifies aliasing and compression artifacts quite significantly.

Trying to play some of the few full-HD (1080p) movies I have, did not turn out so well. The frame rate would be inconsistent, dropping many frames. I can not imagine this is a bandwidth issue, since I fixed the antenna and have secured a good down-link speed in other applications (continue reading section below). Perhaps the XBMC port is not yet optimized for Android. Perhaps this is an issue with the particular combination of hardware in the MK802IIIS. Perhaps a hardware driver is missing. Perhaps installing another ROM with an overclocked CPU could help. In any event, do not expect to be playing full-HD content with this device and the XBMC software it their current state!


It did not take long to notice that the WiFi performance of the device was less than impressive. 10-15 meters away from the access-point, the connection speed remained low and would sometimes drop completely. The application WiFi Analyzer reveals the troubling news.

After Googling this for a bit, I found other people with this issue, and even people who were trying to fix the hardware itself. Apparently, the antenna ground and signal wire are shorted from the factory, and sure enough, opening it up and probing the antenna joins with a multimeter, confirmed that these were indeed shorted out!

One forum thread suggests simply to desolder the ground and mask the connector with some isolation tape. Here's the thing though; as far as I can tell, it appears that the wires are both purposely shorted out at the actual antenna as well as on the main board itself!? I am not an electronics engineer and I have no idea what's going on here, but this seems suspect to me. However, since I had a standard 5db WiFi table antenna laying around, I figured there was no harm in trying to solder this one on instead and see what happened.

Thankfully, the modification resulted in a much better signal, with signal strength going up from -65db to -40db and link quality up from 20Mbps to 65Mbps and I have never lost the connection since.

It is not for your average Joe to perform such a hack (although it's by no means hard) so this aspect is obviously disappointing and is going to cause some people headaches. I have to imagine the antenna design is some crude cost saving maneuver by the manufacturer and that there's a way to get to the actual non-shorted RF point for the WiFi chip, but that's beyond my expertise.


The MK802IIIS sports the latest and greatest cheap China SoC, the Rockchip RK3066 which is a 40nm dual-core ARM Cortex-A9 part. While the RK3066 won't break any speed records among the established ARM implementors like Qualcomm, Nvidia and Samsung; this is a worthy upgrade to the widely used AllWinner A10 and A13 (ARM Cortex A8) SoC's which could be found in previous generations of these cheap Android sticks and tablets. Examing /proc/cpuinfo reveals the following:

Processor : ARMv7 Processor rev 0 (v7l)
processor : 0
BogoMIPS : 2399.21

processor : 1
BogoMIPS : 2399.21

Features : swp half thumb fastmult vfp edsp neon vfpv3 
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3sing
CPU part : 0xc09
CPU revision : 0

BogoMIPS is just a very rough indicator of instruction performance, but it can form an interesting performance indicator for us when comparing across other ARM CPU's. I have extracted BogoMIPS numbers for the other ARM devices in my household.

Synology DS211+ NAS (Marvell Kirkwood mv6282):

Processor : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS : 1589.24
Features : swp half thumb fastmult edsp

Cheap no-name china tablet (AllWinner-A10 Cortex-A8 ARM):

Processor : ARMv7 Processor rev 2 (v7l)
BogoMIPS : 1001.88
Features : swp half thumb fastmult vfp edsp neon vfpv3

Western Digital Live TV box (Version 3):

Processor               : Sigma Designs TangoX
cpu model               : MIPS 24K V7.12  FPU V0.0
Initial BogoMIPS        : 332.59

It should be noted that technically this chip is not ARM based and is specialized for video decoding.

Asus RT-N16 Internet router:

processor  : Broadcom BCM4716 chip rev 1
cpu model  : MIPS 74K V4.0
BogoMIPS  : 239.20

Once again, this is actually a MIPS design and not an ARM CPU. Unfortunately I do not own any of the tinkering boards I mentioned in the introduction, but I have tried to determine the values for these platforms by searching forums and list them here as well.


Processor       : ARMv7 Processor rev 2 (v7l)
BogoMIPS        : 851.45
Features        : swp half thumb fastmult vfp edsp thumbee neon vfpv3


Processor : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS : 697.95
Features : swp half thumb fastmult vfp edsp java tls

I was unable to locate any info on Arduino, probably because this kit is so simple nobody got Linux running on it?! Anyway, even if we have to take these numbers with a grain of salt, it's pretty clear that none of the above listed devices comes even close to the MK802IIIS' cumulative BogoMIPS performance of a whopping 4800.

One of the frequently used Android specific benchmarking application is Quadrant, which is a much more thorough test as it includes 2D rendering, 3D rendering, floating point arithmetic etc.

A score of 3000+ is not too shabby, beating the performance of tablets 1-2 years ago. For reference purposes, the quad-core 1.4GHz Exynos 4 (4412) SoC found inside the popular Samsung Galaxy SGIII (International) Smartphone achieves 5815 points. This is actually quite impressive, suggesting scaling of the RK3066 would push a quad-core version (in the works and probably powering a 5'th generation of the MK802) beyond Samsungs current quad-core offering. Meanwhile, Samsung has now actually left the A9 arena, and is pushing the next generation ARM A15 design, which we probably won't be seeing in these cheap China devices for some time.

While playing with overclocking, it became apparent that the device actually runs at 1.2GHz rather than the claimed "up to 1.6GHz" and no overclocking option would push it above 1.2GHz. I reckon that the kernel has the frequency locked down to 1.2GHz, while the CPU itself actually is capable of going 1.6GHz. Reading various discussion forums, it appears that with a custom ROM, you are able to push the CPU up to 1.608Ghz but to be perfectly honest, I don't find that necessary - it would require more power and break the thermal design (remember there's not even a heat sink on the SoC and the USB specification states 500mA as the current ceiling which we're already close to). In any event, the clock rate is another false claim by Rikomagic!

Missing ADB-over-USB functionality

Since the dawn of time, you were able to connect a USB cable to an Android device, and use Google's SDK (specifically the Android Development Bridge, ADB) to connect to the device and perform file operations and use a shell. For some reason, this is not possible on the MK802IIIS and Google searches have led me to believe this may never have been possible. All is not lost however; the ADB tool can also work across a TCP/IP connection, it just requires a system-property on the device.

# su
# setprop service.adb.tcp.port 5555
# stop adbd
# start adbd

As you may infer from the above commands, the MK802IIIS comes fully rooted to a hackers delight. :) There are also a couple of applications that will assist you in enabling adb TCP/IP mode. The one I would recommend is adbWireless, since you can enable auto start mode, particular handy if you are going to use the MK802IIIS in an embedded scenario (as I do). You will then also want to set up the WiFi connection with a static IP-address, so that no discovery is necessary and so you can easily connect to the device with ADB etc.

Remote controlling

As mentioned previously, there's great USB keyboard and mouse support, so the easiest really is just to connect a cheap wireless keyboard/mouse. For media PC's there are even a lot of small keyboard/mouse combos that takes no more space than a remote. You may also simply download the MK802 III remote control application from Google Play and use it as a trackpad (for when you have HDMI connected and can see the display).
For remote/embedded purposes, there are several VNC servers available in Google Play. I like VNC server since you can make it start up automatically.

Ubuntu's Remote Desktop Viewer works well, but you can probably use any of the known VNC viewers, or even the HTML5 browser interface. Once again, unscaled connection reveals a frame buffer with native 1280x720 pixel resolution.


So there you have it, a quick walk-through of my first week with the MK802IIIS. Whether you will like this device or not, depends entirely on what you plan to do with it; so this conclusion will get divided into two distinct parts.

As a media gadget, it has great potential but image quality is not going to impress anyone with an alternative HD box (AppleTV, WD Live etc.). On a few items, Rikomagic is actually lying about the device - it is not 1.6GHz (only 1.2GHz) and it does not render 1080p full-HD (only up-scaled 720p). So unless you are willing to go through some hoops, is satisfied with SD quality (DVD content or a small TV), I would not recommend this product in its current form. Having said that, I may go ahead and order another MK802IIIS for my 32" bedroom TV, since 54$ is still dirt-cheap for these features.

As a tinkering platform, it's still a bit early for me to make sound conclusions. However, you definitely do get a *lot* of hardware and performance for your moneys worth. On top of that, the super low power consumption of the device makes it ideal for just about any embedded scenario. A rooted Android 4.1 OS means there are a ton of software readily available, so it's really just up to your imagination what can be done with it. In case you are missing Bluetooth from this review, there's also a version of the mk802 with this, for just a few $ more.

I will continue to investigate the device on my own terms, namely as a low-power embedded server for harvesting water, heat and electricity consumption in my house. In all likelihood, this entry will get a follow-up in the near future when I have had time to dig a bit deeper. Thanks for stopping by and happy hacking!

Update on the WiFi issue

Since writing this post, I have consulted an antenna engineer where I work and shown him the antenna design. It turns out, that the short I can measure with an ohm-meter is not unusual at all with small antennas destined for high-frequency (2.4GHz+) signals. What I really need to measure is induction around the high frequency and that requires special tools (which I was shown, looks like a big oscilloscope). In other words, nothing is wrong with the design of the antenna, other than the fact that performance is poor. So my recommendation would still be to mount a better antenna if you have that option, or at the very least, pull out the antenna so it sits further away from the (potentially quite noisy) CPU.