Building a center dash display - feedback?

I'd not use one of the cheap USB ELM327 based ones for anything other than supplementary gauges. It can't cope with the data rates and will stop 'recording'. You can specify the individual CAN id's you're interested in but then you're limited to looking at one thing at a time. Admittedly that's in a production car with DSC/TCS/ABS/EBD and a lot going on but even so I think you'd be pushing it.

I used this as the basis of my CANBUS hardware with the arduino CAN Shield you could probably use the same or very similar with the Raspberry pi through the GPIO header on it. Or you could wait until something is available for it or even use the arduino as a pre-processor (I intend to do things this way to start with).

The arduino will drive small screens (think normal mobile phone screens rather than 'smart' phone) but wont manage anything large or graphically intensive. The RPI otoh will do 1920×1200!
At the moment only DSI or HDMI but its brand new (I've not yet got one myself, still on the 'interest' list, as Tim says LVDS is preferable as the screens are cheap and widely available.

If I was to be doing it as a fixed screen I'd probably use something like this http://www.ebay.com/itm/200690008406
 
Last edited:
Tim,
Will and I have been scheming for some time and have teamed up on the project. I opted for the 7.7 as it fit perfectly in the available space and Will just HAD to copy my lead :) Will is the lead Tech on the project and I will be the install/bezel designer. At some point you will have a local example of this work to review.

Nice. Def want to check that out. I need to check your car out period actually.
 
Might as well buy direct than from FleeBay:

Lilliput and Mini Touch 700 Touch Screen Monitors 7-12.1" models.

You guys might also find this interesting though I'm not sure on the depth in the centre console for the SL-C:

Bybyte Infotainment Solutions

I'm looking to do a very simple and as cheap as possible double-din system in the case above for my MX5 to tide me over for a while, in this instance I'm looking more for satnav/music/phone integration using something like Centrafuse than pulling engine data.

In the future (not on the MX5), I'd want a CarPC that controls two screens, one for the dash, another separate one for the 'stereo' and it must be a tight integration, look as 'factory' as possible and most importantly be STABLE/RELIABLE.

Not only should it pull data from the CANBus connected to the ECU, it must interact with the ISIS CANBus to manipulate outputs depending on certain conditions/soft switches on a touch screen (I know ISIS has their own touch screen but it's too expensive).

Who knows Fran, we aren't too far off the point where it might be cheaper to offer a CarPC based package that runs the dash/console than to run the other dashes, the key thing has to be stability and integration.

Note you guys need to make sure you are getting high brightness display if a lot of sun can get on the SL-C's dash, something like 400 cd/m2 and above otherwise you might have difficulty reading it during the day.
 
Thanks Will! The CAN data stream turned out not to be as hard to work with as I thought. If you have docs for the frame protocol and have a board with a CAN adapter, it's quite easy under Linux. It's really a matter of figuring out how to manage the quantity of data. For example, the Pectel Omega stream has at least 4 frames at 100Hz, plus a bunch of others at 20Hz. A C program handles the read load easily and can write the data to disk in a breeze, but you have to figure out how to selectively send data to the fronted for display. I've gotten the overall CAN server -> frontend rate down to about 10 frames / sec, but I'm also considering not sending individual CAN frames and instead aggregating data into larger frames. Optimizations if/when I have to.

I'm very interested in how you do with the Galaxy tablet approach. I thought about that a lot and haven't ruled it out fully yet. In that case I would use a different smaller embedded PC and pump data via Ethernet to a tablet that's the frontend. This would then just be one app of many on the tablet display. I wouldn't use Wifi as the network connect due to reliability/interference reasons, but I have found a few Android tablets with a wired Ethernet port that would probably work ok. I'm just scared that they're no-name manufacturers and I can't get a replacement board in 2 years when it breaks.

So in the end, the Nexcom VTC1000 looks good for a few reasons:
1) It's got CAN bus, GPS, WiFi, Ethernet, video (VGA or LVDS) all integrated into a ruggedized enclosure specific for car applications. No hassle with drivers, USB dongles (except TPMS).
2) Support from the company (they've been around and look like they will be for a while) and the community for this board.
3) Supreme flexibility of OS distro, displays, etc.

And even if I use the Nexcom, I can convert to using a tablet frontend at a later time too. Still an option I'm exploring.

Regarding the display, I plan to use the largest one possible that can sit near the top of the center dash. I really don't like the Tesla Model S full touch screen interface, as I think tactile feedback from buttons and switches for some stuff crucial. Mine will be a 7-10" LVDS touchscreen which I'll figure out once I have the car (supposed to be this coming weekend - hooray!)

