actually I understand what your saying there and its opening doors for me because the protocol is the interesting part and how the manufacturers manipulate this stuff so its only a matter of time before walls are broken down, CAN isn't new its been around for many years its just that there wasn't the need for me to understand it purely because it was in industry use but now its officially in cars that makes things different.
edit: im still into the old way of probing the ECU via a breakout box (bob) which is still the most direct way in as long as the values are known and I have software thats give me this information and many garages use it, it just takes longer and the new way sounds pretty good and a time saver as long as the data can be relied on ( software being the issue ) and thats where costs come into it
Maybe this will help you start:
I'm using a bluetooth based ELM327 on my 2007 Citroen C4. The ELM communication is simply ASCII so the following can be tested even using a simple terminal program, like HyperTerminal which comes with Windows XP (character case is not important):
- after opening the port, send "atz" to initialize the ELM. Actually, this init is optional, but do it just to be sure. In more advanced scenarios, "atz" may be unwanted so "atws" can be used to "warm start" the ELM.
- Issue "ATL1" to enable the line feeds when using Hyperterminal so the results will be easier read.
- now you can send "almost raw" hex numbers that correspond to the OBD2 mode and PID you want to access. The "tricky" part here is that you actually send the ASCII chars of the bytes! Example:
To read the mode 1, PID 0 data that are the bitmask of the supported PIDs from 00-20, you need to send "0100" (without "AT"... this is not an AT command). So, 4 ascii chars must be send to the serial: "0" (ascii 48), "1" (ascii 49), "0" (ascii 48) and "0" (ascii 48). the answer from ELM will be 6 "hex bytes" (in ascii form!). Check also http://en.wikipedia.org/wiki/OBD-II_PIDs for a list of PIDs and answers.
so, no special initialization is needed for simple usage.
Jus a quick note to let you know that I have built circuit in Page 49 RS232 figure 9 using PCB given in your side, to communicate with the vehicle, am currently having a concern / problem with the chip responding with unknown values, chip responds with something like this: ÿ þ and þþ or responds þþ ¾ þþ if u query about the vehicle VIN no whereby Scantool ELM5 gives correct VIN.
my VB software is working 100% I have tested it with ELM5 hardware from Scantool. And communicates with my vehicle (CAN Bus) well.
RS232 Tx and Rx LEDs flash but my OBD-II Tx and Rx LEDs only flash first time you power it up: I have jumped pin 28 and the ground as explianed in page 39, but didn’t help
Didn’t touch any of PP commands / AT commands or baud rate settings, please now that chip is in defualt
I find the protocol because of it difference and lack of communication via multiplex meaning the problem with newer cars ie: many protocols are used within the system and the diagnostic tool cant do all of them and that's where it fails, think about it? elm uses a pin out not considered CAN so the wiring has to be set using a break out box ( unless you have a multi tasking protocol tool and the 16 to 9 pin doesn't do it because its defined protocol so the pins have to be reset per protocol and that means many leads hence the need for a break out box so you can switch protocols speed not being the question because switchable does it most software does it if you know how to set it,
main thing is 16 to 9 pin when most multiplex need more and that's where the 20/ plus pins are required,
CAN has its own setting in pin configuration 16 to 9 pin and all the others have their own like ISO/kpw and other engine management systems so its a single item your looking at, air bags/ ABS/ traction control/ ESP/ ect ect all use different protocols and that's called multiplex