I am excited to hear you guys are doing this kind of system in the SL-C ....it is certainly a "next level" approach....keep it up.
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 leadWill 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.
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
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
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:
![]()
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'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
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.
I'm not sure on the specs of the Galaxy Tab, does it have a USB *HOST* port?
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.
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
. . . 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).