In-Vehicle Infotainment is a slightly silly (IMO…) word for the center dash display of a modern car. It’s the system that runs the audio, GPS, settings, etc. on the car via a touchscreen LCD. I want to put the same in my car, but since this isn’t your run-of-the-mill production vehicle, I want to do some specialized functionality like diagnosing the data coming from the car. More or less the only choice I therefore have is to develop my own home-grown system, which I’m actually very excited about. Combing cars and computers into one sounds like lots of fun to me.

Typically, most folks build these “carputers” (the names just get better…) to plug into an existing car and mostly for the “tainment” rather than the “info” reasons. In my case, it’s a little bit different as I am much more focused on having access to all of the data floating around the car than anything else. Entertainment is icing on the cake, so for now I plan to display the data coming off a Controller Area Network (CAN) bus onto the center dash and I’ll be happy once I achieve that reliably. So what is can then? CAN is an automotive industry standard developed by Robert Bosch GmbH in the 1980’s for having various electronics communicate within a car.

I won’t go into the details, but in my SLC the Pectel SQ6M ECU I’m deploying takes all the sensor input, uses it to make decisions on what to do with the engine and then sends it out via such a CAN interface, allowing any other system to do what it pleases with it. Applications include triggering certain lights or motors if a parameter is of a certain setting, logging the data for later analysis or more simply, displaying it.

The hardware for such a system is pretty cheap and readily available via sites like mp3car.com. Even a board with a CAN input is easy to get in a small case and with a low-power Intel Atom CPU. The software is also relatively simple for most applications, unless of course you want to do custom stuff like I do. I won’t be able to just run Windows or a Linux flavor, but instead will be using a very new Linux-based platform called Tizen to building my system. Linux makes life easy, because it supports CAN in the kernel out of the box. Tizen makes life even easier, because it’s a Linux distro curated by Intel and Samsung to be the basis for phones, tablet PCs and vehicle entertainment systems. It’s pretty much perfect for what I want to do (once it ships as a non-beta release that is…).

Beta or not, I need to make sure I’m not getting in over my head on this before I plan aspects of the car around this or I invest in hardware for it. I need to make sure I can get a proof of concept done to make sure I can get the data path working, which I’m happy to hereby report that it indeed does. So here’s what I did:

1. Fake out the ECU: I can generate fake frames for a Pectel “Omega” data stream on a Linux Ubuntu system and put the frames on the system’s CAN bus. I only did 3-4 of the most important frames, but the rest are easy now that the framework is in place.
2. Build a CAN network: I don’t actually have the ECU or a system which has a physical CAN port, so I need to fake the CAN network interface out via a virtual device. Luckily, this is part of the Linux kernel and installed by default on Ubuntu Linux and I just configure the virtual device. Super simple.
3. Read the CAN data and send to frontend: Once I have the frames writing to the CAN bus I need to read them correctly (remember the writing is fake data coming from software I wrote to act as the ECU on the CAN network). For that, I built a small program which picks up the frames, massages them and makes them available for a frontend application to consume. Tizen is mostly based on HTML5, so I take the CAN frames and pump them out again via a Websockets interface, which is a recent W3C standard for doing client (browser) to server interaction. I optimized this slightly to only send frames when they’ve changed from the previous one, thus cutting down on the data rate.
4. Display the data: Using the websockets interface, I’m able to write the proof of concept frontend to test the data stream by using standard, free web development tools. That’s especially helpful because for now I don’t have a system I can develop directly for Tizen on as I am waiting for the MacOS-based SDK and emulator which is set to arrive soon. Regardless, with the tools I can use right now, I am able to decode data without a sweat at about 100-130 frames per second, displaying it as raw values as well as drive a set of gauges.

Here’s a screenshot of the gauge screen showing 4 parameters (yes, those dials move…):

And another screenshot of the raw data page:

If you’d like to check it out for yourself please send me an email to tim@timtt.com and I’ll give you the link.