pcmhacking.net

Nice work Ant! Looks like yourself an vn5000 have working software. Good to see yours is doing well!.

This was an interesting read, now makes sense to why the avt's are so expensive as they can read the required protocol. Whereas the ELM misses out on some vital info.
Even then, very cool that the vin read/write was sorted. Defeats the purpose of any application have a vin lock.

I like the open source idea, and the hardware that antus chucked up (I think it was you ant?), looks good.. not sure if anyone attempted to make one though?.
Big problem with open source is quality control and version control.. Would need a central person to get the new info/coding and implement this into the "main" version. Otherwise keeping track of whats been changed and what version will be an utter mess!.

I dont think support for this would be an issue, looks like plenty of interest in this with 27K+ views! If 3-5 people were working on this at once.. progress would rapidly increase. Say 2 people work on reverse engineering keys or see what the scantools/software do by developing a "fake pcm" ect.. and another 2 working on coding and implementation of information, Id say that would work perfect.

I know how slow a one man army is... unbelievably slow, development of my software is at a crawling pace due to the R&D of scantools.. working out whats going on then the implementation of the new information. Even worse when working out seed/keys.. theres only so long one pair of eyes can stare at a bunch of bytes in excel before going nuts!

Anyway, looks like we have a bunch of information, alot of talk about software and VB but no software chucked up. Im happy to scrap together something simple to do a vin read/write, that should give a basis to start working off. People still keen?

HPTuners works on a vin lock.
Efilive works on serial of the eeprom/bin file.

Tre-Cool wrote:HPTuners works on a vin lock.
Efilive works on serial of the eeprom/bin file.

Hmm was under the impression they both worked off the vin, or at least the last 6 digits (Serial) of the vin

hptuners works on serial + vin (making it expensive to replace an OS you dont want) but efilive just works on serial thus is fairer in that regard.

As far as hardware goes, has anyone considered this?
http://www.ebay.com/itm/Mini-VCI-J2534- ... 36&vxp=mtr

less than $25

It is labeled for Toyota but has VPW capability. From what I understand is works essentially the same way as a Mongoose unit, but I have limited knowledge of all of this.
It also has "user upgradable firmware" which could mean (with some editing of the firmware) we could override any packet size limits it may have, but seeing as the actual purpose of this tool is to flash I would think it wouldn't need that.

And yes I know it is Chinese garbage, but it might be sufficient.

What if the software was written to support J2534 standard, then you could use any cable that compiled whether its mongoose, techii or tactrix?

the standard applies to the cars side of the interface cable. cable to laptop each still use their own protocol so they are all different.

Interesting, theres a tear down about it here:
http://www.youtube.com/watch?v=0E7tBXDkexY

Is there any docs to back up that it does do VPW? From the tear down it looks like its the canbus version.

Mmm.. didnt find much about it. Not a whole lot of fact sheets, no clue on the Tx,Rx limitations though.

It SHOULD function well enough to do flashing. It is compatible with GM's flashing software (used for Software upgrades, not tuning), as well as Toyota Techstream (flashing upgrades to Toyotas, also grabs diagnostic data, not sure about tuning). It is my understanding that j2534 applies to the vehicle, cable, and software. There is an API template that you are supposed to use to build the API for the cable, so if we use those functions we could make the software useable any j2534 cable that comes with a properly formatted *.dll. (this would include Mongoose cables, so those who don't want to trust Chinese stuff can spend a couple hundred on that)

The API template can be found here: http://www.drewtech.com/support/J2534/index.html
That is DrewTech's implementation but the major functions should all be the same no matter who manufactures the cable. The rest is PassThru.

Another thought: I can buy one of these cables and examine the driver that comes with it and see what functions it exports, that way we can make sure we have the correct function names.

I am a programmer but I am new to the PCM world, so I have some experience with other things and maybe I can help? Who knows.