Interest in Tuning for Boost with the Stock ECU

[DDozier]

And to clarify again - you are working on the OBD1 NSX ECU only? Do you have any understanding of how the OBD2 ECU differs?

Given the low production volume (and engineering effort) Honda put into the car after it was launched, I would imagine they tried to change as little as possible, adding DBW and the OBD2 protocol implementation while leaving everything else (as close to possible as) alone...

It is my understanding that the OBDII ECUs are unique from the OBDI ECUs and to all other Honda Products as it seems our DBW system is Unique to the NSX, by the time Honda got around to adding DBW to other Honda engines they abandoned this type of throttle body and used a more industry standard unit that is still being used on modern engines. There was changes in the ECU and TB along the way from the 1995 to 2005 as the part number for the various years are different:

Year ECU Part Number TB Part Number
1995 - 37820-PR7-A33 - 16400-PR7-A31 Discontinued
1996 - 37820-PR7-A33 - 16400-PR7-A31 Discontinued
1997 - 37820-PBY-A05 - 16400-PR7-A32
1998 - 37820-PBY-A05 - 16400-PR7-A32
1999 - 37820-PBY-A05 - 16400-PR7-A32
2000 - 37820-PBY-A08 - 16400-PR7-A33 - Low Emission Vehicle (LEV) standard added
2001 - 37820-PBY-A08 - 16400-PR7-A33
2002 - 37820-PBY-A08 - 16400-PR7-A33
2003 - 37820-PBY-A08 - 16400-PR7-A33
2004 - 37820-PBY-A22 - 16400-PR7-A33
2005 - 37820-PBY-A23 - 16400-PR7-A33

I have done about as much research as I can on the TB as it was needed in my efforts to use the Infinity ECU from AEM. AEM has looked at the TB and has determined at least for now, they will not support it with their new ECU. As a result we will be forced to change to a supported TB w/DBW in order to use the Infinity on the OBDII cars. If we can crack the OEM OBDII ECU it would be the holy grail of NSX tuning. I know HP tuners just recently cracked the Viper Gen4 ECUs by erasing the entire ECU and loading a custom operating system on the OEM ECU so they can tune it. I am sure the effort to do this is enormous and the R&D and expertise to pull something like that off would be crazy but they did it for a very small market of cars as the Gen4's were made from 2008 to 2010 and only 2453 were made. Our production numbers stretch over 10 years, 3 TB changes, 5 ECU changes and only 3404 cars. In the case of the Viper they are charging nearly the price of a stand-a-lone ECU for the ability to tune the OEM ECU but I think as a tuner and NSX owner it would be worth the price to tune the OEM ECU and keep the OBDII systems active for emissions testing. This is the extent of my knowledge of the OEM OBDII ECU as I have no idea how to crack one of these units or even how to start a project like that. Hondata has cracked the S2000 ECU and offers a flash tune product but they have said in the past they have no interest in the NSX ECU as the production numbers are too low for a reasonable chance for return on their investment, for what it is worth they only offer a flash tune product for the 2006-2009 S2000 and they happen to be the first of the DBW S2000's and Honda lists the ECU as rewritable in their parts description no such luck for the NSX ECU.

Sorry for the Tread Jacking!!

Dave

 

[sr5guy]

Looks like the major change was done in 2000. They switched from a 84pin PLCC Hitachi H8/536 processor to a H8/539 112pin QFP processor. The processor is the same family as the OBD1 processor - H8/500 - so the code would be second nature for me. If someone is willing to spend the money I would GLADLY reverse the code which is _THE_ most difficult thing to do.

-Matt

 

[DDozier]

Looks like the major change was done in 2000. They switched from a 84pin PLCC Hitachi H8/536 processor to a H8/539 112pin QFP processor. The processor is the same family as the OBD1 processor - H8/500 - so the code would be second nature for me. If someone is willing to spend the money I would GLADLY reverse the code which is _THE_ most difficult thing to do.

-Matt

OK based on what you know about the processor, will we ever be in a flash tuner type of programming via the OBDII port? or do you think the ECU will require a hardware modification?

Back to the OBDI ECU, do you have a plan for dealing with boost yet, what about mapping the knock control on the OEM ECU?

