Nistune Forums

Just wondering if this could actually be done with NIStune? Totally remove the need for the MAF and it's limitations, just a 3-bar MAP sensor and an IAT sensor. Would mean no more worrying about intake pipework at funny bends or changing diamteter, etc.

Would also give much better low load drivability. Obviously would not be an easy task and would need a lot of work, but I would love to see it implemented into the stock ECU. TBH, I reckon with speed density and 3-port boost solenoid control (as per my other thread) the stock ECU and NIStune would become more attractive. I still see lots of people opt for the A'Pexi PFC when there is no need to. I used to see the same with Evo's not too long ago. Everyone used to go standalone (A'Pexi PFC, GEMS, ViPec, Motec, etc) or Piggy-back (AEM, Greddy e-manage, etc). However, with recent developments the OEM Evo ECU can do everything aftermarket can and more, such as...

• Twin Maps
• Valet Mode
• CEL on knock
• Speed Density
• 3-port boost solenoid control
• NLTS (No Lift To Shift)
• Proper Anti-Lag
• "Pops & Bangs" (mild anti-lag between gear changes)
• etc

All these things above, with the ability to keep the stock ECU and limp home mode, OEM diagnostics, etc has made people in the Evo scene shift from standalone and piggy-back to just using the OEM ECU and getting it remapped.

It has taken a long time, and LOTS of open-source development to get the Evo ECU where it is now. I would love to see the OEM Nissan ECU follow the same path.

I think the issue with the Nissan ECU is the hardware limitations of what the pin function is available to do.

I know one guy on HybridKA forum (Before it was hacked and taken down) was working on a MAP conversion table and an elarged cell tuning area and a few other things. I don't know what ever happened with that project but i know there were a few issues still to be overcome at the time.

Example, NLTS requires a clutch switch input to the ECU or some other way of the ecu knowing that the engine is about to be disengaged for a gear change. Few ways around it, example while the TPS=100% you could monitor the neutral switch (add a secondary switch) and if that is tripped while at full throtle that could be a signal that you want to flat shift, but all this stuff requires a lot of code time to implement, which there isn't a lot of room in the factory rom. Especially after nistune does their consult patch, that takes up more space.

A few of the features you speak of can be done with the use of a multi map non-realtime board such as the PLMS Developments board which can do 4 maps on the fly switchable. You can do no lift to shift with the addition of the clutch switch, valet mode with a hidden switch to enable another map that has got a low speed/rpm limit (or one that disables the car).

(EDITS to add things i thought of after posting.)

I have a map/iat setup using a 300ZX/Z32 ECU on my own car for almost 2 years now and it works very well.

Although, I'm not sure how it's done on the EVO ecu, but in most Nissan ECU's there is no room for a 'learn' function (due to the very limited memory in most older Nissan ECU's).
Meaning, a seperate computer was installed in the car for a couple of weeks and this computer created the correction tables and VE map based on AFM, MAP, IAT and a few other sensor signals.
I then copied these tables/VE map into a 300ZX ECU with modified code and the AFM was permanently disconnected/removed.

I used the same principle on another 300ZX, but the maps the seperate computer came up with were quite different... perhaps due to slight engine/intake variations and/or sensor output variations.

I haven't done any more tests to see if there's a pattern or if it's possible to create some sort of base VE map.
But even with a base VE map it will be extremely difficult/impossible to implement some sort of onboard correction or learn function which will correct the base VE map to something that will be ideal for your engine/setup...

I'm sure in the later and much more sophisticated ECU's as used in eg. the 350Z it will be possible to handle all functions, but for the older Nissan ECU generation you will probably always have to (temporarily) use a seperate computer to be able to get it working near perfect. (IMO)

The other problem that people often overlook is that, although some code re-use exists, all the Nissan ECU families are different. So the effort put into say a Z32 ECU would need to be largely repeated to add the same functionality to an SR20 ECU.

Often this sort of stuff comes down to individuals like Eric who know the code for one particular family of ECU's intimately. People with a personal interest in a certain vehicle. They then have the motivation and hopefully the time to really get to know their ECU. Unfortunately it's just too much to expect Matt to re-write code for all of them.

