Hotwiring the future of in-car tech with a smartphone and Raspberry Pi

Most current in-car infotainment and “telematics” systems follow a common theme in their design. For the sake of safety, branding, and a sustained source of revenue, they shackle vehicle owners to an integrated system that does poorly the things that smartphones already do well. The “connected car” dream has arrived in small doses on selected vehicles, and it has idiosyncrasies that drive vehicle owners who’ve become used to the power and simplicity of smartphone apps a little bit crazy.

OK, a lot crazy. A few months back, I ranted about my personal experience with MyFord Touch and the shortcomings of in-car technology. It seemed like the car makers were missing the point with systems that tried to copy smartphone features and to get developers to code for their own proprietary platforms. While a recent upgrade to MyFord Touch (that I had installed at a dealership) has solved many of the problems that drove me to distraction, it’s still a locked-down environment that gets in my way more often than it does what I want.

When Michael O’Shea, the CEO of Abalta Technologies, told me his company was working on a system called Weblink that draws on the capabilities of the cell phone to drive in-car systems, I wanted to see it immediately. He gave Ars access to a prerelease iOS application and sent prototype hardware to test it with: it’s a fairly standard 7-inch VGA touchscreen tethered to a Raspberry Pi computer.

I plugged the Raspberry Pi into a DC adapter in my car and booted it up. Seeing a Linux startup console on my dash, I started to salivate at the potential. Even after the test was done, I was still turning over the ramifications of the system in my head. While there are clearly a few bugs to be worked out, there is also so much potential. This promise lies not just in Weblink or in harnessing smartphone technology and economics, but in future applications of cheap, modular, wirelessly networked computing power in a vehicle.

The Web on your dashboard

The Weblink “app” for iOS and Android is essentially an application server for the client software that runs on the Raspberry Pi (and will run on embedded computing systems on “head units” from manufacturers that license the Weblink technology). What shows up on the screen is an HTML5 interface to the Weblink server app itself as well as other applications on the smartphone that it interacts with.

The Weblink server app can be connected to the client in a number of ways. Two of those approaches use Wi-Fi—either a peer-to-peer connection, using a static IP address setting for the smartphone, or over an existing shared Wi-Fi network. The second approach works best if you’ve got your phone enabled as a Wi-Fi hotspot or your vehicle has some other in-car Wi-Fi hotspot. There’s also the option of tethering the phone to the client over USB. O’Shea said that Bluetooth connections will also be available in finished Weblink units.

Once I got things connected, I took some of the HTML5 applications already configured in the Weblink menu for a test drive. Some of the applications were purely demos, but the vast majority of the apps were fully functional. Media applications on Weblink—such as Slacker Auto, 8Track, and NPR’s Web radio player—worked flawlessly on the prototype.

That’s largely because applications that have been developed in HTML5 require little if any modification to run on Weblink, O’Shea said. The Slacker Auto app that was included on the Weblink demo, for example, is essentially the same application that runs on the Chevy MyLink system. So if you’ve already developed an HTML5 application for iOS and Android devices that accesses location data, the same code can be run within Weblink’s sandbox with minimal modification.

It’s also possible to create hooks that tap into native applications on a phone. One example of that is a demo mapping program from TeleCommunications Systems, which uses a “helper” app on the smartphone to control the view of the map so that the smartphone’s screen can be used as a sort of touchpad to pan the map on the dashboard screen.

By default, audio from Weblink apps I tested played from the iPhone itself, though Weblink can be configured to “stream” the audio to the client over the USB or network connection. In the commercial units, there will be support for Bluetooth “streaming” of audio. But I was able to switch audio to the MyFord Touch/Sync system as well as to a Bose portable Bluetooth speaker through my iPhone’s own settings as a workaround.

Since the Raspberry Pi setup of Weblink was, as O’Shea put it, “a simple evaluation kit” that was one of a dozen or so configured to show the technology to potential partners, it wasn’t set up as a full demonstration of the platform and lacked call-handling features and the like. There are certainly some challenges posed for Abalta’s developers by the nature of iOS itself—particularly for cases when the phone is connected to the client over Wi-Fi.

For example, when a phone call comes in, iOS forces applications to suspend, which terminates the network connection between the smartphone app and the client. The same thing happens with popup notifications. In both cases, Weblink has to re-establish the Wi-Fi connection once the alert or call has been cleared. Alternatively, neither of these is an issue over Bluetooth or USB, because those connections use Apple’s iPod Accessory Protocol (iAP) to handle communications.

Convergence by the dashboard light

In some ways, Weblink resembles the next generation of technology planned by General Motors. As I was in the middle of testing the Weblink, I paid a visit to GM’s OnStar Command Center in downtown Detroit and got a look at a prototype of the next version of OnStar’s telematics display. (It’s branded as MyLink for Chevrolet, Cue for Cadillac, and Intellink for Buick and GMC.)

Like Weblink, the next version of the MyLink/Cue/Intellink interface will be based on HTML5. But instead of using a smartphone’s computing power, the applications will run on the telematics system’s embedded computer. While they’ll be stored locally, they will be able to use the 4G wireless being built into the next generation of GM’s OnStar systems to connect to the Internet (with applicable charges for data usage of course).

GM’s approach has the advantage of integration with both the rest of the vehicle and with the OnStar service—which can connect a driver with a real human being to help them do things that tapping and dragging on a touchscreen can’t. And OnStar and Sync can also get access to information on vehicle performance and potential maintenance issues. Those things that aren’t in Abalta’s scope for Weblink.

This doesn’t mean that sort of functionality couldn’t be brought into Weblink or a similar system. Most of the data that drives car telematics is accessible over vehicles’ Controller Area Network (CAN) through a vehicle diagnostics port—a port that generally only gets used when you bring your car in for an emissions test. Ford has sponsored the development of OpenXC, an open interface that allows other devices to plug into the CAN and pull data from it. That interface could, for example, be used with an application like Weblink to launch a call to 911 when airbags deploy or upload vehicle performance data. The same apps could use the accelerometer data from a phone to alert 911 of a rollover and give a location for the accident.

That sort of thing is a significant hack right now—one the Raspberry Pi running under my armrest in my Escape inspired me to take on. But it could soon become a feature of aftermarket and off-the-shelf systems for people who’d rather not pay for OnStar or Sync or the other equivalent services offered bundled with vehicles at the dealership. It should also help those of us who drive less-expensive models that don’t come with the option to begin with.