j1850 3 byte Header format

Hello all... I am really trying to get an understanding of the j1850 protocol but need help. When trying to request the trouble codes, a 3 byte header will be used. And, from what I understand, you are to use physical addressing (not functional). My question is, what goes in the second byte of the header? I thought the first data byte (after the 3 byte header), was the place to send e/e troubleshooting bytes.
TO help me get started, could someone send me an example of what my header and data field will look like when requesting trouble codes?

Basically,

Byte1 = priority (bits 7,6 and 5. 0=high 7=low), addresing mode and other flags,
Byte2 = physical ID of destination, $10 = PCM
Byte3 = physical ID of source, $F1 = off-board tool

Also, I'm moving this to GM VPW section.

Magnus,
I Love ya Man!!! I'd surely by you lunch at your favorite place if I could...

So, I'm looking at j2178 part 4, and it say's that id 10 is "reserved for SAE"... The document say's '94.... Is there a newer document I can get a hold of?

I am also curious, I read in the postings, that GM doesnt do IFR's... If this is the case, will I just complete my frame, then wait (slavingly) until the Bus contacts me at my address [f1]?
Also, what are possibilities of damage to the bus if a voltage of say, 12 volts accidentally get sent on the bus? I've seen spec's with highs of max 8 volts... but then again... that just what it 'says'...

Any luck in finding some updated doc's for J2178?

Michael, I'd love to help you more with your questions but I too am in the dark regarding a lot of the VPW.

Thanks for the gratitude, however I must give credit where credit is due and Paul@EFILive definately deserves the credit for all the VPW knowledge I currently posess. He has been a great contributor on this board regarding VPW.

You have a link to the documents you are looking at? I'm not sure where newer ones are, I really need to get on the web pages and start puting the data up there for all of us to look at.

I believe you just send out a packet to your destination and then wait for one to arrive back with destination being F1 (off-board scan tool).. but don't quote me on that I am learning just as you are.

Welcome to the board btw. :)

Quote:

---

Originally Posted by Michael

So, I'm looking at j2178 part 4, and it say's that id 10 is "reserved for SAE"... The document say's '94.... Is there a newer document I can get a hold of?

---

J2178 Part 4 is only for message types: 0,1,2,8,9,10 and 11.
There are 16 message types defined by bits 3,2,1,0 of the first byte of the 3 byte header.
Each of those message types for J2178-4 is FUNCTIONAL addressing. The only supported destination address for FUNCTIONAL addressing on GM that I know of is $6A - legislated diagnostics.

If you want to send a message to the PCM via a physically addressed message using $10 as the PCM's physical address you'd best use message type 12. ie low 4 bits of byte 1 of 3 byte header should be 1100.
The physical ID's are listed in section 9 of J2178-1
$10..$17 are reserved for engine controllers.
GM normally uses $10.

Regards
Paul

Quote:

---

Originally Posted by Magnus

Michael, I'd love to help you more with your questions but I too am in the dark regarding a lot of the VPW.

Thanks for the gratitude, however I must give credit where credit is due and Paul@EFILive definately deserves the credit for all the VPW knowledge I currently posess. He has been a great contributor on this board regarding VPW.

You have a link to the documents you are looking at? I'm not sure where newer ones are, I really need to get on the web pages and start puting the data up there for all of us to look at.

I believe you just send out a packet to your destination and then wait for one to arrive back with destination being F1 (off-board scan tool).. but don't quote me on that I am learning just as you are.

Welcome to the board btw. :)

---

Thanks for the kudos Magnus - I help where I can.
Good summary of OBD-II comms :) It is pretty much that simple - with a few twists that turned my hair grey - way too early.

If anyone has any questions I'll try my best to answer them - like Magnus I do not have ALL the answers.
And the answers I do have are really only relevant for GM.

Paul

Quote:

---

Originally Posted by Michael

I am also curious, I read in the postings, that GM doesnt do IFR's... If this is the case, will I just complete my frame, then wait (slavingly) until the Bus contacts me at my address [f1]?
Also, what are possibilities of damage to the bus if a voltage of say, 12 volts accidentally get sent on the bus? I've seen spec's with highs of max 8 volts... but then again... that just what it 'says'...

Any luck in finding some updated doc's for J2178?

---