I suspect the EVO success was largely due to the open source development you speak of. Having lots of people helping would share the load. But often you'll find that once somebody spends days and weeks investigating code and getting things working then they become a lot less keen to share!

PL

PL wrote:The other problem that people often overlook is that, although some code re-use exists, all the Nissan ECU families are different. So the effort put into say a Z32 ECU would need to be largely repeated to add the same functionality to an SR20 ECU.

Often this sort of stuff comes down to individuals like Eric who know the code for one particular family of ECU's intimately. People with a personal interest in a certain vehicle. They then have the motivation and hopefully the time to really get to know their ECU. Unfortunately it's just too much to expect Matt to re-write code for all of them.

I suspect the EVO success was largely due to the open source development you speak of. Having lots of people helping would share the load. But often you'll find that once somebody spends days and weeks (or months!) investigating code and getting things working then they become a lot less keen to share!

PL

Never a truer word spoken !!!

This kind of happened on the nissan ecu forums. Gabes project on hybridka was looking promising but there is a lot of work to it. at the moment I'm adding table highlighting and rom check summing. Over 60 ecu code bases to patch and check it starts taking a long time for a relatively simple code mod

This kind of happened on the nissan ecu forums. Gabes project on hybridka was looking promising but there is a lot of work to it. at the moment I'm adding table highlighting and rom check summing. Over 60 ecu code bases to patch and check it starts taking a long time for a relatively simple code mod

Do you really need to do it as a VE Setup.

The Wolf V4 uses the map sensor as its load point and will then add in fuel correction based on an IAT Sensor.

Why cant we do the same with the Nissan ECU or at least something similar.

Here is something i have been thinking about for a while.

Remove AFM and plug in a Map sensor and a IAT sensor.

Feed the input of both sensors in to a PIC/AVR controller <- Or a similar device.
You program this device to Read the voltage of the Map sensor. Determine what the pressure is.
Read in the IAT Sensor voltage and Determine the air temp.

Now what we want to do here is output a load signal back through the Standard MAF wiring. That uses the MAP and IAT data.

You could even build in the VE table functionality into the PIC/AVR controller. Or just use my correction method.

Correction method would be based on air expansion at certain temps.

For example: <- Warning made up values are being used here.

at 35deg air is 2% less dense that air at 30deg

So if you controller bases 0% Correction at 30degs then at 35degs you add a total of 2% to the signal being sent back to the nissan ecu.

Any thoughts feed back on this idea? Let me know why this wont work? Or why you think it will work?

wish it was that easy
your conversion method will only work for one small specific rpm range

As you are forgetting at least one important variable in the equation to convert a speed density signal to an airflow signal, which is RPM (TPS is also an important variable, as throttle position basically alters the VE)

airflow is quite different from absolute pressure.
example: at 1000 rpm your absolute pressure sensor may output 1 volt and the AFM sensor outputs 1.5 volt
at 6000 rpm the absolute pressure may be the same and the sensor still outputs 1 volt , but your AFM is now outputting 3 volt, as an engine at 6000 rpm is pumping around a lot more air then at 1000 rpm, causing the airflow to increase.

This is where the VE map of the engine comes into play

crans wrote:Do you really need to do it as a VE Setup.

The Wolf V4 uses the map sensor as its load point and will then add in fuel correction based on an IAT Sensor.

Why cant we do the same with the Nissan ECU or at least something similar.

Here is something i have been thinking about for a while.

Remove AFM and plug in a Map sensor and a IAT sensor.

Feed the input of both sensors in to a PIC/AVR controller <- Or a similar device.
You program this device to Read the voltage of the Map sensor. Determine what the pressure is.
Read in the IAT Sensor voltage and Determine the air temp.

Now what we want to do here is output a load signal back through the Standard MAF wiring. That uses the MAP and IAT data.

You could even build in the VE table functionality into the PIC/AVR controller. Or just use my correction method.

Correction method would be based on air expansion at certain temps.

For example: <- Warning made up values are being used here.

at 35deg air is 2% less dense that air at 30deg

