It doesn't. None of it does. Stop paying attention to it. Same with the schematic you're about to post in the next post--it's all a waste of time, energy, effort, etc. All the 160 baud stuff is completely irrelevant to the CCM-based Corvettes. Just forget about it. And if you see it mentioned in your research, realize that it doesn't apply to what you're trying to do, ignore it and move on.

Sort of. In that you only have a single communication channel and if multiple devices try to talk at once the message is lost, yes. In that there's a clear way to demand a direction, no.

If you short the serial line to ground, it'll pull the serial data low, which will probably cause the serial data line to go dead as long as it's shorted to ground. There should be sufficient protection to prevent any sort of cataclysm from happening if this happens, but I wouldn't try to test that theory. However, jacking +12V into the +5V TTL serial data line will probably cause magic smoke to come out, so definitely do not try that.

As the +12V is a requirement of the OBD2 standard, the 94-96 Corvette ALDL connector has +12V on pin 16. For the earlier CCM cars (pre-94), you are correct that there is no +12V pin (though there is a fuel pump +V connector on pin G).

"Synching the datastream" is just making sure that you're at the correct baud rate and data setting. If you are, then your analyzer will correctly interpret the change in voltage levels that it's detecting on the serial data line. Remember, that's all this is--just voltage going from 0V to 5V in a specific pattern which can then be interpreted by a logic analyzer as hex data.

Don't look at me, I didn't design it. I assumed it would need a ground to the car as well, but it very much does not. Arduino, no clue, because I have a real logic analyzer so I've never tried to use an Arduino as one. But again, you need to remember that a lot of the research you're doing is both horribly wrong (the 160/8192 baud stuff) and misdirected (thinking you need to know command structure). You do not need to send any commands. There's no need to have flow control. You're literally just attaching a device to the serial data line that's watching the line go from low to high, and then turning that data back into hex for you to analyze. There's no active components, no ALDL mode requests, nothing. It's all passive.

Again, all of your "research" that's on the 160 baud stuff is nonsense and needs to be thrown out, forgotten about, and never touched again--at least for the purposes of this thread, which is about ECM-CCM comms. If you want to do research into how to perform similar tricks with pre-CCM cars using their 160/8192 ECM interface, then by all means; but this thread is about the CCM, which doesn't use any of that. It's completely and utterly different and until you figure that out you'll be spinning your wheels wasting time on things that won't get you to your goal. Please understand.

 

I think you may be too quick to condemn the resources I posted. In particular, the page with the first wiring diagram explicitly states that it works for both the newer 8192 system and the older 160 system:
My bluetooth ALDL adapter works for both as well.

Do you have any source I could look at explaining the difference between "early" and "late" 8192? Repeating "160 baud is irrelevant" is not helping me - what would help is knowing why it is irrelevant, and which aspects are different between a 160 baud system operating in 8192 mode and a newer 8192 system. Nothing I read even acknowledges that there's a difference between the two, and a lot of things just say "this is for GM 8192 baud". Without understanding the difference between the two, I can't filter out irrelevant information.

I know much of my research is beyond the scope of what I'm trying to do here, but A) I can't afford to risk damaging something and B) if I ultimately make an interface box, I will need more functionality than a passive sniffer.

That's bizarre that your logic analyzer works with just one lead connected. That totally defies my knowledge of circuits; I'd be really interested if someone knows how that works. Not to get too off topic.

Edit: New roadblock. The Uno only has one UART, which means its RX and TX pins are one and the same as the RX and TX on its USB port. If I hooked this up as planned, it would be the same as just connecting my laptop's USB port directly to the ALDL serial line. I think I can read serial data over digital pins though.

 

It worked! Unfortunately I wasn't able to get any driving data, as I'm snowed in.

I'll post the sketch and data in a bit.

Edit: Collapsed some of my rumination. However, there's a little worthwhile info in here.