You ared right GM does not use IFR - it's part of the 3 byte header, bit 3=1 means IFR not allowed.

SAE recommends that all circuits connected to the OBDII connector be protected from ALL possible voltages and shorts that can occur by incorrect connections. It's just a recommendation - I wouldn't go testing it out.

my apologies, your right, part 4 is Func addressing...

...the only link I have that's worth a darn is

http://www.diy-efi.org/gmecm/ecm_info/obd2/

It has a lot of stuff, but OLD. (1994). Lord know's I don't want to shell out $140 for the 2002 copy of hs-3000... just for a part timer/hobbiest/shade tree mechanic like myself....

Does this help any?

Functional Messages
===================
Request current value of PID ($00..$20)
Send: $68,$6A,$F1,$01,$PID
Recv: $48,$6B,$10,$41,$PID,[up to 5 data bytes]

Request freeze frame value of PID ($00..$20)
Send: $68,$6A,$F1,$02,$PID
Recv: $48,$6B,$10,$42,$PID,[up to 5 data bytes]

Physical Messages
=================
Request GM VIN
Send: $6C,$10,$F1,$3C,$01,$F2
Recv: $6C,$F1,$10,$7C,$01,$00,$36,$48,$38,$56,$54,$18
Send: $6C,$10,$F1,$3C,$02,$F3
Recv: $6C,$F1,$10,$7C,$02,$4B,$36,$39,$46,$59,$4C,$5E
Send: $6C,$10,$F1,$3C,$03,$F4
Recv: $6C,$F1,$10,$7C,$03,$30,$31,$32,$33,$34,$35,$F6
Vin: 6H8VTK69FYL012345

Request GM PCM#
Send: $6C,$10,$F1,$3C,$04
Recv: $6C,$F1,$10,$7C,$04,$00,$F7,$81,$C2
PCM#: $00F781C2 = 16220610

Request enhanced PID ($0000..$FFFF)
Send: $6C,$10,$F1,$22,$PID-msb,$PID-lsb,$01
Recv: $6C,$F1,$10,$62,$PID-msb,$PID-lsb,[up to 5 data bytes]

Enhanced PIDs $0000..$0020 are identical to generic PIDs ($00..$20).

Regards
Paul

Paul, that info is excellent. Would you mind if I collected some clippings of the posts you've made regarding VPW to help build the GM VPW page on this site?

Quote:

---

Originally Posted by Magnus

Paul, that info is excellent. Would you mind if I collected some clippings of the posts you've made regarding VPW to help build the GM VPW page on this site?

---

That's fine, anything I post here is "free" to be used by anyone, anytime for any purpose.

Warning: I try to post accurately but I have been known to make mistakes... :P

Paul

Thanks for the information... I guess, if one's looks long enough on the internet, the information will come....
I can say, that right now, I have a fair understanding of the [physical address] communication's on the j1850.

I wonder now, how does one (line myself), find out the address assignments. Is there a spec for this? For example, the j2178_p1 says "engine control = 0x10 - 0x17. That's 8 nodes... We know what 10 is (and the functionality is described in spec j2190, but what about the rest of the nodes (and there functionality)?

Someone once tried to point me to the hs-3000 book (not regarding this quition). Well, I have found out that the 99 version of the book has a few spec's dated 94... Is the 2002 version more updated with this information?

O.k... Slowly getting there... So, I understand that you should use mode (or command) 0x22 and request a PID when trying to get actual sensor values, etc... BUT...
Now, I am curious as to how one 'turns off' a cylinder, say for example when doing a cylinder by cylinder check (I forget the catch phrase). I remember seeing a diagnostic tool that could do that. I would imagine that it requires writing a value in PCM memory temperarily, but I can't imagine which one....
Any ideas???

Quote:

---

Originally Posted by Michael

I wonder now, how does one (line myself), find out the address assignments. Is there a spec for this? For example, the j2178_p1 says "engine control = 0x10 - 0x17. That's 8 nodes... We know what 10 is (and the functionality is described in spec j2190, but what about the rest of the nodes (and there functionality)?

---

Just send a supported, but harmless command to each of the 255 possible nodes - like "Stop transmitting diagnostic data" - mode $25.

