Anyone worked with the 16196397 yet?

[RobertISaar]

BIN changes look correct.

item list in the new ADX omits the viewing of anything that would be coming from the T-side, though the commands to have both E and T side sent are present and could be configured to do so.

you'll have like 15 items coming across from the E-side in the list view, I didn't want to put just bare minimums in there if for nothing other than packet error checking. some are useful to look at, others not as much. MAP above 100 is a value, it's an offset and scaled MAP value that is only really used for the boost VE and boost main spark tables. should show 0 at all times until the MAP sensor reaches the 100kPa calibration value, then it should start showing non-0 results. scaled at X*0.78125, though I don't think I put the scaling into the ADX yet. with an initial value of 100, that gives it a 100-300 range.

GM using C is not surprising.... considering the number of different masks that came and went in the 86-95 timeframe(where P4 and eventually P6/P66 became dominant), punching it all out in assembly would be hell. even just small patches(50 bytes or so) in a single mask are trying at times. I've never actually considered the existence of 6811->C assembler, I assumed going from low-level to high would be problematic at best. playing with the code in C does seem like it would balloon out of our size constraint pretty easily.

[Xnke]

It's much faster to write in C than assembly-but C is low-enough level to be usable. It was actually designed to do this kind of work, things that needed to be assembled for compactness and speed as well as being able to be used for other things. I do not know the name of the decompiler, but I'll get it.

Testing to commence in a few minutes, I should have another video of the current patch's behavior.

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