Anyone worked with the 16196397 yet?

[RobertISaar]

finally had a chance to watch this.

most of that, I was expecting, but there should have been a good period of silence after the mode 8 commands.... like the amount of time that it quit communicating after the mode 1 requests, that's what I would expect from a mode 8. the fact that it never quit is odd, to say the least.

I did just have a really dumb thought though. assuming you don't have anything integrated like a 94-95 Grand Prix Driver Information Center, there's really no reason to have the PCM chattering so much... could clear the ALDL message scheduling tables, then it should never attempt to send data until prompted. not the greatest fix, but it may be enough to at least get the boost patch troubleshooting done. I don't have those tables listed in the XDF at the moment, but they're already documented on both E and T side IIRC.

[Xnke]

That would be helpful-I had thought about integrating the trip computer at some point but that isn't really a priority. Antus and Charlay86 on PCM Hacking are taking a stab at it too. They are thinking that the pcm may be taking the 3x input and defaulting the Baro/map stuff due to an error. Also, in Charley's experience the map code mods can't have a jump splitting them up or he had the same problem.

I am collecting all my info and your info and wiring info for these and getting it all to them to see if we can all work together and get this cracked. I dug into the code with my local buddy, and that cylinder count thing LOOKS like it may be all you need to change to 4-cylinder mode!

[Xnke]

Ok, so today I turned off the E-side ALDL scheduling, and the E-side communications were MUCH improved. Totally usable, except that a lot of data no longer worked...so I will have to be selective with what I turn off. Just need to work out what the DIC stream location is, and turn that one off-it may be done via process of elimination.

Odd thing is that I did not turn off the T-side scheduling, but the DIC chatter was stopped completely-so the DIC info is coming from the E-side???

[Xnke]

Here are the datalogs and details from today's work on things.

First off-shutting off everything in the ALDL scheduling table (at least the one we've found so far and implemented in the XDF) does NOT stop all the chatter. Something else (probably something on the T-side table) is still chattering away.

The E-side ADX does not get all the data once we start turning stuff off on the ALDL scheduling table. The important bits still seem to work, but RPM & TPS for example are not being received. Notice the Baro and MAP values...I think the patch is screwed up again. (had a bit where the patches would only partially apply, which is superweird.)

The T-side ADX (normal ADX) is still receiving all the data we want to see-and it is stable, good data now. I did have 6 data errors, but they were well defined short-duration events and the data stream recovered properly. I actually started and ran the engine with the 1-bar code, and have a decent length datalog. I didn't try with the 2-bar code, as the engine does not run with it so it's me flailing at the accelerator pedal to sustain a running engine, and the above E-side ADX showed issues with the baro updates and map updates.

I will be adding the Wideband O2 internal modification to the PCM in the truck this evening. Hopefully I can figure out the patch format to add the patch to the XDF and get it to apply correctly, as this greatly simplifies the checksumming process.

[Xnke]

Ok, so I have written the wideband O2 code for the E-side and added the input to the PCM. How do I get the code I wrote into the "patch" function on the XDF? Is there any documentation on this anywhere?

[dzidaV8]

In tuner pro, select 'Insert New XDF parameter' -> Patch.
Then in the opened window you can add multiple patch entries. You should add one for every 'continuous' change in binary.

Example:
You want to change the binary in two places:
1. starting at address 0x00FF from: 00 2D 6F 00 2B 11 to 30 85 F2 AA 20 00
2. starting at address 0x01A2 from: FF FF to A1 00

Then you should add two patch entries:
1.
Start address: 00FF
Patch data: 30 85 F2 AA 20 00
Base data: 00 2D 6F 00 2B 11

2.
Start address: 01A2
Patch data: A1 00
Base data: FF FF

And that's all.

You do not have to give "base data" but if you add it, it's possible to remove the patch.

[Xnke]

Excellent. I'll attempt that this evening.

[Xnke]

Still dont' have the hang of this XDF patching thing. I can patch it via hex editing and the wideband stuff *works*, I just need to get the value into the normal datastream instead of the E-side only datastream now. Once that's done, wideband support is in.

Boost code has possibly been fixed but since I can't get the XDF patching to work, I'm afraid to dive in and start hex-editing that many lines in so many places, especially with the wierdness in locations between the XDF patch and the patch notes.