[Oldman]

I'm trying to understand timing errors. It looks like they are directly related to acceleration of the engine and how the firmware processes the information from the index sample.

At 5000 RPM an engine is moving 30,000 degrees per second. At 7000, 42,000 degrees a second. If it accelerates from 5000 to 7000 in 2 seconds, the acceleration rate is 12000/2 = 6000 degrees per second. Since the crank moves about 90 turns a second, it would be 6000/90 = 67 degrees of crank advancement per turn. In two seconds that would let the crank rate speed up 90*67 = 6030 degrees per second or 12,000 degrees over the period, so this appears to check.


Since there are typically four position samples per turn, it would be a 67/4 = 16.75 degree error if the firing were simply delayed 90 degrees from each index. The acceleration error would be zero if it fired right on an index. It can't fire in advance of an index because it isn't there yet, it has to use indexes that are already gone.

Since old type engines always fired right on the index and advanced by physically moving the index around, they did not have this acceleration error issue.

I'm trying to figure out how the software reads the position sensor. Do they actually advance the mechanical reference point of the position signal indicator so it is slightly in front of the most advanced possible spark advance? If they did something like that, the error would be closer to zero than 16.75 degrees.

Say when we set the base timing to 10 advanced. Is that really setting the reference pulse to maybe 35 advanced, with the EEC software delaying it 25 to get a base of ten? If it did that and the spark advance was 20, the crank would only turn 15 degrees after index to spark. That means the error induced by acceleration would be 15/360 = .04167 of a turn times the 67 degree acceleration rate or a 2.8 degree error in the direction of excessive advance.

Or is there a sub-routine that figures out the acceleration rate and compensates it out?

I'm really just trying to figure out how the basic code handles this, because if the crank is speeding up it will be ahead of where it would be if were a steady speed for a given time after index.

[tvrfan]

