TTP Engineering

iTrader: (465)

You are not using the correct ecuID/XML definition.

BoostEEd

iTrader: (19)

BUMP!

jeff_ro

iTrader: (4)

How can I fix that? Because the stat rev limit is the first thing I want to change, and it seems it's not in the right memory location. The car is a 2006 EVO 9 GSR, USDM, memory model SH7055.

MalibuJack

iTrader: (5)

Get your ECu Internal ID#, write it down, go onto the openecu forum and search against that number, thats not an unusual rom and there's probably an updated definition for it.

The default XML definitions that come with ECUFlash are a little outdated. You HAVE to update the definitions to the most current ones you can find. I suspect that the reason for this is the software is an independent development from the map definitions people are creating. And there had been some argument that some of the user contributed definition files were "Pirated" from other software and for legal reasons its safer not to include any new ones with the ECUFlash software.

jeff_ro

iTrader: (4)

Thanks MJ, problem solved!

gudmundur

iTrader: (2)

Hi

EVOScan logging stops randomly.
It seems that it happens less often if I untick some of the elements to log

I am not using a slow laptop .. it's got a 1,8 Ghz cpu and 1gb of memory.
I have tried reinstalling and that didnt solve it.

Mitsulogger does not have this problem but there isnt support for my AEM WB in Mitsulogger so I am stuck with EVOScan

Any ideas on how to solve this are surely appreciated

regards
Gudmundur Thor

MalibuJack

iTrader: (5)

I noticed this too with Evoscan, it was one of the reasons that I decided to write my own program. It has very little to do with the speed of the computer, its really just that evoscan occasionally gets timeout errors and its solution for the error is to stop logging, than to try to continue. Mitsulogger handles communication errors differently.

The good news is I should have some time this upcoming week to fix the ZT2 bugs I came across, add some new features, and I'll probably add AEM support, but I'd like to actually do it with an AEM unit in hand, but AEM nor any vendors have come forward to loan/give me a device to develop with so I'll write a simple simulator that I can use instead.

Mr. Evo IX

iTrader: (5)

Mine stopped all the time until I realized it was the anti shock protection on my thinkpad laptop causing the hard drive to stop. Now if I disable that I can log indefinitly in evoscan. The weird thing is Mitsulogger never stopped on me.

Hope you can get the AEM support in there MJ.

gudmundur

iTrader: (2)

Good point .. I need to try disabling it

thanks for the tip Mr. Evo IX

And I surely do agree ... would be lovely to get AEM support in there.
I would send you my AEM MJ if I wouldnt be on the other side of the Atlantic ocean

regards
Gudmundur

MalibuJack

iTrader: (5)

The shock protection feature freezes disk activity, in turn it freezes disk writes which will cause the buffer of the serial port to Overrun.. Mitsulogger is immune to this error as it has a large circular buffer, plus it recovers from buffer overrun by continuing reading the port instead of timing out. The disadvantage is this could result in data loss, but I felt it was the lesser of two evils as I would have this happen EVERY time I ran Evoscan on my drive to work.

Mr. Evo IX

iTrader: (5)

That's intersting that we all have thinkpads.

donour

iTrader: (6)

This one still baffles me. The OS should take care of that. The filesystem should be be smart enough buffer writes until the disk is in a stable state for a sync (or until the block i/o layer complains).

d

chrisw

iTrader: (2)

not if the recieve buffer is a predefined array size.

mitsulogger has a somewhat better approach, but as MJ says, it could lead to data loss

donour

iTrader: (6)

No doubt a ring buffers are a better way to go. That was proven 35 years ago. I'm just saying that momentary loss of disk access should NOT stall the application.

d

MalibuJack

iTrader: (5)

It should, but in reality it doesn't.. I recall someone gave me a good explanation of why it does it, but in general the OS blocks writes, which in turn suspends the programs writes to disk momentarily, just long enough for the IO to cause the serial buffer to overrun if your writing to disk simultaneously.

The problem is block writes using "Proper" buffering leads to more data loss if the application misbehaves.. I'm actually surprised that this isn't handled better