MalibuJack

iTrader: (5)

Yeah most of us who have some sort of ability to log MUT and some piggyback data seem to have no problems either..
Its looking more and more like this is unique to either the code, or something specific to this car.

donour

iTrader: (6)

Just to be clear. I think I'm the only one around who has written both an Xede library and a MUTIII library from scratch. I can say for certain that there is not funny business with delays introduced with the code I've written and the values are pretty close.

However, it seems to me like the only real way to resolve this is for somebody to drag an oscilliscope out to the passenger's seat and tap the CAS line. I know my Xede and MUT values are close, but I don't know that they are actually correct.

d

MalibuJack

iTrader: (5)

There aren't many of us in the position to do that. I'm glad you caught this thread and jumped in as we're able to give insight from a perspective outside of logworks. The only thing I ever noticed with the ECU+ or UTEC and MUT logging, is the Tachometer is off by a few hundred RPM, and thanks to the stepping values and scaling, the logging tends to be around 200rpm (give or take) different.

But seeing a difference like had been described is something I never saw before. But I haven't had the opportunity to run logworks and LC-1 outside of my bench and development environment, which is way too controlled to see anomolies like that anyway.

donour

iTrader: (6)

Well the tach is a pretty low accuracy device. There's mechnical lag incurred by sweeping that needle back and forth and the tick marks are close together compared to the size of it. Off the top of my head, I'd bet you could change the reading by 200RPM just by moving your viewing angle 30-40 degrees.

Somebody get a scope. It's too cold for me to go out to my garage!

d

jfitzpat

I think you might want to take a closer look at the data we have so far. Everything is being logged at the same time. The waveforms from all three sources are bing recorded at the same point and are an exact match. You can see it by eye, but you can also confirm it with the measurment tool.

We also know that it is a high probability that the XEDE value is correct (hence the original CAS signal is correct). The probability is high because the XEDE trace exactly matches the trace from the LM-1. They do not visually overlap because the scales are different (look on the left side of the window), but at every measurement point they are virtually identical. The LM-1 is determining RPM from an ignition spark, so it is independantly verifying the measurements of the XEDE using a different measurement principle.

I'd love to say it is my MUT code or plug in code, but there is very little evidence to suggest that could be the case. We know I'm acquiring the correct MUT param because the waveform is an exact match. The 'multiply by 31.25 and convert to LW samples' code also appears to be in the clear. It is identical for all ECU params, which appear to validate, it is 99% the same for the XEDE plug in, which is validated against the LM-1, and we have other people running the exact same code with no discrepancy.

The best explanations still appear to be that the ECU is unique, fooled (bad false CAS signal, etc.), or corrupt.

I'd love to say 'my XEDE works...' is proof positive that some of the theories are false, but I've too much experience with motorsports stuff. Many times one install will have noise or signal problems that another does not.

-jjf

Side Note: Both the MUT and XEDE plugins are written from scratch. I did the MUT plug in by visiting a shop near our office and looking at the Mitsubishi tool with my Tektronix scope.

I did the XEDE plugin when NJ1266 came by our office. He had a simple direct to comma delimited file tool and I monitored and captured the serial traffic. I figured out the basic request, framing, time stamp, RPM, and timing offset right away. I was going to contact Vishnu to figure out the rest, but NJ1266 sent me some more comma delimited logs with all params. and I got the packets to line up.

I'm mentioning this because I don't want anyone to think that Innovate violates anyones usage agreements, etc. NJ1266 saw me do the XEDE reverse engineering, and my MUT code is already open source (I also did SSM and OBD-II for tactrix at the same time).

I've since seen your MUTlib (I found it searching for conversion formulas - see above), but both your hardware (UART) setup and protocol initialization sequence are different from what I reverse engineered from the Mitsubishi tool. MalibuJack mentioned you had done an XEDE thing, but I haven't looked at it. My plug-in for XEDE is not open source yet, but will be shortly. I'm sure you will find that initialization and usage again differ from whatever you developed.

donour

iTrader: (6)

I'm not questioning how you are drawing your conclusion. I do agree that something is funny. I just haven't seen such a discrepency between Xede and MUT logs.


I agree with you here.


Again I agree.

I don't think it matters that much. The DMCA provides a clear clause for this type of use and I don't hold an xmap or MUTIII license.

The MUT procotol work did use a lot of trial and error. It's likely that it does not match the official tool. I think I'm the only evo owner on the planet without readily available windows machines, so I work over in my own private corner of the universe.

But hey, real men build their own tools!

Here's the relevent code for the Xede:

http://pyxede.cvs.sourceforge.net/*c...e=text%2Fplain

d

jfitzpat

FWIW, I'm doing three things at once today - and just realized that my message sounded terse - that was NOT my intent!

I just felt that latency had been disproved, but the words came out impolite.

FWIW, I don't really have a NIH problem. I literally didn't find anything when I started putting together stuff for the tactrix cable, so I wrote it. I would still have done the same spelunking even if I had used libmut - because I like to understand what I have to support, but your efforts are appreciated.

My addendum was just the knee jerk think of making it clear that, as a commercial company, we weren't productizing open source work. LogWorks is free, the Plug ins are free and open source, and I try to credit any other work we rely on.

Regards,
-jjf

nj1266

iTrader: (6)

Ok,

I did another log using the 31.25 number and this time the ECU rpm came out very close to the LMA-2 rpm and the xede rpm.

The black numbers are LMA-2, the pink are xede and the blue are open port. I have no idea why the first log had erroneous rpm open port data. Perhaps something got corrupted. Keep in mind I am running THREE inputs into my laptop via USB ports.

I will keep an eye on this and see if it repeats in the future.

jfitzpat

Definately keep an eye. The more I look at the log you first sent exhibiting the problem, the more I'm convinced that something was fooling the ECU. If you have additional occurances, I'd love to look at adjusted CAS with a scope.

The data looks rock solid and the waveform was tracking very well, A data link error, or something else like that just doesn't seem right.

Thanks for the update!
-jjf
-jjf