j1850 3 byte Header format

[verret]

As before I have the following hex code that is being sent to my car via my remote car starter. This code is for opening my doors, before I was decoding it incorrectly here is my new theory:

88 C7 A2 30 11 55 AA C4

When I start decoding this transmission I get stuck.

88: Priority of 4, 3 byte header, no IFR, Functional Addressing...

C7: according to J2178-4, C7=External Access on p. 369 of the HS-3000 and page 41 of the J2178-4 document found on a website given earlier on this board.

Also of note is that the W-bit is a 1.

A2: Source of transmission (Convenience - doors, seats, etc.) p261

30: is the secondary address byte or in binary 00110000, Q-bit = 0, C-bit = 0 thus, WC = 10 -> report status

bits(5-0): 11000 or 0x30 which isn't in the book :-(

I stopped decoding the signal here... I didn't bother getting into the 11 55 AA

C4 is the CRC and I have verified that is correct.

What I believe it does is the following: It unlocks all doors and disarms the factory alarm.

Thanks

[Fred Macall]

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 [sic] 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

Thank you very much for that information, Paul!

I have been trying to read the DTCs from my '97 GM Chevrolet
Malibu's Electronic Brake Control Module and Body Function
Controller. I was stuck until I saw your suggestion about
using mode $19 with J2190 (physical addressing). Mode $19
does give me the DTCs from my EBCM! I am still getting a
$7F response, to a mode $19 request, from my BFC, however.
Does it need mode $20, or something?

(Having said that, I almost want to go out to the car and
give mode $20 a try! Actually, I am going to read through
the rest of this thread first.)

Fred Macall

[Fred Macall]

Ah, the one after $19 is $1A, of course. Not $20. Now, I'm
thinking about going out to the car to try $1A. After I
finish reading this thread!

[Matrixx]

Hello !!


I'm new to the forum. I have been reading all the post, and I'm really interested into build a J1850VPW on-board lcd for my car. I get this idea on my head for about 3 years but I just started with it this week. I have read from Paul for his excelent EFILive work.

I started yesterday night to grab some chatter from my car with a DSO.

I was able to decode by hand the printed pattern. I find there is many activity with the ignition switch at "ACC" position!

one of the misterious packets is:

$E8 $FF $40 $03 $ED

As I read from this forum, I have been looking for the SAE HS-3000 document for download but haven't had luck yet.

Does someone have decoded this messages..? I still need to parctice with the "normal" diagnostics messages.

The plan is to use BascomAvr and Atmel M2560 to do the project.

[LSX378]

Hello !!


I'm new to the forum. I have been reading all the post, and I'm really interested into build a J1850VPW on-board lcd for my car. I get this idea on my head for about 3 years but I just started with it this week. I have read from Paul for his excelent EFILive work.

I started yesterday night to grab some chatter from my car with a DSO.

I was able to decode by hand the printed pattern. I find there is many activity with the ignition switch at "ACC" position!

one of the misterious packets is:

$E8 $FF $40 $03 $ED

As I read from this forum, I have been looking for the SAE HS-3000 document for download but haven't had luck yet.

Does someone have decoded this messages..? I still need to parctice with the "normal" diagnostics messages.

The plan is to use BascomAvr and Atmel M2560 to do the project.

Any source node address? Or is the $03ED?

[Matrixx]

hmm.. don't know. I just "spy" the bus, still hav't interact with. this packet loks to repeat every certain time.

I think I need to study a bit more :P

[LSX378]

hmm.. don't know. I just "spy" the bus, still hav't interact with. this packet loks to repeat every certain time.

I think I need to study a bit more :P

What type of car? There are normally dozens of messages with many different source addresses. Even with Acc on.

Unlikely to find any exact info on these in an SAE doc apart from the basic ranges as they are OEM specific generally.

[Matrixx]

Thanks for get my question,

car is a Grand Am 1999 3.4L

It has a LS1 ECM I guess.

I spent this night reading again over this post and I'm now understand more the 3 byte header format. I learned today about physicall and functional.

I'll get back with more understanding of what I'm asking before ask

[Matrixx]

I finally make the idea to work. I have coded a simple routine to listen the J1850VPW bus. I'm used the Atmega2560 module and after some tweak in the timings it works nice.

I tested it with a workbench Junk (but good) PCM. It is same as one in my car.

The output from my interface with the PCM alone shows this:

J1850VPW 1.34

