j2534 Open Source Resources

[KerchumA222]

It looks like I will be using com0com or parts of it to make a Virtual COM port to emulate ELM327 commands through the j2534 interface. That will be my first step.

[Taylor]

It looks like I will be using com0com or parts of it to make a Virtual COM port to emulate ELM327 commands through the j2534 interface. That will be my first step.

Why emulate the ELM? Do you have existing code that works with ELM and you want to accomplish with J2534? An elm adapter should be fairly straight forward depending on how you have your code laid out. I layered my software so i can swap out interfaces as required. I have written code for the ELM/ST devices, so now i just make small changes to make J2534 standard work

I picked up the MVCI, got the DLL installed on win7 thanks to some auto enthusiast message board, and i was successfully able to start a diagnostic and a programming session on an Audi ecu. I need to figure out the "handshake" first though for this ecu type to move forward to read/write.

I too am in USA, i work on bench with a "offboard programming" kit i made, essentially just obd2 connector + breakout box(that has connections for my sniffers/monitors/la).

[KerchumA222]

I will be programming by bench most likely but I don't have the shit together for it yet except the PCM itself. It came out of a Sunfire I engine swapped (and PCM/harness swapped) to Ecotec...

The reason I am layering ELM327 is to test the underlying software I am writing that simplifies packet transmission/reception/logging through the J2534 interface. It certainly isn't the end goal... its just a must easier piece of code to test (For example I can just plug it into my firebird and talk, no fear of bricking the pcm). Once normal communication is stable I can look into how GM reprograms the PCM using this unit and follow their general pattern.

There is a j2534 logger out there that I might use and update my car with GM TIS2WEB. Then I will map out the processes I can identify, and then get more help from the kind people on here

[KerchumA222]

I forgot the most important part: I haven't found any open source GM Diagnostic software compatible with J2534. The cost of entry for this is super small. Really... like the price of a normal ELM327.

The parts I am working on right now are proper detection of connected J2534 devices (0404) and being able to select them/load the library for them. Still not sure if I should write it in C# or VC++ or VB (god forbid)... or maybe java or something. If anyone has any suggestions in that light I am willing to take advice. I want other people to participate after I lay the groundwork after all.

[antus]

I still dont see how you will be able to get around the 8 byte packet payload size limit on the elm, or in the case of VPW lacking VPW 4x support? If the programming apps wont work because of that and the logging software doesnt exist Im still not sure what your going ahead with here. That is, I dont see the advantage of developing new code against J2534 rather than ELM native? If you want to log the car, you might be best picking up the elm adx for tunerpro 5 and fixing that. I think it'd be less work to reach an end goal.

[KerchumA222]

antus you misunderstand me. J2534 is completely capable. The only reason for writing an ELM327 wrapper is so applications written for ELM327 (like logging programs) can use the J2534 interface. The vehicle programming will be handled by the J2534 directly and natively (as in no wrapper on top of it). But you are right there isn't any advantage after that except for my own understanding. I think I'll skip the elm part.

On the same note I have decided to write this thing in Java. Might take me a while but I have the basics planned out so far. Also there is at least 1 other open source j2534 java application (for subaru and mitsubishi so I still need to create the J1850VPW parts and the actual bootloader bytecode and all the parts in between). I can use that program as an example of using J2534 communications (like how they handle asynchronous data transfer, etc.)

I will be using JNA to import the DLL functions. I will also be using a JNA library called "Platform" (platform.jar) that will handle registry access. I may also write parts of the application in Groovy for simplicity (and for my own learning sake).

[antus]

Ahh right gotcha. I have wondered if rom raider would bring any advantages over tunerpro. I'll be interested to see how you go.

[rolls]

How did you go with developing your own J2534 cable?

It may be easier to develop a DLL that works with an existing product eg an AVT cable http://www.avt-hq.com/

The issue is almost no cable support reading/writing the voltage to the OBD pins, without this you can't truly support J2534

Another option would be to use something like this as a base and then add a daughter board to allow the voltage set/sink to ground functionality to the OBD pins.

http://www.seeedstudio.com/CANBUS-Shiel ... -2256.html

I'm assuming you would only implement ISO 15765 as this is the most common.

[antus]

The allpro adaptor is the most promising hardware platform at the moment. http://www.obddiag.net/allpro.html

I started developing VPW 4x protocol support (and ended up developing a sigrok / dsview protocol decoder as part of it) http://pcmhacking.net/forums/viewtopic.php?f=3&t=4761

The proof of concept was solid, but pretty rough and wasteful of device resources. I still want to get that project across the line one day, but Ive been caught up with other things. One issue is how best to extend the elm protocol, or maybe to replace it completely. If there was a J2534 layer on top of it I guess it would not matter, but the elm protocol is pretty inefficient and requires twice the bus speed to transmit the data as every data byte goes across it as 2 ascii hex bytes. Its also pretty wasteful of interface ram for the same reasons.

[rolls]

J2534 is preferable to me as if it supports J2534 then you can flash any vehicle using the factory software. Be interesting to see how much development would be needed to add support of programming read/write of voltages so a J2534 dll could be written.

Might send them an email and see how hard it would be to add the ability to drive various OBD pins high their board, the software is open source which helps.