Corvette CCM Reverse Engineering Anyone?

[spfautsch]

I've found eehack's raw cmd function great for this - saved me from finding / building something on my own. No need to be connected to the ALDL to send / see the checksum byte.

Today's logging was off a good bit on avg mpg. 23.0 actual / 24.3 by the dic (including 60 miles w/o logging) and then 25.8 actual / 22.1 by dic on the return trip (only 60 miles).

I'll have to do some more test-drives with different ratios of PCM polling to CCM traffic. That'll be a tall order with the time change and winter coming. I hate driving this thing at night because the deer-infested winding back-roads will be calling out to me to avoid the mind-numbing monotony of sitting in interstate gridlock.

Whatever the case, the dic-based fuel consumption stuff isn't all that terribly important to me. The gauges work and everything else does so I'm happy with it given that I can make logging to a SD card works. Ordered a logging shield with RTC today, hope to have it in a couple.

I'll need to figure out handling when the ASR / ABS barges into ALDL communications and gracefully reconnecting. Beyond that it should be completely unnoticeable.

Have the VIN / patch / auto trans / maf discovery figured out for the most part. Though I might just remove the e-side / maf check altogether since it's not really relevant to passive logging and doesn't work with the engine running anyway.

[NomakeWan]

I'm actually not entirely sure how the ABS/ASR thing works, so good luck. I know that it freaks out and throws a Code 72 when you connect a scan tool like a Tech 2 or EEHack, but I'm not entirely sure why since you shouldn't actually be telling it to shut up and it isn't supposed to talk unless spoken to (by the CCM). I haven't done any raw idle logging while driving, however, so it's entirely possible that's why I haven't seen any traffic from it. I will point out however that the GM definition I have states it's not supposed to actually talk on the bus unless the CCM specifically requests it to.

So hey, another mystery to solve!

[spfautsch]

eehack will send a F9 mode 8 command if the 'silence extra modules' is checked. This is what causes the MIL on the ASR / ABS module (currently known as the EBTCM module).

As memory serves, I was seeing eehack disconnect after an ASR event. My assumption was that the module was barging in with a message and stepping on messages currently in progress. So I had steveo leave this option enabled on y bodies by default. This was back in 2015-ish. I never ran an idle scan to prove it, perhaps this will be my chance to solve that mystery.

I suspect the (calling it) EBTCM module is sending a message that it has intervened with throttle control. Possibly a precursor to the modern stuff where these modules only interact over canbus. But that's just my suspicion.

[NomakeWan]

eehack will send a F9 mode 8 command if the 'silence extra modules' is checked. This is what causes the MIL on the ASR / ABS module (currently known as the EBTCM module).

As memory serves, I was seeing eehack disconnect after an ASR event. My assumption was that the module was barging in with a message and stepping on messages currently in progress. So I had steveo leave this option enabled on y bodies by default. This was back in 2015-ish. I never ran an idle scan to prove it, perhaps this will be my chance to solve that mystery.

I suspect the (calling it) EBTCM module is sending a message that it has intervened with throttle control. Possibly a precursor to the modern stuff where these modules only interact over canbus. But that's just my suspicion.

According to what I've found so far, only the Delco ABS on the F-body actually does that; it sends a message over the UART to the PCM telling it about ASR events. This PCM function is disabled on Y-Body calibrations.

I am super curious about your experiment however!

[steveo]

eehack uses that silence f9 command because another logging tool uses it and one of my users had convinced me it was necessary
i'd never proven it and had no trouble without it on my 1994 or 1995 fbody
eehack was written on both a test bench and in a 1997 body with an 8051 ecm straight wired to the aldl so 'the rest of the bus' was never something i worried about when first developing it

[spfautsch]

eehack uses that silence f9 command because another logging tool uses it and one of my users had convinced me it was necessary

I'm fairly certain I was that user. Will keep you posted if I find it necessary with my logger project.

So here's an arduino sketch (mega 2560 minimum required due to 2+ hardware serial ports) to log to an SD card in a Y-body. Representative logfiles included. As with my previous example sketch, this is a minimalist, down-and-dirty representation of functionality. I will probably not post a lot more about it unless there are users with interest, but wanted to put it up for the possible benefit of NomakeWan. At the very least it will demonstrate how to use a hardware timer / counter (timer 3 on the mega) to implement a delay between ALDL receive and microcontroller transmit.

This grabs data from the ALDL and the DIY-LTCC simultaneously and writes to an SD card. I'm particularly proud of the .eedata file creation. Even while requesting some CCM broadcast data between the PCM requests that eehack would normally ask for, I'm seeing an .eedata file with roughly the same acquisition rate as eehack manages while completely silencing the CCM. I've no idea how accurate the fuel consumption data is, but the primary fundamentals of the "black box logger" concept have been satisfied.

I think I have no further use for the reman CCM steveo. NomakeWan if you'd like to use it coordinate with steveo. Otherwise steveo, hang on to it for the immediate future. I would like to have it back eventually, but currently have a "date" with a paint gun, waterproof sandpaper, and the such for the next few months.

[kur4o]

Something I have been waiting for a long time. Definitely will build a test rig and get the opportunity of blackbox logging.

Some help on the setup will be highly appreciated. I am in no hurry, a good winter project.

[NomakeWan]

So here's an arduino sketch (mega 2560 minimum required due to 2+ hardware serial ports) to log to an SD card in a Y-body. Representative logfiles included. As with my previous example sketch, this is a minimalist, down-and-dirty representation of functionality. I will probably not post a lot more about it unless there are users with interest, but wanted to put it up for the possible benefit of NomakeWan. At the very least it will demonstrate how to use a hardware timer / counter (timer 3 on the mega) to implement a delay between ALDL receive and microcontroller transmit.

Just to make sure I know what's going on here, you have this line:

#define TCNT3_TICKS 28    // 62.5us each 24 = 1.5ms
...
OCR3A = TCNT3_TICKS;   // set timer0 compare match register A
...
TCCR3B = (1 << WGM32) | (1 << CS32) | (1 << CS30);

If I'm understanding this correctly, isn't this actually 64 microseconds per tick, thus making 28 ticks 1.792 milliseconds? Check my work.

System Clock: 16000000 Hz
TCCR3B = 16000000 / 1024 = 15625 Hz
1 tick / 15625 Hz = 64 microseconds/tick
64 microseconds * 28 ticks = 1.792 milliseconds

Is there an errata or something I'm missing? As you know, I've not addressed timers before, so I want to be sure.