ECUFlash / Evoscan / Mitsulogger Questions
#376
Well, look at the front O2 sensor voltage, and if the car is in closed loop. If the car will not run in closed loop, and/or the front O2 sensor voltage is either not present, or not reading right, then you will never have any short/long term fuel trims as its not going to go into closed loop operation. Other sensor problems can cause the same problem.
There is a small chance that the ROM version your using, is not appropriate for the year car too, or there were some periphery bits changed to disable one of the O2 sensors, and the front O2 sensor was disabled by mistake.
There is a small chance that the ROM version your using, is not appropriate for the year car too, or there were some periphery bits changed to disable one of the O2 sensors, and the front O2 sensor was disabled by mistake.
#377
You can start and idle the car, and if its working properly, you will get some sort of Low and Mid (long term) fuel trim value if its in a reasonable range.. It doesn't make the car run any better or be very drivable, but you can aquire fuel trims from just idling. I do that to check if injector scaling, or airflow settings are proper for modifications that have been done, before driving the car around to see what additional adjustment is necessary.
If your getting no O2 feedback value, then your not in closed loop, if your getting no front O2 voltage value, then there is a problem with either the sensor, wiring, or rom version.
If your getting no O2 feedback value, then your not in closed loop, if your getting no front O2 voltage value, then there is a problem with either the sensor, wiring, or rom version.
#378
Malibu, i am not sure if this was covered in this thread but i recently adapted an EVOscan definition to mitsulogger.
EVOscan:
<DataListItem DataLog="Y" Color="" Display="Boost Error" LogReference="BoostError" RequestID="8A" Eval="0.0241*x-3.087" Unit="psi" MetricEval="" MetricUnit="" ResponseBytes="1" GaugeMin="-5" GaugeMax="5" ChartMin="-5" ChartMax="5" ScalingFactor="1" Notes=""/>
My adaptation for mitsulogger:
<Request LogReference="BoostError" RequestID="8A" Eval="0.0241*x-3.087" Unit="psi" Logged="y" Response="2" />
I originally had the Response byte as 1 for mitsulogger since that is what it has in the EVOscan definition but it kept crashing mitsulogger. Can you explain more about response bytes, what they do and why it would have crashed?
Thanks - Mike
EVOscan:
<DataListItem DataLog="Y" Color="" Display="Boost Error" LogReference="BoostError" RequestID="8A" Eval="0.0241*x-3.087" Unit="psi" MetricEval="" MetricUnit="" ResponseBytes="1" GaugeMin="-5" GaugeMax="5" ChartMin="-5" ChartMax="5" ScalingFactor="1" Notes=""/>
My adaptation for mitsulogger:
<Request LogReference="BoostError" RequestID="8A" Eval="0.0241*x-3.087" Unit="psi" Logged="y" Response="2" />
I originally had the Response byte as 1 for mitsulogger since that is what it has in the EVOscan definition but it kept crashing mitsulogger. Can you explain more about response bytes, what they do and why it would have crashed?
Thanks - Mike
#379
The response is the bytes returned to Mitsulogger from the Openport cable.. Generally that is 2 bytes, one byte is the Echo of the request, the second byte is the response. This is what made it so adaptable early on to allow it to handle unusual requests and responses.
If you had a request that returned 2 bytes, then the value would be 3..
the reason it would crash with a value of 1, is that would only be an echo, with no response value.. It is of no value to the logger to get a blank response. Unfortunately I never put much error handling into dealing with improper entries in the XML file, as that was a temporary thing, intended to offer compatibility with Evoscan at the time. I had always intended to store the requestID's in a different method.
If you had a request that returned 2 bytes, then the value would be 3..
the reason it would crash with a value of 1, is that would only be an echo, with no response value.. It is of no value to the logger to get a blank response. Unfortunately I never put much error handling into dealing with improper entries in the XML file, as that was a temporary thing, intended to offer compatibility with Evoscan at the time. I had always intended to store the requestID's in a different method.
#380
Thanks MJ for the info. Let me point this out. In scan tech i am only getting .020 volt reading for the front o2 censor.
Then along with that for some reason in Mitsulogger im not getting any fuel trims readings at all.
Would this be because my car is running way to rich ?
Then along with that for some reason in Mitsulogger im not getting any fuel trims readings at all.
Would this be because my car is running way to rich ?
#381
The response is the bytes returned to Mitsulogger from the Openport cable.. Generally that is 2 bytes, one byte is the Echo of the request, the second byte is the response. This is what made it so adaptable early on to allow it to handle unusual requests and responses.
If you had a request that returned 2 bytes, then the value would be 3..
the reason it would crash with a value of 1, is that would only be an echo, with no response value.. It is of no value to the logger to get a blank response. Unfortunately I never put much error handling into dealing with improper entries in the XML file, as that was a temporary thing, intended to offer compatibility with Evoscan at the time. I had always intended to store the requestID's in a different method.
If you had a request that returned 2 bytes, then the value would be 3..
the reason it would crash with a value of 1, is that would only be an echo, with no response value.. It is of no value to the logger to get a blank response. Unfortunately I never put much error handling into dealing with improper entries in the XML file, as that was a temporary thing, intended to offer compatibility with Evoscan at the time. I had always intended to store the requestID's in a different method.
Any news on the new version of Mitsulogger?
#382
So the newest version of ECUFlash I could get working is 1.29a and this is because I have an older Mitsubishi Tactrix cable. Will not running the newest version cause issues in the future?
#384
I've suspended development until I can find a new job now that I'm settled down here in Texas. Unfortunately the aktivematrix website and mitsulogger won't be paying any of my bills.
#387
The older Tactrix Mitsubishi and Universal cables have some hardware limitation making them not compatible with any version past 1.29a. There isn't much difference with the new versions besides 3D graphing and support for new platforms. I'm just wondering if this will cause compatibility issues with certain patches that might require the newest version.
#389