48 EA 10 0A 00 72
E8 FF 10 03 B3
48 EA 10 0A 00 72
49 92 10 01 BE
49 92 10 01 BE
48 EA 10 0A 00 72
49 92 10 01 BE
48 EA 10 0A 00 72
E8 FF 10 03 B3
49 92 10 01 BE
48 EA 10 0A 00 72
49 92 10 01 BE
48 EA 10 0A 00 72
49 92 10 01 BE
E8 FF 10 03 B3
48 EA 10 0A 00 72
49 92 10 01 BE
48 EA 10 0A 00 72
49 92 10 01 BE
48 EA 10 0A 00 72
E8 FF 10 03 B3
48 EA 10 0A 00 72
after this line it keeps sending this same packet every second.
E8 FF 10 03 B3
E8 FF 10 03 B3
E8 FF 10 03 B3
E8 FF 10 03 B3

Now I will add verbose decode for the header byte. I'm still looking for HS3000 document.

[LSX378]

I finally make the idea to work. I have coded a simple routine to listen the J1850VPW bus. I'm used the Atmega2560 module and after some tweak in the timings it works nice.

I tested it with a workbench Junk (but good) PCM. It is same as one in my car.

The output from my interface with the PCM alone shows this:

Now I will add verbose decode for the header byte. I'm still looking for HS3000 document.

Congratulations on getting this out of a 2560. What input did you use?

[Matrixx]

Tnx!

I had no time to build the complete input/output conditioner but as preliminary input used just a voltage divisor, as I only listen to the bus.


J1850-------/\/\/\/------- 2560 PINF.0 --------/\/\/\/\------GND

Bus side R=5.6K, GND side R=10K
I used M2560 PinF.0 as it has screw terminals on my module.


Yesterday midnight I sampled data from the car, as there are other modules present I get a lot of messages... I need to make the complete I/O to start talking to the nodes.

Also I noticed sometimes my interface did not separate the frames well, but still do not lose bytes. I think I need to shorten the EOF timeout.

[LSX378]

Tnx!

I had no time to build the complete input/output conditioner but as preliminary input used just a voltage divisor, as I only listen to the bus.


J1850-------/\/\/\/------- 2560 PINF.0 --------/\/\/\/\------GND

Bus side R=5.6K, GND side R=10K
I used M2560 PinF.0 as it has screw terminals on my module.


Yesterday midnight I sampled data from the car, as there are other modules present I get a lot of messages... I need to make the complete I/O to start talking to the nodes.

Also I noticed sometimes my interface did not separate the frames well, but still do not lose bytes. I think I need to shorten the EOF timeout.

Cool. Simple and effective. Did you use F0 in digital or ADC mode?

[Matrixx]

F.0 is configured as digital input.

Take a look at the code

is a rar file, remove the .bin extension.


I'm learning OBDII. I have the project uploaded to:
http://www.diyprojects.zobyhost.com/

[LSX378]

F.0 is configured as digital input.

Take a look at the code

is a rar file, remove the .bin extension.


I'm learning OBDII. I have the project uploaded to:
http://www.diyprojects.zobyhost.com/

Great work there! A straigtforward and simple approach that works! .

[Matrixx]

BTW, wich wil be the command to clear BCM trouble codes...?
BCM is class2 OBDII J1850vpw

I have tried service $04 but it only clears the PCM codes.

My BCm has some trouble codes due to electrical failures.

[LSX378]

BTW, wich wil be the command to clear BCM trouble codes...?
BCM is class2 OBDII J1850vpw

I have tried service $04 but it only clears the PCM codes.

My BCm has some trouble codes due to electrical failures.

You may need to address the BCM node explicitly. i.e. engine ECU is $10, trans module if installed $18 for example.

[Matrixx]

But as I know mode $04 is Functional, so how I will address BCM (mine is $40)...?

Should I use service $14 ?

$14 $80 $00

5.6 Mode $14—Clear Diagnostic Information
5.6.1 FUNCTIONAL DESCRIPTION—The purpose of this mode is to provide a means for the external test device to
command on-board modules to clear all diagnostic information. This information includes primarily
diagnostic trouble codes, but can also include freeze frame data or other on-board test results that may be
stored as a result of the trouble code being set. This extra information is device dependent.
There are three ways this mode can be used. If only the test mode value is included in the request, then all
diagnostic information stored in the module is to be cleared.
Diagnostic information can optionally be cleared by function (Powertrain, Chassis, or Body) by sending
P0000, C0000, or B0000 as data bytes 2 and 3. These must be encoded using the same convention as
when codes are reported (see description for Mode $13). The first two bits of the first nibble are:
00 - powertrain
01 - chassis
10 - body
11 - undefined
This translates to the following values for data bytes #2 and #3:
$00 00 - powertrain codes
$40 00 - chassis codes
$80 00 - body codes
$C0 00 - undefined

[Keith@HPTuners]

When you send a functional message, you do not supply a destination. Functional messages are broadcast and all nodes can respond, if they have a response to send.

[Matrixx]

There is the problem, sending mode $04 does not clear my BCM codes, only PCM.

When get trouble codes again, the BCM codes are there, the same ones without start the vehicle.

[Keith@HPTuners]

Whats the complete packet you're sending?