one other part, is what cars will it be meant for.... cars have different communication protocols (of the OBD), some provide more info than others, and some control more things from the ECU than others (etc the windows). what you sed bennY is good. one node could be used to understand all the stuff the car can provide, and then "tell" the other nodes what they should or shouldn't do. but it would require great programing from some one , to understand a wide variety of cars... woulden't it?

for OBD thats correct. My knowledge there is limited to VW/Audi <=build year 2000, for those i can say they all use the same protocol/datablocks. Afaik OBD2 is also a standard, where at least data like RPM/Speed Datablocks should be the same.

windows for example are @VW/Audi controled by comfort can bus. for this we need advanced users who can sniff their can bus and provide such informations. as the system is modular we will end with different OBD nodes for the different manufactors/cars which provide the informations in the same format to keep them compatible to the whole system.

I have a conference call with a guy who is proficient with OBD and CANbus on Tuesday who said he is interested in the project and would like to lend his knowledge. I think eventually we will provide instructions with how to datalog you vehicles bus systems and upload the data and then programmers can use that data to improve compatibility.

FYI, I have the Ford enhanced Auto Engenuity software for Ford and will be buying the GM expansion pack very soon. This is bi-directional software that sees pretty much everything the Mfg sees, it commands solenoids on and off, reads ABS, Airbag, transmission circuits etc. I'm just throwing it out there as additional resources in case it helps.

FYI, I have the Ford enhanced Auto Engenuity software for Ford and will be buying the GM expansion pack very soon. This is bi-directional software that sees pretty much everything the Mfg sees, it commands solenoids on and off, reads ABS, Airbag, transmission circuits etc. I'm just throwing it out there as additional resources in case it helps.

That would be incredibly valuable information. I would love to get that software eventually, I just cant justify that cost at this point.

I threw that out there thinking if you ever need access to my truck connected to this software through team viewer for data collection, verification, etc. then pm me and we'll figure it out. The software requires a security dongle plugged into USB otherwise there might be more ways to skin this cat...

I threw that out there thinking if you ever need access to my truck connected to this software through team viewer for data collection, verification, etc. then pm me and we'll figure it out. The software requires a security dongle plugged into USB otherwise there might be more ways to skin this cat...

I am sure we can do something remotely in time. I will definitely keep that in mind. Thank you for reaching out.

I have always envisioned making an ODBII driver package... I just don't have the skillset to accomplish this yet.

The idea is you have a central package that can cipher the data and send it out in a common format. This software piece would do all of the dirty work needed to accomplish the input and output. The interface between the software and any other software would be a common interface that could be used by anyone. This would be built into a common library. It would likely need to be built in C++ since C++ can run on just about everything.

The idea then is that the user chooses which "driver" to use and it just works like a printer.

My intent is to build this into something that could be used for ANY ODBII consideration.

Imagine having a universal package that allows you to diagnose your car and adjust your own settings.

Built on the base it is unreal what you could do..

Just a dream at this point but once I can build something to play with I will be looking more into it... I am thinking maybe I should build one of my ARM boards into an ODBII trainer...

In our vehicles a large portion of them have a high speed network for high priority items and a slower speed network for less priority items.

This has gotten me thinking we might want to actually consider 2 networks in any design work we do. One network would be for mission critical things such as ODBII and the other would be for less important things that if they are delayed it is OK such as streaming of music or other non-essential data.

The two network idea really is only if we need it though. If you run all of your mission critical stuff on the same box then it really doesn't need a high priority network. And this high priority network would only be between those devices that need it. For instance if you have a central module reading ODBII information that you want to send to a dash cluster to display and to your PC to look at diagnostics those three items are the only ones that have those networks attached.

I also was thinking more on the ODBII driver project. This could also involve a master/slave configuration that would allow two computers to run the software. The master is the one that actually pulls the information and sorts it all out. This could then broadcast it to another location where the same software receives it and can use it. This would allow us to build a system on one ODBII hardware item and just keep adding modules that can access it if need be.

What you are all talking about sounds strikingly familiar to my Automotive Message Broker project. It's basically a unified daemon for getting and setting values from the vehicle. It is one of the components in Tizen IVI but it runs on almost any Linux system. I have it running on my beaglebone in my car. It's plugin based and has plugins for all sorts of things from policy management via Murphy (among other things it can turn up and down the volume according to your vehicle's speed), data logging, OBD-II and more. It also has a set of plugins that enable master/slave mode. Data in this mode is communicated over a websocket in JSON. This makes it a very good data source for html5 applications like GhostCluster that comes with Tizen IVI.

Anyway, I'm not sure it meets your specific needs but I thought it was worth pointing out.

cheers,
Kevron

Former author of LinuxICE, nghost, nobdy.
Current author of Automotive Message Broker (AMB).
Works on Tizen IVI. Does not represent anyone or anything but himself.