Nistune Forums

Sorry I meant the ECU does not tell me which tables its using. Apart from reading the knock map flags, the rest I have to work out from the consult information available

Hmmm ..
That is a shame because I was thinking that the map highlighting was based on what was actually happening inside the ECU.
Now it seems it's more the result of a statemaschine you wrote?

So there's no further wisdom to be found in the highlighting, or is there?

Matt wrote:Sorry I meant the ECU does not tell me which tables its using. Apart from reading the knock map flags, the rest I have to work out from the consult information available

If you wanna work out what's actually happening inside the ECU then get a couple of emulators and dig in!

PL

Hi Pete,

By 'inside' I was referring to a display of the tables actually accessed.
I mistakenly assumed the map highlighting would somehow receive this data directly from the ECU.

It's good that this has been clarified now ..

We can only work with the info that comes from the diagnostic port. Matt can do code changes to do some sneaky stuff but the bottom line is that you don't have full access unless you use an emulator and really dig into it. Then you can get a trace of what's being accessed when inside the ECU.

I'm sure Matt will clarify when he gets a moment.

PL

By 'inside' I was referring to a display of the tables actually accessed. I mistakenly assumed the map highlighting would somehow receive this data directly from the ECU.

Proper map highlighting and tracing is only available by using hardware maptracing. This is where dedicated hardware monitors address hits and then sends that information back to the PC. This is available with Nistune when using Moates Ostrich 2.0 emulators. There is an option 'hardware tracing' which will show pink cursor highlights of hit maps

However that does not highlight tables currently in use, because generally many tables are read but not all the information is necessarily used during certain conditions

The idea of map highlighting is to take for example when TPS=IDLE then we know only idle maps are being used. Or if the knock flags is active in the ECU then we know the knock maps are used. The table highlighting is then taken through a series of tests by checking reported tables against hardware maptracing to verify its correctness. In certain conditions I may have to modify the behavior further like in this case to improve its accuracy

Thanks Matt,

You once mentioned that you modified the consult routines and as a result
I was under the impression that the map-highlighting is actually hard data coming from the ECU.

When the highlighting first came up in one of the NT versions I thought that is great
since now I exactly can tell from the cursor which map is being used ..

However I already grew ,suspicious, when map highlighting was still happening in log playback.

What can be said now is that the high-lightening is an indicative display only.
It is based on your understanding of the ECU but it is not entirely based on hard data.

I think this should be made clear in the manuals ...

Cheers ..

Nistune firmware modifies consult routines to allow write, PIN locking and STORE (burn) operations to the NvSRAM on the Nistune board. That firmware is probably over 5 years old now but there are no ECU specific operations in there

It is not possible to determine which tables are used without extensive modification to each ECU code base to record such things

Table highlighting and has only appeared mid last year with no changes to the firmware. I added an extra read command to look at the knock flags, and then the following logic in the Nistune software. Map tracing has always been in there (even with a factory ECU it is available)

That is how the tracing and highlighting works on log playback... by using the same parameters (we now also record the knock flags)

It is the intention that table highlighting is accurate for all intensive tuning purposes, especially given that I know most tuners I assist with tech support don't even read the manuals. An example was the bug with the backwards highlighting for Z32. So this particular enrichment table will be fixed in the next release

There're additional enrichment coeffs and tables (Z32):

151C contains a calculated value issued originally from 7EB0/7F30 tables
141C-1D contain a multiplied value from 151C and a value interpolated by rpm/2 from the table 7600. 141C-1D is really used as an injection offset to the final pulse, so 7600 table decreases the enrichment according to RPM
156D contains an enrichment coeff. issued from a skilful calculation with these tables used as input:
_7F60 table is used if in neutral and interpolated with rpm low byte (3187 rpm max=255*12.5)
_7F70 table is used if in gear and interpolated with rpm low byte (3187 rpm max=255*12.5)
_7FC0 table interpolated with engine_temp

On Z32, 156D is always 0 because all the tables 7F60, 7F70, 7FC0 contain 0x80 everywhere (and 0x80+0x80=0)
151C is substracted from 156D, but never taken into account because negative.
So, only 141C-1D has an influence on warm-up enrichment.

Complicated story with this enrichment tables around crank an warm-up. I think all this tables were only made for the emission test. The Europe emission test cycles simulates from a cold start on, cruising through quarters with 30km/h, than through villages with 50km/h, out of town 80km/h and finally on the highway with 120km/h. All with quite less throttle on a dyno under standardized conditions. http://en.wikipedia.org/wiki/European_e ... _standards

The problem is that the Jap-import vehicles have another test cycle (i think without cold start), that’s the reason for different O2 feedback temps in different countries.
We have to drive such a cycle with every import-car that was never official homologated in Switzerland, or if you modified an engine on a homologated car (as example only open Pod filter, or theoretical a tune with Nistune). The limit values for these Euro-cycles are very strict and the main problem is that the Japimports were made for the Jasma cylce and they don't pass the Euro Cyle without modifications. So we have to plump, modified and test every single import car in a very very expensive labor. That's the reason why we are nearly the only company, which can homologate Skylines, S15 or high modified cars in Switzerland. The last car hasn't passed the euro cycle. I was able to bring the emission over 100% done with a retune with Nistune. Thanks to god an Matt for Nistune You will be surprised how bad the standard Nissan maps are…

The new understanding of the new tables can be a very good base to improve emissions for the Euro test. It will be great, if Matt could integrate this information in small info windows that pops up, when you stay a while with the mouse on a table.

What do you think about?

A&M-Motorsport wrote: You will be surprised how bad the standard Nissan maps are…

Could you elaborate ?
Fuel map ? Regular timing map ? Enrichment for warm-up ? Cold/warm start maps ? advance when cold ?

I have this marked for including to the next build. Yes I will investigate and add the tables in as required. Work on that early next week

151C contains a calculated value issued originally from 7EB0/7F30 tables
141C-1D contain a multiplied value from 151C and a value interpolated by rpm/2 from the table 7600. 141C-1D is really used as an injection offset to the final pulse, so 7600 table decreases the enrichment according to RPM

I've read this section of the code and that makes sense. I will add RPM enrichment table to the Z32 address file

Other addresses I'm confused with. From my 41P03 JDM disassembly:

7F60 - Warmup timing table (15 degBDTC ... 20 deg BDTC)
7F70 - Timing knock count limit (constant)
7FC0 - Unknown constant (value 07)

multiplied value from 151C and a value interpolated by rpm/2

Hardware trace shows this is not RPM / 2 but 0 -6000rpm like other tables

Adding this to Z32 address file is sufficient to add this table to Nistune:
RPM_ENRICH,&H7600,16,1,16,1,RPM enrichment multiplier of coolant temp enrichment

Are these/this RPM-Enrichment=Table based on K, or basically just an adder?

K is still part of the multiplier and these tables are another part as a conditional mutliplier (condition being coolant temp) used in total fuel injected

Cranking is the main place where K is not used