Interest in Tuning for Boost with the Stock ECU

[NeedMoreBoost]

I just started looking for an early NSX so I can turbo it, consequently I've been running all over the NSX internet world, and happened upon this thread. I find it amusing that you guys are working with the same hardware and software that I use to tune my 80's GM projects. Tunerpro and Moates both really took off in the broader market in the last several years. Good stuff!

Anyway, I loosely follow what you guys are discussing, but I have little experience with most software and no experience with source code so I have nothing to add.
However, if you come up with a solution that requires additional hardware to be added inside the ECU, I'll bite. I'm an Electronics Tech so no problem in that arena.

Instead of rambling further, I'll just wish you guys good luck and say keep up the great work! A lot of DIY'ers might greatly benefit from this. Thanks!

Oh, and if timing works out right (i.e. If I find -the one- soon) then I'd be willing to be some kind of a beta tester if needed.

 

[DDozier]

Hey Matt,

Just a follow up question after you posted the 3.0l base and vtech timing tables, were you able to map out the knock sensor modifier timing table, I am curious to see how the OEM tune is handling knock, how agressive it removes timing and how quick it puts it back after an event is seen. Any info you have on the subject would be great.

Have you found a way to monitor knock or the knock modifier through the stock ECU?

Thanks

Dave

 

[sr5guy]

Hey Matt,

Just a follow up question after you posted the 3.0l base and vtech timing tables, were you able to map out the knock sensor modifier timing table, I am curious to see how the OEM tune is handling knock, how agressive it removes timing and how quick it puts it back after an event is seen. Any info you have on the subject would be great.

Have you found a way to monitor knock or the knock modifier through the stock ECU?

Thanks

Dave

Hi Dave!

I apologize about the delay in getting back to you, I'm right in the middle of moving my garage from one bay to another (in the same building) so things have been hectic here for the past few weeks.

The knock sensor system is very complex on these cars, I've honestly only brushed the surface of it. I have identified the knock modifier, and the knock indicator status bit. I've induced knock on purpose (increased timing) and saw the knock counts rise. There are 2 knock modifier tables (in the legend) that specify how much timing to pull (referenced by an RPM and MAP x and y axis). One table pulls a bit more timing than the other. It is possible that one map is for when the ECU detects the car is running non-premium low octane fuel and the other for when excessive knock is detected (failure of the EGR, overheating, etc).

The biggest problem I am having is converting the raw data into something useful. In order to come up with a good conversion formula I have to sit out in the car with an accurate timing light and see what changes amount to 1 degree of timing. I simply haven't had enough free time to do this.

I will try to dig a bit more into it for you tonight.

-Matt

 

[Honcho]

I just posted about ECU mods for NA cars with I/H/E and found this thread. Wow. I don't understand much of it, but it looks like we can tune the ECU to adjust for larger injectors, which appears to be the limiting factor for NA cars. Keep it up!

 

[sr5guy]

New Tunerpro Dashboard

I got the RDX injectors installed on my Legend last week so I have to get everything ready for a dyno trip next week some time. Unfortunately, I have to find a new dyno operator as I think my usual shop may have went out of business :/. Regardless, I have to get everything set up to do some live tuning, and I found a great dashboard layout which I modified for use with my communication definition. Right now I'm limited to logging 14 8-bit high speed items at a time, but I'm working on adding a few more.

