new $EE tuning thing!

[jthompson122183]

Well I found out what the 21cd table is on t-side. I asked about the table in a tuning group on Facebook and this is what was postedAttachment 10395

[steveo]

You can check mode 7 aldl commands on t-side[starts]. Third or fourth byte is the destination device ID.[Here is quick list third and fourth byte:
0a,0a; 10,10; 91,90; f0,f0; 40,40; 45,45; 12,12; 92,92; a6,a6; 40,41; 42,43; 91;90;

$81 should be traction control module
$40 is something corvette related
I might play with oem tool to find other ids.

awesome info, thanks!

[kur4o]

I make some log analysis of oem dumps and other dumps.
It looks like it is common for eside to answer 05 aa on the first mode 06 request. I have no idea why maybe PCM dependant or some deliberate glitch left from GM.
So you can try to add e-side exception on mode 06 request to accept 05 as valid answer. That may resolve the issue.
On the oem dump I found the same situation and the tool continue loading without error. I found on the same dump it force try mode 5 when seed key is not to specs and if it gets 05 aa it continue with routine.

I guess the 05 answer is not permanent but it happens from time to time with no logic between events, so It might be software imperfection or hardware issue.


f1 56 08 b1 might be good when engine is off. It is used for reprogramming shut up request, so it should work.
When engine is on it may be not enough especially on y-body heavy traffic use. Other possible solution could be fuse removal shut-up request.
ALDL is not used for scanning y-body, it is on the class-2 data, I will try to hook elm device on the class-2 and see what oem is transmitting.
Those extra modules on y and some b really load the bus and can get you as fast as 2 frames per second. So first try to identify module id and than play with commands.
The list is IPC, CCM, HVAC, ABS, Airbag, and some other on corvette.
The best way will be some vette guy to make raw dump on the bus to see what is exchanged and at what rate.

[kur4o]

Well I found out what the 21cd table is on t-side. I asked about the table in a tuning group on Facebook and this is what was postedAttachment 10395

There are four tables like this for each sensor two front and two rear.
I see no evidence in the disassembly that this table is used for something like that. I guess it is used only for corvette obd-2 diagnostics for sensor health when engine is not warm enough.
Still need to see if it is related with blm update enable routine. It is really complicated and unclear.

[steveo]

It looks like it is common for eside to answer 05 aa on the first mode 06 request. I have no idea why maybe PCM dependant or some deliberate glitch left from GM.
So you can try to add e-side exception on mode 06 request to accept 05 as valid answer. That may resolve the issue.

i'll check it out.

Those extra modules on y and some b really load the bus and can get you as fast as 2 frames per second

some of the more deluxe b-bodies are having similar problems, pulling fuses is solving it.

i can make a special routine to bombard and query the related modules to see what answers to mode 8 requests.

[steveo]

posted a new beta with possible fix for b-body and f-body cars. for 0xF1, 0xF0, 0x81, 0x0A, 0xA6, and 0x40, i repeat 10 mode 0x08 requests each. i modulate the timing of the requests themselves +0-5msec between each request and +75-80msec between each iteration. this brute force takes less than 1 second but might be enough to hammer the bus and make the devices listen. i've sent this beta to two users outside this forum that have had issues and i'll see how it works for them.

also possible fix for kur4o's e-side nonstardard aldl reply. it still produces an error in the debug log (as it's technically a breach of normal aldl comms due to its mode mismatch), but if 0xAA is the response, and it's the first mode 6 packet for the e-side, it flushes the read buffer and continues on. i think that'll effectively go past it. let me know how it works.

[kur4o]

Tried the new beta, so far the mode 05 issue is gone. It still shows the error mismatch but loads fine the bin afterthat. I am very happy with that.

Sniff some module commands for data request.

Y-body
abs [f9 57 01 00 af]
sir [fa 57 01 00 ae]
ccm [f1 57 01 00 b7]

B-body
HVAC [ea 57 01 01 bd]
ccm [f1 57 01 01 b6]
SIR and ABS as y-body

[steveo]

thanks that's a BIG help. eehack has a lot of users emailing me, i can use them to do some raw commands and figure out what we can get.

glad mode 5 is working for you.

[steveo]

digging around i found the ABS data sheets for the y-body, also just noticed the common ADX file for tunerpro has SIR labeled as ABS, so now we have at least some of the SIR data. i'll start with the SIR module definition, and look into ABS more.