Dave

 

[sr5guy]

OBD2: If a factory flash datalogging protocol over obd2 exists then yes you could.If not it would require a simple TTL to USB converter.

OBD1: boost control is under development. You brought up a sensitive subject I had the whole knock sensor system reverse-engineered from patent documentation. My laptop hard drive crashed and I lost about 2 months worth of work on it. I will post the patent number and some more information when I get home tonight. It described the system perfectly, btw.

 

[greenberet]

HUGE progress. ENTIRE fuel system has been defined!!!! Every single variable that effects fueling in any way is adjustable, configurable and tunable.

Now to start work on defining the ignition system!

-Matt

That's great news, Matt. Thanks for doing this and I'm sure it will bring good carma and hard cash your way.

 

[bngl3rt]

Nice list, Dave. Given the number of 95+ NSX sold (vs. 91-94) plus the huge variety in ECU parts after 95, I can see how cracking it might not be worth the time...

 

[DDozier]

OBD2: If a factory flash datalogging protocol over obd2 exists then yes you could.If not it would require a simple TTL to USB converter.

OBD1: boost control is under development. You brought up a sensitive subject I had the whole knock sensor system reverse-engineered from Honda patent documentation. My laptop hard drive crashed and I lost about 2 months worth of work on it. I will post the patent number and some more information when I get home tonight. The patent described the system perfectly, btw.

Sorry did not mean to poke you in the eye with the knock sensor thing. What I really want to know is how Honda calibrates their sensor and what the factory knock threshold table looks like, how much timing it pulls and how it puts it back in after the knock event ends. I would guess that outside the sensor data the Knock Fuel Adder you have already defined combined with the Knock Ign Cut you will define are really the info that would be best to know, but being able to see the raw knock data and how the ECU looks at the sensor to determine knock from noise would be very helpful for setting up any ECU that uses the factory sensors.

Can we tell by looking at the ECU to OBDII connector wiring diagrams if the data path is even an option at the OBDII connector. I have wiring diagrams for the OBDI cars but not for the OBDII cars, I will pull them from Mitchel in the morning and see what we have to work with at the OBDII DLC

Dave

 

[sr5guy]

Sorry did not mean to poke you in the eye with the knock sensor thing. What I really want to know is how Honda calibrates their sensor and what the factory knock threshold table looks like, how much timing it pulls and how it puts it back in after the knock event ends. I would guess that outside the sensor data the Knock Fuel Adder you have already defined combined with the Knock Ign Cut you will define are really the info that would be best to know, but being able to see the raw knock data and how the ECU looks at the sensor to determine knock from noise would be very helpful for setting up any ECU that uses the factory sensors.

Can we tell by looking at the ECU to OBDII connector wiring diagrams if the data path is even an option at the OBDII connector. I have wiring diagrams for the OBDI cars but not for the OBDII cars, I will pull them from Mitchel in the morning and see what we have to work with at the OBDII DLC

Dave

Edit: The forum keeps converting this file into .jpg which causes it to loose all quality, I will try to fix later.

I resolved the problem and hopefully I will remember to keep more up-to-date backups, it really hurt because the system is tremendously complicated and spread out everywhere within the ECU. I have one thing leftover from the crash, and that's the schematic I made. There is one error I know of Q801 and 802 should be tied to gnd at the base instead of +5v IIRC. From what I gather the knock hardware determines if there is a knock/no knock situation based on various programmed (in code) outputs from the microprocessor. The sensors are sampled in the noise gate when no combustion noise occurs and again at the knock gate during combustion. There samples are divided into 8 maximum panes and the sample length defines how many of these panes are open during the sample. I cant recall many more of the details, I need to go back and re-enter the data and chase it around for a few days. I would really like to know what electronic effect q801 and q802 have on the circuit, do they function as noise filters or amplification gain?


OBD2: The issue is more with the protocol which is in the code on the MCU, if there is no OBD2 flashing protocol in the code then a custom one will have to be made and most likely a ttl-usb converter installed.

-Matt

 

[DDozier]

