Instructions to change fuel maps on 14CUX Griffith, Chimaera

I dont know which version he was using, it was just odd how the fault showed itself with the loop back working, but not the ECU. Ill point him in the direction of the FDTI site and see what he says.

Dan
I've noticed from reading the Motorola MC6803U4 data sheet the microprocessor three timers run independently of the code, which I should of realised in the first place, sorry. I also notice in the ignitionInit code timers 1 & 3 are used for the injector banks. Therefore am I right in thinking the ignitionInt code only starts the timers and then the code continues executing leaving the timers ticking away on their own? That explains why the next ignition spark interrupt doesn't interrupt the timer early, if anything at very high revs the code could potentially re-start the timers even before the timers have had enough time to finish from the last spark interrupt, effectively holding the injectors open.

While reading the Motorola MC6803U4 data sheet it was also interesting to learn about the processor’s different operating modes, am I right in thinking the 14CUX uses mode 2 as the MPU Ram Location is $0040 to $00FF?

Yes, the timers run independently from the core processor and, if required, can stay open continuously. And I think you're correct about Mode 2.

The normal 6803 has one timer. The U4 version has three and, as I remember reading somewhere, was introduced especially for electronic FI. Two timers are used to drive the two engine banks and the third is used for the purge valve. I could be missing something obvious but I'm still unclear on why the standard 6803 wasn't used.

The fact that the banks are fired independently and out of phase with each other, using 2 timers instead of one, probably has more to do with distributing and reducing the current pulses required to open them, and reducing component current ratings. If the banks were wired together and driven from one ECU output, I don't think we could tell the difference.

Also, even though it's convenient to run the purge valve from a timer, it's slow duty cycle means that this could easily be done through a general purpose MPU output port.

Does it not simply do this as you have lambda control per bank? If you run the same injector pulse time on both sides of the V8 against the MAF reading, the resulting mixture is different between the two sides of the V8, I suspect due to the way the plenum is vented on one side.

On the lambda probe front It did occur to me that it might be possible to use the more common Zirconia lambda probes with the 14CUX- the voltage ranges are pretty much identical for rich or lean, and Id suspect the switching is faster on a modern probe. The input resistance of the 14CUX is very high so should not affect the probe output. Plus these probes are about £20 each, not £100. Only hurdle is the thread size is larger. The current set up is pretty crude- the AF ratio is all over the place even in closed loop- even running well it will bounce between 14:1 and 15:1 all the time.

Thats whats I mean, yes. If you want to try it- you dont need to put a new boss in yet- just remove the wide band probe you have and use that boss, (assuming its in the manifold not down pipe) then use RoverGauge to check the short term trim is cycling as it should with the the probe wired in- It would be easy to see if the two sides cycle at different speeds then as well. I think the reason for the resitive probes in the first place is they dont care if they get wet as they dont vent to the atmosphere for an oxygen reference, so ideal for a 4x4. Not really an issue in the TVR. I have some vague Idea about doing this myself- but Ive spent so much time trying to get the Amethyst set up and working (its gone back now as faulty now after a promising start), I need to do other things than lock myself in the garage for days.

That was just a bit in one of the tuning manuals mentioned is was fractional richer on the RV8 but I dont think you would ever notice if it was a point or two one way or the other as the cycling is slow and fairly crude at best. Its just if the new probes are faster it will keep it nearer lambda one with less overshoot if the ECU can keep up (?).

There is a saying that when you are too close to the elephant, all you can see is grey.

As it turns out there is nothing crude or slow about the way the 14CUX uses the Oxygen sensors in the exhaust, and you will see exactly the same behaviour on any modern car. The cycling rate increases dramatically with engine speed, so you can see that it is not a limitation of the system.

Taking a step back, you need to look at the reason why the vehicle is run on Lambda 1.0 in the first place, since this is not ideal for economy or power on these engines. It is certainly not for combustion efficiency, but rather more for correct operation of the three-way catalyst.

European legislation requires that all petrol-engined vehicles manufactured after January 1993 be fitted with a catalyst. It goes on to require that if they have a catalyst, they must be operated at Lambda 1.0 for certain parts of their operating cycle which is mostly warm cruise and idle. This same piece of legislation is the one that effectively killed all the promising research into Lean-Burn engines, as they were effectively outlawed. Things have got even tougher since then, but that's another story.

When a three-way catalyst is operating correctly, it will store Oxygen as a normal part of the chemical process. However it can only convert oxides of Nitrogen when the mixture is richer than Lambda 1.0, which is why the cycling of the mixture around Lambda 1.0 is vital. Oxygen is stored all the time in a healthy catalyst, but NOx is only converted in the rich side of the cycle. Since the catalyst effectively averages out the chemistry, the overall result is correct.

Using the Laboratory-grade Horiba Oxygen sensors (and nearly all the others too), the 14CUX always runs at 14.7:1 when it is on Lambda control. If you see something different, you need to check your calibration.

Personally I cannot see the point of changing to an inferior Zirconia sensor, even if it is possible since the original typically is very reliable and lasts around 80-120K Miles. Prices have come down in recent years too. If you are going to experiment, I would strongly recommend forking out for genuine Bosch version. They aren't much more expensive than crappy pattern items, but they are vastly more reliable and don't age badly. I have binned dozens of nasty cheap pattern sensors over the years.

Whilst I'm here (as I probably won't be back for some time), a certain amount of wooliness in determination of the road speed causes a soft-cut limit, rather than the more scary drop-dead type. The modern ECUs such as the Jaguar Range Rover Denso and even Land Rover Puma diesel Visteon go to great efforts to achieve this effect, whereas a simple lack of processing power can work nearly as well!

Steve, yes, one bank stops firing at the limit. The opposite bank is not fired instead, if that was your question. That bank waits for its normal turn in the sequence. As Mark Adams pointed out, this approach is an effective soft-cut and takes very little processing. The down side is all those VSS state samples along the way.

Dan,
When I started studying the full data structure and you comments in the code I noticed in the main loop that you say the high RPM ADC mux table is heavily loaded with extra road speed measurements. Therefore my first thought was would removing all the extra road speed measurements from the high RPM ADC mux table stop the road speed measurements above 4185 RPM? If so would that remove the road speed limiter above 4185 RPM and reduce the load on the processor. I’m sure you remember what happened the last time I change a mux table, lol, but at least we learnt something.


BUT!! More recently I’ve noticed in your RoadSpeed V2 comments that the main ADC road speed service routine is called from the main loop and I quote “Oddly, the 8-bit value measured at channel 7 (the VSS signal) by the ADC prior to entering this routine is not used” and I see you explanation why.

Does this mean the extra road speed samples in the high RPM mux table are wasting time, at high RPM, testing for idle and faults and not actually measuring the road speed?

In roadspeed asm you say the road speed calculation route (comparator test) is call numerous times from the spark interrupt. So does this mean the road speed is actually calculated via calls from the spark interrupt and not via the main loop mux table which I think answers my first question. Removing the extra road speed samples wouldn’t remove the road speed limiter above 4185 RPM as the road speed is calculated in the spark interrupt.

I’m now starting to question the benefit of the high RPM Mux table.

Cheers
Steve