(someone please correct me If I'm wrong !!)

I think this is what you are asking.....

As far as I know the EEC-IV has TWO modes for what you are asking.

Basically the box logs the time of the sensor 'tick' as it passes, and then calculates rpm instantaneously using the gap between the ticks (by recording the time they occur, not by waiting for them).
The box also knows ticks occur at a fixed point (e.g. 10 BTDC) for each cylinder. The sensor is fixed, it cannot advance and is always 10 BTDC.
Most systems have a Cylinder 1 marker as well, on most setups this is just a wider slot, which the box can recognize, leading edge is same timing as others.
SO how does ignition advance before this like the springs used to do ? I think that's what you are asking.

At low speeds (e.g. idle) the timing is fixed at the sensor point, and the box can't get the tick before this .....

So what box does, is it 'skips' one, and uses the tick for the previous cylinder as its timing mark ... this gives it lots of time to calculate, and it then adds a delay to THAT tick,
based upon current rpm and its lookup tables for degrees BTDC and other conditions (throttle etc). This means there is very little timing error.

(does that make sense ?)

[Oldman]

Basically the box logs the time of the sensor 'tick' as it passes, and then calculates rpm instantaneously using the gap between the ticks (by recording the time they occur, not by waiting for them).
The box also knows ticks occur at a fixed point (e.g. 10 BTDC) for each cylinder. The sensor is fixed, it cannot advance and is always 10 BTDC.
Most systems have a Cylinder 1 marker as well, on most setups this is just a wider slot, which the box can recognize, leading edge is same timing as others.
SO how does ignition advance before this like the springs used to do ? I think that's what you are asking.

At low speeds (e.g. idle) the timing is fixed at the sensor point, and the box can't get the tick before this .....

So what box does, is it 'skips' one, and uses the tick for the previous cylinder as its timing mark ... this gives it lots of time to calculate, and it then adds a delay to THAT tick,
based upon current rpm and its lookup tables for degrees BTDC and other conditions (throttle etc). This means there is very little timing error.

(does that make sense ?)

Yes. I didn't know the algorithm for calculation. I knew for sure there wasn't a little gypsy woman with cards predicting the future, so it had to be using a past PIP event to calculate position.

So what you saying, if I understand correctly, is both the low time window and the falling edge of the square wave peak are used for position, depending on speed. Is my understanding correct??

The reason I ask is I'm looking at a Excel spreadsheet I made that calculates maximum spark error based on engine speed change rate, number of reference points, and RPM. It looked like with 90 degree crank index and a typical RPM acceleration, timing could get near 20 degrees off if a previous tic (I guess that is what you call it) were used to trigger spark with zero degree timing ignition. That is because of the window width between tics of 90 degrees and the crank being ahead of where it would be if it wasn't speeding up.

I always did hardware design and never programming (beyond school in the 1970's and a Motorola 6800 processor in machine code.) :)

I assumed either they set the tic point just in front of the highest advance ever used and ran with that, which would lead to only a 20-25 degree maximum possible window where the crank could "get ahead" and a couple degrees maximum error, or they did some fancy thing where they learned the acceleration rate of the crank. I knew they had to do something.


I wonder if there is anything anywhere I can read on this? Thanks for your time on this.

[cgrey8]

From what I've understood, transient error is just something these older EECs suffer when under high rates of acceleration. I don't know at what point, Ford began compensating for this if ever. On acceleration, first gear and unloaded neutral is where this issue is most significant. The EEC requires a few PIPs to calculate the current RPM. But the actual RPM, while the engine is reving, can be much higher than the EEC believes it is at any given moment during the acceleration...and that's just in the calculation of RPM.

Then add in the propagation delay of acting on the latest RPM value. In 15MHz GUFx EECs, I believe the Fuel and Spark tables are processed in the background loop. When the RPMs get really high, the interrupts are coming in so fast, there's not a lot of time left for the background loop to run. As the RPMs get into 6000 range, the background loop may only complete an entire pass every 1 second and the RPM that the earlier calculations of the loop calculated with are different than calculations done later in the loop. But it's quite possible for the current commanded spark value to be when the EEC was calculating for 4000RPM/90% Load, but actual engine conditions could be 5500/85%. If the spark table differentiated greatly between those two conditions, then 5500 on the engine would be treated as though the engine was only at 4000.

I suspect things like injector PW and timing also get skewed a bit. At the time of the cylinder charge, the RPM and current air intake were one thing, but by the time the injectors are actually firing, the engine condition is something else. Thus it would be possible for 1st gear high RPM/Rev conditions (where engine RPM acceleration is highest) to actually result in different/higher/leaner AFRs than 4th gear would be at the same RPM/Load conditions (i.e. where the engine acceleration rate isn't as great).

I just assumed that newer EECs overcame this with a combination of brute-force and memory. With faster processors, you get more time for background loop processing. And with more memory, you can have different spark and fuel tables for lower speeds/gears. I'm not familiar with modern day EECs to know just what all they do and don't do. But with the computing power of modern day embedded processors and the low cost of flash/RAM, the options are far greater than they were in the 80s.

With the advent of surface-mount accelerometers, it'll be even easier for EECs to do things like detect actual acceleration rates so it can compensate for these type things. It can also detect loss of traction/control and respond to those conditions before the driver was aware of the issue. Embedded accelerometers have the potential to do more than that. EECs will be able to trend engine performance under real-world conditions and not just do adaptive learning of fuel control, but also adaptive learning of optimal shift-points to get the best fuel economy while cruising and optimal performance.

[Oldman]

Well, acceleration of the car has little to do with acceleration of the engine. It is the acceleration of the crank rotation that causes the skew, not how fast the car moves.

This is subject to any math error I might have made, but if the crank accelerates from 5000 to 7000 in 2 seconds, the rotation increases 6000 degrees per second. Since it rotates about 100 times per second, it has to increase speed about 60 degrees per turn. With four index points per turn, the maximum error when starting at one point and sparking before the next point (90 degrees later) would be 60/4 = 15 degrees. That is the maximum uncorrected error with 90 degree firing lag from an index.

The closer it fires to a tailing index the less error. If it fires 45 degrees after index without correction it would advance spark 7.5 degrees, if it fires 22.5 after index it would be about 3.75 degrees error. Since the crank, because of weight, can't possibly change rate instantly, it seems possible just to measure the time difference between two or three previous indexes and plot the change per index.

I'm reasonably sure Ford must do that.

If a processor does the match in eight clock cycles, a 15 MHz clock is .067 uS per cycle. That would be .53 uS per calculation. That's 1.8 million calculations per second if each calculation takes eight clock cycles. Of course a processor is busy doing many things, but it seems reasonable that there is time to watch several tics and plot the rate of change.

I'm just curious about this. I have a test fixture. I suppose I could use a sweep generator to sweep the RPM up and down and look at the actual spark timing, but I thought someone might know the code used to calculate crank position at spark time.

[tvrfan]

Er...to be honest I haven't thought about this in terms of degree errors.....hmmmm......I'm thinking about times

And Yes, I do remember something about leading AND trailing edge of the timing PIP being used.

From a programming point of view, on a 4 cyl engine, then there is a 'tick' every 90 crank degrees, (actually every 45 degrees, lead+trail edges, assuming 1:1 blade profile), and at what 6000 rpm, then there are 12000 sparks per min, = 200 sparks per second (or 200 Hertz) . This would give 5 millisecs between sparks. Even my old box had a 4.8 microsec base cycle (7.5Mhz), so it's still 1,000 opcodes or more, give or take.....plenty of time. At 4000rpm it's 133 Hertz = 7.5mS.

I'll have to double check, but it already occurs to me that if box uses interpolation of only this and previous PIPs to measure crank acceleration, the error can't be all that much....

What's the actual between PIPs acceleration in terms of time ? if it's 2 secs 4k to 6k then 1k per sec, or 20% (4k to 5k) increase in one sec, but interpolation is on every PIP, so even if linear accel, interpolation is already a max of 10% out (or less), so if high speed advance is say 30 degrees BTDC (reasonable ?) then it could be 3 degrees out......
NO - accel is linear - and spark occurs 30 degrees of 90 or 1/3 in time terms,is so for a quick headspace, then I am assuming max error would be 1 degree, one third of total error caused by accel.

(Is that right or have a screwed that up ?? .... happy to have my thoughts reviewed !!)

[cgrey8]

The thing you may be forgetting is that the EEC may be 15MHz, but the MBus out to RAM and ROM is only about 1MHz (effectively).

I come up with this because the control line strobe time on the MBus is 1/3rd the processor clock speed (5MHz). Then consider that fetching of data via the DAR takes 2 strobes on the MBus to indicate address. Roughly 1 MBus strobe time to settle, then 2 strobes to receive a 2-byte response. Even if all that the processor is requesting is a single byte, if the byte is in the high byte of a word, the MBus memory will transfer the low byte first anyway (little endian processor).

Instruction fetches are the only optimization over the MBus. The processor's Program Counter is mimiced in the ROM, called the Slave Program Counter (SPC). With the ROM maintaining its own SPC register, the processor can strobe its way through each byte of instruction data (i.e. opcode & the data the opcode operates on) without having to keep sending new memory address info. However if the processor ever branches, which happens a lot, that's another 2 bytes for the new memory address to update the ROM SPC before the processor can start strobing through instruction data again. What I don't remember is if the efficiency of "short jumps" translates to the MBus. But IIRC, the only thing short-jumps save is a byte in ROM instruction code space, not a byte in address update transfer on the MBus at execution time.

Point being, of the processor's 15MHz, there's a lot of wasted clock cycles just waiting for data to be pushed or fetched. So I don't think you can do a direct translation of MHz to opcodes the way you were. My guess is the clock cycles to execute each opcode is in ADDITION to the wait time to fetch it and its data from ROM and to push/pop data to the RAM (including stack data). So you may be looking at an average clock cycle count of 30ish/opcode, not 8 when you consider all the branches, subroutine jumps that do implicit stack data transfers, and the DAR data fetches.

[Oldman]

Maybe not. I don't know a thing about the Ford processor.

What processor does the A9L and other early stuff use? Must be some old Motorola stuff.

Do you know how it handles the PIP?

[cgrey8]

The A9L (and most of the 95-older) Ford EECs use the Intel 8061 which is a Ford-specific processor very similar to the Intel 8096. From 96-on, Ford needed more memory so they needed a multi-bank processor which is the Intel 8065. The MBus is similar to the 8096 with the SPC optimization to make execution a little faster.

There's a document that should give you an idea about the Ford hardware architecture:

eectch98.pdf

I guess it is worth mention that there is 256bytes of internal registers. So frequently accessed data is stored there, and opcodes that operate only on registers WILL execute at 15MHz rates. But the fetching of each opcode and the operands still have to come over the MBus...no avoiding that.

[85GT]

Keeping FN131 in play might have an advantage for fast accelerating engines. Vice tables for steady loads..

Hmm... now if there were WOT Spark functions for each gear, you could compensate for each gear's engine acceleration.

Wondering if base table and lugging function in conjunction with FN131 can be made to work in an unintended fashion for such situations.

[decipha]

no need, engine loading / cylinder pressure is directly correlated to airflow (load)

for any given load at any specific rpm the engine is only going to want so much timing (mbt)

drag and acceleration rate aren't going to affect that, if anything you'd only be compensating for the error in the calculation, which is better handled by resolving the issue rather than trying to band-aid over it (i.e. edis)

[85GT]

I think that's what their concern is, the error in the calculation based on the processing delay. Not sure how solve that issue given their existing hardware.