OBD VIN format

sonicmule · 07-13-2009, 12:11 PM

Hi there

A quick question about the VIN format returned from PID 0902.
I've decoded the vin ok until the last three bytes which are not ascii codes.

The last 6 numbers in the vin are 623364 and in the response from the ecu, the data also is 62 33 64 so no conversion is needed.

Is there some sort of rule that states take the following bytes as numbers when you find a byte over the ascii value of 'Z' ?

p2psmurf · 07-13-2009, 12:57 PM

All 17 bytes of the Vin should have been send as ASCII characters, in your case:
36 32 33 33 36 34. So, the answer is non-compliant.

Just curious: what car is this (make, model, engine, model year) and where are you located (Usa, Europe, somewhere else).

sonicmule · 07-13-2009, 02:31 PM

The car is an MG ZS 180 2.5 litre V6 manufactured in 2004 with a Siemens ECU.

The ecu responds with EOBD from a 01 1C request.

It seems very strange why the last few numbers have been coded this way as the the VIN is 17 digits like all other VIN numbers

p2psmurf · 07-13-2009, 03:52 PM

Software is written by programmers, who are human and make mistakes.
This is not the first bug and it won't be the last either.

sonicmule · 07-13-2009, 04:59 PM

Ha haaaa! After the dealings I have with Siemens at work, why doesn't this surprise me LOL

Vitaliy · 07-13-2009, 08:41 PM

Quote: Originally Posted by sonicmule

Hi there

A quick question about the VIN format returned from PID 0902.
I've decoded the vin ok until the last three bytes which are not ascii codes.

The last 6 numbers in the vin are 623364 and in the response from the ecu, the data also is 62 33 64 so no conversion is needed.

Is there some sort of rule that states take the following bytes as numbers when you find a byte over the ascii value of 'Z' ?

What scan tool and software do you use to get the VIN? Can you post the complete response?

Vitaliy

Vitaliy · 07-13-2009, 08:51 PM

Quote: Originally Posted by p2psmurf

Software is written by programmers, who are human and make mistakes.
This is not the first bug and it won't be the last either.

I strongly doubt that this is a bug in the ECU firmware.

Vitaliy

malcom2073 · 07-13-2009, 09:25 PM

Quote: Originally Posted by Vitaliy

I strongly doubt that this is a bug in the ECU firmware.

Vitaliy

But it could very likely be a bug in the scantool, especially if it's an ELM knockoff.

sonicmule · 07-14-2009, 03:59 AM

The scantool is a OBKey bluetooth dongle, wasn't a cheepo ebay thing

Here's the response from the VIN enquiry

49 02 01 00 00 00 53 65 48 6B 13 49 02 02 41 52 52 54 4C 48 6B 13 49 02 03 4C 57 4C 46 49 48 6B 13 49 02 04 34 44 62 33 22 48 6B 13 49 02 05 64 00 00 00

p2psmurf · 07-14-2009, 05:21 AM

You never know with interfaces, but this looks an ecu problem to me.
Could be a problem in the ecu firmware when sending the Vin-number or the Vin-number was incorrectly programmed by a scanner - with no complaints from the ecu firmware.

sonicmule · 07-14-2009, 05:45 AM

Should the response come back in one go?
I'm sure I read something saying you have to send a couple of bytes to receive the next block of data?

michbound · 07-14-2009, 10:01 AM

Quote: Originally Posted by sonicmule

Should the response come back in one go?
I'm sure I read something saying you have to send a couple of bytes to receive the next block of data?

Yeah the response should come back as 5 lines of data, if this is CAN you can send flow control to request next block but for the rest of the protocols that is not needed.

It does look like the ECU is buggy should be returning with ASCII chars

Thanks
Paul
OBDPros scantool

Aberk · 07-14-2009, 01:58 PM

Quote: Originally Posted by sonicmule

Hi there

A quick question about the VIN format returned from PID 0902.
I've decoded the vin ok until the last three bytes which are not ascii codes.