• What's the minimum message length? Would it be four bytes? [Device ID] [message length] [mode] [checksum]
• Do $8D ALDL messages all have a checksum? Edit: Yes, it appears they do. However, I see some three-byte messages that have no mode byte.
• Why is it necessary to silence everything to read the diagnostic datastream? If each message is prefixed by a device ID, couldn't you just filter out the stuff you don't need? Or is the issue that the other devices on the bus are trying to talk over the DDS?

I finished my script to format the serial data. It's very simple, but I'll share it eventually. I ran all of my serial data through my script, and everything was able to be broken down into messages with the IDs:

• F0: "CCM ALDL device presence check"?
• F1: CCM
• F4: ECM
• 10: Broadcast?
• 40: ?
• 41: ?

Furthermore, the checksums work out for each message as I've broken it down. It's a "ones complement" checksum, meaning that you add all of the bytes together with the checksum, and the number you get should end in "00".
As far as I can tell, the datastream consists of four repeated messages. The values shown were with the engine off.The first three continually repeat in sequence (although it could be any even permutation of the three, such as 41 -> 40 -> 10), and the fourth appears exactly every 16 lines.It's possible some other messages were in there, but I was just eyeballing it. Maybe I'll have my script find all unique lines.

The question is - what are devices $40 and $41? At first I assumed they were not the ECM or CCM, but now I doubt that. There isn't a single message from $F1. Maybe I have that ID wrong. Didn't @Nomake Wan say the CCM is the traffic cop of the serial bus? If that's the case, its ID must not be $F1.

I found a page talking about ALDL on a car with a BCM. I'm not sure how relevant it is, but it contains the following list (originally from Moates I think?):
I previously understood that the ID byte indicated which device the message was for. Now I'm not so sure. I need to read up.

The datastream definition says that $10 is some sort of broadcast, so perhaps $40 is the CCM requesting an update, and $10 is the ECM responding?

 

I don't have a source for you. The earlier systems do not use the same communication and require different circuitry in the adapter (for example, the 10kohm switch) to get certain devices to talk properly. The later CCM ALDL requires no such fancy circuitry to properly communicate, and does so at native 8192 ALDL. It's just plain not worth expending effort on anything derived from the earlier 160 baud system. I tried that when I first started out last year and knew nothing, and got nowhere. Then I switched to just dealing with the modern stuff and it worked out peachy keen. Your prebuilt ALDL interface devices likely have extra circuitry inside to be able to deal with every possible ALDL connection. So from where I'm sitting, it's not worth it to me to waste time there. But like I said, if you're curious and want to develop similar tech for the pre-CCM cars, then go nuts.

