Anyone worked with the 16196397 yet?

[Xnke]

Had any time to look at this, Robert?

[Xnke]

So this is the information Mark sent back to me about the bad data issues:

During the bad data, the ECM is sending the F0, F4, and E4 module data, when you’re only requesting the F4 module communication. I’m thinking the issue is that the other modules aren’t being silenced. I don’t know enough about the LT1 ECMs to know why this might be happening, though. Perhaps it just comes down to adding silence commands to the connection macro.



Example of what I’m seeing in the logs:



DataAcq Write

0000: F4 57 01 00 B4 .W...

DataAcq Read

0000: E4 0A 58 00 03 ..X..

Looking for packet...

DataAcq Read

0000: DA C1 F4 57 01 00 B4 F4 95 01 16 16 60 24 00 02 ...W........`$..

0010: BF FF 00 D8 00 80 80 00 00 F5 C2 00 0C 7A 7B 00 .............z{.

0020: 00 3C 0D 90 00 00 00 00 05 00 00 00 00 40 44 00 .<...........@D.

0030: 20 00 03 00 00 21 20 30 02 00 5E 02 00 00 00 00 ....! 0..^.....

0040: 00 00 00 ...

52.448: Command/Reply Success

END MACRO: ECM Mode 1 Message 0 Reply

BEGIN MACRO: ECM Mode 1 Message 0 Macro

DataAcq Write

0000: F4 57 01 00 B4 .W...

DataAcq Read

0000: F0 56 E4 D6 0A



In the big read in this example, you can see the tail end of a previous packet, followed by the F4 57 01 00 B4 echo, followed by the (highlighted) start of the F4 module’s message 1 reply, then the packet.



You might be able to align on the reply’s static header data (F4 95 01).



-Mark

Anyone got any ideas how I can implement some of Mark's suggestions?

[RobertISaar]

that's.... odd. the ADX should already have a few pauses and mode 8 commands being sent as part of the initial connection process specifically to prevent this issue.

the way I setup the initial connection was to send the mode 8 command to the T side 5 times, wait 50mS, send the packet that grabs the VIN 5 times, wait another 50mS, send the mode 8 request 5 times again to the T side, wait another 50mS and then start the mode 1, message x requests to get the stream going.

it almost looks like both E side and T side are trying to communicate one after another?

[Xnke]

That log is from your E-side ADX, I haven't looked into the command macro structure yet.

Been working on finishing up the paint work and A/C hoses, once that is done it's basically just down to making it run. Only missing part (completely missing) is the air-to-water I/C, all the parts are made save the hoses and actually fitting the tank, pump, and heat exchanger, but all that will wait till it runs, 'cuz I gotta work out a method to cycle the intercooler pump based on IAT. (I think I can hack the current OE code to do that, based on EGR stuff.)

[RobertISaar]

if you wanted to save an output on the ECM, you could hook up a Schmitt Trigger(or a small microcontroller if you didn't want to go analog) to the IAT circuit. for something that likely wouldn't need the IAC to move around due to increased electrical draw(or maybe it would? I'm not sure how much amperage your pump would require), and probably wouldn't need any other qualifying values, it almost seems a waste.

[Xnke]

Well, right now I can set up the EGR output to trigger on coolant temp, so I figure I can just go to that section of the code, and substitute the IAT variable for the coolant temp variable-but I need to be sure that I *only* catch the EGR functions with that mod. That way, the EGR output trips a relay coil, which then handles the intercooler pump. Basically I'd just have EGR active at idle to redline, but only when temperature is over X value-this would allow me to tweak not only when to run the pump but I could have it specifically not run the pump during periods like idle warmup.

All of that is moot until we can get it to read the 2-bar sensor properly. I still don't have any idea what I'm doing with this, the patch attempt I made bricked an ECM so clearly I did something pretty far off the trail...

[RobertISaar]

does your ALDL setup have indicators on it that light up when comms are happening? I think I'm going to have to throw more mode 8 commands into the initialization scheme and specifically shut up both E and T side before attempting to communicate with either. it's strange, for whatever reason the calibrations I run in the same PCM don't exhibit the same behavior, when I send mode 8 commands to it, it quits talking for the 2 or so second timeout that a mode 8 with nothing after it should cause.