Keep me posted on how you do with your system. Very curious!

Tim

The Nexcom looks like a good approach for the hardware. I assume you think it has enough processor power for the task? Also, I assume you will be using an SSD instead of rotating media?

Aggregating or sampling frames is a good approach when your display doesn't require the same refresh rate as the data rate from the device. And for certain kinds of data like pressure and temp, the changes that are significant happen so relatively slowly that 90% of the data can be discarded without a loss of utility. This has positive implications for processing efficiency and so performance.

The data that is really important to update in real time is mostly RPM, and possibly speed. The Koso already does a fine job in displaying and smoothing that data, so what is left normally doesn't require such intensive processing and display. I suppose if you started tracking knock signals, etc, you'd need to log them all; but you'd probably only need to show the knock events, not all the silence between them.

Most of the data I want to see in the center stack in real time changes relatively slowly anyway, so in this case, Bluetooth is probably fast enough. It certainly seems that way in the testing I've done so far.

Re the center stack real estate, the width of the stack and the height of the console (assuming you are using that) limit the size of the screen to around 7". Rob promises me that the 7.7" screen in the Galaxy Tab 7.7 fits there, and it seems to, when I lay it up against the dash. I don't see how you can fit a 10" screen in there without seriously hacking up the dash. But I'd like to be proven wrong! :)

One advantage of the Galaxy tab is that some of the system buttons have a haptic interface, so you can feel them when they are pressed. Pretty cool for a car app, where you don't always want to be looking at a screen while driving (especially in a car like the SLC).

The Galaxy also has built-in GPS, BT, wifi, and of course, it can be obtained with cell radios as well (both Rob and I have wifi/cell tablets). So it could conceivably be used as a phone in the car.

Not sure how you'd drive the tablet from the Nexcom, especially if you rule out wifi. What are the problems you see with that? Parenthetically, I am using wifi in the car to control the ISIS system from my phone, so I am sensitive to the idea of interference, and hope my wiring runs reflect that concern. I'm thinking about using the phone to tether to the tablet to avoid having to buy data and talk plans for the tablet.

I'm pretty excited about the idea of IVI in the SLC, and working against the limit of not having space for a traditional DDIN solution makes it cooler still.

Please keep us posted as you progress. If I have time, I may make up a small video showing the tablet approach Rob and I are working.

The approach I am taking in my car is to use the steering wheel controls on my steering wheel, which will control a hidden single DIN headunit. The headunit will supply amplified output, and if I am clever, access to the included radio functions as well. In other words, the tablet supplies audio to the headunit, which outputs it to speakers; the headunit is controlled by the controls on the steering wheel. Rob's car will probably just run the audio output from the tab to an amp, and use a separate volume control to manage that.

For those who haven't seen the wheel, here is a picture:

IMG_1321.jpg


The wheel bolts right up to the unmodified column, but the wiring has to be re-done to send the signals down the column correctly. I'm in the process of ordering new connectors and wiring them up.

The controls on the right spoke should give me all I need, but I am thinking I can also use the paddle shift controls to do something. Still pondering that- and looking for suggestions!
 
I'd not use one of the cheap USB ELM327 based ones for anything other than supplementary gauges. It can't cope with the data rates and will stop 'recording'. You can specify the individual CAN id's you're interested in but then you're limited to looking at one thing at a time. Admittedly that's in a production car with DSC/TCS/ABS/EBD and a lot going on but even so I think you'd be pushing it.

I used this as the basis of my CANBUS hardware with the arduino CAN Shield you could probably use the same or very similar with the Raspberry pi through the GPIO header on it. Or you could wait until something is available for it or even use the arduino as a pre-processor (I intend to do things this way to start with).

