I finally broke down and ordered a cable so I can do some logging on my '94 Z28. I've logged it before using a friend's cable and Freescan, but I've never really been impressed with Freescan's capabilities. So, I plan on writing my own scanning software. It shouldn't be a big deal...data in, data out, right? I've done this a few times before with serial driven devices, so I think I have that under control.

Now, on to my questions. Here's a snippet from the data stream specification for my car:
[code]MODE 0 (RETURN TO NORMAL MODE)
ALDL REQUEST:
- MESSAGE ID = $F4
- MESSAGE LENGTH = $56
- MODE NUMBER = $00
- MESSAGE CHECKSUM

ECM RESPONSE:
NORMAL MESSAGES


MODE 1 (TRANSMIT FIXED DATA STREAM MESSAGE 0)
ALDL REQUEST:
- MESSAGE ID = $F4
- MESSAGE LENGTH = $57
- MODE NUMBER = $01
- MESSAGE NUMBER = $00
- CHECKSUM

THE ECM WILL RESPOND WITH THE FOLLOWING MESSAGE:
- MESSAGE ID = $F4
- MESSAGE LENGTH = $92
- MODE NUMBER = $01
- DATA BYTE 1
.
.

- DATA BYTE 60
- CHECKSUM[/code]
I believe that I have to send a "mode 0" message to enable communications with the ECM. Once that's set, I need to send a "mode 1/message 0" message to the ECM to request data, then wait for a response. Once I get a response, I do it over again to get updated parameters. So far, so good. Here are my problems:

1. Say I want to send my "mode 1/message 0" message...I'm thinking that I just have to create a byte array that looks like (0xF4, 0x57, 0x01, 0x00, *something for checksum*), then send it through the serial port. Am I correct?

2. Checksum...how do I calculate it for each message? I haven't found a good explanation yet.

I think that once I get those two questions answered, I'll be good to go. The document I have for the data stream spec describes the returned message, so I shouldn't have any problems with that. I'll be writing this in VB.NET...if I get it working well enough to be useful (realtime display + logging + whatever other crap I throw in), I'll make it available for free if there's interest. Thanks in advance for any help you can offer!

 

Finally found an answer for my checksum problem...
As for my other question...I guess I'll just spit data at the PCM in different formats until it responds. Victory via brute force!

 

I think you can just subtract the result of the sum from 512 to get the checksum. I tried it with two different sets of number from your post and it worked for both. It's a little trick I came up with last night for a test I have tonight. I was working with number conversions, compliments, and various binary representations and it works for what I'm doing for my test rather than messing around with flipping and calculating bits then converting back. Or in the case of the previous arithmetic you posted, having to do modulus division and extra calculations.

I noticed that your check sum is basically just a matter of finding the compliment which is sort of what I made up the trick for.

If the range of the sum is always within 512 and 256 then you'll save a little processing time on the calculations..otherwise if it falls within other ranges too then the necessary equality testing to do it that way would eat up more processing time than the modulus division.

If it's not worthwhile to program it that way you can still use it to calculate in your head quickly. Just find what range the sum is between 512-256-128-64-32-16-8-4-2-1 and subtract it from the next highest number out of that list.

BTW PM me or IM me sometime about this. I'm curious to know how you are doing with this endeavor. I've had some computer programming and I'm in a hardware class right now that works on the motorola 6800 which is very close to what the F-body actually runs.

The checksum is probably just an EDC (error detecting code) and they do it that way because it's super easy to test for error in assembly programming. You just sum all the values and BEQ - branch if zero bit is one. Then it branches off to an algorithm that dumps out all the values.

 

Hi
I’m designing a digital display readout panel to be used with ODB1. This panel is to be mounted in the center console in the compartment used for old audiocassettes in my 94’ Z28. I want to read the data directly from de ECM and send that data to the display and optional to a laptop using a USB/RS232 connection. I have the interface with the car completed, and right now I’m finishing the display part. I have mounted (3) 3 digits seven segments display 2 for MPH and RPM respectively and the other is multifunction. Also and have 4 bar graph displays for oil press etc. And finally a VFD display of 2 lines by 20 characters. I’m want to be able to view has many parameters at the same time, in real-time without a laptop or a scanner.

This is a C function to request a message to the ECM
Check how the cheksum is computed in C.
Note that the checksum is 2 complements
//================================================== ============
// ECM message request
void ecm_msg_req(unsigned char messg)
{
unsigned char ibyte[]={0xF4,0x57,0x01,0x00};
unsigned char chksum=0, i;
ibyte[3]=messg;

do
{
delay(2);
}while(RXD==0);

for (i=0 ; i<4 ; i++)
{
com_putchar (ibyte[i]);
chksum=chksum + ibyte[i];
}
chksum = ~chksum + 1;
com_putchar (chksum);

}
I will like to share ideas with you, or is you want more help you can e-mail me. And anyone involved with embedded microprocessor design can contact me. When I have the device complete I’ going to share photos, is going to be like a litter “Knight Ryder” in the center console jejeje

 

A little update...

I think I have the basics figured out, but I haven't been able to check my work since I don't have my cable yet. I may wander down to my buddy's shop tonight and borrow his cable to see if everything works. I need to finish up my test realtime display form...I've already written some code to log the incoming messages in a separate test app, but it will be easier to test things in realtime.

