Anyone worked with the 16196397 yet?

[Xnke]

Well Robert, I figure it's time to abandon ship here until Tunerpro gets a bugfix release to correct the erratic data problem, I can't give you any kind of usable data.

Spent two hours fighting the issue I was having with data being fine until the engine is started-whatever I did a few months back to fix it hasn't actually worked-it was just a fluke that the problem went away when I was talking to Mark about it. There's still five or six posts on the Tunerpro forum with reports of the same thing, so until someone can actually take a tunerpro install to Mark with the problem, I doubt I'll get anywhere with this.

Supposedly there's nothing he can do about it without being able to reproduce it locally or have some serial port monitoring, so I guess the next thing I need to do is get some serial port monitoring in place and try again.

[Xnke]

Ok, so I was collecting data for Mark to work on Tunerpro with, and actually got a few shots of "usable" data for this.

This is E-Side ADX, and the logs are done with the Tunerpro Debug output open for Mark, but hopefully there's some data for you to use too, Robert.

[RobertISaar]

looked at all 3 logs, yes, there is usable data here!

particularly log7, ECMMAP and ECMRaw 2BAR are both updating when the engine is spinning.... and both agree with each other in most samples as well(the ones that don't, I chalk up to additional a/d reads that occur between sending the two items(with one being item 16 and the other being item 48 in the stream, there's 32 other bytes of data that get updated first. at 8192 baud, that's .03125 seconds, almost enough time for 3 80Hz loops to complete, let alone the MAP updates that can be done based on the 24X crank sensor signal).

but then.....

after your first cranking, your MAP sensor settles from 100.76kPa as a barometric-looking value down to 95.22. after the second cranking, it maxes out at 60.... all while the actual baro value was sitting at 104.45(expected, since we have to pretty much disable baro updates with a boost application). log4 has something similar, though MAP and baro more or less agree before first crank at 100, then MAP tops out at 97, while baro still sits at 100.

I'm not sure why the MAP sensor's value would "stick" at progressively lower values after cranking.... if you're able to replicate it, can you take a voltmeter to the MAP sensor's 5V, ground and signal lines while the ECM is reporting those odd low values?

[Xnke]

Can't find anything wrong in the wiring or voltage checks-and remember, if I flash the 1 bar tune and put in a 1 bar sensor, it's absolutely perfect. Smooth idle, revs like a rocket ship straight to 100kpA, blower is still in full bypass mode so will only make 108kpA max.

Don't get hung up on the MAP going lower after cranking-it's not totally predictable and given enough key-on, start, key-off, key-on events, you'll see it run the gamut from 50kpA all the way to 99kpA. I rarely see 100kpA here for baro so *usually* you'll see it at 98.5 or so. I can pull the vacuum line off the MAP sensor, key the engine on so the PCM starts to report sensor values, and manually pull a vacuum on it and it wasn't updating before-I need to check and see if the raw value updates with the engine not running...stock 1 bar code does and I think that may have something to do with the issue. Prior to running the E-side only ADX, the 2-bar code did NOT update the sensor if the engine was not running, but TPS/coolant temp/air temp all updated fine.

I've got to send some stuff along to Mark tonight, and he's working on the data corruption issue.

[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?