So if you controller bases 0% Correction at 30degs then at 35degs you add a total of 2% to the signal being sent back to the nissan ecu.

Any thoughts feed back on this idea? Let me know why this wont work? Or why you think it will work?

Isn't that what the fuel map is for?

5psi at 2000rpm use this much fuel
5psi at 5000rpm use this much fuel

All i am suggesting is changing where the load comes from.

PL wrote:The other problem that people often overlook is that, although some code re-use exists, all the Nissan ECU families are different. So the effort put into say a Z32 ECU would need to be largely repeated to add the same functionality to an SR20 ECU.

Often this sort of stuff comes down to individuals like Eric who know the code for one particular family of ECU's intimately. People with a personal interest in a certain vehicle. They then have the motivation and hopefully the time to really get to know their ECU. Unfortunately it's just too much to expect Matt to re-write code for all of them.

I suspect the EVO success was largely due to the open source development you speak of. Having lots of people helping would share the load. But often you'll find that once somebody spends days and weeks investigating code and getting things working then they become a lot less keen to share!

PL

I totally agree with you there mate. Having done dis-assembly at uni it's not something I want to do again any time soon TBH! I HATED it and do not envy the likes of Matt and other guys who dis-assemble these ECU's to enable us to remap them. My degree was a joint one between Electronic Engineering & Computer Science (2/3 engineering, 1/3 comp science). Needless to say I aced the engineering aspect of the course, but did not do too well on the comp science, purely because I hate software and love hardware. :p

As you say, the success of the Evo is most definately due to the open source community. Just look at the likes of ECUtek, they are a company who have been able to remap the OEM Evo ECU for far longer than any open source stuff has been out for, but they are obviously quite secretive about their work. As such, they don't have ANY of the extra features available that the likes of EcuFlash has thanks to open source.

Also, I am not sure about the Nissan ECU's, but when you look at an Evo ROM in the likes of IDAPro you can see that less than half the ROM is actually used and there is lots of free space for people to write code for all these extra features. Now I'm guessing Matt should be able to tell us whether or not this also applies to the Nissan ROMs or if they are pretty much full as it is after being patched??

Like you said, it also comes down to what processor you are working with, and doing it with 1 does not mean it can be copied over. Again, back to the Evo scene, most of the extra features I listed above were only available on the Evo 7 ECU onwards because it was mainly Americans who were working on it, and they don't get older Evo's over there, just from the 8 onwards. So only very recently has the Evo 5/6 ECU been coded to add these extra features, because what worked on the 7/8/9 ECU did not work on the 5/6 ECU's.

It most definately would be A LOT of work, but seeing the OEM Nissan ECU do more than what a lot of aftermarket systems can do would be immense. I would love to see everything on the list above there one day, but for now Speed Density and 3-port boost control are top of my list for what I want to see.

I bow down to the likes of Matt who have the patience to sit and dis-assemble these ECU's with little info at hand and having to do lots of trial & error. Not something I could ever do TBH. Like I said, I prefer hardware to software any day of the week.

He he he - I'm a bit of a hardware guy myself, so I feel where you're coming from!

PL

Being a raging alcoholic (methonal injection) I have considered a coolingmist smart controller to convert the various sensors then sending signal to the ecu via the maf signal. You can have up to 4 sensor inputs and program their interaction with each other to send a single signal out. Basically you'd be programming your own mapecu. I'm online chatting with coolingmist right now to see what they think.......

There is not much room in some ECUs to actually fit any extra code in. For example B14 SR20DE I had to squeeze around 0x2600-0x2800 in the memory space to fit the various part numbers. Below this was IO addressing and above this at 0x3000 is the RAM mapping and ROM at 0x4000-0xFFFF

Q45 VH45DE had no spare ROM at all. Had to pull out the high gear maps to finally get this one done. Nistune patch code is under 512 bytes to fit in the 0x200 memory space. Once I start adding more features it just wont be available on certain ECUs just due to size limitations

Interesting subject.

Tomei were able to get MAP sensor, IAT sensor, Barometric sensor to work with stock GTR ECU and it works. Same with SR20DET ECU. Also they have base ROM data for SR, RB26 that you can download to load onto their ECU's.