I received my RDX conversion kit from Prospeed and I must shout him out on the great kit. Even the packaging was impressive! The kit is plug in and play and completely reversible if you want to return to your old injectors (trust me you WON'T want to!). In preparation for installing the injectors, I wanted to figure out the calculation for injector pulse width. I identified what was injector pulse width in RAM but didn't have a calculation to get it into milliseconds. So, I put my car on an oscilloscope last weekend to scope injector pulse width in milliseconds. I did this so that I could draw up a conversion formula for the injector pulse width in Tunerpro - (basically by modifying with the formula until the two matched in real time).

This allowed me to come up with a formula to convert base and current pulse widths, injector dead times, coolant and intake temp correction, and acceleration enrichment into milliseconds and to provide a pulse width variable to calculate injector duty cycle - a product of both inj. pw and RPM. This shown in the video as the 3rd analog gauge from the left on the bottom. As you can see with the new dashboard, things are cleaned up quite a bit. Tunerpro allows for multiple dashboards. My plan is to set two main dashes up, one for tuning fuel and another for tuning ignition with knock indicators. As a note, my wideband o2 sensor hasn't been calibrated, I think its reading about .5-.7 AFR leaner than actual.

<iframe width="420" height="315" src="http://www.youtube.com/embed/gosMr0C-LKA" frameborder="0" allowfullscreen></iframe>

-Matt

 

[RYU]

That's incredible work Matt. The extra sensor input on the ecu is a nice bonus.

Also, a bit of a selfish question but if you come across the timing/fuel adjustment measurements for high IATs it sure would be nice to know. You've got your hands full but your work is really impressive.

 

[DDozier]

Way to go Matt, 14 PIDs is plenty if you split your tuning into section fuel then timing. What happens if you slow some down some of the PIDs like the fuel table selected, engine coolant temp or really any of the status monitors, could you increase the number of total PIDs, or just gain resolution on the others.

It looks like the two fuel maps are for Open loop and closed loop. Is there a PID for open/close that you can monitor or is that the same thing as your fuel table status. The switch between the two tables is based off of load or change in throttle percentage? I assume you have two timing tables as well that follow the fuel table switch. I think that the NSX ECU may have at least two more fuel and timing tables to deal with Vtec. Is there a fuel or timing modifier for VIS in the Legend?

Sorry for so many questions but the OEM ECU tuning strategy is very interesting to me.

Very cool to see your project progress, I would love to see this setup make it to market.

Have you come up with a solution for boost yet? The holy grail!

Dave

 

[sr5guy]

That's incredible work Matt. The extra sensor input on the ecu is a nice bonus.

Also, a bit of a selfish question but if you come across the timing/fuel adjustment measurements for high IATs it sure would be nice to know. You've got your hands full but your work is really impressive.

Yes I have, I think I mentioned that to you in a PM. IMHO, you should work on getting those intake temps down - either by CAI and phenolic spacers or with meth injection.

Way to go Matt, 14 PIDs is plenty if you split your tuning into section fuel then timing. What happens if you slow some down some of the PIDs like the fuel table selected, engine coolant temp or really any of the status monitors, could you increase the number of total PIDs, or just gain resolution on the others.

It looks like the two fuel maps are for Open loop and closed loop. Is there a PID for open/close that you can monitor or is that the same thing as your fuel table status. The switch between the two tables is based off of load or change in throttle percentage? I assume you have two timing tables as well that follow the fuel table switch. I think that the NSX ECU may have at least two more fuel and timing tables to deal with Vtec. Is there a fuel or timing modifier for VIS in the Legend?

Sorry for so many questions but the OEM ECU tuning strategy is very interesting to me.

Very cool to see your project progress, I would love to see this setup make it to market.

Have you come up with a solution for boost yet? The holy grail!

Dave

Hey Dave,

There are actually 3 modes of ECU communication - built in from the factory and selectable in the rom.
1. bi-directional full duplex - send it a memory address and it responds with a value
2. 14 byte one-way stream read from a list of (modifiable) memory addresses in the ROM.
3. 66 byte one-way stream read from a list of (modifiable) memory addresses in the ROM.

The full duplex mode is what I'd like to use because it is the most flexible, but unfortunately it is very difficult to program into tunerpro. Each value would require at least a dozen steps to program in each PID in tunerpro with no copy/paste option! I am working with a member on the Legend forum (Quaraxkad) that is working on a custom stand alone program for 2way communications.

The 14byte stream is what I'm using in the demonstration. It is the fastest way to monitor multiple PIDs, since the ECU is not tied up with processing the requests of full duplex serial. In reality, the stream is in effect bi-directional because I can modify the addresses it streams in real time with my ostrich emulator. The 66byte stream is what the ECU uses from the factory and contains all of the critical sensor values. It is the slowest because of the length of the stream - each value is only updated about once per second. I re-wrote the streaming program last night and can now select the length of the stream. The problem was that I didn't realize the streaming routine was called 3 separate times per program cycle. It was fixed by pointing all 3 calls to the same routine and defining the stream length variable in tunerpro.

Actually on the Legend there are 2 ignition maps - one for when EGR is operating and another for everything else. The NSX adds one additional ignition map for VTEC. The NSX has 2 additional fuel maps - one for VTEC closed loop and one for VTEC open loop. You would need 3 status PIDs to tune the fuel maps properly on the NSX - Fuel Map Status (open/closed), VTEC status and EGR Status.

The open/closed loop transition is based on a few factors - coolant temp, throttle position and engine load. I'd say its primarily based on throttle position. I can make changes to variables in the program that selects the map to lock the ECU into a certain map for tuning purposes.

There is no VIS modifier at all.

No direct solution for boost yet, but getting the injectors installed and working has led me to understand the whole fueling process within the ECU. I really need to get on my game this year and get a snail hanging off my exhaust pipe .

-Matt

 

[DDozier]

In TunerPro if the pids are defined, can you select what you want up to the 14 pids and will TunerPro write the serial string for you, or do you have to setup a dashboard for each unique set of pids you want to monitor.

Any chance of changing the MAP sensor and rescalling the tables to mach the new sensor like we talked about before to deal with boost?

What are the chances of ever unlocking the OBDII ECU's?

Are there any other analog inputs left on the NSX ECU?

I must say I envy your tanacity on this project it is a lot of effort. Good Job.

Dave

 

[sr5guy]

In TunerPro if the pids are defined, can you select what you want up to the 14 pids and will TunerPro write the serial string for you, or do you have to setup a dashboard for each unique set of pids you want to monitor.

Any chance of changing the MAP sensor and rescalling the tables to mach the new sensor like we talked about before to deal with boost?

What are the chances of ever unlocking the OBDII ECU's?

Are there any other analog inputs left on the NSX ECU?

I must say I envy your tanacity on this project it is a lot of effort. Good Job.

Dave

Tunerpro doesn't do any of the streaming, the ECU's microprocessor does this in it's stock form. By disassembling the ECU's program I was able to back-trace the routine that handles the serial streaming. I discovered the 3 modes of communication with 2 of them streaming a 14 and 66byte stream select-able by a program switch. I also discovered the location of the list of memory addresses (14 for the 14byte, 66 addresses for the 66 byte). This list of addresses is read out of the serial port at the rate of about 1 a millisecond. The ECU adds a header byte and parity check (so that it can tell its head from its tail) and then streams out of the serial port the values of each PID defined in order of this list of addresses.

I created a list in tunerpro ROM definition of these addresses and you can go in and change the order and location of any address in that list. This list of addresses is stored on the chip and is there from the factory. I labeled the list 1-14 to correspond to the order of which they are streamed from the serial port. So if #1 was coolant temp ($FCDF) and #2 was RPM ($FC52), the first byte of the stream would be coolant temp and rpm successively. If I wanted the first byte to instead show intake temp, I'd go to #1 and change it's address to ($FCCF) - intake temp. If I then updated the chip to the emulator while the car was running, the first byte of the serial stream would change from coolant temp to intake temp.

What I did last night was to re-write the stock (honda) serial handling routine to change the length of this stream from 14 bytes to whatever length I specify. If I wanted a 100byte stream and I had room to have a 100 byte list of addresses I could do it. I would simply add room to the list of addresses and label them 15, 16, 17, 18, 19 etc. The only problem is the longer the stream the slower the updates get, at 14 values its extremely fast as shown in the video.. I think I could expand that up to 30 or so values and still have the stream reasonably fast.

Now here's where the confusion comes in. Tunerpro also handles the datalogging for the stream. Think of the datalogging in tunerpro as a separate program with a separate definition. You have to tell it how long that stream of bytes is, what each byte is and give it a calculation to get that raw data into a real world number. In the above example, the first packet is CTS and second is RPM. You would define #1 as coolant temperature and enter a formula (x-40) to get it into degrees farenheit. You would define packet 2 as RPM and enter a different formula (X*28) to get that raw value into RPM. Even then you're not done! You still have to make and layout the dashboard! If I make the stream longer, I would have to define that the stream is now longer and enter the information and formula for those extra packets.

I'm not really interested in re-scaling the N/A fuel maps for boost with a modified map sensor. My goal from the beginning has been to add resolution to the fuel tables - possibly even switching to a separate set of maps when boost is detected. I feel confident that I will accomplish my goal sometime soon. I believe the Legend/NSX ecu in it's stock form far surpasses the resolution and finite control of any aftermarket engine management - if only I had been doing this 20 years ago

Let me ask you this - what is so difficult in converting an OBD2 car to use a cable throttle body? If a plug and play OBD2-OBD1 adapter was made and a cable throttle body was retrofitted... do you see where I'm going?

There are a few analog inputs that could be "creatively redefined"... It depends on how far you want to take it, I'd say there are 3 inputs that could be re purposed for external usage (A/C Pressure, Ignition Timing Adjuster and clutch switch). If you want to get crazy, I could add up to 8 more if additional (simple) circuitry was added.

Thanks man! This has so far has been my favorite hobby, I'm almost worried about what I'm going to do once I've finished . I do have some wild ideas to take ECU tuning to the next level, but I'd rather just show you than talk about it!

-Matt

 

[Cozmo]

I thought I was a geek but you sir are my hero :biggrin:

 

[sr5guy]

I got the NVSRAM chips in on Monday. In layman's terms these new chips are equivalent to flash memory - their contents can be changed on the fly. In this case the ECU itself is going to do the changing. I had to write a program within the ECU to change the contents of the NVSRAM over the serial port, but in order to even get that to work, you have to put the initial program on the chip.

You might ask why go through all of this trouble when the moates ostrich already handles emulation. Well there are two reasons, first off is cost - the ostrich retails around $200 while the NVSRAMs can be sourced under $50.00. The second and primary reason is that the programming is done over the ecu's serial port - this enables a single serial connection to control emulation and datalogging. This serial connection can be via USB or bluetooth.

Unfortunately my EPROM programmer doesn't handle the new chips, but thankfully I am the master of using things inappropriately.. Since I have complete control of the ECU and it's microprocessor and coding, why not use the ECU to program the NVSRAM? I installed a riser board with two sockets, extended the address and data bus to the second socket and installed some basic logic to handle the chip enable, read and write signals. There is also a switch that controls the mode of the processor. When it's flipped up it's in programming mode - it switches the internal ROM off and the processor's 0 page is rerouted to the left chip (source). The source can be either an eprom chip or the Ostrich. The source chip contains a simple program to boot the processor and copy the contents of the program stored within itself to the NVSRAM (destination).

When the switch is flipped down, the ECU resumes normal operation with the NVSRAM activated as the primary chip, allowing me to test the chip I just programmed! I could leave everything as-is with the riser card and install it in the car and test the chip. The jumper on the circuit board controls which half of the NVSRAM gets the program - left position programs the automatic side, right position programs the manual side. It doesn't matter if the source chip is installed or not still because it's chip enable signals are no longer valid with the processor in normal mode. (this was one of those convenient accidental discoveries lol)

Thankfully, once the chip is programmed it can be installed directly into ecu without any riser card. A few simple (reversible) hardware changes have to be done to enable the write signal to the chip and account for a relocated address line. The final product will look something like this:

Note that in the picture above there is an extra socket sandwiched between the NSVRAM and the board. The final product will include a low profile socket and much neater wiring. Thankfully it just BARELY clears the A/T daughterboard with the low profile socket.

My "lab" 5/5/12

-Matt

 

[RYU]

Any updates Matt? :smile:

Would it be possible to offer some type of OBD1 NSX Scan Tool to aid in the tuning of say and F/IC?

Please pardon my newb question..

 

[sr5guy]

Any updates Matt? :smile:

Would it be possible to offer some type of OBD1 NSX Scan Tool to aid in the tuning of say and F/IC?

Please pardon my newb question..

I'm currently working on a project to link the ECU via bluetooth to an Android phone for datalogging and remote tuning purposes. If you know any decent Android programmers, please let me know.

Thanks,
Matt

 

[RYU]

Matt, perhaps you and F0obot can you work some magic together.
http://www.nsxprime.com/forum/showpost.php?p=1604696&postcount=45

 

[foundry3]

I'm currently working on a project to link the ECU via bluetooth to an Android phone for datalogging and remote tuning purposes. If you know any decent Android programmers, please let me know.

Thanks,
Matt

Peter Linszter has a solution that does this on Android for eCTune/Crome, he was more than happy to help me with the eCTune ISR protocal so he may be willing to help.

http://www.linszter.net

 

[sr5guy]

Matt, perhaps you and F0obot can you work some magic together.
http://www.nsxprime.com/forum/showpost.php?p=1604696&postcount=45

Thanks!

Peter Linszter has a solution that does this on Android for eCTune/Crome, he was more than happy to help me with the eCTune ISR protocal so he may be willing to help.

http://www.linszter.net

Sorry for the delay in getting back to you, I'm actually on vacation - coincidentally - in Chicago. I drove my car out here for the national Legend meet in Milwaukee and am now staying in Chicago for a mini-vacation. If you'd like a demo of what I have available feel free to get ahold of me. I am sending you a PM with my contact info now.

-Matt

 

[bngl3rt]

I don't mean to derail the thread - my question is slightly orthogonal...

You mentioned the ROM in the NSX is almost full from the factory (whereas on the Legend there was some extra space to add more code). However, if you've dumped the ROM and understood the circuit and the layout of the address space (RAM, NVRAM, etc), what are the obstacles to modeling the NSX ECU entirely in software?

In other words, if all the physical inputs and outputs that the software expects were connected to a powerful PC with high resolution A/D and D/A converters, is the CPU used by the NSX ECU sufficiently well understood that an emulator could execute a minimally modified copy of the extracted machine code and run a real engine?

This setup would be ideal for tweaking and tuning, with the idea that the final setup could be ported to a powerful modern embedded platform (i.e http://www.gumstix.com) and then the RAM and ROM limitations would no longer be a concern :smile:

 

[DDozier]

I don't mean to derail the thread - my question is slightly orthogonal...

You mentioned the ROM in the NSX is almost full from the factory (whereas on the Legend there was some extra space to add more code). However, if you've dumped the ROM and understood the circuit and the layout of the address space (RAM, NVRAM, etc), what are the obstacles to modeling the NSX ECU entirely in software?

In other words, if all the physical inputs and outputs that the software expects were connected to a powerful PC with high resolution A/D and D/A converters, is the CPU used by the NSX ECU sufficiently well understood that an emulator could execute a minimally modified copy of the extracted machine code and run a real engine?

This setup would be ideal for tweaking and tuning, with the idea that the final setup could be ported to a powerful modern embedded platform (i.e http://www.gumstix.com) and then the RAM and ROM limitations would no longer be a concern :smile:

I think that for most of us that have a choice between tuning the stock ECU and replacing it with another would choose to tune the stock ECU. We have several choices in piggyback and plug-n-play stand-alone ECU's now.

I personally like the idea of a simple solution:
Change ROM > Flash ROM > Tune > drive car.

Not sure what I want can be done, and too make it worse I want it for an OBDII ECU. At the very least if Matt can bring to market a gauge/data monitoring solution for OBDI that will open the door for much better tuning when a piggyback is used.

Dave

 

[RYU]

at the very least if matt can bring to market a gauge/data monitoring solution for obdi that will open the door for much better tuning when a piggyback is used.

Dave

+1000

 

[bngl3rt]

I think that for most of us that have a choice between tuning the stock ECU and replacing it with another would choose to tune the stock ECU. We have several choices in piggyback and plug-n-play stand-alone ECU's now.

The middle ground I was getting at was to run the very advanced and complete software from the stock ECU on a much more capable and expandable hardware platform.

The issue with the standalone aftermarket ECUs is that you're basically starting from scratch and rebuilding the entire engine model with fewer sensor inputs and less testing. The stock ECU's software and mappings were developed with thousands of hours of testing the car under a much bigger range of conditions. Imagine if that could be your starting point, without the ROM space limitations of 1991.

 

[bngl3rt]

Not sure what I want can be done, and too make it worse I want it for an OBDII ECU.

I could imagine retaining full OBD2 capability by porting the stock ECU software to a new hardware platform :wink:

 

[sr5guy]

I don't mean to derail the thread - my question is slightly orthogonal...

You mentioned the ROM in the NSX is almost full from the factory (whereas on the Legend there was some extra space to add more code). However, if you've dumped the ROM and understood the circuit and the layout of the address space (RAM, NVRAM, etc), what are the obstacles to modeling the NSX ECU entirely in software?

In other words, if all the physical inputs and outputs that the software expects were connected to a powerful PC with high resolution A/D and D/A converters, is the CPU used by the NSX ECU sufficiently well understood that an emulator could execute a minimally modified copy of the extracted machine code and run a real engine?

This setup would be ideal for tweaking and tuning, with the idea that the final setup could be ported to a powerful modern embedded platform (i.e http://www.gumstix.com) and then the RAM and ROM limitations would no longer be a concern :smile:

What you are saying sounds great on paper, but it's implementation would be far more complicated than working around the stock ECU's limitations. Sure, the software modeling is understood to the point where you could model something like that in software. But it would be tremendously difficult considering it's in a rare, obsolete, processor specific assembly language and not in any port-able high level language. It's basically 20,000 lines (408 subroutines) of IF-THEN statements, do you feel like entering them manually in a higher level language to run on a PC? Then you have the hardware issue - sure the 0-5v sensors are easy to duplicate with an A/D converter but what about the crank sensor inputs? How about PWM outputs to the EGR valve? Fuel Injector drivers? Forget it!

I say, it's much better to work around the stock ECU and it's limitations. The limitations pose challenges that force you to be very efficient. With the NVSRAM installed the free space limitations can be worked around and is no longer an issue. If you were to get as far as I am in the reverse engineering of the ECU you would have a much greater respect of both the software and military grade hardware that is already existent.


-Matt

 

[DDozier]

The issue with the standalone aftermarket ECUs is that you're basically starting from scratch and rebuilding the entire engine model with fewer sensor inputs and less testing. The stock ECU's software and mappings were developed with thousands of hours of testing the car under a much bigger range of conditions. Imagine if that could be your starting point, without the ROM space limitations of 1991.

You may be starting from scratch with most FI tunes anyway, Once you change the injector and exceed the OEM MAP sensor limitations you will be reworking the entire fuel and ignition maps. You could leave most of the fuel trim routines in place and ignition trims in place as well but the basic fuel and ignition tables will have to be reworked completely. As soon as the VE of the engine changes in any way from the OEM tune the tune has to be reworked as with any standalone. The goal with this project I think is to make best use of the OEM ECU in a FI system. I believe the OEM ECU can be a better piece of hardware than most standalone ECU's, we just need the tool to make it work for FI.

From what I can tell and Matt would be better to make the point but the OEM ECU has everything we need to make for a very stable, programmable ECU with a limitation of how the ECU looks at the MAP sensor. Once Matt sorts that out the game is on.

Dave

 

[sr5guy]

I haven't updated this thread in ages, I wanted to post here to let you guys know that the project isn't dead! I finished my NVSRAM coding a few months ago. This is what allows the ECU to be flashed in situ with no additional hardware modules, and individual byte changes to be made to the ROM while the car is running. I polished it up, added some redundancy and safeties to it so that it would be reliable and commented it as posted here. Quaraxkad has been helping me on the PC interface programming end (the program that is used to send a new ROM file to the ECU) and pending a few minor modifications, his program will be ready shortly.

Here's a quick explanation of whats happening in the code:

To send one byte to the ECU there are 3 command codesm DATA, MSB and LSB:
D0 xx (Data)
D1 xx (Address MSB)
D2 xx (Address LSB and WRITE)

To write data #BB to address #1234, the commands would be as follows:
D0 BB
D1 12
D2 34

Since all addresses within the ECU are 16 bit and the serial port deals in 8 bits at a time, the address has to be split into two parts - MSB and LSB (most/least significant). In case your wondering about why 3 separate commands have to be issued - and the resulting rather long-ish program - I had to work around some limitations of the stock ECU. This ideally would have been inserted into a modified serial routine, but I wasn't able to access or change that routine at all. In order to make this program function correctly I had to insert it in to the kernel loop so that it runs once every microsecond. To make it play nicely with the serial routine (that runs on interrupt and MAY even interrupt this routine) that conveniently places it's received data in RAM, I added some waits and checks to facilitate that safely. The write to the NVRAM doesn't occur until the last command is issued (D2xx) and that part of the program checks to make sure that the other two commands (D0xx and D1xx) were received successfully to prevent invalid data from being written to the ECU.


-Matt