Yes it's the wrapper bytes and no it's not proprietary. It's for the AutoTap AT1 V1 interface by B&B ElectronicsOriginally 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.
Paul
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
Reverse engineer it - or find someone or some organisation that can provide that information without compromising a "commercial-in-confidence".
Paul
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.
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?
#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.
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.
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...
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?
We got this guy Not Sure, ...
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....
Business Network Solutions - for all your PC, network, printer and computer security needs.
Reply With Quote