A vehicle is a complex environment, especially when it comes to the driver interacting with various controls. Some of the most distracting aspects of advanced user interfaces are related to user input. We decided to alleviate this issue by using a minimal amount of keys to get everything accomplished. So, how did we do it?

Physical Controls

The W221/W216 steering wheel comes with 2 sets of controls, one for the left hand and one for the right hand. Each set features up/down/left/right buttons as well as an ok/back button. As such, we have a total of 12 buttons to work with. However, this doesn’t mean we need to use every single one of them. We need to keep things simple, remember?

Navigation Scheme

Basic navigation is accomplished with up/down/left/right buttons, as expected. The “OK” button will enter a menu while the “Back” button will back you out of menus, step by step.

Functions

In addition to pressing a button, a usually neglected secondary function is holding the button down. In our case we decided to map this function to actions like automatically scrolling to the end of a list or selecting a specific interface control. In other words, if you’re scrolling through a long list, and the action button (ok/apply/cancel/etc.) is located at the end of the list, you’d have to scroll all the way down to get to said control. However, holding “down” pressed, will automatically select one of the action buttons. Press “UP” and you’re right back where you were in the list. Time saved and distraction avoided. The same notion is logically applied in different parts of the interface, to maintain consistency.

Real World Considerations

As usual nothing is as simple as it seems and no good deed goes unpunished. There are several aspects that need to be taken into consideration when coding key flow in a user interface.

OEM Functions

The OEM buttons function as you would expect. If a button is pressed, a key status signal is sent at specific intervals, that indicates which buttons are pressed and which are not. We need to take this signal, decode it and forward it to the user interface at specific time intervals to accomplish the desired hold down/release effect. Another thing to keep in mind is that while we can read the key presses, we also have to filter them accordingly. We only want key presses to be forwarded to the car in certain instances, like when the user is in the OEM menu, interacting with the OEM instrument cluster. This will be accomplished by the CAN decoder part of the system . This piece will exclusively decode CAN messages and forward them accordingly. It will also have the ability to generate its own messages, should we need to interact with the car from a non-OEM menu, and run on a dedicated M4 processor core.

Software Design

Ideally, software is modular, and each piece knows how to handle button actions on its own, which is not complicated if you only have one window/process on screen at a time. However, things get exponentially more complicated when you have software that is window or app based. Every window needs to be aware of what actions are being requested, and either perform said actions or forward the requests to other parts of the system. Certain development environments account for this, and provide a framework to handle key presses, which is a good starting point. If you are looking for this framework to integrate with your custom interface 100%, it will not. So what now?

Key Watchdog

Simple, we create our own key generator that talks directly to the MCU communication piece, which in turn, talks to the CAN decoder interface. Let’s not get ahead of ourselves though. The idea is to generate keypresses that work within the framework provided by the environment. In other words, we take control of signals being sent out like “key press”, “key release” and repeat intervals. How does this help us? Well, for example, if you are in the “media/music” menu and the “OK” button plays/pauses the currently playing song, and you want to display an options menu by holding down the “OK” button, then the first action of holding down “OK”, within the traditional framework will be a button press. In other words, your song will play/pause and then the options menu will be displayed. This clearly needs fixing.

However, with our customized signals, we can simply have that first action be a repeated keypress, followed by other repeated keypress at custom intervals. This will show the options menu without playing/pausing the song. It will also give us other advantages, like having the ability for certain parts of the interface to generate key presses for other parts of the interface, without a clear forwarding chain.

Final Words

Yes, developing a custom key generator will take some time but, along with a custom developed keyboard, it will filter out a lot of the aggravation generally felt when dealing with systems that make use of limited physical controls. It will also give users complete control with very few buttons, and completely avoid distracting touch screen controls.