Instructions to change fuel maps on 14CUX Griffith, Chimaera

[davep]

danbourassa said:

...
So, there needs to be a shot of fuel injected toward each intake valve for every engine cycle. This is why a bank of injectors is fired for every 4th spark. There are two bits in the interrupt that are toggled in a binary counting pattern (0,1,2,3,0,1,...) that keep track of this. Let's call them A and B.

  A   B   Interrupt
---------------------
  0   0    Right Bank (fuel)
  0   1    Right Bank (no-fuel)
  1   0    Left  Bank (fuel)
  1   1    Left  Bank (no-fuel)
  0   0    Right Bank (fuel)
  0   1    ...and so on

The non-fuel interrupt does less and returns to the main loop sooner than the fuel interrupt, since some of the code is skipped. VSS state sampling code is distributed throughout the interrupt and a couple of VSS samples are skipped along with the code. That's the only reason the short interrupt has fewer samples.

Edited by danbourassa on Monday 7th April 17:14

Dan, that's a lot clearer now thanks. Just one further point, the 14CUX LR docs state:

"Banks are operated alternately except at start-up when simultaneous operation is used to provide additional fuel to the system. Injectors are shut off during deceleration."

So I presume the 2 digit bank control table is overridden (or extended) during cranking (both banks fuel and contiguous fuel interrupts) and deceleration (both banks no fuel and contiguous no-fuel interrupts)?

The pulseWidth graph below clearly shows the drop towards zero on deceleration:

[danbourassa]

davep said:

So I presume the 2 digit bank control table is overridden (or extended) during cranking (both banks fuel and contiguous fuel interrupts) and deceleration (both banks no fuel and contiguous no-fuel interrupts)?

Dave, I see that you are already busy logging injector pulse width. Colin will be happy that his efforts are appreciated.

Before you take that LR document too seriously, note that they also say "a maximum of approximately 9.0 milliseconds at full load" and you already show a spike well over 10 milliseconds.

There is never "simultaneous operation" although there IS a short period of double rate injector pulsing. During this time, there is no non-fuel interrupt, so each bank is fired every 2 sparks instead of every 4 sparks. This period of time can easily be changed. The 16-bit variable at $009D/9E is initialized to 192 decimal at power on. The 14CUX software double injects for this many sparks after start-up. This is equivalent to 48 engine revolutions and lasts about 3 seconds. If you want to reduce fuel a little quicker at start-up, you might want to try reducing this number. It is not in the data section but can be found under reInitVars in file reset.asm.

[spitfire4v8]

danbourassa said:

