MalibuJack

iTrader: (5)

BTW.. Its important that if you send logs, you can't trim them or remove any of the columns.. I need to see if data is shifting due to a missing response, or how many lines per second your getting..

MalibuJack

iTrader: (5)

Its hard to tell with your data, but it looks like its dropping an item earlier in the line.. That response wait parameter might help you..

Understand that the faster the engine runs, the more "Distracted" the ECU is to responding to data requests..

I'll add some error checking to the v2 code to verify the echo response is correct, if its not, I'll carry over the value from the previous line or use something to easily identify a bad value (an xxx or something)

nj1266

iTrader: (6)

MJ,

Is there any possibility that you can include an IDC parameter in the next release of your logger?

I think that this is a very important parameter to log and since the rpm and IPW are logged, then maybe you can add that parameter.

MalibuJack

iTrader: (5)

You can add that yourself if you want.. Thats the whole point of the requestid.xml file..

nj1266

iTrader: (6)

The problem is I do not know how to write the language, otherwise I would have done it myself

AlwaysinBoost

iTrader: (17)

Jack what about logging extrenal sensors or other logging devices like those found in the innovative lineup. I have an RPM converter (LMA-2) from Innovative which is basically a 5 channel 0-5v logger. I'm using it to log my gm 3bar map sensor. Is there anyway in incorporate that data??

MalibuJack

iTrader: (5)

Well, in this version no.. But v2 will have the ability to leverage any device with the right module and programming means that it can log anything you have interfaced to the computer.

MalibuJack

iTrader: (5)

I actually rearchitected the v2 code a bit, now the logger is seperate from the MUT-II code, the MUT portion now operates independently of the logger which means I can spin the logger at any sample rate I want, and there will always be data available to log.. This means if you have a device that runs faster than MUT-II, you can sample at the higher rate.. This doesnt mean the logger will be any faster, but it means that it will sample at the rate that the fastest device can run (if its necessary) This also means I have better and more flexible way to request data and handle responses.

evovette

iTrader: (3)

I actually got the -14 value a few times, went into ECUplus to make sure it wasnt really happening LOL then I just replaced the -14 with the value I found in ECUPlus......thats how I fix problems!

ries

iTrader: (36)

I also found the -14 in the timing adv column a few times on a couple of logs I did on my way home yesterday, mostly at idle. Malibujack, I can send you the logs if you want. Ill also post up on activematrix.

MalibuJack

iTrader: (5)

Post them on aktivematrix.. Make sure their zipped so their smaller than 300k.. I need to know when its happening..

Has anyone tried using the request wait function yet to add a 1ms at a time to give the logger time to get a response from the ECU.. Since there is no handshaking, the buffer is queried for 2 bytes, the timeout is very short to improve performance and that means if there isn't already data waiting, it could be getting something invalid..

Another test is to go into the requestID.xml file, and create a duplicate line for Timing, call it Timing1 (so it doesnt conflict and generate an error for a duplicate definition) then place it in different places in the sequence of requestID's, but start with just duplicating the line and making it below it.. Compare the two values when you see if it drops out also.. If their both the same value, then it could be the ECU doing something, if their not the same then it could be something else, if one is correct and the other is not, then its probably data loss. Again, try to use the request wait function to add 1ms

MalibuJack

iTrader: (5)

I think I figured out what it is.. I think the ECU is only responding with one byte, the echo to the requestID 06.. If you look at the requestid file, it subtracts 20 from the integer value of the byte, if there is only one byte response, the program uses that byte mistakenly (I don't think I'm checking the length, only that the response echo (first byte) is correct..) If you subtract 06-20 = -14 therefore the the result data was missing.. If the raw result was 0, it would be -14

It looks like this might happen for any request that gets back an echo only, only the result will depend on the echo value, and the conversion formula..


Now there are two ways this can be fixed.. use the previous value in the log, or use a clearly defined error value such as "xxx" what would you guys prefer to see?

Since this is a farily easy thing to fix, I may fix it and release a v1.1

But I think you guys should still try using the request wait function to see if that eliminates it (by slowing down the logging a little)

MalibuJack

iTrader: (5)

BTW, the echo always comes back, but if the ECU is "distracted" and you don't give it time to respond, your response will only have the echo.. I guess statistically its possible to poll the ECU at that exact moment on occasion..

Here's the weird part.. Evoscan does this too, only it shows up less frequently because it either is missing the column (throws off the length of the line).. I have seen this in evoscan when I look at older ones, every so often if I look at the file in Excel, there is a line that is shorter (has less columns) than the rest..

ries

iTrader: (36)

posted the 2 logs I did yesterday on activematrix. all the -14* values are at idle toward the end of each log, Ill try slowing down the logging just a little.

evovette

iTrader: (3)

Ill try that as well on my ride home tonight.