While I was digging through the archive of data streams I downloaded, I found a data stream used for communicating with the ABS computer. It looks to be one way though, so I don't think that there's going to be a way to cycle it or anything. Not that it matters to me since I ripped out my ABS a while back, but it could be useful for others instead of taking it to the dealer. If I get that stream working, you'll be able to read ABS trouble codes, clear ABS trouble codes, and monitor sensors connected to the ABS controller (voltages, individual wheel speeds, etc).

I'll post up some screenshots and results if I get everything working correctly tonight.

 

"Rise from your grave!"

I finally got around to working on this again...it's been a while, but I've had 10,000 other things to put my attention towards in the past year. Microsoft came out with .NET 2.0 a few months ago, which features managed serial port support instead of relying on crappy third party tools. It makes programming this stuff much, much easier.

I started coding on Sunday and managed to put together a test application that I could use to send raw bytes to the PCM to see how it would respond. After a couple of hours of testing, it was obvious that it wasn't going to work. The PCM would either not respond at all or would respond with garbage. After fiddling with the COM port settings, it turns out that I needed to enable DTR on the port to make it work. After changing my test app, I went back outside, started the car, fired up the application and...success! I had craploads of...something?...scrolling across the screen.

It turns out that "something?" is some sort of fixed chatter that the PCM is always sending out. Had I read this article a little more closely, I would have figured out that I needed to send a mode 8 command to shut it up and then whatever other command I wanted afterwards. Unfortunately, I missed that part. Since I was confused by the chatter, I gave up for the night (probably a good thing since the neighbors absolutely love hearing my car fire up at 11PM).

Now that I've figured out how everything works, I should have better results to post tomorrow. I'd like to at least be able to send each type of request to the PCM and get a response back so I can make sure everything is working properly. I should be able to do that by tonight. Then I need to figure out how I'm going to work around the couple of problems that I forsee.

All of the messages going in and out of the PCM follow a specific format (ID, length, mode, data data data, checksum) except the constant chatter. This really pisses me off since it prevents me from being able to do things the easy way (asynchronous data receives). I can hack around it by doing everything serially and by sending a mode 8 request before each message, but I'm not sure yet how it's going to affect performance. Ideally, I'll be able to pass the data as follows:

Mode 8 message (PCM shut up)
-->PCM response
Mode 1 message 0 (engine, sensors, some MALF codes, etc)
-->PCM response
Mode 1 message 1 (MALF codes, status flags for lots of stuff, some transmission stuff)
-->PCM response
Mode 1 message 2 (diagnostic crap?)
-->PCM response
Mode 1 message 6 (detailed transmission status...pressure modifiers and stuff)
-->PCM response

I'd like to do this 3-4 times per second. Depending on how it performs, I may have to trim some things out of the real-time display and just log them to disk for later viewing. I guess we'll see what happens.

Oh well, enough rambling for now. I'll keep at it this week and keep you all updated on how things are going. Hopefully I can stay focused and finish it up this time around. At least I'm making some kind of progress!

 

Subcribing. Half of the stuff in this thread reads like Hebrew to me but I like where it's going.

 

Most of what comes out of the PCM looks like Hebrew to me too. The spec docs I have do a pretty good job of translating everything though. The main goal of this project is to develop a scan tool that can log anything and everything coming out of the OBD1 PCM (starting with the '94 LT1 auto PCM, adding others later on).

The most important feature I want to add is a playback function for log files...either realtime or frame by frame (with a slider or something). I'm not quite sure how I'm going to implement it yet, but I think it can be done. I'm thinking it will be a great tool for "around town" driving diagnostics...instead of having to stare at the laptop while driving, you can hit the space bar or something when the car does something stupid to set a flag and play it back later to see what was going on. I'm sure I'll think of other stuff to add in as it progresses.

 

I think it's a great idea and I wish you the best of luck. Once youre done you should take orders

 

Right.. something similar to the lt1 scanmaster.... with a better display.. i like IT..

 

The Scanmaster seems very limited to me. There are some things I wish it read but doesnt. Could help so much for troubleshooting.

 

Maybe I'm missing something here but, doesn't datamaster already have all of this?

 

After looking at their spec sheet, yeah, I guess theirs does all of that too. It also costs $120...writing my own is free.

EDIT: Forgot to add my update. I had the PCM talking the other night, so it looks like I'm headed in the right direction. I also determined that the constant chatter does follow the "id,length,data,checksum" pattern, so I'm making some modifications to how the application sends and receives data. Hopefully I'll have the basic stuff down by next week. I'd spend more time on it this week, but I have to take care of some things around the house (like getting my mower running and cutting the grass before the city comes and does it for me). I'll post another update when I make some more progress.

 

That's cool, the time to do that just wouldn't be worth it to me.

Are you going to give yours away for free or sell it when you are done?

 

If it works well enough, I'll give it away. I'd never sell it because then I would have to support it...I do enough of that crap at work and I hate it. I'm not sure how useful it will be first pass since it's only targeting 1994 ODB1 LT1s with an automatic transmission. I need to do some comparisons on other OBD1 LT1 protocols and see if I can come up with an all-encompassing solution, but I'm not sure how easy or difficult that will be.