The arduino will drive small screens (think normal mobile phone screens rather than 'smart' phone) but wont manage anything large or graphically intensive. The RPI otoh will do 1920×1200!
At the moment only DSI or HDMI but its brand new (I've not yet got one myself, still on the 'interest' list, as Tim says LVDS is preferable as the screens are cheap and widely available.

If I was to be doing it as a fixed screen I'd probably use something like this Open Frame 7" Lilliput Touch Screen Monitor SKD Kit with VGA/HDMI/DVI 669GL | eBay

Thanks for the link.
Yes, I was not going to use the ELM based ones. I was going to try to find some type of off the shelf controller that if needed can be modified (designing one to the exact needed spec is the way to go, but one off PCB start to become costly). I was going to talk to these guys to see what they got.
Using the Pi was my thinking because it contains the video out to drive the needed screen.
 
Last edited:
The Nexcom looks like a good approach for the hardware. I assume you think it has enough processor power for the task? Also, I assume you will be using an SSD instead of rotating media?

It should have enough power. The C program which relays the data uses about 1% CPU on a 3-year-old cheapo Athlon box, so it won't be a problem. The concern is the graphics intensiveness of the JS, but since this is the Tizen reference platform (literally the one the Intel devs use), I'm pretty confident it will be ok. If the JS is a problem, I'll have to convert to Qt which will take a little work, but would be awesome to learn. Definitely using an SSD - that's a must and they're pretty cheap nowadays.

Aggregating or sampling frames is a good approach when your display doesn't require the same refresh rate as the data rate from the device. And for certain kinds of data like pressure and temp, the changes that are significant happen so relatively slowly that 90% of the data can be discarded without a loss of utility. This has positive implications for processing efficiency and so performance.

The data that is really important to update in real time is mostly RPM, and possibly speed. The Koso already does a fine job in displaying and smoothing that data, so what is left normally doesn't require such intensive processing and display. I suppose if you started tracking knock signals, etc, you'd need to log them all; but you'd probably only need to show the knock events, not all the silence between them.

Exactly. I'm sending down RPM & speed 4x per second and all the other sensors only if they've changed AND it's been 5 seconds. I'll reduce that window if necessary. You're exactly right, it's about the "events" that happen.

Most of the data I want to see in the center stack in real time changes relatively slowly anyway, so in this case, Bluetooth is probably fast enough. It certainly seems that way in the testing I've done so far.

Re the center stack real estate, the width of the stack and the height of the console (assuming you are using that) limit the size of the screen to around 7". Rob promises me that the 7.7" screen in the Galaxy Tab 7.7 fits there, and it seems to, when I lay it up against the dash. I don't see how you can fit a 10" screen in there without seriously hacking up the dash. But I'd like to be proven wrong! :)

Cool. 10" is probably too big unless you turn it to be taller than wider. I may use an 8" display, but we'll see. A lot of it depends on standard Tizen display support for me. I want to be able to take release builds from them, add my packages and not have to recompile when there's any update. Thus also the hardware choice - I'm willing to spend a few more $ and have some suboptimal situations if I can reduce the variables and future maintenance costs.

One advantage of the Galaxy tab is that some of the system buttons have a haptic interface, so you can feel them when they are pressed. Pretty cool for a car app, where you don't always want to be looking at a screen while driving (especially in a car like the SLC).

The Galaxy also has built-in GPS, BT, wifi, and of course, it can be obtained with cell radios as well (both Rob and I have wifi/cell tablets). So it could conceivably be used as a phone in the car.

Neat, did not know the haptic part. Tacticle feedback is key and it sounds like from the below you guys are adding real buttons for volume and a few other things. I'm punting on audio for the meantime, but would like to do real physical buttons somewhere. I like the analog stuff - putting in a real needle tach in the driver dash for example.

Not sure how you'd drive the tablet from the Nexcom, especially if you rule out wifi. What are the problems you see with that? Parenthetically, I am using wifi in the car to control the ISIS system from my phone, so I am sensitive to the idea of interference, and hope my wiring runs reflect that concern. I'm thinking about using the phone to tether to the tablet to avoid having to buy data and talk plans for the tablet.

My dev env is a Linux box in another room that runs the server and I run the client locally on a Mac. They connect via WiFi, so you could run the server on the Nexcom (Tizen or other Linux distro) and then have the fronted running on the tablet connected via Ethernet. Frontend code could be stored locally or come from server, doesn't matter much since it's small.

My comment on Wifi is just through the experience of running Wifi networks in urban environements. I live in a house in San Francisco and have lived in multi-family buildings here, Chicago and Boston with Wifi networks. They are spotty even if you get the best routers and the reason is many devices throw off electromagnetic waves. One of the biggest culprits are microwave ovens. Our wireless in Chicago would go down every time we turned ours on. Since this is a kit car I'm sure there are some components which will create interference and with my "let's reduce the variables" mantra in mind, I'd rather have wired Ethernet which is less fickle to debug. Also on Linux, the command-line tools for wired Ethernet config are way easier. That said, if the display has mostly non-mission-critical data on it, lossier networks will be just fine.

ISIS integration is far in the future for me. I'm curious if I can plug into their CAN bus and start sending signals on it, but for now I'm ok with keeping that a separate system.

I'm pretty excited about the idea of IVI in the SLC, and working against the limit of not having space for a traditional DDIN solution makes it cooler still.

Please keep us posted as you progress. If I have time, I may make up a small video showing the tablet approach Rob and I are working.

