MUT-II diagnostic and logging support done
#1
MUT-II diagnostic and logging support done
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
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
#3
EvoM Guru
iTrader: (5)
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+
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+
Trending Topics
#9
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.
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.
#10
Evolving Member
iTrader: (4)
Join Date: Dec 2003
Location: Ventura County, CA
Posts: 357
Likes: 0
Received 0 Likes
on
0 Posts
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?
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?
#11
Evolved Member
iTrader: (8)
Join Date: Apr 2003
Location: Georgia
Posts: 2,138
Likes: 0
Received 0 Likes
on
0 Posts
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?
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.......
#12
Evolving Member
iTrader: (4)
Join Date: Dec 2003
Location: Ventura County, CA
Posts: 357
Likes: 0
Received 0 Likes
on
0 Posts
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'
Both could be implemented I'm guessing, load values and load 'descriptions'
#14
Tell me what you'd use the load value for.
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?
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
#15
EvoM Guru
iTrader: (5)
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.
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.