not sure what the vette CCM or bbody hvac spits out and not sure anyone will care, but might be cool to look into too.

[steveo]

new beta that hopefully resolves all those b-body and y-body connection issues (no other big changes)

the 'deluxe' b-bodies are especially troublesome.....

[steveo]

still failing with b-bodies and intermittent with y-bodies. uploaded a new beta (7) with a special function in the 'raw' window that provides a log of idle traffic with timing information, so users with y/b/d bodies can send me their idle traffic for analysis.

[kur4o]

Again played with ALDL communications.
There is some interesting stuff.

Idle traffic is not idle at all it is preconfigured in the bin.
What is transmitted is located on the following address pointer that points to the modes to be transmitted.
For f-body
tside:
3ac7[f253]
3acf[f2b7]
3ad7[f2cb]
3adf[f2b7]
the idle message
f0 56 f4 c6 is message to inform for f4 id on main bus.

On y-body there is no idle traffic. The ccm is the master bus.
That`s why there is problem with oem tool to communicate with y-body calibrations. It is waiting for idle traffic from ccm and sends f1 56 00[enter normal state message], since I don`t have corvette ccm connected on the main bus the tool refuse to communicate. It is possible that y-body still connect via aldl line since I hooked elm device to sniff traffic and there is no data send over class 2 data[maybe it is waiting for ccm data first or it is not using common obd2 protocol.

I checked buick bin and there is much more idle traffic sent from pcm. ALDL message located at this address.
F2 CB
F2 D7
F2 F5
F3 1B
F3 25
F3 2F
F3 39
There is really long messages out there.
One sure way for b-body is to patch some of the unneeded traffic message from b-body. That way some stuff wont work but it will be very good for the bus.
Maybe some of this idle messages are keep alive and it wakes other devices.

For y-body I will need idle log to see what is happening.

The idea for idle logging is really good. I hope it gets permanent activated by hidden switch in the options. It needs improved logic to identify bus message better, to filter the id and message lenght and after that is easy to display. For PCM idle you can load it with PCM mode 7 ids list.
I noticed during sniffing that there are some extra bytes shows from somewhere but not quite sure where they come from.

[steveo]

On y-body there is no idle traffic. The ccm is the master bus.
That`s why there is problem with oem tool to communicate with y-body calibrations. It is waiting for idle traffic from ccm and sends f1 56 00[enter normal state message], since I don`t have corvette ccm connected on the main bus the tool refuse to communicate. It is possible that y-body still connect via aldl line since I hooked elm device to sniff traffic and there is no data send over class 2 data[maybe it is waiting for ccm data first or it is not using common obd2 protocol.

that's my observation too. the corvette doesn't have much crazy traffic on that line, but i've found people that connect before starting the vehicle have a bit better luck. i doubt they would have bothered to push all the obd-ii pids on the obd-i datastream. i bet 'class 2 serial data' is mostly unused.

I checked buick bin and there is much more idle traffic sent from pcm. ALDL message located at this address.
F2 CB
F2 D7
F2 F5
F3 1B
F3 25
F3 2F
F3 39
There is really long messages out there.

you have no idea. there's barely a gap, but there are gaps. i think if i just saturate the bus to shut up the CCM first so the heartbeat goes away then maybe any other modules that are problematic, i'll be OK.

how i do it already for f-bodies, but they have an approx 30msec gap between idle traffic, so if i use a 75ms gap between my messages, it pretty much always lands on a blank spot within a few tries.

i had a very helpful user (who is testing this stuff for me) dump a buick and a caddy, both key on and key off. file attached.

there's a ton of junk on that bus. look at this, maybe you can make sense of it, i sure can't! he can make it connect by pulling fuses, but he says there are three fuses, so i think the CCM heartbeat isn't enough (maybe another device takes over as master?)

[steveo]

0xF0 isn't a real device but maybe a bit more of a broadcast ID? do you know much more about it?

this is all really interesting stuff, every time i think i understand the datastream there's something else going on.

i wonder if there are any HVAC mode4 commands... maybe we could blink lights or display funny stuff

[kur4o]

Can you ask him to make a log after PCM is shut over by 08 mode.
I need to see what is send when the PCM is silent.
On b-body I am pretty sure PCM is the master.