The approach I am taking in my car is to use the steering wheel controls on my steering wheel, which will control a hidden single DIN headunit. The headunit will supply amplified output, and if I am clever, access to the included radio functions as well. In other words, the tablet supplies audio to the headunit, which outputs it to speakers; the headunit is controlled by the controls on the steering wheel. Rob's car will probably just run the audio output from the tab to an amp, and use a separate volume control to manage that.

Video! Both good solutions. As above, I'm with you guys on the tactile feedback.

For those who haven't seen the wheel, here is a picture:

IMG_1321.jpg


The wheel bolts right up to the unmodified column, but the wiring has to be re-done to send the signals down the column correctly. I'm in the process of ordering new connectors and wiring them up.

The controls on the right spoke should give me all I need, but I am thinking I can also use the paddle shift controls to do something. Still pondering that- and looking for suggestions!

This is sweet. I "wasted" over an hour looking into this last night cause I thought it was so awesome. This is a C6 wheel, right? Future upgrade for me once I consider audio. Good stuff.

Tim
 
I'm sure you know this already but the buttons on the wheels work via each button having a 'unique' resistor behind it, this means that the interface can be two wire.

To make life easier with such a wheel you can get an interface such as the 'CarPC JoyCon'
CarPC JoyCon EX was released - Centrafuse Auto - Connected Car Apps User Community

I have the Joycon, but am using a PAC steering wheel interface for this application, at least to begin. The output of the Joycon is a USB port, which is perfect for a car PC app like Centrafuse, but not likely for a headunit which doesn't expect to see controls coming in on a USB port (most of them are looking for file-system devices like memory sticks). Most of the headunits have a dedicated port or control wire for steering wheel controls. The PAC interface uses that feature of those headunits.

It would be interesting to try to connect the Joycon to a USB port on the tablet, but the tablet's native drivers don't support devices like that do they? Writing android device drivers is way outside the scope of this project for me- I want to finish the car and drive it before I have to trade it in for a wheelchair with a WARP motor, skinny slicks and Li-Ion batteries.

And yes, the SW controls use differential switches. :)
 
I'm not sure on the specs of the Galaxy Tab, does it have a USB *HOST* port?

That's a nice steering wheel, is it actually carbon fiber?

timtt said:
ISIS integration is far in the future for me. I'm curious if I can plug into their CAN bus and start sending signals on it, but for now I'm ok with keeping that a separate system.

This is what I have been looking into, I think I briefly saw it discussed on the ISIS website but nothing was concrete. I guess if it's a CANBus you can just hook it up and sniff the wire as you are now to see what is going on when certain actions are taken.

if you can hook up an ISIS CANBus to a PC that would be great since they also have an adaptor for Vintage Air that connects it to the CANBus and can be controlled via the ISIS system, in theory you could control that as well through a nice frontend such as Tizen or Centrafuse and be completely integrated.

The only thing is I think the ISIS interface for Vintage Air is only for their biggest unit which doesn't fit in the SL-C as far as I am aware.
 
The joycon description mentions that it conforms to standard USB HID, meaning it emulates a standard usb keyboard. With a host USB adapter such as this:

Galaxy Tab

It should be doable I would think. Also we should keep in mind that Android is nothing but a chopped down linux kernel, as time passes the manufacturers are going to turn on more and more of the base kernel to bring in compatibility with additional external devices.
 
Personally I think the Galaxy Tab is overkill for such an application when a 7in android tablet can be had from ~£50 (or about $60). I bought a cheap one and that comes with a full size USB socket.
 
I'm not sure on the specs of the Galaxy Tab, does it have a USB *HOST* port?

Yes, but it's more of a software question usually. Thankfully, Android 3.1 upwards supports it, which is a big upside for using Android for this kind of stuff. My understanding is the iPad hardware also supports it, but Apple just won't turn it on in software.

This is what I have been looking into, I think I briefly saw it discussed on the ISIS website but nothing was concrete. I guess if it's a CANBus you can just hook it up and sniff the wire as you are now to see what is going on when certain actions are taken.

Oh good, but I'd probably wait for someone to figure out the protocol or that they document it. It's not super hard, but it's a lot of trial and error. Bigger fish to fry on the car for now.
 
I'm building a center dash display for both all the entertainment pieces, but also to visualize data coming off the car and would love to get your feedback on an early sample. I wrote a few words about it and did a screencast demo on my blog / build log: A working IVI system prototype « blog.timtt by Tim Trampedach (I'd post the video directly here, but you can't like you can do with pictures)

