pcmhacking.net

The1 wrote:interesting read
http://hackaday.com/2013/10/29/can-hacking-protocols/

Yeah that is actually a good read. Always find good stuff on hackaday.. I do recall readin about one with reverse hacking a brother printer lcd screen... still makes me want to rip into the vy vz lcds and do the same thing.

Back on topic.. so... still no elm cable... Im beginning to think the elm and I are just not meant to be!
Makes it really hard to diagnose issues without like the weird disconnecting issue you are having VX. Might have to halt this project and do more research until I get a cable.

Had another crack at debugging the app this afternoon.

Straightened out a few issues, and cleared up unnecessary coding as well as categorize everything under the correct region for easier viewing
With that done, fixed up some simple mistakes, and ensured that the connect/disconnect functions dont have anymore hickups. Ran it through the elm emulators and seems to happily connect and disconnect now (was ending comms before the thread finished causing a crash) so it does additional checks to ensure the background thread has ended before continuing

I did make changes to the elm setup, should be more informative, auto scrolls down and stops saying each time its looking for elm at idle.

VX, Iv dropped the .net requirements to 3.0, it was on 3.5. This should fix your issue on the other computer!
Annnnd, iv redone the monitor all function + the vin function for CAN 11bit. Havent implemented the OSID or PCM# yet.

If anyone can test to see if the monitor all function + filter is working, that would be great!.

Will see how it goes tomorrow if no one else can test it before then!

Got some good and bad news.

The VPW vin retrieval works! Just need to convert the received data to the text box and thats sorted.

But Iv mucked up the "115200 baud" fast baud setup somehow when cleaning up coding last night. Although it works when unticking that option. Ill see if I cant make a quick fix on it.

Thanks for those who have been testing!

I think I fixed the fast baud hickup.
Also Made the vin now show in the textbox, and will also do the OSID and PCM# request for VPW protocols.


Am now currently working on making a proper "auto detect" protocol function.. Make use of the ELMS "try protocol" function and see how that goes.

*Edit
Funny enough Iv picked myself an old serial obd2 cable from a mate that didnt want it. Cant get it working though.. Have power and ground connection to the cable but no luck so far.
Im assuming its based off the elm? Havent seen anything like it before.

Well, tested on a commodore, Jeep and i30 and dont get anything back from the device.. Must be a dud. *sigh* back to waiting... Im almost to a point im going to implement a remote connection scheme to allow live debugging over the web, and when I finish that.. I bet the stupid cable will roll up

Well.. That fast baud enable still doesnt work for some reason.. Im not quite sure why. But should be able to set to standard rate of 34800 until I sort that out.

On the plus side, a bit of tinkeringand soldering got the OBD2 cable working. Looks like it uses a elm322, so works on the VPW protocol. Hooked her up to my scantool and.., It worked!

When selecting VY Engine Gen3, it sends back:
[17:08:49:167] Received: 6C 10 F1 20 64
So 6C priority byte, to 10(pcm), from F1(scantool)... so.. what to respond back to that with.. will need to go over those logs taken before.

Ill now set the elm header to 6C F1 10 to pretent to be the pcm and see what happens.

*Edit
Heres our winning frames:
[15:30:52:187] Received: 6C 10 F1 20 64
[15:30:52:187] Received: 6C F1 10 60 72
[15:30:53:653] Received: 6C 10 F1 20 64
[15:30:53:653] Received: 6C F1 10 60 72
[15:30:53:669] Received: 6C 10 F1 10 01 07
[15:30:53:684] Received: 6C F1 10 50 01 84

So need to fire off 6C F1 10 60 72.. must just check if pcm is present.

Tech2 recognises my responses back, but this elm cable is a dinosaur and isnt quick enough to capture data, stop monitoring, fire off frame and begin monitoring again, since tech2 then looks for the next message to receive but the elm misses it and tech2 says communication lost... will need two cables for this

[17:44:16:148] Received: E9 3A F1 3C EC
Next Message from the tech2.. hmm.. sends to 3A..
Guessing I need to respond with E9 F1 6A 7C XX?


That frame its sending makes the tech2 display "identifying.."


So I guess this is the point that we need a working custom frame sender to start getting info from the cars. Since I cant seem to guess the response.. will just have to manually get it!
If anyone can try setting a header of: E9 3A F1 and then sending: 3C Hopefully something will come back from that. Cant use my software for that though, so will need to use terminal or something else.

Ill work on getting the VPW custom frame send/receive function going so that this can be done within my app.

*Edit
Attached is new version, have added in VPW custom frame send/ receive. If anyone could try sending 3C with a set header of E9 3A F1 that would be great! Have also re-implemented the VPW engine data read for testing

Looks like its working alright! Vin,OSID and PCM# seem to be all picked up.

The Engine data did something a bit weird..
[06:46:27:312] Requesting Engine RPM: 01 0C..
[06:46:27:343] Engine RPM Found: 6C F1 10 7F 01 0C 11 DF

[06:46:27:343] Requesting Coolant Temp: 01 05..
[06:46:27:375] Engine Temp Found: 6C F1 10 7F 01 05 11 C9

So we have our standard headers in red, got mode 7F (general response) in green, the mode (01) and PID (05) in dark blue, the data in pink and the checksum in light blue.
So, my problem here.. is thats not the response back that I was expecting?! Shouldnt the mode be 40+ the request.. eg 41 instead of 7F?
Plus both requests displayed 11 as the data.. which seems wrong.. a pcm on bence isnt going to be idling at all lol.

Sooo, could it be the priority byte (6C) is to blame? Generally I think the header is set to 6A when requesting basic engine data. Might have to try that out.
Typical response that I was looking for was: 6C F1 10 41 05 00 40 XX

noooo 7F is a Fail.... as in what the hell was that packet you sent me I dunno wat you are talking about... 7F

Jayme wrote:noooo 7F is a Fail.... as in what the hell was that packet you sent me I dunno wat you are talking about... 7F

AHHH what was I thinking, I forgot about that.. Reading through some gmw papers explained that.

Soooo.. Im either sending something completely wrong, the pcm doesnt support that PID .. or that priority byte is making it upset?

Might have to request some to try changing their priority byte from 6C to 6A and see if that sorts it? Since I dont think the vin request worked on 6A?
I wouldnt have thought the priority would of made such a deal..

Well, least the tech2 should explain some unknowns once I get pass the identifying screen.