I think i found my load problems, i am only logging 4.3V at the battery while cruising and ocassionaly i get a 13v spike, am i right to assume that my battery is dead, and the high load calcs are droped data and the reason i'm running sub 10.0 AF because of the latency compensation?

 

4.3 volts?? Well, 14.3 is pretty normal, but 4.3, your car wouldn't be running right if that was true..

Of course if the data is bad, and the load calculation uses battery voltage, then there's your problem..

 

Just got back from gettin ghte battery tested, it passed with flying colors 10.8v under full crankin load, 12.4v stationary, 14.4V with car running,

i have no idea what the hell is going on i'm thiking that it might be surge it happens alot around 2000-3500 rpm specially while cruising slowly.

 

If thats really an accurate reading (your getting that value on every logger you try) then you have something wrong with your alternator, or that electronic module that controls the electrical system that goes out on occasion that I've heard about.

 

i jsut got back in but i'm only having voltage reading prolbem when using the 62500 baud rate.

Under the normal 15XXX baud rate it shows 14.32 volts while cruising.

I haven't the slightest idea, i pulled put my TT from under the dash and it shows 14.x volts at all times.

 

Okay at least thats just a software glitch.. Out of curiosity, which logger were you using at the time?

If your using Evoscan, try Mitsulogger and see if it reads correctly, and vice versa.. I'm wondering if its some sort of bit error because of the port speed, if it is, then both programs should exibit the same problem..

 

i had the problem in evoscan and mitsulogger, the only one who read properly was ecuedit.

 

Thats actually very interesting, others who have used mitsulogger with the 62500 mod are having no trouble with the single byte data responses..

I was unaware that ecuedit was even able to log the higher speed at all. Are you sure it was logging at the higher speed? Or was the baud rate set at the higher speed, and the ecu running at the lower speed, hence corrupt data?

Anyway, it may be a framing error (actually its likely that it is) and you can try adding an ms or so to the request wait value in Mitsulogger, it may be there isn't enough time for the ECU to return that request for some reason..

I wish I had more insight into the inner working of the ECU for some of these requests, according to the guys on my site, the RequestID represents a table of values that are updated regularly by internal registers as they are used by the ECU, And the serial MUT code only grabs data from that table (basically just a table of shared memory) and replies to requests. However the serial communications get a low priority (I think its polled for requests and services responses) and are probably not interrupt driven, what that means is if you stack requests too quickly, they can be lost or replies can be inappropriate or never returned..

 

Oh, and FWIW, I actually have the USB FTDI chip programmed to timeout very quickly and may be actually the echo from an earlier request..

I would try moving the battery line in the requestID.xml file (or data.xml in evoscan) up a few lines in the file..

4.3v in the calculation converted to 58, which is 3A in hex, and that is the requestID for air temp which is a few lines up... Try moving battery before the air temp value and see if it starts reading differently..

This is just an experiment since this shouldn't happen under any circumstances, unless of course the baud rate and timeouts are having a little trouble..

 

In reality, there is no handshaking going on, and therefore the data you are getting "occasionally" when it glitches, could be in error..

In fact, I'm fairly certain that its similar to the -14 degree timing error, that is, an incomplete request or inappropriate response.

I have a new release of v1 (v1 Release A) that will be posted on my site tomorrow night, that will do a little better handling of the responses, and will discard inappropriate responses, they have to meet two conditions, that the echo is the same as the requestID, and that the length of the response has to be longer than 1 byte, if it doesnt meet these two things, it will use the previously logged value instead of calculating an abhorrent value.