Nistune Forums

I worked out that @ 7500 rpm max injector duty time is 16ms. How is it possible that Nistune reports more than this in its data logs? Am I missing something obvious?

Thanks

i have same problem on CA18DET,
# at idle:
- the reported injection time is 2.4 ms (consult gauge)
- on the fuel map it is something like 0.9ms,
- on the min inj time is something like 5ms.

anyway i have a Z32 AFM and 720cc injectors, this things probably screwed up the calculation/estimation (k and void time are not standard)

Interesting, everything on my ecu is stock at the moment.

Ed

Take the consult reported injection ms time as accurate

The injection/AFR on the maps are based from calculations I got from some old documentation, these same calcs are also used by Romeditor/LiveEdit which use the following calculation

TP Index * Fuel map value * Pulsewidth (0.125ms)

The pulsewidth hard coded value is meant to be the minimum pulsewidth for a CA18

However after looking at the way that AFRs are worked out I dont totally agree with the AFR/Pulsewidth/% that comes from these calculations which all these programs (including NIStune) use. Especially with regards to the way the O2 feedback flags are used. I'm currently looking into a way to make this calculation a bit more realistic

Of course... change the scaling or K constant and any of these calculations get thrown out the window

and the real pulsewidth value is in fact from what i understood an interpolation betwen the value from 4 cells and not the vaue from a single cell

Well this evening I fitted a Q45 MAF and 800cc injectors to a GTIR ecu, after trimming the K constant a bit the table values began to be real life again.

Matt, I mentioned interpolation between cells. I dont think you have implemented this in the software, and it really slows me down.

What i mean is if you highlight a row of cells say with random values of 2,1,1,1,10 you could then for example right click and choose interpolate row, and the row would then be 2,4,6,8,10. See what i mean? ideally row column and block should be possible say a block would just work between each corner.

I hope this makes sense. Also as I said to have ignition and fuel maps available at the same time. Other usefull information to display would be the AFR base (it may do this already) It would help trim in larger injectors by getting the AFR base to 100%

Would it be possible for the above to be considered as updates?

Other than that, the above car is going on a r/r tomorrow. I will have power figures to report back by the end of the day:)

Ed

Hi Ed

Matt, I mentioned interpolation between cells. I dont think you have implemented this in the software, and it really slows me down.

It depends what you mean by interpolation. What I was mentioning, was that in the maptrace, that the four cells used as the basis for interpolation and the primary cell are selected

However I wish to display in addition to this the NIStune determined interpolated value for AFR and timing ... this has not been done yet and is on my To-Do list

That would involve working out of the four cells, how much percent of each cell the maptrace is using in the ECU and then working out a total. This occurs on a X (TP) and Y (RPM) basis

What i mean is if you highlight a row of cells say with random values of 2,1,1,1,10 you could then for example right click and choose interpolate row, and the row would then be 2,4,6,8,10. See what i mean? ideally row column and block should be possible say a block would just work between each corner.

That makes sense and this feature had not even thought of yet. Basically you wish to have something like a select cells, then say CTRL-I to then interpolate them.

Unfortunately it is not as simple as what you have mentioned above, since that is one-dimensional interpolation

If you have a fuel map with say the following

1 1 1 1
[2 9 4] 1
[4 5 5] 3

Where just cells with 2,9,4 are highlighted, then if you wished to interpolate these, that is not too bad, since we would have a sliding scale between 2 ... 9 and then interpolate each value on this scale

However if you do 2,9,4 and 4,5,5 on the next row, then 2D interpolation would be required...

There is also the case where you may wish to take the surrounding cells into account (including above and below). This requires further 2D interpolation which requires for each cell, taking an average of the 8 surrounding cells. But I dont think you wish to go that far?

Also as I said to have ignition and fuel maps available at the same time

Enable this under File - Configuration - Multiple Windows and also disable docking

Other usefull information to display would be the AFR base

Sorry, dont understand this one. what do you mean by the AFR base?

I didn't use the right term for that. In programs such as Nissan Data scan there is the A/F base which should usually be around 100 ish. It may already be possible, but can this be included or brought up some how is a little window or something? It would help when sizing injectors and changing the K value, if im thinking along the right lines.

The interpolation feature does not need to be in any way over complicated, or clever. Its a common feature in almost every mapping software I use, and it greatly speeds up the map building process. It just has to be as simple as i said really.

NIStune also provides a consult AFR modification which is in terms of percentage of AFR starting at 100%. This is available under one of the diagnostic adjustment panels

However this modification is only changing a built in RAM location within the ECU for diagnostics to temporarily adjust the AFR. The ECU uses this and calculates it on a percentage basis


The global K constant adjustment also modifies base AFR, but it is a 16 bit value and I dont know the % associated with each change for each individual ECU to make a similar decoded assessment.

Ie a K constant change of 16 on an RB30 will have more impact than a similar change on an SR20


I will add some interpolation from what you mention. Can you suggest some other mapping software for me to look at to see how to follow the logic?

Heres some, E-manage (both blue and ultimate) Power FC (datalogit) though this is not as nice, and also omex.

E-manage ultimate has the nicest way about it. Software is freely available here: http://www.mohdparts.com/emanage/pc/ult ... 9_full.zip

RE the AF base, if you could have a window just showing what the RAM location is reading, would be fine. Then I could with larger injectors adjust the K value manually until the AFbase is showing 100% again.

thanks for the link. i'll have a look

in regards to the AFR base... If you change the K constant, this RAM value does not change. It is only modified by consult... and used as part of a big calculation to work out pulsewidth. I suspect this is used at the end of the pulsewidth adjustment calculation and just adds/minuses a % of that pulsewidth

When you change K constant, the ECU / NIStune will not know what the base AFR is any more to make a % reading (especially if you change injectors or AFM)... trust me I would if I could display this

However.... perhaps there is another value in the calculation in RAM I can monitor, prior to getting into the tables.

I'll put an investigation item into this to have a look...

Ok Its not something I want to change, I just want to know what the value is when I am mapping a car.

Back to original Q - how is inj. time calculated?
On my CA18 it changes rapidly by as much as 2 times in certain areas of fuel map Of course my AFR doesn't do that in reality

Back to original Q - how is inj. time calculated?
On my CA18 it changes rapidly by as much as 2 times in certain areas of fuel map Confused Of course my AFR doesn't do that in reality

This would be somewhat of a difficult question to immediately answer. Final injection time calculation is very cryptic within the code, mainly because the primary MCU is not performing injection control itself. Rather it passes variables to a companion processor that actually takes the variables and turns it into a real pulse.

On ecu's that do not have native consult (as provided by original engineers) you can only rely on code comparision, and/or real time reverse engineering. Because fuel calculations (ex.TP formula) vary between ecu, the first method could be potentially difficult. The second method would simply take a lot of time and would generally be specific only to that ecu.

So Vetal, I believe Matt is working on answering that question and then applying in your software, it will just take a short amount of time (hence adding an investigation item).