Hey MJ, don't get me wrong. Mitsulogger is a great program and I have nothing to really complain about. Goes to show what a great job you've done when the only things to complain about are trivial little UI tweaks.

Just did some logs and it feels like it is initializing a bit faster. Or is it just me?

 

I know, I hate GUI's so I get irked when people complain about GUI stuff..

Anyway, yeah there were actually a bunch of fixes which improved the performance of many features. Initialization works a little better, but the only thing I changed was the detection of the hardware comes when you first run the application, which definitely makes the initialization go a little faster. I also fixed a few timing issues which might have helped.

 

I don't understand what conflict there could be with LogWorks, particularly if it isn't running. Did anyone post a more specific error?

-jjf

 

Thats what I'm trying to figure out. Mitsulogger does use the MTS.DLL and MTSSDK.OCX files, but I'm uncertain if that would try to read all the configuration data available if there is any.

I also got no specific information about what MTS devices he was running or which wideband he was using.

I'm trying to keep all the bug reports on Aktivematrix so I can address them as I get them.

 

This one confuses me also. More specifically because Mitsulogger doesn't produce any dialog boxes on shutdown. The only error for not initializing the interface would show up when you first start it. Its possible there was an error left behind from when it was first started, but I'd guess something like that would be hard to miss.

 

Woohoo, just verified the memory read (live tuning) protocol itself works in mitsulogger.

 

Kickass! I just upgraded here.. haven't had a chance to use this yet but I like that I can now resize the application window

 

I found two bugs in the LC1 logger.. One isn't actually a bug, but I had overlooked how numeric data is interpretted in DataLogLab.. The other bug only affects people with multiple channels (LMA-3 addon, LM-1 with the Auxbox hooked up) and this was a stupid oversight on my part.

They should be fixed and an updated file to download will be posted later today. There is one more bug, that probably existed since the first version of Mitsulogger but only was noticed by a member yesterday, that I'm trying to fix right now.

 

doh

 

doh

 

Snowing here now, so hopefully give her a test run Sat. Thanks Again MJ!

 

I'm glad I got my post edited before too many people have me crap lol. I had to reinstall the "connection" for the cable so my logger was in demo mode lol.

Working great other than needing to edit a definition for the map sensor in DLL

Good work MJ!

 

LOL I figured you'd catch that pretty quickly.. The demo mode evolved from a debug mode I was using when I had no access to an ECU at my desk, I still use it to make sure all of the calculations work properly as its a random number generator that dumps its values into the logger so the definition can be tested.

 

MJ -- A couple of quick points regarding v1.6:

(1) THANKS A TON FOR DOING THIS....What a great asset for the community!
(2) I had the system crash when I hit my rev limiter (3rd gear pull) -- I had to close v1.6 and ZT2 and unplug the USB2 cable
(3) How accurate is the CalcLoad (Load) function? I am seeing high 200's and low 300s....whereas evoscan v.98 is more like 250 / 260....
(4) What does MAP represent and what are the units of measure? I am guessing it is reading boost from the ZT2 and it is psi.
(5) What does Knock represent? Knock Sum looks familiar, but Knock gives me some crazy numbers.

Again thanks a ton for a great tool.

 

You can disable the knock parameters other than Knock Sum, their for debugging the Knock Filters and aren't very useful for logging.. That'll let the logger run faster too.

Yes, the MAP value (the last few parameters with AFR, MAP, EGT, USER1) are all ZT2 values..

Its hard to say how accuate the load calculation is.. Its only as accurate as the information you give it. However if you put the correct injector scale, and latency values in, you should be seeing fairly correct numbers. Evoscan has the values hard coded for 513 injector scale, and stock latency values.. If you have aftermarket injectors and its scaled for that, then it will show lower load than expected as IPW is shorter..

The real way to tell is to see if the load its recording falls into the correct cells, on my car it does, so its hard to know for sure. FWIW in v1.5alpha, it always read about 10% higher, now it should be alot closer, especially with aftermarket injectors.

You do have several intake mods that can also affect the engines Airflow (reading higher) and therefore causes the load to read a little higher.

The way to check, is to compare the Load value with ECULoad value (before it clips at 160) if its reading fairly accurately, the two should nearly overlap if not overlap completely.. Calculated load is always troublesome for me.. Enough so that I don't really use the values more than a guideline when tuning.


I'm hoping the sliding latency value added for voltage helps the accuracy of the calculation..

Don't forget that you cannot disable parameters such as InjPulseWidth, AFRMAP, Battery, or the custom request Latency, as the calculations no longer generate an error when their disabled.. They will just read improperly.

For comparison's sake there is a second LoadALT custom request, its the Evoscan calculation with injector scale variable included (you can change it to 513) I use that to verify the calculations between the two are consistent.. But if you replace the InjectorScale variable with 513, you can easily compare how altering injector scale and latency values can alter the load calculation.