On the death of hardware

23.09.2012 19:11

A few days ago I came across this article with an eye-catching title Hardware is dead. Two arguments are made there: first that consumer electronics designed and manufactured in Asia is becoming so cheap while maintaining a reasonable level of quality that western hardware companies don't stand a chance against them. And second that this will lead to a situation where content producers will be able to subsidize the whole cost of a device, giving hardware away for free with the hope that profits from content will more than make for the loss.

The first argument is nothing new. I remember how strongly it was voiced by the dean of Faculty of economics in the last year's round table on the role of engineers in society. Yet somehow there is still electronics design and manufacture going on in Europe. I am quite confident that the cost of eastern products will further go up as soon as their environmental and social standards catch up with the west, but this is merely my mostly uneducated opinion.

I'm more worried about the second prospect. It would create an incredible situation where you can get a physical object for free, something that necessarily requires a certain amount of raw materials and work to construct per copy, while on the other hand you pay for bits that are essentially free to copy. You may muddle up the issue by saying how selling hardware has low profit margins while content allows for a high margin. Still that doesn't change the fact that for the foreseeable future the cost of rearranging electrons in the RAM of your device into the recording of the latest blockbuster will be insignificant compared to the cost of rearranging atoms to make the said device itself.

I will conveniently skip the question of fixed costs, e.g. cost of design for hardware and production for content. We're talking here about complex devices produced by the millions where the situation regarding the cost of design is probably not all that different from the cost of producing some content for mass consumption. Hardware can still be surprisingly expensive for niche products though.

Subsidizing a product from the sale of consumables is nothing new of course. It's been done for all sorts of things, from printers, mobile phones, coffee machines to paper towels. The problem invariably appears when someone else tries to make consumables compatible with yours, only cheaper since they didn't have to subsidize your device. To prevent this kind of competition this business model always depends on some kind of intellectual-property monopoly-enabling legislation. In the past there have been some pretty creative uses of such laws in this context, for example where DMCA was applied to physical objects in the case of famous Lexmark ink cartridges.

Die Aktivitӓten in diesem Raum sind in deinem Land nich erwünscht.

What happens in the case where consumers themselves can make the consumable you depend on for your profit? Content shown on that give-away tablet is exactly such a case. Everyone can write text, make a program, record audio or video. Not to mention that pesky copy command every computer has that is just as effective as content producer's. Suddenly one product's users also become its enemies. This leads to nonsensical solutions like DRM and walled gardens. In some markets this practice has already been generally recognized as a bad idea. In European Union for instance mobile operators can no longer lock phones they are selling to their network, which means that at least in this country you can no longer get free mobile phones. Many are still subsidized of course, but whoever is selling them has to account for the subscriber's freedom to switch to another network. As regulators in other fields realize that such practice is harmful, I'm sure other kinds of give-away hardware will fail in a similar way.

Actually, I hope hardware subsidizing will never even come up to such a level. It might be great in the short term for hackers (hey, you get a free toy which you can jailbreak) and ordinary users (hey, you get a free toy) alike. But in the long term it will do more harm than good. For most people it basically exploits a psychological trick where people are bad at accounting for future costs, meaning you are tricked into buying things you don't actually need. Not to mention the throw-away culture such practice would enable (supposedly we are working towards a sustainable economy) and the escalation in the war over general purpose computing as companies more eagerly start to fight jailbreaks.

Posted by Tomaž | Categories: Ideas | Comments »

Don't sit on your Kindle

19.09.2012 18:56

A few days ago Jure brought me his 3rd generation Amazon Kindle. Someone sat on it and the results weren't encouraging. While the plastic frame and the display appeared undamaged from the outside, only a small portion of the screen in the lower left corner showed any signs of life when the device was turned on. The rest kept showing the screensaver image that was displayed when the Kindle was last turned off.

Kindle 3 with a broken screen

Opening it up was a bit time consuming, but pretty straightforward. I used an old credit card to carefully pry open the plastic latches around the edge. There are many tear down descriptions and around the net, so I wont bore you with details here.

Kindle 3 without back cover

There appears to be a RFID chip taped to the back cover.

RFID tag on Kindle 3 back cover

After removing the battery, circuit board and the central support frame it was quite apparent what is the cause of the malfunction. Since Amazon just released new Kindle models recently, replacing the display panel isn't really worth the hassle, even though supposedly you can get replacement panels.

Cracked back screen panel on a Kindle 3

So, this Kindle is now basically useless as a book reader, but it still contains a perfectly usable ARM-based embedded computer that is capable of running Linux. Since it consumes very little power it might be quite useful as a small always-on system to have at home. The motherboard alone doesn't seem to boot without the (smart) battery and the display connected to it, so that is a bit unfortunate. But even in the original frame it doesn't take much space and I might simply hang it on a wall somewhere.