The last 6 numbers in the vin are 623364 and in the response from the ecu, the data also is 62 33 64 so no conversion is needed.

Is there some sort of rule that states take the following bytes as numbers when you find a byte over the ascii value of 'Z' ?

That would be incorrect. You should have seen 36 32 33 33 36 34 in the data fields as the last digits for your VIN.

I have seen a CAN 11 500 2004 Ford F-350 with 6.0L diesel respond with nearly all FF in the VIN data fields. So it is possible that it is an ECU issue.

Vitaliy · 07-15-2009, 03:06 AM

Quote: Originally Posted by sonicmule

The scantool is a OBKey bluetooth dongle, wasn't a cheepo ebay thing

Here's the response from the VIN enquiry

49 02 01 00 00 00 53 65 48 6B 13 49 02 02 41 52 52 54 4C 48 6B 13 49 02 03 4C 57 4C 46 49 48 6B 13 49 02 04 34 44 62 33 22 48 6B 13 49 02 05 64 00 00 00

If we try to make sense of it, we get:

49 02 01 00 00 00 53 65
48 6B 13 49 02 02 41 52 52 54 4C
48 6B 13 49 02 03 4C 57 4C 46 49
48 6B 13 49 02 04 34 44 62 33 22
48 6B 13 49 02 05 64 00 00 00

So from the headers we know that the protocol is either ISO9141-2 or J1850 VPW. The ECU address is $13, and for some reason the header of the first message is missing. Another thing to pay attention to, is that the last three bytes are zeroes, which should not happen with a VIN. The standard says "Message #5 shall contain VIN characters #14 to #17 inclusive".

The actual VIN payload is:

53 41 52 52 54 4C 57 4C 46 34 44 62 33 64 00 00 00

Which translates as:

SARRTLWLF4Db3d????

Weird. I would get a second opinion, using another scan tool.

Vitaliy

sinclairvital · 07-16-2009, 03:50 PM

Thanks Vitaliy. You got the formatting right there. It does look like the VIN wasn't set correctly inside the ECU.

Another example with OBDKey 1.10k (not VIN in this example)
13:05[8mS]>Tx:0904
13:06[477mS]>Rx:0904
49 04 01 30 36 41 39 F1 48 6B 10 49 04 02 30 36 30 33 DB 48 6B 10 49 04 03 32 54 4C 20 05 48 6B 10 49 04 04 30 30 34 30

Note how OBDKey 1.10K presents the ISO multiple frame responses as a single line. This is the same if multiple responses are received from ECU’s responding to the same command.

What has happened is that the checksum from the first frame is presented and so are the three header bytes from the next frame, except in the last frame received where the checksum/CRC is stripped out.
49 04 01 30 36 41 39 F1 48 6B 10 49 04 02 30 36 30 33 DB 48 6B 10 49 04 03 32 54 4C 20 05 48 6B 10 49 04 04 30 30 34 30
As the frame lengths are static it should be simple to skip the header bytes for multiple frame responses from single ECU’s. In the case of multiple ECU responses, all the responding ECU addresses can be acquired with headers on.

For a VIN example:

13:39:41: (@18.109s)Sending {0902}, attempt #0

Quote:

0:9:0:2:0D:0A:
4:9: :0:2: :0:1: :0:0: :0:0: :0:0: :5:7: :6:8: :4:8: :6:B: :1:2: :4:9: :0:2: :0:2: :4:2: :4:1: :4:2: :4:4: :1:B: :4:8: :6:B: :1:2: :4:9: :0:2: :0:3: :3:5: :3:2: :3:0: :3:5:

:F: :4:8: :6:B: :1:2: :4:9: :0:2: :0:4: :3:0: :5:0: :4

: :3:0: :1:1: :4:8: :6:B: :1:2: :4:9: :0:2: :0:5: :3:9: :3:4: :3:3: :3:1: :0D:
0A:>:

Would be interpreted as

13:39:42: (@19.359s)WBABD52050PM09431
Any guesses which car this was??

I hope this helps.

Sinclair
KBM Systems.