On the newer ECU/Processors 2000+ ECU's is there any room left for custom code to be added if needed, If I recall correctly the OBDI memory was one of the limiting factors as you did not have much room left to add any code. Can you tell if the OBDII ECU's have moved the MAP sensor hardware processing onto the new processor by looking at the ECU it self. If they had more room on the processor to handle the MAP calculation and did actually move it there we may be able to solve the boost issue on the OBDII cars easier than the OBDI ECU's.

Shawn has an 04 ECU listed for sale, I would be willing to buy it and have it shipped to you if you want to work on the OBDII setup. Let me know via PM and we can talk about this new project.

Dave

 

[sr5guy]

On the newer ECU/Processors 2000+ ECU's is there any room left for custom code to be added if needed, If I recall correctly the OBDI memory was one of the limiting factors as you did not have much room left to add any code. Can you tell if the OBDII ECU's have moved the MAP sensor hardware processing onto the new processor by looking at the ECU it self. If they had more room on the processor to handle the MAP calculation and did actually move it there we may be able to solve the boost issue on the OBDII cars easier than the OBDI ECU's.

Shawn has an 04 ECU listed for sale, I would be willing to buy it and have it shipped to you if you want to work on the OBDII setup. Let me know via PM and we can talk about this new project.

Dave

No way to tell without getting a read of the code from the OBD2 ECU. I have gotten much better with my code writing and ecu "hacking" abilities, and while there still is a very limited amount of free space its not so much of a limiting factor to the project anymore.

The map sensor processing issue with the OBD1 ECU is because of a hybrid MCU/chip memory arrangement - not a hardware issue -there code is stored in the MCU and on the external chip. The map sensor routine was stored in the processor and inaccessible unless a new MCU was programmed with changes. Work arounds have been developed for this issue. ALL of the OBD2's ECU code is stored solely on the MCU, and once read and flash program developed/found all routines would be fully accessible.

-Matt

 

[DDozier]

No way to tell without getting a read of the code from the OBD2 ECU. I have gotten much better with my code writing and ecu "hacking" abilities, and while there still is a very limited amount of free space its not so much of a limiting factor to the project anymore.

The map sensor processing issue with the OBD1 ECU is because of a hybrid MCU/chip memory arrangement - not a hardware issue -there code is stored in the MCU and on the external chip. The map sensor routine was stored in the processor and inaccessible unless a new MCU was programmed with changes. Work arounds have been developed for this issue. ALL of the OBD2's ECU code is stored solely on the MCU, and once read and flash program developed/found all routines would be fully accessible.

-Matt

You are about to be elevated to Hero status, thanks

Dave

 

[sr5guy]

Got the knock sensor system COMPLETED!!!



Ignition system almost there!!!



This is really starting to come together folks!

 

[greenberet]

Awesome!!!

 

[DDozier]

Got the knock sensor system COMPLETED!!!

View attachment 113846

Ignition system almost there!!!

View attachment 113847

This is really starting to come together folks!

If there is a status value in the logic chain for knock or ignition trim, is there a PID to monitor that value. How fast is the data stream for monitoring. I know you had a fast enough data stream to make the software gauges work during your live data testing, but is there a limit to the amount of data we can pull out of the ECU during the tuning process. I guess what I am getting at is do we need to divide the tuning process into modules like Fuel, Ignition, Knock, Idle, Fuel Trims....ect due to the data stream limits and if so do you need help with that part of the process. I can donate some time to the project if you think my input would be helpful. Realize of course I am not looking to make any money off this thing but my goal is to transfer as much of this project as possible into the ultimate goal for me of having a tune-able OBDII ECU that maintains the OBDII monitors for emissions testing. Since the hardware looks to be somewhat compatible from the early ECUs to the newer ECUs the hope would be that the code and data would transfer over and that the newer ECUs may even be easier to flash program since the processor and memory are unified on a single chip. Ideally flashing an unmodified ECU would be the best but if we need to modify the 2000+ ECUs that would work for my needs as well.

Dave

Dave

 

[sr5guy]

