Software On ELM Street - OBD2 Software Development

[Tazzi]

Umm.. Im not too sure about the whole disconnecting issue! Ill debug the whole process and see whats going on.
Might be best if I send a quick "reset elm" message to clear the elms current config before continuing.

And im pretty sure the apps framework requirement is 3.5, but will drop it down and see if that fixes it up.

[VX L67 Getrag]

I'll check framework today & if it's just that for the issue than I'll up the framework don't dumb your program down!

But yeah maybe an elm reset button may help the issue, seems strange monitor program can't see anything after it happens too but it can still dump the pcm!

[VX L67 Getrag]

Was as I thought both machines have framework 4 as that's needed for HPT software & it works fine!

Just tested again on xp machine & setup elm settings & then click connect...
Shows in screen below attempting to connect to comport....
Searching for device...
Then the window pops up saying OBD2Logger has encountered a problem & needs to close. We are sorry for the inconvenience.
Do you want to send error report

Not sure what else to say or test?

[Tazzi]

Im not sure VX, Ill need to do some more debugging on connecting and disconnecting. Cable should be rocking up anytime next week so should make it a hell of a lot easier to debug whats going on.
Will be something really simple causing the drama.

[Tazzi]

Well... I think I sorted the whole reconnecting issue.

And the Filter is almost finished. Just making sure that it clears the filter on every "chatter disable" click and then re-enables the filter on listen to chatter.

Im also a little bit confused on the CAN protocol. As in, now that I have turned off the "auto format", is there anything other then the standard headers and the normal request that I need? eg CAN format (11bit): XYZ SS TT
Where SS is the mode and TT is the table/pid request?

Havent found a nice CAN protocol breakdown yet. Neither do I understand what exactly the elm is doing with the auto format on, and whether theres any info I need to add.

Will attempt to add some simple Read requests for both VPW and CAN protocols and see if they work.

[vlad01]

I don't think there is a definitive CAN protocol. As far as I understand every manufacture have there only slight variations?

I know suby guys are forever deciphering CAN messages with every new model series.

[vlad01]

forget that^ It might just be the messages that vary from whole makes the system.

from what I read here> http://en.wikipedia.org/wiki/CAN_bus

Bosch own the technologies. there is some licensing for making compatible hardware? not sure if this implies the protocol or not?

[Tazzi]

forget that^ It might just be the messages that vary from whole makes the system.

from what I read here> http://en.wikipedia.org/wiki/CAN_bus

Bosch own the technologies. there is some licensing for making compatible hardware? not sure if this implies the protocol or not?

Unfortunately that doesnt really break down the message format in a legible manner.

From what Iv found, its as simple as being:
02 46 11 22 33 44 55 66

Where our Device ID would be 02 46
And our bytes of data would be the 11,22,33,44,55,66

We can also have "padding" enabled or disabled. Where there must always be 8 bytes of data, where the extra missing bytes are just 00's.

Guess we will only know by trial and error. Will need to go over those logs that VX chucked up, See how the requests are made and break each byte down. SHould just be a matter or doing a normal request as seen on the VPW protocol.. I think!

[Tazzi]

Yeah think Im a bit lost. Will definitely need to throw up another version to test this out.

But from the logs, sending: 0105
will retrieve: 7E8 03 41 05 4A

So the header response being 7E8, so we would set our request header to 7E0.
Looks like the 03 is the length of the data. Eg (41,05,4A)
The 41 is the response to our mode 01 request. (All responses are 0x40 increase of the mode)
And the 05,4A is the actual data to be interpreted.

Now, with the auto formatting turned off, Im unsure whether I need to insert that "message length" byte or not. Might be a couple tests to find out.

[Tazzi]

New versions up and running.

Have added VIN support for VPW and CAN, Both should work.. The CAN will not interpret the vin completely as I dont have any examples to base off of for sure but will display the response in the response box, Once I know what the response looks like I can then interpret the hex into Characters.

Have also added an export function for the command counter grid.(Hope that helps VX!)
Also added is the Filter function for both VPW and CAN. Hopefully that all works fine!!.. Should be able to set to 7E8 to see response from pcm or set to 7E0 to see whats being sent from the scantool/software ect.

Have no way of knowing if any of the above works, so any testing is appreciated!

If the above works, Can finally clean up unnecessary coding, add some proper error support ect since having multiple protocol support is a bit of a mess around and Iv just been mashing bits and pieces together as Iv been learning. And can finally move onto dynamic PID requests and gets some data from the damn tech2!