1. There is no delimiting byte.
2. The minimum message length is exactly what you thought--four bytes. Specifically, a message like "F9 56 00 [checksum]," which is a Mode 0 "return to normal" request for the ABS. As defined in the datastream definitions.
3. All messages have a checksum. If you are missing mode bytes, I would suspect your analyzer having a bug or missing a message byte. It's a noisy bus!
4. It's necessary to silence the bus before getting diagnostics because the ECM/PCM is not the bus master. So to request that the ECM/PCM send you diagnostic data (Mode 1 request), you first need to tell the CCM to shut the hell up (mode 8) in order to become the new bus master and issue a Mode 1 request to the ECM/PCM. Same with getting diagnostic data from the ABS computer or any other slave device on the bus.
5. According to my FSM for 1994, the devices on the 8192 baud serial data line are the CCM (bus master), ECM/PCM, ABS/ASR, C68 Climate Control (if equipped), and airbag module. The PKE module, radio module, and FX3 modules are on separate pins (for 94-96, that's pin 8, pin 14, and pin 3, respectively).
6. The CCM is indeed the "traffic cop" of the bus. It is the bus master. All serial data communication flows between the CCM and the other modules on the bus. This is also why the 'paperclip' method works; you're essentially flipping a switch in the CCM that says, "Hey, go ahead and tell the other devices to do a mode 1 fault code report. Then I'll process them and put them up on the dash. And if the user wants to reset a code on a module I'll send that module a Mode 10." The CCM is, quite literally, acting like a Tech 2 when in diagnostic mode.
7. Much like 160 baud, the BCM stuff is completely and utterly irrelevant to a Corvette. Ignore it.
8. The ID byte tells you which device the message relates to. It doesn't indicate the sender or recipient. For example, when the CCM is in diagnostic mode and you request codes for the ABS module, the CCM will send a Mode 1 request with the F9 ID byte. The ABS module will then respond with the requested data also with the F9 ID byte. This is another reason why you have to tell the CCM to shut the hell up if you want to command other modules yourself; because otherwise the CCM will talk over you.

 

It seems unlikely that it would be a bug or a dropped byte. In thousands of transmissions, I can find nothing other than "$40 55 6B". The length byte says it is three bytes long, and the checksum adds up. It would take a hell of a coincidence for that to be an accident.
Edit: Here is the only info I can find on "40 55 6B":
Oh, also refer to the A111 datastream definition. Not all messages have a mode byte (in the case of $10 detailed below).

Which section was that in? I was digging through my FSM and couldn't find any info like that. Of course, mine isn't necessarily laid out the same as yours, but I can hope.

While it's not necessarily the same as my car, I see enough consistency between various GM protocols that I think it's worth use as reference (albeit with the caveat that it's not gospel).

Hmm, interesting. Would every request for data have Mode 1, 2, or 3?
Isn't Mode 1 the entire diagnostic datastream? Or does the F9 ID + the Mode 1 cause the ABS to release its DDS, whereas the ECM would need Mode 1 + a different ID?

I'm going to attempt to decode $10 59 08 39 00 00 56.
0x10 and 0x59 are ID and length obviously.
A111 says the next byte is the status word. 0x08 is 00001000, so all bits are zero except bit 4. That indicates that the dash is set to English units, the engine is an L98, and the AC clutch is off. The remaining five bits are "spare". Curious that one of the spare bits would be set to one.
After that comes coolant temp. "Deg C = N*.75 - 40," so 0x39 = 57, and 57*.75 - 40 = 2.75 °C. That's 36 °F, which is spot on. Just for fun, it was 0x49 at the end of my serial log. That's 15 °C = 59 °F. Seems reasonable.
Next is engine RPM. "RPM = N*25." My engine wasn't running, so 0 RPM is correct. The end of the log showed 0x25, which is 925 RPM. Perfect.
Then vehicle speed. "MPH = N." Can't really test this one without moving, but it was 0 throughout the log.
Last, the checksum.

The definition file also shows $F0 56 F1 as "CCM ALDL DEVICE PRESENCE CHECK." Possibly something to interact with a Tech 2? Or maybe it's something obvious.

That's a nice sanity check.

That leaves just two lines to be decoded.Since $40 55 6B is constant, I have to assume the $41 line encodes the MPG info. Here's a line from the end of the log. Note that only two bytes are 00 in both.I'll have to go for a drive and see if either byte changes with fuel economy. Edit: per previous discussion, it's more likely that the components needed to calculate economy are transmitted rather than the final value.

 

Second book, section 8A (Electrical Diagnosis), page 50 (Data Link Connector).

If it's a request for data, I would assume it would need to be one of those modes, yes. I don't think it's possible to request data without a Mode 1 (request diagnostic data), Mode 2 (request 64-byte chunk) or Mode 3 (request specific 8 bytes) request.

You are correct that the F9 [Mode 1] specifically tells the ABS to send a diagnostic datastream in response. And that if you wanted a diagnostic datastream from the ECM, you'd need F4 [Mode 1] instead. But also that you must be the bus master in order to send those requests because otherwise the CCM will talk over you.

 

Thanks! For those interested, for my '90 it was on 8A-50-2.

It looks like the CCM has two serial data lines, but they tie together. I'm thinking these must be RX and TX, and they combine because it's a half-duplex system. The serial bus connects to:

• ALDL connector pin M
• Heater and A/C programmer - electronic AC only (C68)
  • C68 has the ability to display engine parameters, such as RPM or CTS. I wonder what this communication looks like? Perhaps logging it would shed some light on things. It occurred to me that this is one more functionality that a standalone would lose. I'm not worried because it's so hidden, and a standalone provides much nicer datalogging, but just a note.
• Electronic brake control module
  • Interestingly, this one only shows one pin, whereas everything else displays both RX and TX. Perhaps RX and TX tie together internally? As I understand it, everything on the bus needs both since the CCM coordinates everything.
• Electronic control module

It does not appear selective ride control (FX3) communicates with the CCM. The SRC computer directly controls the "service ride control" light. It shares the VSS input to the ECM.

I can't find a connection between the radio and the CCM either. It gets VSS directly just like SRC. Curiously, the radio control head, heater and A/C control head, and heater and A/C programmer head all are connected to ALDL pin J via the "entertainment and comfort data line". Without C68, it's just the radio on that line.

Edit:
Injector flowrate:
Progress!!! I was thinking about what the ECM must be sending the CCM, per my edit to my previous post, and I realized that if it's sending the components rather than the calculated value it must be sending the CCM the injector flowrate. I looked in my bin, and I have it set to 5.63 gal/hr. The raw value corresponding to that is 0xB4. I looked in the datastream, and the 11th byte (starting at zero - think this is convention) is 0xB4 in every single entry. I can test this hypothesis by tweaking my bin and taking another log.

Assuming the preceding is true, it must also be sending engine speed, injector PW, and VSS. Or, perhaps it's sending RPM, running total fuel, and running total distance. It's also possible the ECM might be combining one or more of those three things, but if that's the case I'm not sure why injector flowrate wouldn't be added in as well.

Here are lines from the beginning, middle, and end of a log.



Engine speed:
We know this is sent in the $10 line, but I'm not sure if the CCM can/does combine data from two different messages. At any rate, I think byte 2 of the $41 message is RPM. It stays close to 0x25, fluctuating slightly between 0x24 and 0x26.

Injector PW:
I looked in my ADX, and injector BPW is calculated in ms as "X * 0.015259". Looking at a recent datalog, injector BPW is around 2ms at idle. Dividing by 0.015259 gives 131 decimal = 0x83. Okay, I don't see any bytes that remain around this value. So maybe not.

Running total fuel:
It looks like that ticked up about once per second at idle. I'm not sure I even have a second of data (Arduino serial monitor overflowed very quickly), but I could see if I can find something that was zero before I started the engine and both 1) nonzero and 2) monotonically increasing after.
Byte 2 passes the first check but not the second.
Byte 4 is zero in both cases.
Byte 8 passes both checks, but it's increasing much faster than it should be.
Byte 9 passes both checks, but its growth is far too erratic.
Byte 10 passes both checks, but its growth is both too fast and too erratic.
Byte 12 is zero in both cases.

Hmm.

Running total distance/VSS:
Since I didn't move, this one should be zero in all cases. This means it could be byte 4 or byte 12. Byte 12 would make sense because of its proximity to the hypothesized flowrate byte (byte 11). This one is easily tested. There's a ton of salt on the roads right now, so it could be a while before I can test. Maybe I can just go to the end of the driveway and back. The VSS is 4000 pulses per mile, and the ADX item is scaled by 0.0005, so I think the ECM must increment running total distance traveled every two VSS pulses?

Maybe the CCM needs to see the car moving in order to trigger a MPG query? I don't think I can make much progress until I get some data with the car in motion. I also need to log to a file through Python so I can avoid the overflow issue.

 

This is correct; when you come to a dead stop, your MPG is 0. Because at 0 speed, you will get 0 miles regardless of how much fuel is consumed.

If you have a way to get the car up in the air, you could do testing without physically going anywhere. The VSS is on the transmission, not the individual wheels (the wheel sensors are used for the ABS/ASR, not the CCM and ECM).

 

Well obviously MPG would be 0 at a stop, but it doesn't seem implicit that the CCM would be smart enough to stop querying MPG if it saw VSS was zero. Actually, the CCM doesn't even have a VSS line, so I would expect it gets this info from the ECM in the same transmission that contains the rest of the MPG calculation parameters.

That's a good idea about elevating the rear wheels. I'll give that a shot. I wanted to do that anyway to diagnose a clutch issue.

A little off topic, but does a Mode 1 ABS request include wheel speed? I'm thinking of ways to implement traction control with my standalone.

 

The CCM does have a VSS line. I dunno if your FSM is the same as mine, but in mine it's shown in Book 2, Section 8A, page 51-5.

Yes, the ABS Mode 1 Message 0 includes the wheel speeds for each individual wheel. For the '92 ABS/ASR, refer to A175.DS. For 1990, A134.DS.

 

You are correct about the VSS line. Dug a little deeper and found it in my FSM as well. It seems odd that the serial line's broadcast ($10) would include vehicle speed when every device on the bus has their own VSS line.

Thanks, I'll check the definition out. That's a big help.

I got some data with the rear wheels off the ground, but I'm having trouble making sense of it. There are no new messages that I did not previously describe, so the data I already had must have contained all of the elements of the MPG calculation. There were two $50 messages (out of a thousand in that log), but each one had a checksum error. I think those must have just been partial transmissions, because the only other checksum error I got was a message immediately before one of the $50 messages.

In the thousands of messages I captured, every single $40 was identical ($40 55 6B), so that's not it. The $F0 messages were likewise identical.

We've also previously ruled out $10. I looked through the logs, and all the $10 messages are the format already seen. As an aside, I think I have something mixed up for byte three. In my log, I triggered the dash to metric, then back to English, then turned on the AC. Byte three changed from 0x08 to 0x09, back to 0x08, then to 0x0C. I'll table that for future investigation.

This brings us back to $41. I don't have the energy to reason through this tonight, but here's the raw data. While I didn't timestamp the log to mark the events listed, I figured them out from data in the serial (i.e. RPM goes from 0 to nonzero; VSS goes from zero to nonzero).
Right before and after starting the engine:Right before and after engaging the clutch:I'm thinking I'll plot each byte over time. Visualizing how they're changing should help. Maybe one of you guys can get something from these:




I'm tentatively thinking byte 8 could be the running total fuel. It's also possible that byte 2 correlates with injector BPW. Here's a plot from a datalog:



Byte 2 shows the same trend of an initial spike, then a dip, then gradual recovery to an in-between value.

Edit: The only other thing that makes sense for byte 2 is RPM. However, byte 2 leveled off at about 40. Assuming that was at 800rpm, the maximum value of 255 (0xFF) would be only 5100rpm. On the other hand, byte two being 40 at ~1.5ms BPW would mean 255 would be nearly 10ms. The largest BPW I can find in one of my logs is 8.9ms, which is perfect.

I think I can verify this by taking a log where I stab the throttle at idle. BPW should suddenly jump and then fall back down with RPM lagging behind.

It's probably not necessary, but I think I'll update my script to plot this data real-time so I'm not running back and forth as much.

Edit: I've noticed some strong similarities between some bytes in $10 and $41:

• $10 byte 3 (coolant temp) and $41 byte 5
• $10 byte 4 (RPM) and $41 byte 2
• $10 byte 5 (speed) and $41 byte 12

I don't understand why there would be duplicate plots, but the similarities are quite compelling. Here are the $10 plots:


 

One way to still use the C68 to display engine parameters is to implement another interface. Right now you are working on serial communications but if your aftermarket ECU has an OBD2 interface, you could use that to retrieve the parameters with the Arduino and put the data on the serial line.

 

This isn't dead, I've just been busy. I'll keep updating until this is solved, although it would speed things along if someone else had serial data to contribute.

@Mike in Boston , I was thinking - I believe you told me that your rear defrost will not work because the CCM needs to see that the car is moving. However, the CCM is directly wired to the VSS, so serial communications should not affect that. Am I misremembering your issue?

 

That can't be the issue according to the FSM. The FSM does not mention speed being an issue with the rear window defroster/heated mirrors, and as you point out, the CCM has a direct VSS input anyway. The CCM only cares about whether or not it's receiving a rear defroster request on pin D5. If pin D5 is grounded, the CCM ackowledges the request for the rear defroster and heated mirrors to turn on, and grounds the rear defroster relay accordingly for a fixed amount of time. That all said, there is a stipulation in the FSM is that the engine must be running. However, there's no "engine running" pin on the CCM, so either it's only looking for the key to be in 'run'...or it's looking for specific serial data from the ECM/PCM referencing RPM. This is the likely culprit; since the CCM also measures engine revolutions to monitor engine oil life, this is the magical serial data ticket that's likely causing the rear defroster to not work.

 

Nowake Wan is correct. It wasn't "moving" issue but a "running" issue. My assumption has always been that the CCM checks with the ECM before triggering the rear defrost circuit but until we can log it and see what it looks like we will never know. I even tried wiring my stock ECM up with everything I thought it needed but what I couldn't do was pulse the pin (I can't recall the pin) that the distributor pulses with 5 volts per revolution to simulate "running". It was a while ago so I may be fuzzy on the details but spoofing the serial data, if indeed that is the missing component, is a better solution then pulsing an ECM pin.

 

I tried using a serial stream capture app while logging, but it seems like it was a port conflist. I have maotes aldl usb setup and can log using tunercat. If I had more understanding of which capture tools will work I would love to be able to mirror the project on a 93 LT1 AT. These ECUs are very basic even comparing to the FSM there are only a dozen or so actual PIDs of interest. How can I capture serial streaming?

 

You have two options.

1. Use a logic analyzer. This is a separate physical tool, which should be connected to a different computer from the one you're using to talk to the car. You jab a pin into the serial data wire on your car, then it just listens to every single thing on that wire. This is how I'm reverse-engineering the ABS/ASR signals from the Tech 2.

2. Use a piece of software called a Serial Port Monitor. While experimenting, I used the free trial of HHD Software's "Serial Monitor." It did exactly as described; I was able to easily log all communication between my laptop and the car while reading from and flashing the PCM on my car. It was thanks to this software that I was able to get datalogs comparing how EEHack, Flashhack, and DataCat flash routines work. Instead of paying for the full version, I bought a logic analyzer.

 

"Use a logic analyzer". - so is this software or hardware? I've looked at a few things from raspberry pi to actual ocilloscopes on ebay. how would the signals sync with logged tuner pids I wonder? Also what is the analysis objective for getting these signals cataloged. to model the signals so you could program a replacement ECU or a partial slice? For ability to tune with HP Tuners? If so what is the ECU that could be actually programmed to do the same thing as the OEM? I would think a way to get the raw data wouldn't be to reverse engineer the tuner logging software to dump the serial data? Am I way off there?

 

A logic analyzer is a piece of hardware. I use one from Saleae. The "signals" would "sync" because you'd tell the logic analyzer what to expect; namely 8192 baud 8N1. If you tell it what type of data it is, it can correctly interpret the signal for you into hex data.

As for the objective, once you have the hex data, you can start comparing it to known ALDL information and see if you can identify what exactly is being said by what device and when and what it contains. You would then, potentially, be able to replicate those signals in order to make the CCM and such happy even if you swap ECMs.

You don't need to do that to tune one of these cars. That's easy peasy, no reverse-engineering required. But getting an aftermarket ECM to play nice with all the other computers in the car? Good luck; to my knowledge only Torqhead has done that.

I'm not sure how to address your final question before you asked if you're way off. The question doesn't make sense. Could you try rephrasing it?

 

How is the science experiment going?