...
Send: $01,$01,$41,$04,$6C,$10,$F1,$25,$D9
Recv: $01,$01,$C1,$04,$6C,$F1,$10,$65,$99
This means ID $10 exists on the class-2 bus
Send: $01,$01,$41,$04,$6C,$11,$F1,$25,$DA
Recv: No response - ID $11 does not exist.
...

You can then match up the ID's with the ID ranges to figure out which is which.

Communicating with the other nodes is the same as communicating with the PCM - the functionality may be different. But to know all the nodes' functionality you'd need to purchase that information from GM.

Regards
Paul

Quote:

---

Originally Posted by Michael

Now, I am curious as to how one 'turns off' a cylinder, say for example when doing a cylinder by cylinder check (I forget the catch phrase). I remember seeing a diagnostic tool that could do that. I would imagine that it requires writing a value in PCM memory temperarily, but I can't imagine which one....
Any ideas???

---

EFILiveV5 Pro will allow you to perform bidirectional controls including the cylinder balance test. The bi-directional controls are a pre-set list of commands that the PCM will recognise.

We spent many years figuring them out and unfortunately I am contractually bound not to release that information.

I can say the GM bidirectional controls use "manufacturer reserved" J2190 modes to enter bi-directional mode and to send bidirectional commands so unfortunately the HS3000 documents will not help.

Once a bidi control is sent to the PCM it causes the PCM to alter it's behaviour for about 5 seconds. If a keep alive message is not received within those 5 seconds the bidi control times out and is terminated automatically by the PCM.

Sorry for not being as helpful as I'd like to be.
Paul

gOOD onE! Have to buy you lunch too somtime... ;)

I was actually thinking about doing a routine like that, but wasn't sure which "non-aggresive" command to send... You almost lost me for a second, then I realized that the first 4 bytes in your example was probably aimed toward one of your proprietary piece's of equipment. Have any idea how to turn off a cylinder?

fORGET that last question... we send our messages at the same time, and I, not reading yours'...
So... A manu resv'ed command inside j2190 ... hmmmm...
...mode 31 or 38 with an occasional [test device present] mode 3f... and inside the 31 or 38... Some number(s) will give me what I need... Hmmmm... I know, you can't tell me.. but it sure is intruiging... And this is probably a stretch of number's I don't want to sequentially hit, becuase my luck, on of the commands inside the start diagnostics (31 or 38) will be " test # 999 - Destroy engine and never run again while shooting flames out the tail pipe..... "

another question... If I wanted to obtain this information... How would you suggest I go about doing it? Contact GM? SAE? ISO? Reverse engineer it? Move in next door to you, get buddy-buddy, and one night, through a bunch of beer in ya, and get ya to confess? ;>

Well, I've found it... It looks like, if I want the information, I'll have to buy the manufacturer's shop manual (at helm incorporated). The electrical and emissions manual is $45. I am hoping that it will have it in there, becuase j2205
http://www.arb.ca.gov/msprog/obdprog/noticef.pdf
led me there... :-/

Quote:

---

Originally Posted by MICHAEL

gOOD onE! Have to buy you lunch too somtime... ;)

You almost lost me for a second, then I realized that the first 4 bytes in your example was probably aimed toward one of your proprietary piece's of equipment.

---

Yes it's the wrapper bytes and no it's not proprietary. It's for the AutoTap AT1 V1 interface by B&B Electronics
Paul

Quote:

---

Originally Posted by MICHAEL

So... A manu resv'ed command inside j2190 ... hmmmm...
...mode 31 or 38 with an occasional [test device present] mode 3f... and inside the 31 or 38... Some number(s) will give me what I need... Hmmmm... I know, you can't tell me.. but it sure is intruiging... And this is probably a stretch of number's I don't want to sequentially hit, becuase my luck, on of the commands inside the start diagnostics (31 or 38) will be " test # 999 - Destroy engine and never run again while shooting flames out the tail pipe..... "

---

Hmmm, believe it or not there is a "shoot flames out of tailpipe" override command. Set the desired AFR to 0 and run as fast as you can before your cats get covered in unburnt fuel and ignite. I've never actually blown anything up but the potential is there.

Anyway - even though I said J2190 I did not mean one of the documented modes. I just meant the override commands follow the same message format as J2190.

If you look at the HS3000/99 book section 4 of J2190 (on page 140) you'll see a list of Modes.
Modes: $A0..$BF are reserved for manufacturers to use, $E0..$FF are the corresponding reply mode numbers. (i.e. +$40).