Last Saturday was a Software Freedom Day in Kiberpipa, so went with the spirit and jailbroken it and installed a chrooted Debian system. Installing the jailbreak and usbnet took some trial and error since I was not sure which firmware version was last installed and it's hard to navigate the menus without the feedback from the display. In the end I resorted to doing the same procedure on my own kindle in parallel, so that I could see where in the menu the cursor was. Without that I'm not sure how I would be able to type in ";" and "~" characters using the on-screen keyboard. These are required when enabling the usbnet hack.

The built-in software from Amazon takes quite a big chunk of 256 MB of available RAM, so running a chrooted Debian is not really optimal. I'm looking into replacing the built-in firmware with Debian altogether, but for that I first have to find a RS232 adapter so that I can see the serial console from the Linux kernel. Otherwise I'm pretty sure I'll brick the device on the first try.

Posted by Tomaž | Categories: Life | Comments »

Leaky librrd4

17.09.2012 21:21

librrd4, the library behind the RRDtool, version 1.4.3 as shipped in the current Debian Stable distribution (Squeeze) has a gross memory leak. This caused problems on my server because I use a long running daemon process to plot several graphs (not a script that periodically gets called from a cron job, which seems to be the dominant way of using RRDtool these days) and because I use the RRDs Perl bindings, which dynamically link to librrd4 (as opposed to RRDp which spawns a separate process).

The red dots on the graph below show the virtual memory size of a Perl process that continuously calls the RRDs::graph() function in librrd4 1.4.3:

Comparing memory usage between two versions of librrd4

The blue dots mark the same test using librrd4 1.4.7 which is currently in Debian Testing and which apparently has this problem fixed. While librrd4 1.4.7 doesn't seem to be present in Debian Backports, the source package from Testing compiles without a problem on Squeeze, so upgrading is pretty straightforward.

Just in case all of the above saves debugging time for someone...

Posted by Tomaž | Categories: Code | Comments »

Brute forcing IR remote

09.09.2012 19:24

I have an old Sony CMT-CP11 Hi-Fi that drives a pair of speakers in my living room. I use it to listen to the radio, CDs and everything sound-related my desktop computer outputs. If I remember correctly it will soon be 12 years old and it has aged incredibly well. I've only opened it up once, to make a backup battery hack so that I don't need to reprogram the radio stations each time power goes out.

It has one annoyance though. While it has two auxiliary audio inputs, it only allows switching to them by pressing a button on the front panel. Otherwise most other functions can only be activated from the infra-red remote control. That's unfortunate because it's preventing me from having a script on my desktop that sets everything up automatically when I want to listen to the audio from the computer on the Hi-Fi speakers.

I was thinking that maybe the Hi-Fi component actually implements a command for switching on the auxiliary input but whoever designed the remote control ran out of buttons or something like that. A bit of searching on the web quickly turned out a description of the physical protocol and a collection of codes used by Sony equipment.

After recording and inspecting the codes transmitted by my remote control it turned out that most buttons produce the 12-bit variant of the code with a few buttons using 20-bit codes. While the codes matched their functions as recorded at the site linked above, unfortunately none of the codes listed there for switching on the auxiliary inputs produced any response on my Hi-Fi.

Perhaps it is using some code that is not listed? 12 bits make for 4096 possible codes. That's not outside of reach of a brute force search: with 5 seconds per try that comes to around 6 hours. I chose a 5 second delay because for input switching that's how long it takes between a command is sent and the audio output actually appears on the speakers (plus some error margin).

Of course, I didn't want to spend 6 hours in front of the Hi-Fi, listening whether the correct output is playing. Therefore I hacked up a simple automatic detector. I made the computer connected to the auxiliary input play a continuous 600 Hz tone (using simply Audacity Generate -> Tone function and looped playback). On the other end a laptop running the IR code brute forcing had its line input connected to the headphones output and detected the tone.

Brute force search for IR codes on a Sony CMT-CP11

Not wanting to lose too much time with filters or anything fancy, I simply took a Fourier transform of the signal and compared the mean amplitude in the band around 600 Hz with the complete spectrum (excluding the DC component). This turned out to work well enough for this purpose, although I did get a few false positives when the radio was playing. But those were simple to filter out since they were limited to a few samples while a genuine switch would give a continuous detection:

# samples is an array of 2048 16-bit samples from ALSA
w = numpy.abs(numpy.fft.rfft(samples))

signal = w[30:32].mean()
noise = w[1:].mean()

if signal/noise > 100:
	# success! detected the 600 Hz signal ...

In the end, this exercise wasn't successful. I failed to find any 12-bit codes that would switch to the auxiliary inputs. I also tried all combinations of 20-bit codes with the 12-bit device prefixes I saw transmitted by the remote control (complete 20-bit space is a bit too much for an exhaustive search). I did find out that such brute force testing makes my (also Sony) TV go crazy, so I had to unplug it while the test was running.

