Software On ELM Street - OBD2 Software Development

[TazzI]

yes I did and it didn't work... what ecu are you basing this off... this was just off a E38.. which is can

are you using a LS1 or try with a Memcal based pcm with uart

To be honest.. I havnt got that far
My full understanding of OBD2 and such is pretty limited. I am focusing on any pcm that communicates over VPW, which isnt CAN obviously.

Also, I dont have a car to test with.. I dont even have an ELM cable yet! lol.. Its on the way. Am so far developing this from others feedback! haha. But the main aim of this is to develop a dedicated app for holden commodores for fault daignostics, which ill be reversing the tech2 to get all the manufacture specific fault codes ect.

This is assuming I get a work application! haha

[TazzI]

Some good news, looks like the application does work! Had a tester successfully get info from there car, this includes the ignition status, engine data and obviously cable set up.

Am chucking in a monitor all function to listen to all the traffic, and revising the vin read section. Will update soon.

[doubledip]

good work taz... actually testing a few things now onmy test bench so might chuck a few ecu's on there and see what there is

[TazzI]

Cheers Double,

Iv had some mixed responses on who has it working and who doesnt. I think it all depends on the protocol that the car is using. Im specific aimed it at the J1850 VPW

[doubledip]

Well that's pretty much LS1 ecu

[TazzI]

Ah sweet as, will keep note of that.

[TazzI]

Seems that the elm device needs a good solid connection to the obd port to ensure that it powers up and works correctly, otherwise cant connect to the elm and set required settings.

Also seems that some pcm's havent been outputting to simple request such as 010C (RPM request). Not sure if this is because they are on bench, or because the elm device timesout before the pcm responds due to too much traffic of request is low priority thus completely missing it!

Iv bumped the elm timeout value to 1000ms instead of the default 400ms to rectify the issue. If the elm still sends back "NO DATA", then it may be a matter of resending a few times incase the pcm missed the message. Might have to tinker with the priority byte to see if that doesnt speed things up a bit.

Also tinkered around with developing a gauge from a few bits and pieces off the net and suited to my liking. So far the gauges will look something like this..

[TazzI]

Moving forward slowly.. Doubledip, Im now understanding why you asked what cars/protocol I was aiming at.. as not all commodores use the same communication!

Iv so far sussed out that the LS1's will use VPW (cheers double!). But from VZ onwards, they use CAN.
From what I gather, I have two main CAN types, 11bit and 29bit. 29bit seems to be for more diagnostic/general requests and is similar to that of VPW except different header. Whereas 11bit seems to speak directly to the desired module using a more refined module specific header(xyz).
Only way of really determining the header of a specific module would be to monitor traffic over comms with scantool connected up doing bits and pieces (I think)

Also looks like CAN then splits into High(500Kb) and Low(250Kb), so again.. I guess its a matter of more generic info on the high and more specific on the low? maybe?

For the elm327, the protocol options I have to choose are:
6-ISO 15765-4 CAN (11 bit ID, 500kbaud)
7-ISO 15765-4 CAN (29 bit ID, 500kbaud)
8-ISO 15765-4 CAN (11 bit ID, 250kbaud)
9-ISO 15765-4 CAN (29 bit ID, 250kbaud)

So I assume that these work on VZ and up..

Looks like I might have to have a good read through the "GM Lan Single Wire CAN Bus Sniffing" thread since that seems to cover alot of the elm communication. Read alot about SWCAN.. but Im lost on whether VZ's would use this or not? Infact Zerone.. you started diving into developing software with the elm, how'd that go!?

[TazzI]

Just had a very good read of the "GM Lan Single Wire CAN Bus Sniffing" thread. ALOT of good info in there explaining 29bit formatting and typical responses!. STeep learning curve though.

I understand the 4 byte header, breaking it down into its bits to then determine the priority bits, arbitrary ID and sender bits. Makes it easier to determine what the frames purpose is and who sent it.

Also trying to wrap my head around the whole mask and filter settings for the ELM. So looking at an example from GMlan thread:
Header Filter : AT CF 00 00 00 94
Mask Filter : AT CM 00 00 1F FF
Setting the above header filter will only show messages 'from' 94 (source ID) eg. 10 2E 20 94 01 00

Easy to see that the Header Filter directly checks the header, in this example, only frames that are sent from the module ID '94' are displayed and everything else is ignored.
Whereas for the Mask, I understand that it does a boolean check on the bits to determine whether to keep or discard the frame.
So If I break the header down into its bits.. I would get:
priority|Arbritary|Sender = 1 0 0 | 0 0 0 0 1 0 1 1 1 0 0 0 1 | 0 0 0 0 0 1 0 0 1 0 1 0 0
Which then converts to Priority = 4, Arbitrary = 171 and SourceID = 94

..Now only thing Im lost on is Im not 100% sure on how the mask is being applied effectively..and what is actually doing.
When applying a mask of 1F FF, all bits of the priority and arbitrary are set to 0, and all bits of senderID are set to 1. eg.
0 0 0 | 0 0 0 0 0 0 0 0 0 0 0 0 0 | 1 1 1 1 1 1 1 1 1 1 1 1 1
So Im taking a stab at this.. but im guessing that the elm will check if the incoming frame has any of the sender bits set to 1? If so, allows the message through?.. mm not sure.

[TazzI]

Cool, I think I get it now.. after staring at 1's and 0's for a while and scrolling through logs.
So the Filter is a quick way of rejecting message based directly on the header bytes. And the mask is a more flexible moderator of what gets rejected and accepted based on the bits.

So using the above example, converting to its bits (10 2E 20 94)
priority|Arbritary|Sender = 1 0 0 | 0 0 0 0 1 0 1 1 1 0 0 0 1 | 0 0 0 0 0 1 0 0 1 0 1 0 0

If I then want to set a Filter of 10 2E 20 00, meaning I want to see messages with 10 2E 20 and dont care about what the "sender" byte. If I then want to further refine my searching, I can set the mask..

Using a mask of 1F FF FF 00, will look like this: (Read = header, Green = Arbitrary, blue = senderID)
1 1 1 | 1 1 1 1 1 1 1 1 1 1 1 1 1 | 1 1 1 1 1 0 0 0 0 0 0 0 0
So what are these 0's and 1's? Any "0"'s mean "I dont care", whereas the 1's mean "The received frame MUST match our mask".
Therefore, the mask is saying the CAN priority must match, the priority and destination must match, but the last 8 bits (SenderID) do not matter.

So in this example, out mask and filter are essentially doing the same thing. Although this can be set up to show things between say: 10 2E 20 17 and 10 2E 20 1F. Which would display info from different modules to the ID "20" from the modules between the values of 17 and 1F

This is what I *THINK* is going on. It kinda makes sense, and follows what Iv found in logs, although this is only an early interpretation and will need to test this out and see if we get messages that correspond to out filter + mask to prevent buffer full problems and look for specific messages.