On black magic

27.09.2011 17:42

A while ago, during lunch break at a BarCamp, I sat at a table with some of my colleagues from Zemanta. There was an iPhone 4 on the table and conversation touched its infamous antenna issue. Gašper said "You know, I heard antenna design is kind of a black magic" to which I replied that somewhere an RF engineer is probably saying to her colleagues "You know, I heard software development is kind of a black magic".

While I was only half serious at the time, it did get me thinking. I believe that design in all fields of engineering has parts that can be calculated analytically. Parts where laws of nature, either directly or through simplification and abstraction permit parameters to be calculated with formulas and algorithms to some useful engineering precision. There are also other parts where the only solution is an experiment. Those are the parts where you have difficult to predict parameters, chaotic systems or simply involve systems so complex that an analytical solution either doesn't exist or costs more to obtain than doing a series of experiments that will lead to the same result.

I understand black magic as a problem that favors an extremely experiment-oriented approach. A problem where a solution can only be obtained with a heuristical process. One that requires intuition of a designer that has over the years accumulated and internalized a large number of failed and successful experiments. Designer with enough experience that when presented with a problem he can intuitively recall what approach worked well in a similar case, even if he can't explain it.

The two approaches, the purely analytical and purely experimental, overlap to a large degree. For example when designing analog circuits you can go pretty far calculating exact values down to the last resistor in the system, counting in stray capacitances and so on. Or you can take a more experimental approach. Calculate some basic parameters with wide enough error margins, build a prototype circuit or a simulation and tweak it until it works to your satisfaction. I would argue that the sweet spot lies somewhere between both extremes. Both in the aspect of least effort and quality of solution. Of course, hitting that sweet spot, knowing when you went too deep into theory, is also where intuition and experience come into play. It's a different kind of intuition though and arguably one that is more broadly applicable than the black magic one mentioned above.

Moving work from design to implementation.

Original by Paul A. Hoadley CC BY-SA 2.5

It's quite the same with software engineering. Just replace pages upon pages of differential equations with design documentation in a waterfall model. Or incremental building and optimization with the coveted agile approach.

In fact my growing dissatisfaction with the software development world is that the mindset is ever more moving towards extremely experimental design. This is most apparent in the fresh field of web application programming. There is little to no strict documentation on much of the modern frameworks that hold the web together. Few well defined interfaces have specifications that are too complex to fully understand and are riddled with implementation bugs. It's the field that favors the magicians that have enough mileage to recite individual web browser CSS bugs by heart in the middle of the night, ordered backwards by the issue numbers. With continuous deployment, increasing hate of version numbers and release cycles for software this bias is only growing more prevalent throughout the software industry.

It's an interesting contrast to the inherently analytical nature of computer programs and it certainly doesn't look like the fictional RF engineer's statement would be any less well grounded than my colleague's.

Posted by Tomaž | Categories: Ideas | Comments »

Ars Electronica 2011

14.09.2011 19:59

Two weekends ago I went to Linz, again joining the Kiberpipa team visiting the yearly Ars Electronica festival of modern arts. I was intrigued by the Origins motto and the colaboration with CERN.

Continuization Loop

Eventhough I had the feeling that this year's event was somewhat smaller than the last one I was again surprised at how much effort this little Austrian city dedicates to modern art. A weekend was just barely enough to skim through all the exhibitions and attend a few performances.

Real-life wireframe simulating surface of the water

Last year I complained that the ideas often overtook the actual implementation and that many exhibits didn't work as they were intended. This year it certainly didn't look that way. For instance Tsukuba University exhibit contained all sorts of interesting gadgets with intriguing designs and flawless operation. We also saw automated algae-cookie-making-machines, wearable robotic tails, speaking pianos and all sorts of other interesting stuff involving electronics and mechanics.

Machine making cookies from algae