The underlying assumptions are that I'm building a street car which I'll take to non-racing track days here and there. I'm trying to lay the groundwork for upgrading to a great interior after I get the car on the road. Any suggestions you have on what to show, how to organize the data, visualizations, etc. would be greatly appreciated. Feel free to respond here, on my blog or email me at [email protected].

Thanks,

Tim

Watched the demo. Impressive.
 
I am interested in what forms you will display the data.

I watched your video blog, Tim, and saw the simple round dials that you put up there as an example.

Giorgetto Guigiaro is considering new ideas about how to display data to us. For example here is the cockpit to his Vadho concept:

2007ItalDesignVadhoCockpit001.jpg


Siemens has their experimental VDO instruments:

sight_at_night.jpg


Some of the military forces of the world have thought about how to display a lot of data so that their soldiers might absorb it easily in quickly. Can their efforts guide you in your making your displays?

For example, Sweden's cockpit for their JAS 39 Gripen fighter:
SaabJAS39GripenCockpit002.jpg


Or Tim, my uncle has put a nice display into his new F-35A fighter:

F-35_Cockpit_dusk_with_virtual_HMD_001.jpg


Do any of these examples inspire the possibilities for data display?

Bassanio et Portia
 
Last edited:
HUD

As you can see from the post above, the militaries put the most important information, the information that changes the most, on a Heads Up Display (HUD).

Some automotive companies already have a basic HUD in their cars.

2008_BMW_5-Series_HUD_001.jpg


The JAS-39 Gripen or a Eurofighter Typhoon sports a large HUD.

TyphoonHUD001.jpg


Which gives the "driver" (pilot) a lot of information.

SaabJAS39GripenCockpit001.jpg


Can using a HUD like the Gripen's help inform the SL-C driver so that he or she may drive the SL-C better?
 
Helmet-Mounted Displays

Some displays dispose with large displays placed far away on some exterior panel and put the information right into the "driver"'s (pilot's) helmet. It is called, imaginatively enough a Head-Mounted Display (HMD)

Here is an HMD on an Apache helicopter pilot.

AH64Apachehelmet001.jpg


Do you see the green oval in the photo of the F-35A cockpit? The green oval the display that is overlaid right in the pilot's helmet.

F-35_Cockpit_dusk_with_virtual_HMD_001.jpg


Why use big, heavy,displays far from the driver when you can "add lightness" by putting small, light displays over the driver's eyes inside the helmet (Helmet from the Typhoon again)?

JointHelmetMountedCueingSystem001.jpg


Or, if you are not racing and are not required to use a helmet, you can project the information on a lightweight headset.

FinalFantasyVirtualInstruments002.jpg


"Wait a minute!" I can hear someone say, "that last "photo" is a scene from a science fiction movie!"

True, because science "fiction" is becoming scientific reality. Very quickly.

"You want me to cover up my eyes and drive a car that is as fast as an SL-C? That's suicide!"

New ideas can be scary. So is taking your eyes off the road at 200 mph to look down at a gauge or display you may or may not be able to see. A head-mounted display can make you MORE, not less, safe.

To inspire faster, cheaper, lighter, more reliable, safer SL-C's,

Bassanio et Portia
 
Haptic Controls

. . . One advantage of the Galaxy tab is that some of the system buttons have a haptic interface, so you can feel them when they are pressed. Pretty cool for a car app, where you don't always want to be looking at a screen while driving (especially in a car like the SLC).

Sweet!

Haptic controls are virtual. No parts exist to wear or break. They weigh nothing. Talk about "adding lightness"!

A haptic switch looks like a switch, it feels like a switch, When you "press" the haptic switch, you "see" it move in and out, you "feel" it with your fingers, and what you want to happen, happens.

But the switch is not there--physically. You see it through a display. You feel it through force-feedback in your gloves.

Now, how much of the SL-C do you want to control with haptics?

Do you want to control just peripheral systems, like the movie character is doing in this scene?

Haptic forearm control

FinalFantasyVirtualInstruments001.jpg


Haptic controls

FinalFantasyVirtualInstruments003-1.jpg


Or do you want to control the SL-C completely through weightless, wear-less, unbreakable haptic controls? The movie scene shows the character performing surgery with a haptic control (figure with green glowing sphere on right).

FinalFantasyVirtualInstruments004.jpg


Remember--science fiction is rapidly becoming science fact.

Back to the discussion. Using haptic controls on the SL-C, weight goes down, reliability goes up, clarity goes up, the SL-C driver is in more control of his faster car than with "real" steering wheels or pedals.

If you are scare of such an idea, say so! Saying it makes it less scary.

Bassanio et Portia
 
Back
Top