Anyone worked with the 16196397 yet?

[RobertISaar]

Any update on the E-side-only ADX? I have been *very* slowly stepping through the disassembly and while I've not made any profound insights, I have found two typographical bugs that may or may not actually matter, according to my friend who knows about these kinds of things. I haven't even started to try and make sense of the patch yet.

Basically, I sit down with a pencil and paper and start at the top of the loop, writing out the commands to try and get them to tell me what it's doing-combined with the comments it seems to help me make better sense of it.

How goes the KLDE repair and modification?

E-side ALDL info: look at the E-side disassembly around 91D5 and you'll see the E-side M1m0 response, changing the RAM/ROM/register addresses will allow for nearly any value to be watched. it's a 63 byte payload and modifying what is being spit into the stream doesn't effect any kind of module or the comms ability with the T-side, so pretty much all of it could be scrapped if desired. I keep some fairly constant stuff in there just to errorcheck the stream, but otherwise, most of it is free game. the ADX I'm attaching still has T-side stuff in it, but it's more or less hidden from view and isn't setup to communicate with T-side by default. with this ADX, it looks like I was monitoring EGR% and some knock stuff when I was last using it. I don't think some of those values are there in factory calibrations, so they would show up incorrectly in something that hasn't been patched to transmit them.

to get around having to make patch every time a value I want to monitor comes around, I just made an address inside tunerpro. "Mode 1, Message 0 ALDL Response", that should only exist in the E-side table list, I never made a table for the T-side since that more or less stayed constant. the offset value in the ADX and table location value in the XDF differ by 1, though I should probably change that at some point in the future. just something to keep in mind. starting at 9235(position 49 in the XDF, position 48 in the ADX), there's a lot of 2A5, which as far as I can tell, is a completely unused value. it's easy to add items there for monitoring since it won't have to replace anything. because of that, I've setup the ADX to read the raw 2/3BAR MAP value and the above 100kPa values from there. just need to open the table and change position 49 to 0369 and position 50 to 036A. the E-side baro and emulated 1BAR MAP values are already in the stream, so all 4 values can be compared simultaneously to see if something funky is going on.

so, ADX work is done, just need to change two values in the BIN to match and the E-side ADX will function well enough for the values we need to keep track of.

typographical bugs? maybe issues, maybe not, I do things in a bit of a non-traditional manner with a lot of success, especially when it comes to labeling, but it has burned me before.

the domestic Mazda rides again, turns out one plug wires failing will cause a rapid demise of something in the distributor, after replacing the distributor, still had an issue with cylinder 4, so i quit messing with it until new plug wires came in. replaced those and it once again sings happily up to its rev limiter in the 7400 range.

Shit's goin' down now...Half price books, dollar and 50 cents!

when i started cutting my teeth on 6811s, it was the GM P4 variant, which that book wouldn't have been entirely appropriate for, but with a P6/P66 application, it would have been beyond monumental. it probably explains why i have somewhat quirky methods of getting things to work and testing methods in general. it's also why i can't really hook into high level languages either, about the only original programming I've ever been successful with has been at assembly level. Trying to make anything beyond simple Android tutorial apps felt like a drill to the temple. Arduino has been an okay-ish experience though.