Actually, the CyberArts Exhibition included projects that stood firmly in the field of hacker activism. For instance Newstweek and Sentient City Survival Kit. I also didn't expect to see analysis of scrapped Facebook user profiles in an art gallery. The best idea in my oppinion goes to the Tool to Deceive and Slaughter, a featureless black box that perpetually sells itself on eBay.

A tool to deceive and slaughter

I think CERN had a really good presence on the festival. They had two halls dedicated to various physics experients, presenting activities at CERN, what and how they are searching for the origins of the universe and how a lot of what they do can also be interpreted in an aesthetically pleasing way. As always I was looking on the whole thing with what was probably too much of an engineer's eye. When my questions became a bit too technical one of the demonstrators admited that he was just a local arts student and that he doesn't know that detail. That impressed me even more since before that I wouldn't say I wasn't talking to an engineer or a physicist. I'm just not used to meeting artists that are capable of keeping up this level of technical discourse. All congratulations to their arts university if this is the norm rather than an exception.

Cross-section of LHC in Ars Electronica Center

From the performances we managed to attend the Tesla Orchestra concert (two huge singing Tesla coils plus a guy wearing a conductive suit and background music) and Android Theater. While the performance was quite impressive, the advertised puzzle of who is android and who is human just wasn't a challenge, even with the catastrophically bad echo in the hall. I would argue that the robot actor was on the other side of the deepest end of uncanny walley, but the face motions just aren't there yet. I would however like to see one day the results of the questionaire we were given at the exit.

In the clouds on top of the parking garage.

And lastly, I should mention the event on Danube, which was inspired by the Arthur C. Clarke's Childhood's End novel. No James-Bond-style running on trains this year, just an hour of fireworks synchronized to music, big explosions, robotic voices and green beams of lights. Oh, and rainbows and "how many roads must a man walk down" in the end, which was kind of a confusing finale and not exactly what I remember from the novel.

Posted by Tomaž | Categories: Life | Comments »


10.09.2011 13:50

A while ago I was given this piece of hardware to analyze. It's a scary little bug that sits on the cable between a computer and a monitor and makes screenshots. It comes in HDMI, DVI and VGA (the one I have) flavors and looks more or less like a short extension cable. All of the nasty bits are hidden away in one of the connector housings and the only suspicious thing giving it away is an extra USB cable that goes into it. That is used for power supply when the device is in stealth mode, and for reading the captured data afterwards (you need insert the red USB key between the computer and the device in order to access it).

The manufacturer recommends using it on employees and children. In the latter case I hope to teach them how to evade such monitoring should they ever find themselves in a society that encourages that. The use I was exploring though was a bit less sinister capturing of presentation slides on lectures for Viidea.

VideoGhost, VGA version

The first thing I noticed the moment I plugged it in is that my EeePC 901 crashed and required removing the battery to get it to boot again. Trying it again on a different laptop produced similar results. However turning the machine off, plugging the VideoGhost in and turning it on worked.

Since VGA is analog output only that's a bit surprising. I suspected this has something to do with Display Data Channel, which is a fancy name for an I2C bus that's used in all recent monitors for identification. Poking around I quickly found out that all the pins on the middle row of the VGA connector are tied to ground, including pin 9, which is +5 V supply for DDC. Shorting this to the ground while the computer is turned on probably trips some fuses which cause the computer to crash.

I'm not sure whether this is a design or manufacturing error. I also wonder why they haven't used this pin for power supply instead of that suspicious USB cable.

VideoGhost, top PCB

Cracking open the shell wasn't trivial, since the whole thing is filled with hot glue. However a careful application of a hair drier and various sizes of flat screwdrivers did the trick. It still works (minus one SMD capacitor I managed to tear off), however I pretty much demolished the case.

The keelog.com site says the device contains a microprocessor and a FPGA chip. What I see inside more or less agrees with that.

There are two PCBs. The top one contains a chip in a QFP64 package that connects to the USB cable, a MicroSD card (hand soldered via tiny wires) and a backup battery wrapped in green masking tape. All markings are sanded off but it's most likely a microcontroller with hardware USB support. Quite a few ICs fit the description and after some searching around I wasn't able to find one that would fit the pin assignments exactly. I'm sure with some more effort the exact chip could be found. There's also an empty header for what might be a JTAG port.