If there is a status value in the logic chain for knock or ignition trim, is there a PID to monitor that value. How fast is the data stream for monitoring. I know you had a fast enough data stream to make the software gauges work during your live data testing, but is there a limit to the amount of data we can pull out of the ECU during the tuning process. I guess what I am getting at is do we need to divide the tuning process into modules like Fuel, Ignition, Knock, Idle, Fuel Trims....ect due to the data stream limits and if so do you need help with that part of the process. I can donate some time to the project if you think my input would be helpful. Realize of course I am not looking to make any money off this thing but my goal is to transfer as much of this project as possible into the ultimate goal for me of having a tune-able OBDII ECU that maintains the OBDII monitors for emissions testing. Since the hardware looks to be somewhat compatible from the early ECUs to the newer ECUs the hope would be that the code and data would transfer over and that the newer ECUs may even be easier to flash program since the processor and memory are unified on a single chip. Ideally flashing an unmodified ECU would be the best but if we need to modify the 2000+ ECUs that would work for my needs as well.

Dave

Dave

Just a few clarifications on terminology... Logic chain would be data stream, and PID is OBD2 specific, it translates indirectly to data stored at a memory address. Instead of having to know each manufactures memory locations, the PID unifies it so that PID 0x04 is always calculated load, whereas with the NSX ECU memory address 0xFCB2 indicated calculated load.

The baud rate is 62500 which roughly translates to 60 individual bytes (updates) per second. So, if you have a stream of 10 variables each will be updated approximately 5x per second (factoring in the 2 header bytes that identify the start/end of stream). I reworked the factory datalogging stream so that the stream length is fully customizable- but - the longer the stream the slower the individual updates. The data that is streamed is also customizable via a table in the ROM. Ideally the tuning process would be divided into modules simply because of the wealth of data that is available from the ECU. There are literally 1,024 (1k) of possible memory address that could be logged in the tuning process and ALL of them are defined .

The current idea is to separate the stream into 3 14byte modules - fuel, ign and other. When all data from all 3 modules is desired simply send a command to change the first module to be 42 bytes long, streaming all 3 modules at once.

-Matt

 

[E-Nough Logic]

We saw updates much faster than 60 bytes per second when we were looking at it, I think you are underestimating the speed. The speed was more than fast enough to make excellent use of the data during tuning!

 

[latzke]

I'm trying to come up with something that would be in the best interest of everyone. My current idea is making the definition public, free and open for *personal* use with the hope that good carma (pun intended) will come my way. Yeah right , I can see the dyno tuners bootlegging it as I speak. My custom code, datalogging protocols and modifications to the ECU (NVRAM flash updating, boost support, etc) will be for commercial sale. I'm open to suggestions.

-Matt

When far enough along you could do a kickstarter campaign to monetize this / fund the last mile of development. Those campaigns define different support levels where people get different benefits for spending different amounts of money. Maybe one level is end-users of a common FI setup (CTSC) who would receive an ECU tuned toward their package, another level for tuners/vendors (folks like LoveFab, Driving Ambition, SOS) where they would get use of your tools and training to be able to tune the OEM ECU, etc. Someone who showed up with enough dough (aftermarket ECU manufacturer) could buy the complete definition, all the data, source to any/all of your related code, etc and be able to productize themselves in some way. I'm not sure what makes sense. The big thing that would keep a kickstarted campaign from working is that people are essentially giving you money now with promise of something in future. There is some risk in that for the supporters...and supporting this could be more expensive than the average kickstarter idea while having a high degree of complexity (risk it won't happen) and relatively low volume (more of a concern for you).

Since the bulk of what is needed is your labor...not huge cash outlays for manufacturing or such...it may not be a good fit. You could just ask for money when you have things in-hand to offer, instead of selling things that you might be able to deliver in the future.

Anyway, the holy grail for me and what I would be willing to pay for, as a mainstream CTSC owner, is an OEM ECU tuned with appropriate maps for boost conditions using larger injectors (RDX?) at stock fuel-rail pressures (or at least a more-resonable fixed pressure). The current solutions (rising-rate FPR, voltage clamp on MAP signal, piggy-backs, AEM EMS, etc) are enough in the non-optimal range to create a void that you could fill. Obviously not all CTSCs are the same with different blowers (whipple, autorotor) having been offered, different diameter pulleys, and different things changed by owners later on (different fuel pumps), etc.

