EE o2 delay

[steveo]

the delay for the integrator.

there has to be one

I want to find it, but I'm a noob and I've brickwalled. could use some help

lets get hunting

one thing I've considered is that it's an execution time delay that can't be changed . I've seen this in embedded control systems, the delay is actually the execution time of the event loop. is it possibly done this way? I think the processor might be too fast... but maybe its a very short delay, which would explain how "blm splitty" ee is

any thoughts?

[EagleMark]

I thought Robert had found it in the V6 equivalent? If so I'd use his address and TunerPro s 2d and 3d features to identify it then start looking around the same location in the V8.

[RobertISaar]

i wish it were that simple...... i've been busying trying to find a replacement motherboard for the wife's desktop. finding good, enthusiast-level computer hardware from late 2008 at a decent price isn't very fun.

P66 V6 uses two tables, INT delay vs airflow(5 value table, from 16-64 grams/sec) done on an 80Hz loop. that is multiplied with an INT Delay multiplier vs O2 error table(7 value table, with O2 error ranging from 0-424mV)

i imagine the LT1 code will be done similarly, though likely with increased table sizes.

[steveo]

i probably have a thousand of motherboards laying around that might work for you; what processor are you workin' with?

[steveo]

man oh man P66 has been ripped right apart, makes EE look shameful

anyone have a good P66 sample bin i can check out?

[steveo]

maybe wont even help, its so... so different

[RobertISaar]

all of that P66 V6 ADX and XDF work is my own, BTW.... want the disassemblies for those too?

i have........ like, all of the BINs ever released for them, export stuff included as well.

the hardware itself is NEARLY identical, but the software is actually very similar to the MPFI 60V6 stuff from 88-93.

[steveo]

yeah i kinda gathered, i recognize some of the tables from my shitty old 2.8. really good job on that stuff, that's a very detailed hack. i'm still suprised nobody has dug that deep into EE yet, i just wish i had the skills to track these things down

[RobertISaar]

i haven't mainly because i have no $EE vehicle.... everything i do have.... i've either been lucky and had a large amount of documentation already generated or i got fed up with a crap factory calibration and did it myself.

now that i've run through the past 22 days of posts on reddit in a hardware swapping group(and sent out plenty of messages), maybe i can start looking at this again.

[RobertISaar]

so i did some really quick tracing of where stuff is going....

E-side word 18B is an airflow value, 16-bit, range of 0-512 grams/sec.
at 6F52, changed into a 0-256 grams/sec 8-bit value, then stored in the TO T-side buffer byte 13 (byte 6C)
it eventually gets transmitted to the T-side, where it is stored as byte 240.
at 5B46, byte 240 gets multiplied by 4, turning it into a 0-64 grams/sec range, where it is used to do a lookup on a 17 value 2D table.
the result of that table is then limited both high and low to a range of 16-64 and stored to byte 19B.
19B is then used for 6 5-value 2D lookups in a row.
the first table it is used for, the result is compared against an O2 voltage threshold.



i'm not saying that is it, but from a quick run through the code, there are enough connections there to get to some INT compares.

[RobertISaar]

interesting..... those strings of tables have some interesting compares going on.

26F1 generates an O2 value that is compared against the left O2 sensor
26F6 " " right O2 sensor
26FB is a 0-1 multiplier. multiplied with the result of the table 271D in two places in the code. at 5D40 for the left O2 and 5E69 for the right O2.

you know..... this looks awfully familiar.....

[steveo]

you're good

i can follow your findings perfectly now that i know what i'm looking at, but i have trouble tracing back to how you found that. shows how foreign this assembly is to me

i dont see what else code like that would be used for, you must be close

now here's where i hit a wall in understanding this ecm (and how to confirm this drives a delay), how would it time a delay like that?

now in a lot of emedded platforms i've dicked around with, operations will take a fairly predictable amount of time, it can just be a portion of an event loop with a counter that figures x iterations of the event loop will be around whatever ms..

but that seems too dumb. so i assume an ECM like this one would use clock cycles? it must have a linear clock.... how is it checked?

i should sober up and look at it again

thanks so much for your work so far

[RobertISaar]

i keep getting sidetracked.... i've found the tables that deal with the delay, along with a lot of the O2 calibration(none of which is in the current XDF that i can see), i just don't have them labeled with 100% certainty yet.

time delay is done via loops. (i'm assuming a couple of numbers here, so they might be slightly off, but the concept remains) once every 1/160th of a second, an interrupt is generated and the processor goes through the vector table and does the work that is found in the 160Hz loop after reseting the timer. then, every other 160Hz loop, an 80Hz loop is done(or at least, two 80Hz loop alternate between which one is executed for a given 160Hz cycle). the O2 logic seems to all be in the 80Hz loop, so whenever an increment or decrement is done in the code on an 80Hz loop(and can only happen once per loop), it is a period of 1/80th of a second(12.5mS).

finding out for certain at what frequency the loop is done at helps with nearly any timing based questions. when i do a disassembly and have a relevant PCM on-hand, if i'm curious as to how often the loop is done and don't feel like or can't backtrack the code well enough, i'll look for a free byte of RAM and insert a small section of code that increments the RAM byte once per execution. then i setup the ALDL stream to transmit that byte in place of something unimportant and see how quickly it runs up.

[steveo]

yep that kind of timing logic, i'm familiar with.

i'm confident you've found it, my XDF is going to be so happy with this addition.

as you dont have a running EE car, i'm totally willing to blow my car up testing it with your instructions to ensure that we've actually found it.

the o2 calibration is pretty anemic in EE for sure, the only thing i have in my 'improved' xdf is o2 swing point vs CL mode. i've actually screwed with it a lot just to stop my car from BLM splitting, but im starting to think i've just been compensating for the fact that the delay wasnt available to me

having one o2 twice as far from the head as the other one is really annoying if you're obsessive about getting your AFR perfect like i am

[RobertISaar]

EE seems to have an O2 calibration method VERY similar to how it was done with the P66 V6 PCM, there don't look to be mean/rich/lean tables, simply a "target" table for each bank..... and surprise, they're different from left to right in a factory cal.

when i have it reasonably defined, i'll let you know. for now: 5 byte table at 26F1 is for the left O2, 5 byte table at 26F6 is for the right O2, those are the target O2 tables. a 5 value table directly after those is a 0-1 multiplier for ???(possibly INT delay), then two 5 byte tables after that, software O2 filter strength tables, left first, then right.

picking up at 270C: another 5 byte table, 0-1 multiplier but unknown purpose yet. 12 value table after that, it is VS O2 error. another 12 value table, again VS O2 error, looks to be INT delay multiplier vs O2 error. after that, 17 value table that looks to create the modified GPS flow for these calculations.



that is an outline of what i have so far. should cover most/all of the O2 and INT calibration tables.