So, there needs to be a shot of fuel injected toward each intake valve for every engine cycle. This is why a bank of injectors is fired for every 4th spark. There are two bits in the interrupt that are toggled in a binary counting pattern (0,1,2,3,0,1,...) that keep track of this. Let's call them A and B.
{{{
A B Interrupt

---

0 0 Right Bank (fuel)
0 1 Right Bank (no-fuel)
1 0 Left Bank (fuel)
1 1 Left Bank (no-fuel)
0 0 Right Bank (fuel)
0 1 ...and so on

Hi Dan .. struggling with this a little bit.
In the code above we have 2 injector events in 8 sparks, ie two injector events in two complete engine rotations. So each bank of injectors is fired only once per bank in every two engine rotations.

This is where I don't understand things :

I know from my aftermarket ecu installs that the std injectors max out at around 340hp, but that is firing each bank every 180 degrees of crank rotation, ie each bank of injectors fires twice for every two engine revs : four firing events in total per two engine revs.

On this basis on the lucas the injectors should max out at around 170hp because there's half the number of injector firing events in that same two engine rev cycle, therefore half the total fuel injected, compared to my aftermarket ecu.

This doesn't happen though .. I have run the lucas on std injectors to well over 300hp.

It's early morning, so what have I missed that's blindingly obvious, but which right now doesn't add up?

Edited by spitfire4v8 on Wednesday 9th April 07:15

[danbourassa]

Hi Joolz,
I'm thinking that frequency of injector pulses is not as important as how long they are ON. A 1 mSec pulse every revolution should be roughly equivalent to a 2 mSec pulse every 2 revolutions (the relationship is not completely linear). The maximum fuel that can be delivered is when the injectors are constantly ON. The 14CUX does have the capability to keep the injectors ON constantly so, given a fixed set of other components (injectors, fuel pressure, etc.) more fuel cannot be delivered.

Now that I think about it, the lower injector frequency is probably better. Less wear and tear on the injectors and constant flow sounds like higher fuel delivery than stopping and starting. I don't know yet whether the 14CUX stops and immediately restarts the injectors even when fuel delivery time is 100% but I've been meaning to investigate this. I think it would be better if the injectors were left ON and the control timer was just renewed.

I should explain that in the latest version of RG (0.7.1) that the new fuel bar graph shows injector ON time as a percentage of available time. As an example, assume 3000 RPM. This is 50 RPS or 20 mSec per revolution. Since there is one injector event per bank every revolution (every 4 sparks), a 10 mSec injector pulse would show as 50%. At 6000 RPM (assuming we could still communicate with the ECU) the same 10 mSec pulse would show as 100%. Colin and I discussed this quite a bit and decided that this was a better way to display the information. Especially since the actual value is also being displayed.

[danbourassa]

spitfire4v8 said:

In the code above we have 2 injector events in 8 sparks, ie two injector events in two complete engine rotations. So each bank of injectors is fired only once per bank in every two engine rotations.

Joolz, I went back and read this more carefully and I believe what you are saying is wrong. Each bank is being fired once every 4 total sparks (not just the sparks for that bank) so this means that both banks are fired once for every single rotation.

[spitfire4v8]

Sorry Dan i've misinterpreted the original posting then. I know I can't be right but couldn't work out where i was going wrong .. I read it as each bank only fires once per two engine revs, which with a max injector duration of 9 or 10ms wouldn't give you enough fuelling for over 300hp. I know from practical experience that you CAN get over 300hp on the lucas, so I knew I was wrong.. just not interpreting the text properly ..
I'll go back over in the corner ..

[stevesprint]

danbourassa said:

Joolz, I went back and read this more carefully and I believe what you are saying is wrong. Each bank is being fired once every 4 total sparks (not just the sparks for that bank) so this means that both banks are fired once for every single rotation.

Dan,
How is the injector opening time not cut short by the next spark interrupt?

[danbourassa]

stevesprint said:

Dan,
How is the injector opening time not cut short by the next spark interrupt?

Steve, an injector bank is only affected by every 4th spark but it seems to me that the larger, high-revving Rover V8s can max out the injectors. For example, I believe the TVR 500 has a 6188 RPM limit. This (if I did the math correctly) equates to 9.7 milliseconds between injector events on a given bank. Dave has already showed us that the ECU can demand more than 10 milliseconds worth of fuel but the available time doesn't allow it. I was simply wondering, in my earlier post, how the 14CUX software handles the condition of turning ON the injectors when they are already ON.

[spitfire4v8]

What revs was that 10ms spike at though? because obviously at slower revs there's more time available ..

[danbourassa]

spitfire4v8 said:

What revs was that 10ms spike at though? because obviously at slower revs there's more time available ..

That's true but I imagine that if 10 ms was required at lower revs that it could also be required at the RPM limit.

[spitfire4v8]

Indeed .. I can't think of anything causing a fuelling spike other than a very rapid press of the throttle and a lot of acceleration enrichment going in which of course wouldn't be needed at larger throttle openings / high revs. Was the spike seen measured under a peculiar set of circumstances not normally seen. Seems strange that the literature suggests the ecu won't supply an injector duration that long (?), and yet in the real world it's been measured ..

[davep]

Spot on Jools. Here's the corresponding rpm trace, throttle blips at idle. Note the higher spike occurs at lower revs though:



The injector pulse time duration trace:



This longer injection on time at lower revs characteristic looks like the injector timer is trying to fill or maximise the increase in available time to provide more fuel.

I shall be doing some road tests to log pulse width at consistent rev levels (1700, 3400 and high) for longer durations during the next few days. Using this data I hope to get the injector/bank timing diagram I'm working on into a more meaningful shape.

Couldn't upload the log traces any earlier as Thumbsnap was offline.

Edited by davep on Tuesday 15th April 09:45

[danbourassa]

spitfire4v8 said:

Indeed .. I can't think of anything causing a fuelling spike other than a very rapid press of the throttle and a lot of acceleration enrichment going in which of course wouldn't be needed at larger throttle openings / high revs. Was the spike seen measured under a peculiar set of circumstances not normally seen. Seems strange that the literature suggests the ecu won't supply an injector duration that long (?), and yet in the real world it's been measured ..

Maybe I'm the one who needs to go to the corner. I wasn't thinking about rapid throttle press as being a strong factor in this.

[FFMan]

As I'm working on a small 14Cux interface with Bluetooth/Android display I read this post from time to time with interest. People here are really getting into the detail of operation.

Is all this work translating into new code/maps and improved drivability or power, or is a more flexible ecu required to get more out ?

[danbourassa]

I doubt if more power can result from all this but improved drivability and many other things are possible. Dave has already demonstrated that certain things can be fixed in software (in his case, road speed calibration). We can now properly extend the RPM table. Want a different idle speed? No problem. Less fuel on cold start-up? Can do. I suppose others on this thread would, themselves, need to answer the question of why we bother doing this. For me, this started because I just can't tolerate not understanding something and being dependent on others. Now it seems like a hobby more than anything else and I feel like I've received as much or more as I've contributed to this thread.

Certainly, new fuel maps are one result. Steve is doing this. I'm planning a major restructuring of the code that will address the VSS strobing problem, serial port bandwidth and other issues. I'm also thinking about over-clocking. The 14CUX has a 4 MHz clock and every board design has margin. Raising this by 10 or 15 percent is within reason and will be huge at the RPM limit. This would raise the baud rate by the same amount but it's not a problem for the FTDI chip. Nerdy stuff for sure, but great fun for some of us.

[davep]

^^^^^^^^^^^
What Dan said. Plus making the acquaintance of some fellow 14CUX enthusiasts.

Also I'm looking forward to seeing the size of the heat sink.

[FFMan]

Its good to understand this stuff, and a mild over-clock would help. From my side, non-standard baud rates not an issue, my uart supports anything.

Will be road testing the Android monitor this weekend I hope - just boxing it up. Quite how the bench work translates to real-world use will be interesting. Generally there are new issues to be resolved

If it was easy it would no fun !

[davep]

danbourassa said:

spitfire4v8 said:

What revs was that 10ms spike at though? because obviously at slower revs there's more time available ..

That's true but I imagine that if 10 ms was required at lower revs that it could also be required at the RPM limit.

During road testing yesterday try as I might I could not get the pulse width to exceed 10.23 mS, and this peak was hit only very briefly during sustained rapid acceleration/load/high revs.

Some traces for rev range and pulse width at 3400 rpm, which show how pulse width varies across the range even at a stable engine speed:




I must say it's interesting to be able to monitor the 14CUX's output now.

[blitzracing]

Anyone tried RoverGauge on Windows 8 yet? I had a guy on Ebay say he could not get the receive signal back from the ECU on windows 8, but it worked perfectly on Windows 7. It did not make a lot of sense, as you could get a receive signal back with a loop back wire, so that would imply that the TX signal was wrong in some way, so the ECU was not responding---wierd

[davep]

blitzracing said:

Anyone tried RoverGauge on Windows 8 yet? I had a guy on Ebay say he could not get the receive signal back from the ECU on windows 8, but it worked perfectly on Windows 7. It did not make a lot of sense, as you could get a receive signal back with a loop back wire, so that would imply that the TX signal was wrong in some way, so the ECU was not responding---wierd

Mark, I use Windows 8.1, no problems. Perhaps reselecting the COM port might solve it.