Paul

Quote:

---

Originally Posted by michael

another question... If I wanted to obtain this information... How would you suggest I go about doing it? Contact GM? SAE? ISO? Reverse engineer it? Move in next door to you, get buddy-buddy, and one night, through a bunch of beer in ya, and get ya to confess? ;>

---

Reverse engineer it - or find someone or some organisation that can provide that information without compromising a "commercial-in-confidence".

Paul

Quote:

---

Originally Posted by michael

Well, I've found it... It looks like, if I want the information, I'll have to buy the manufacturer's shop manual (at helm incorporated). The electrical and emissions manual is $45. I am hoping that it will have it in there, becuase j2205
http://www.arb.ca.gov/msprog/obdprog/noticef.pdf
led me there... :-/

---

I do not believe GM publish the bi-directional controls - at least I've not seen a published document that describes them.

GM's Tech-II will perform the bi-di controls. You can set up a sniffer to watch the data on the J1850 bus as you send commands from the Tech-II. You can easily see the commands and by sending multiple values you can easily work out the scaling factors.

Regards
Paul

tell me what command in specifc you want......

beyerch,
In general, I am looking for something to allow me to do a cylinder balance test. Either the oem test/command sequence itself, or even simpler, how to disable a single cylinder. either but just turning off the fuel injecter one by one (and writing my own diagnostic routine for the measurements).
I don't know if anyone out there has one to look at, but there is a electrical and emmision's book from
http://www.helminc.com/
(advertised to be 3000 pages of info), that apparently, is the same information that the oem tech's use.

"These are the same manuals your dealer service center uses "

If someone has access to one, perhaps they can tell me if it has this information or not. There is also some other books there that look promising... I just don't want to go buying them and get stuck with this $45 book. And the sales people will only tell you "yep, it's a diagnositc book all right".

I don't know... perhaps this is some information I will never have access too. It's just that I got a little hopefull when I read that notice (in an earlier link), that talked some law's that were passed that says the oem MUST have everthing that they use for diagnostic's, available to the public, at a reasonable rate, etc...
[if someone hasn't read it, it's good reading].
... or maybe i'll go buy a scan tool, and return it after I've reversed eng'ed it.

Quote:

---

Originally Posted by michael

...when I read that notice (in an earlier link), that talked some law's that were passed that says the oem MUST have everthing that they use for diagnostic's, available to the public, at a reasonable rate, etc...

---

I do not know for sure but I believe that legislation only refers to manufacturer specific trouble codes and their descriptions. GM already publish them but some mfgs do not - I believe the legislation is aimed at the mfgs that are not making their enhanced DTCs available to the non-dealer service centers.

However, I hope it covers PID data and it would be even better if it also covered bi-di controls but I'm not holding my breath.

If you have any more info on that legislation please point me to it.

Paul

Does anyone have a quick and dirty formula for CRC calculation? ...to save me the leg work?

Quote:

---

Originally Posted by michael

Does anyone have a quick and dirty formula for CRC calculation? ...to save me the leg work?

---

#define MAX_FRAME_LEN 32 // Max bytes in a frame
typedef unsigned char BYTE;
typedef struct {
BYTE data[MAX_FRAME_LEN];
int length;
int crc;
} Frame_T;

// ------------------------------------------------------------------------
// Purpose:
// Calulates the SAE-J1850 Cyclic Redundancy Check byte (CRC)
//
// Note: The 0x11D constant used in the routine is derived from
// the mandated CRC division polynomial of: x^8+x^4+X^3+X^2+1, which
// corresponds to bit positions 8,4,3,2 and 0.
// Those bit positions form the binary number: 100011101 which is $11D.
// I believe that $1D could be used instead because we are only
// generating an 8-bit CRC. I'm not sure why SAE mandated more than
// 8 bits for the polynomial.
//
// Inputs:
// frame, the frame on which to calculate the crc
//
// Outputs:
// None.
//
// Return value:
// crc: The CRC for the supplied frame.
//
// Warnings:
// This function attempts to simulate the hardware CRC circuitry
// explained as part of the SAE J1850 specification on pages 212
// and 213 of the SAE HS3000 document.
// I believe it is correct, but I haven't proved it to be.

