As part of my ongoing effort to make the ECU+ the ultimate tuning solution, I've implemented a new feature that might be of interest to a number of folks: MUT-II diagnostics and datalogging.

MUT-II is the protocol that's used on the early 1990's DSMs and still works on today's EVOs. It's a slow-to-medium speed protocol that lets you see some stock ECU parameters that are normally not visible externally, most notably the stock ECU's "knock sum." This is the protocol used by freeware loggers like MMCD, EvoScan and Mitsulogger.

In addition to the ECU+'s current OBD-II support (the mid-90's and up common diagnostic protocol), the ECU+ can now display a real-time pane of MUT-II information with the click of a mouse.

To supplement the MUT-II display capability, I've also implemented logging of any of these MUT-II parameters. You can select up to 8 different MUT-II parameters and log them simultaneously with the native ECU+ logging values. With this, the ECU+ gives you the best of all worlds logging - log normally invisible stock ECU signals (like knock sum and the fuel trims) at the slow MUT-II rate alongside the higher resolution native signals (like knock amplitude, O2 voltages, RPM, TPS, MAS frequencies, air/fuel ratio and many more) that the ECU+ already supports. In addition, the ECU+ Windows software has been modified to fully support the MUT-II values, including proper handling of different MUT-II calibrations, and the ability to overlay multiple graphs from multiple sources (where the MUT-II logged values may not have been logged in the same "slot").

Screenshots are attached below.

Thanks to MalibuJack for help with some of the MUT-II scaling.

This capability will be in the next ECU+ software/firmware release. It'll be free to current ECU+ silver box customers, of course.

Tom

 

Ohh my goodness!!

Wow, that is much sooner than I expected. Way to go Tom!

Can't wait to give it a shot, I have having to run two loggers just so I can log the knock sums.

Woo Hoo!

 

This was one of the major features that I didn't want to discuss until he was prepared to talk about it.

Its been a long time coming, and IT DOESNT REQUIRE ANYTHING ADDITIONAL to log the MUT-II protocol therefore you don't need to keep your tactrix cable installed for logging.

Obviously this would mean you don't need to use Mitsulogger any longer if you have the ECU+, but I'd be a very happy person if everyone ran the ECU+

 

I'm sure jack already has, but I would be happy to beta the firmware for ya when the time comes.

 

I actually haven't tested it yet, nor any of the new software..

I frequently switch EM setups to test other things, so in the down-time while he was developing these new changes, I put my UTEC on the car so I can try to reverse engineer the firmware.

 

wow...Tom...
i am so happy that i got ECU+.
knock sum....i guess i don't have to guess with knock voltage spikes.
so, when can i start using this program? anxiously waiting...
Chong

 

Glad i have an ECU+!

 

Hi

Thanks again for the great support.

MB

 

That is sooooo freaking awesome!!

Gdamn that is so cool. Hurry up and implement it, I'll paypal an update donation for that knock sum display. I freakin hate having to run evoscan to see when the ecu's thinking its knocking.

 

Wow this is a great addition.
But those people saying you won't need Mitsulogger anymore, how do you know the load values?

Also I'm wondering since the ECU+ can see knock sums now, will it be having the option to do the knock countermeasure based on knock sum rather than voltage?

 

Both interesting question.

The ecu will still be doing it's own knock correction, on first read I thought there would be no need, but then again, i suppose you could be more agressive in your extra fueling / timing reduction to get things back under control quicker.

I think if you were to combine the ability to attenuate the knock signal a bit (like exede does) with the ability to pull timing / add fuel more agressively than the ecu does on it's own... that would be a winning combination

I guess next we will be asking Tom to move to a fuel / timing map system that is closer to the stock ecu's load vs rpm tables.... only with more resolution on the rpm scale. I think that is the way to go rather than the low /med / high style currently used, but that has it's own set of problems since the ecu+ is modifying the maf signal for fuel corrections so unless he did direct timing control like the UTEC does it would be very difficult to follow an rpm vs load table for timing adjustments, since fueling changes would change the ecu's target load cell.......

 

From my understanding the load is calculated from other inputs coming from the MUT, so since all those inputs are alraeady there then you just need to add a calculation for load.
Both could be implemented I'm guessing, load values and load 'descriptions'

 

very very sweet.

 

If MJ will give me the info on calculating the load value, I can look into adding it. AFAIK, there's no technical hurdle there.

Tell me what you'd use the load value for.

It could. The two issues I see are:

1. Capturing knock sum is optional in the ECU+, since you can pick what MUT-II values to log. Any suggestions on how to handle that possibility? Maybe if the user has knock countermeasures enabled, don't let 'em quit the dialog until they select knock sum as one of the logged options?

2. MUT-II logging is inherently slow. Not sure it's a good idea to wait until the knock sum reflects trouble to apply the countermeasure. Retrieving knock sum at 10x per second (which is typical of the slow MUT-II rate) might be too late at the top end of the rev scale, when cylinders are firing at almost 300x per second. The ECU+'s internal knock sensor conditioning grabs the knock sensor at *every* cylinder firing and takes action.

#2 is interesting to me in that it's yet another thing that the ECU+ does "right" that's really invisible to the end user. I spend hours and hours on the software and firmware making sure that things work exactly the way they should. (An example: I've spent the past *three days* trying to get the Windows software to move the cursors the way you expect. Another example: the P0300 problem took *years* to get right, and implements this crazy adaptive algorithm that watches how you drive and adjusts the cam and crank sensor signals on the fly to be as non-P0300-ish as possible while maintaining near-perfect reproduction of those signals. The adaptive algorithm also adjusts for crummy stock and aftermarket cam and crank sensor wheels and adapts to your exact wheel - something that I'm confident *no* other engine management system for the EVO does.) It's frustrating to me that the ECU+ is just plain better than other products in a million little ways, and yet most of these things are under the hood and will never get me a single sale.

Rant off.

Tom

 

Load is used basically to trace the cells in the ECU for tuning purposes, its useful to have in there.

Since you have access to the full (accurate) signals for RPM, IPW, and Airflow, you might want to look up the original load calculation that uses the airflow (MAF) signal as the values in the ECU+ are unclipped and should be very accurate.

Instead of building all of this stuff into the ECU+ firmware though, these calculations can be something you do within the windows software, therefore it might be something you'd want to make user definable and have seperate "user defined" calculations and graphs. That might be the best way to handle it.