I guess if I still want to be lazy and not get up to press the button the only solution left would be to hack together something that would press the button for me. Like a microcontroller that would hook up to the IR receiver in the Hi-Fi, recognize the code that isn't recognized by the Hi-Fi itself, and simulate a pressed key. On the second thought, while it might be a fun hack, I don't think I'm lazy enough to attempt that.

Posted by Tomaž | Categories: Code | Comments »

A sense of science fiction

03.09.2012 18:52

You've probably seen this vintage job advertisement for Jet Propulsion Laboratory at the height of the space race. It has done a few rounds on the web a day or two ago.

When you were a kid, science fiction gave you a sense of wonder.

Image by fdecomite CC BY 2.0

While it was printed well over a decade before I was born I was still touched by it when I first saw it in the web browser. I have always been a fan of science fiction of all kinds and this form of art certainly played a big role in shaping my decision to pursue this meandering career in engineering and science.

Of course, I can't be sure about what the authors of the poster originally had in mind with the sense of wonder. They might have been simply thinking about curiosity and the pleasure of finding things out. Science fiction can certainly spur both, even though the answers it provides to what-ifs must usually be taken with a grain of salt. That's why the word fiction is there after all.

What started this train of thought was rather the possibility that they thought about another feeling. The one you get when you realize you're doing or witnessing something that you have already done or seen a number of times, except now it's for real and the other times were while day dreaming or exercising imagination, fueled by works of fiction.

In any case, I'm sure readers of the advertisement that actually got involved in the space program weren't disappointed in that respect, regardless of how they understood the phrase.

Thinking back, this kind of déjà-vu feeling is actually quite rare. As mundane as it might sound, my only experience of it I can currently recall happened sometime after I got a Kindle, the electronic book reader. Reading a book one evening in my bed, it dawned on me that here I have a device which has been present in the background of so many science fiction stories. I don't think I've charged its battery even once at that point, which added to the feeling of novelty. It was just there, day after day, a few shelves worth of books, casually in my hand. A device I would have placed firmly beside a light saber or a food replicator a decade and a half ago.

I guess the rarity of the feeling can be attributed to the fact that science fiction rarely manages to accurately predict future technological advances. Everyday computing, ubiquitous communications and Internet we have today were completely missed by the stories I used to read as a child. While the capabilities of devices we carry in our pockets are certainly impressive by the standards of several decades ago, they are also completely different from computers that appeared in stories.

Posted by Tomaž | Categories: Ideas | Comments »

IguanaIR send and receive

01.09.2012 16:37

Today I've been playing with the IguanaWorks USB IR transceiver I wrote about previously. I managed to record a few codes transmitted by remote controls that were lying around the room and also control devices by re-transmitting the codes. As details of this operation were not completely obvious to me from the documentation available, here's a short tutorial.

For basic receive and transmit you need just the iguanaIR package (igdaemon and igclient). There is no need for lirc.

For reception, use the following command:

$ igclient --receiver-on --sleep 10
received 1 signal(s):
  space: 57344
received 6 signal(s):
  space: 2901
  pulse: 2389
  space: 576
  pulse: 1194
  space: 554
  pulse: 597

This gives you 10 seconds to point any device that is transmitting IR codes to the Iguana receiver. The receiver demodulates the amplitude modulation and prints out lengths of interchanging silence and carrier signal intervals (in microseconds) to standard output. received ... signal(s) lines can be ignored as they appear to only tell you how the data was divided into chunks when it was sent from the daemon to the client.

As far as I know, there is now way to determine the carrier frequency.

Signals recorded this way can be translated into a raw, unsigned, 8-bit data stream with 1 MHz sample rate using the following Python script.

import sys

for line in sys.stdin:
	f = line.strip().split()
	if len(f) != 2:

	s = f[0]
	l = int(f[1])

	if s.startswith('pulse'):
		sys.stdout.write('\xff' * l)
	elif s.startswith('space'):
		sys.stdout.write('\x00' * l)

This can be handy for viewing or editing signals, for instance in Audacity.

To transmit a signal, use the following:

$ igclient --send path-to-file
send: success

path-to-file should in this case point to a file that has a similar, but not quite the same format as the receiver output above:

pulse 2389
space 576
pulse 1194
space 554
pulse 597

Apart from missing colons this format is also a bit stricter regarding the sequence of pulse/space lines. The file should always start with a pulse (not space) and the client won't allow for multiple consecutive pulse or space lines (i.e. you should consolidate them into a single line). It also appears that if the sequence described by the file is too long, you will get a timeout error from the client, even though the sequence will actually be transmitted by the USB dongle.

You can set the carrier frequency using igclient --set-carrier.

To get this format from a raw file that was produced by the Python script above, use this snippet:

import sys
import itertools

data = sys.stdin.read()
data = map(lambda x: x > '\x7f', data)

for k, g in itertools.groupby(data):
	l = sum(1 for x in g)
	if k:
		print "pulse", l
		print "space", l
Posted by Tomaž | Categories: Code | Comments »