The bottom board has a chip in a QFP80 package that is connected to the VGA signals. It talks to the top board through something that looks like a combination of a parallel bus and I2C.

Capturing a frame from the VGA requires three AD converters capable of 150 megasamples per second or thereabout. I'm not aware of any off-the-shelf FPGA chips that would contain such hardware. It's possible this is in fact a mass-produced VGA framebuffer IC. It's also possible the bottom side of the PCB contains another IC, but I'm reluctant to find out since it would mean more destructive tearing and I might break something.

VideoGhost, bottom PCB

I'm not all that impressed by this design. The amazing mess of wires inside doesn't give me confidence in it's reliability, neither does the already-leaking back-up battery inside. It does however offer some interesting challenges in reverse engineering. I might poke around a little more and perhaps try to sniff the I2C communication on the board or checkout that JTAG port. I also wonder what trickery is used in the USB key that enables the USB communication on the device.

Posted by Tomaž | Categories: Digital | Comments »

Persistent camera switch

07.09.2011 22:04

In case someone else has been wondering why the integrated camera on the EeePC mysteriously gets switched on sometimes. It's not a sign that someone is spying on you through your netbook's webcam. It turns out it's a feature of the eeepc-laptop module in the recent versions of Linux kernel. I've been noticing this since I upgraded to Debian Squeeze with the 2.6.32 kernel.

The eeepc-laptop: enable camera by default thread on LKML pretty much explains it. The kernel module that provides access to the laptop's power switches for various peripherals got patched so that it unconditionally turns on the camera each time it's loaded. This usually happens at boot, but it took me a while to find that out since I mostly put my computer to sleep and only occasionally reboot it.

Now in my humble opinion it was a pretty bad decision to include this patch in the mainline kernel. Leaving paranoia aside for the moment, turning camera on increases power consumption. The LKML thread addresses that but it appears they didn't get to any certain conclusions about the impact to battery life.

I also find the practice of fixing broken userland in the kernel questionable. The rationale for this patch was that people get confused when the camera is turned off and software reports no cameras on the system. Why is that a problem? If the camera is turned off, it's not there. Period. If a particular userland distribution isn't happy with a camera that is turned off it can fix this with a one-liner in a boot script.

Also the state of the hardware power switches is persistent over reboots. So if someone likes to have a camera switched on at all times, he can switch it on once and it will stay that way. This weird crutch of turning the camera on at boot just makes it confusing when one switch fails to retain its state while all others do.

Reverting this patch is simple, but I'm not going to maintain a custom-compiled kernel just for this - I'm still too happy that Squeeze removed the need for five custom kernel patches for various quirks of this laptop. So now I have a one-liner in a boot script that switches off the camera after the module has been loaded.

Posted by Tomaž | Categories: Code | Comments »

Thunderbird mail header style

01.09.2011 11:45

After I upgraded my laptop to Debian Squeeze, Icedove (Debian's rebranded Thunderbird 3.0.11) developed an annoying problem. The mail header names (from, to, cc, etc.) got nearly invisible on the dark GTK theme I'm using:

Default Thunderbird header style.

After some experimenting with the GTK theme itself I found out that the color used for this text is now actually hard-coded (bug 583197). I should mention that neither GTK Parasite nor Mozilla's DOM inspector were useful in finding the particular style this text is using.

As suggested on the thread above, the color can be corrected by modifying the offending headerName style. Instead of rebuilding the default theme it is however enough to simply add an override to ~/.icedove/<profile>/chrome/userChrome.css:

.headerName {
	color: #333 !important;
	font-style: italic !important;

Of course, choose the color and style that matches your theme. Here's how this looks like on mine:

Corrected Thunderbird header style.
Posted by Tomaž | Categories: Code | Comments »