Reverse engineering the bug of my Opel Zafira’s volume knob (with movie!)

The bug

Some articles ago we proudly introduced the Opel Zafira’s electronic handbrake in order to explain de-bounced buttons. We now have some more bad news for the guys from Opel: the volume knob of the car has a bug. We admit… it is a very minor bug, but still, it is a bug. And as good engineers are supposed to do: we describe and document the bug. Here we go.

This is the expected behaviour of a volume knob:

• turning clockwise should increase the volume, while
• turning anti-clockwise should decrease the volume.

Now take a look at the youtube movie. It is bad not the best quality but you should be able to see that at the third clockwise turn the volume actually decreased from 10 to 9.

Also, although we hear lots of clicks (we can assume that one click should correspond to 1 volume delta), the volume stays the same or changes only slightly. In this post, we do not regard this behavior as a bug but as sub-optimal behaviour.

In fact, my (very clean) microwave oven, an AEG Micromat Combi, has a very similar bug but only a lot harder to reproduce (so no movie here but only a bad quality pic :-)).

Reverse engineering the bug

The electro-mechanical devices behind volume knobs are (or could be) rotary encoders. A rotary encoder “converts the angular position or motion of a shaft or axle to an analog or digital code” (see wikipedia). There’s a variety of them in the market.

An important characteristic is the number of steps (or clicks or phases) in one revolution, and also how each position (i.e. each possible step) is encoded.

If we assume a 2-bit quadrature code of a 4-phase incremental rotary then the output is shown in next table:

The two outputs A and B can be connected to a gpio pin of the processor (an additional pin could be needed to trigger an interrupt at a rotary state change).

The algorithm is simple: a transition from (0,0)->(0,1), (0,1)->(1,1)…(1,0)->(0,0) implies a clockwise rotation. A transition from (1,0)->(1,1)…(0,0)->(1,0) implies a anti-clockwise rotation.

Now, what happens if ‘the system’ misses a transition or set of transitions. Then there are 2 possibilities:

1. we detect the miss e.g. (0,1)->(1,0) or (1,1)->(0,0) implies a glitch. In this case, the system can just ignore the state change. Or,
2. we are mislead by the system 🙂 E.g. (0,0)->(1,0) is interpreted as a anti-clockwise rotation while in reality it was a clockwise rotation with 2 misses! Here is ‘our’ volume knob bug.

Possible solutions

There are several solutions to fix the bug. Although this is implementation dependent, we have some suggestions:

• improve the performance of the software so it does not miss state changes of the rotary (e.g. better driver, faster polling…),
• improve the hardware support for software e.g. by providing an interrupt at rotary state change,
• make the bug physically hard to reproduce by the user e.g. by increasing the number of steps of the rotary,
• …

Disclaimer: the above is of course only the result of some professional guess-work 🙂