Anyway, really cool progress. Exciting to see.

 

[sr5guy]

When far enough along you could do a kickstarter campaign to monetize this / fund the last mile of development. Those campaigns define different support levels where people get different benefits for spending different amounts of money. Maybe one level is end-users of a common FI setup (CTSC) who would receive an ECU tuned toward their package, another level for tuners/vendors (folks like LoveFab, Driving Ambition, SOS) where they would get use of your tools and training to be able to tune the OEM ECU, etc. Someone who showed up with enough dough (aftermarket ECU manufacturer) could buy the complete definition, all the data, source to any/all of your related code, etc and be able to productize themselves in some way. I'm not sure what makes sense. The big thing that would keep a kickstarted campaign from working is that people are essentially giving you money now with promise of something in future. There is some risk in that for the supporters...and supporting this could be more expensive than the average kickstarter idea while having a high degree of complexity (risk it won't happen) and relatively low volume (more of a concern for you).

Since the bulk of what is needed is your labor...not huge cash outlays for manufacturing or such...it may not be a good fit. You could just ask for money when you have things in-hand to offer, instead of selling things that you might be able to deliver in the future.

Anyway, the holy grail for me and what I would be willing to pay for, as a mainstream CTSC owner, is an OEM ECU tuned with appropriate maps for boost conditions using larger injectors (RDX?) at stock fuel-rail pressures (or at least a more-resonable fixed pressure). The current solutions (rising-rate FPR, voltage clamp on MAP signal, piggy-backs, AEM EMS, etc) are enough in the non-optimal range to create a void that you could fill. Obviously not all CTSCs are the same with different blowers (whipple, autorotor) having been offered, different diameter pulleys, and different things changed by owners later on (different fuel pumps), etc.

Anyway, really cool progress. Exciting to see.

Thanks for the feedback, I thought of using kickstarter before, but hell you guys have waited 20 something years for this, whats another year or so? I'd rather just get it done, prove it and then sell it, better than working backwards and/or with false promises.

What you could do to help is to find someone semi-local to me with a CTSC that would be willing to pay for dyno time and guninea pig status in exchange for free tuning.

-Matt

 

[DDozier]

How do you feel about coming to St louis for a weekend. I can get you a ctsc car, turbo car, na car. I have the dyno. I can tune if you bring the tool.

Dave

 

[sr5guy]

How do you feel about coming to St louis for a weekend. I can get you a ctsc car, turbo car, na car. I have the dyno. I can tune if you bring the tool.

Dave

I would be more than willing, lets see if we can work out some logistics... PM sent.

-Matt

 

[Valhalla]

Oh now this is getting good! You guys rock.

 

[rj45]

awesome !

 

[sr5guy]

I just wanted to send a HUGE thanks out to Dave Dozier and his clients (also NSXprime members) for hosting me and providing test vehicles in St. Louis. I was out there this past week as part of a multi-state road trip. Unfortunately, our boost support test did not pan out as planned, mainly for lack of preparation on my part. On a positive note, I now have the data needed to perform another test soon. Also, fortunately, I will be relocating soon to Chicago to start a new career which will put me less than 5 hour drive / 45 minute flight from Dave.

-Matt

 

[DDozier]

I just wanted to send a HUGE thanks out to Dave Dozier and his clients (also NSXprime members) for hosting me and providing test vehicles in St. Louis. I was out there this past week as part of a multi-state road trip. Unfortunately, our boost support test did not pan out as planned, mainly for lack of preparation on my part. On a positive note, I now have the data needed to perform another test soon. Also, fortunately, I will be relocating soon to Chicago to start a new career which will put me less than 5 hour drive / 45 minute flight from Dave.

-Matt

Thanks again for taking your time to visit us, with all that is going on in your life right now (congratulations again) I know it was tough being away from home. Thanks for all your efforts, I know we learned something and when round two comes about we should be ready to make some progress on this project. The rest of this month is nuts for me and I am sure it will be for you as well, but next month I will be ready when you are.

Dave

 

[RYU]

Great news! Hope a monitoring options becomes available soon.