BYTE
crc8(Frame_T *frame)
{
ULONG t_crc;
int f,b;

t_crc = 0xFF;
for ( f=0 ; f<frame->length ; f++ ) {
t_crc ^= frame->data[f];
for ( b=0 ; b<8 ; b++ ) {
if ( (t_crc&0x80)!=0 ) {
t_crc <<= 1;
t_crc ^= 0x11D;
}
else
t_crc <<= 1;
}
}
return (~t_crc)&0xFF;
}

Hey! thanks for the information!!! looks like I owe you aNoTHer lunch... (you trying to break me??? :)

- Well, on another note, I've been scoring the net, news'group's etc... looking for information on the GM diagnostics, and bi-di controls... Equipment and Tool Institute has a member ship for an annual due of $5,000. to get access to this stuff. MAN! I remember reading somewhere, where this stuff was supposed to be available "at a reasonable fee". Geez... They call this reasonable? It looks as if me only course of action now, (if I still want the information), is to go buy a scan/diagnostic tool, reverse-eng it... but... If I buy it, I won't need to make one... and that was my whole point of making one, so I wouldnt have to buy one...
AARRRrrgh@!
I officially give up!
Thanks alot ETI... you money grubing jerk offs. See if I ever offer to buy you people lunch.

Well, last night was my first dry run of my little proto-type, and let me tell you, you WILL need to account for arbitration... (that bus is a busy little bus).
One question though, I asked for trouble codes (6c 10 f1 13 00 00 a8), and it sent me back a "6c f1 10 7f 13 00 00 a8 11 c3 00".
This is my original message, and what I understand to be a reject message and (that's not supported -in 7f response)...
Any idea's? I would imagine that requesting DTC from the "00" (power train) would give me something... or should I request from "ff" (all locations)...

Any idea's?

p.s. I had to get to bed last night or I'd of tried some other commands, and even cut-n-pasted some non-requested bus traffice. But, from what I can remember, it was a bunch of mode 3's and 7's (j1979?), talking in frame type a8 and 88 (function addressing), from addresses at 29,25, and of course our friend 10... but mostly address 29 hammering the bus.
-Closer... Got to tweak the arbitration a little, maybe put in some message filtering, and possible some message retries.

Quote:

---

Originally Posted by michael

One question though, I asked for trouble codes (6c 10 f1 13 00 00 a8), and it sent me back a "6c f1 10 7f 13 00 00 a8 11 c3 00".

---

Welcome to GM's "alternative interpretation" of the SAE J2190 specification. They do not use mode $13 it is not supported. See the $11 at the end of the message right before the checksum? That is the response code. Response codes are listed on page 191 of HS3000/99. $11 is "Mode not supported". (And $12 - which you'll see a lot of is "Sub-function not supported or invalid format" i.e. the data supplied for the particular mode is wrong.)

Check out the SAE J1979 mode $18 message format but use $19 instead of $18 as the mode.

Quote:

---

Originally Posted by michael

But, from what I can remember, it was a bunch of mode 3's and 7's (j1979?), talking in frame type a8 and 88 (function addressing), from addresses at 29,25, and of course our friend 10... but mostly address 29 hammering the bus.
-Closer... Got to tweak the arbitration a little, maybe put in some message filtering, and possible some message retries.

---

Yep, bus is busy. Your hardware should implement bit arbitration and your software should follow this for retries:

If no response is received from the vehicle:

1. First resend the original request.
2. If still no response, send a mode $01, PID $00 command to determine if the vehicle is still responding. All vehicles "should" respond to that command.
3. If mode $01 PID $00 is successfuly transmit some other command that can determine if the original message should in fact be supported.
4. If still no response then indicate loss of comms with vehicle.

Regards
Paul

o.K... So, for mode 0 pid 0, the entire command would be " 6c 10 f1 01 00 xx(crc)"? No filler bytes or anything?
I'm asking becuase I don't have access to the j1979 spec, just the j2190 and j1978 p1, 2 and 4, and j1850.

This will come in handy becuase I have already experienced some undesired behaivor between me and the sytem. Those responses I told you about happened only a few times... the rest of the time, I was just ignored... So, today, I tweaked a micro-second here and there, did some wave shaping... and I'm about 2 hours away from trying it again...

Quote:

---

Originally Posted by michael

o.K... So, for mode 0 pid 0, the entire command would be " 6c 10 f1 01 00 xx(crc)"? No filler bytes or anything?

---

Ignoring the wrapper bytes this is the mode $01 PID $00 command and response on an LS1:

17:54:06.576: Send: $01,$01,$40,$05,$68,$6A,$F1,$01,$00,$0B
17:54:06.616: Recv: $01,$01,$C0,$09,$48,$6B,$10,$41,$00,$BF,$BF,$F9,$9 0,$D6

The response bytes of interest are:

$BF,$BF,$F9,90 which make up 32 bit flags:

bit 1 = PID supported
bit 0 = PID not supported

the first byte's most significant bit is PID $20
...
the last byte's least significant bit is PID $01

If you want some info on J1979 download the EFILiveV6 developer's API from the Starr Performance web site.
You won't bea ble to use it wouthout the appropriate hardware but there is a config file called sae_generic.txt which has most of the useful information about J1979 in it.
i.e. PID numbers, ranges, definitions, display formats etc.

Regards
Paul

AAARRRRggghhh (-magnus, I lost my message again, I guess that's what I get for not being a member)....

ANyway... what I was saying was,
here is some traffic on the bus that I tried to decipher, but can't. I can only imagine that they might be the vehicle speed status talking to the wheel's and the brakes...(status's are talking to status's?) Also, the data bytes are also confusing, becuaes I can't seem to match them up in J2178 part 4. Here they are;

95 ff 29 03 f0 d9
88 25 29 07 06 d9 20
c8 ff 10 03 f9 d9
88 33 29 03 10 d9

It appears as thought I'm catching traffice o.k... just can't understand it... (yet)...

More tweaking today... try it again tonight...

Michael, best thing I can recomend is for you to register. I'm not sure if its possible or even how hard it would be to modify the perl source to cash the text box entries.. I don't think it's even possible beause the way the board works, there are no "cached" pages so when you do click back a new one is generated... i think. lol

so just register. :) What's stopping you?

O.k... Now I need help... the other day, when I got those responses (told me my request's were unsupported), for some reason was the ONLY time I have ever gotten a response...
I've got great edges, high's and lows are 0 - 7.8v volts, short's and longs are 64 and 128 (with 2 uS window of error). SOF's are great too. I've even walked the entire message through on a digital scope... Yet, anything I send on the bus is not responded to. I can watch traffic all day long, and when I make another little prototype, I can talk all day long between the two them... But just can't get a response from my GM.

I noticed, that for some reason, the crc is not being placed on the messages I'm seeing on the bus (see my previous post)... Am I not supposed to either?

... I've waited from 300 uS, to up to 500mS before sending request... but, no more response.
I've even gone as far as placing a scope on the bus (while trying to talk to the vehicle) and my traffic looks the very same as the other traffic.

a few various commands I've tried (including crc);

6c 10 f1 13 00 00 a8
68 6a f1 01 00 17
6c 10 f1 10 2e
6c 10 f1 11 33

I'm pretty sure my CRC is o.k. (someone double check)?
just can't figure it out why it was talking to me the other day... but not now. I'm at an impass.

any idea's???

Physical Messages
=================
I did notice, that back on page one, you gave some examples for VIN...
"
Request GM VIN
Send: $6C,$10,$F1,$3C,$01,$F2
Send: $6C,$10,$F1,$3C,$02,$F3
Send: $6C,$10,$F1,$3C,$03,$F4
Vin: 6H8VTK69FYL012345
"
When I use these commands, I do not get the same CRC. Is this CRC between the tester and the computer? (and for explanation purposes, you stripped off the extra 'proprietary' bytes for your type obd tool?)
If this is the case, then I'm guessing that between the tool and the vehicle, the CRC is re-created in the tool before sending out to the vehicle....???

-troubled.

Dis-regard...
I found the fault... I walked through the bit's again, and 'this' time, I went passed the last byte where the EOF should be... but, instead I found an extra byte...
Turn's out that my for loop had a >= instead of just a >.
Went out to the truck at lunch time and was passed info back and forth... I'm sure I'll be back here tommorow (after banging on it tonight), with some fancy quistions...
Sorry for the false alarm...

you are having WAY too much fun!!
Good info though....