Mitsulogger v1 Officially Released
Originally Posted by cij911
I used the logger this AM and did a long normal (read fairly slow ) drive to work. At the end when the car was warm, I ran it hard from 2nd thr 4th...I saw a weird occurrence with timing that I have never seen with Evoscan, so I am hoping this is just a bug. Basically I saw -14 degrees of timing in several cells (not back to back). Here is a screen cut and paste (if you want the file just let me know). Again, my timing logs with Evoscan have never gone below 5 degrees and in the 5K range are generally 11 or so...
Code:
RPM ECULoad InjPulseWidth AFRMAP FuelTrim_High FuelTrim_Low FuelTrim_Middle O2FeedbackTrim O2Sensor TPS AirFlow AirTemp Baro ISCSteps KnockSum TimingAdv Speed Load 4468 159.38 16.9 179 0 3 2 0 0.92 49.8 1075.59 45.16 99 97 1 8 33.55 235.98 5156 159.38 18.43 181 0 3 2 0 0.92 100 1534.76 41.07 96 120 0 10 43.5 255.0545304 5906 159.38 16.38 174 0 3 2 0 0.9 100 1603.95 38.84 95 120 6 11 43.5 235.0955172 6687 159.38 15.1 171 0 3 2 0 0.9 100 1603.95 33.99 94.5 120 3 14 50.95 220.02 7312 159.38 7.94 169 0 3 2 0 0.92 9.02 132.09 33.99 103 83 0 38 60.89 113.9527811 6531 25 3.33 140 0 3 2 0 0.74 100 1107.04 38.84 98 76 0 15 60.89 53.0955 5625 159.38 19.97 189 0 3 2 0 0.94 100 1603.95 36.49 95 85 0 11 62.14 265.1585714 6093 159.38 18.18 190 0 3 2 0 0.92 100 1603.95 33.99 95 120 0 13 69.59 239.598 6468 159.38 16.9 187 0 3 2 0 0.92 100 1603.95 31.36 95 120 0 14 69.59 225.8845989 6875 159.38 16.38 187 0 3 2 0 0.92 100 1603.95 28.57 94.5 120 0 15 74.56 218.7519786 7187 120.62 1.28 153 0 3 2 0 0.86 9.02 176.12 31.36 103 83 0 38 80.78 14.21647059 6531 98.75 9.47 175 0 3 2 0 0.92 100 1484.44 33.99 95.5 84 0 -14 80.78 132.4712571 5812 159.38 20.22 192 0 3 2 0 0.94 100 1603.95 31.36 95 103 0 10 83.26 264.3553125 5906 159.38 18.43 191 0 3 2 0 0.92 100 1597.66 31.36 95.5 120 0 -14 86.99 241.7008901 6125 159.38 18.18 191 0 3 2 0 0.92 100 1603.95 28.57 95.5 120 0 13 86.99 238.3435602 6312 159.38 17.15 189 0 3 2 0 0.92 100 1603.95 28.57 95.5 120 0 14 91.96 226.8871429
It is the result of inadvertantly calculating the echo from the request and not the result (because there likely was only one byte response)
This is easy to fix in the code, it doesnt just show up in the timing, it can show up anywhere, only its not as obvious in other fields due to the more complex scaling algorithms.
This is easy to fix in the code, it doesnt just show up in the timing, it can show up anywhere, only its not as obvious in other fields due to the more complex scaling algorithms.
Do you have the Tactrix drivers installed, have you plugged in the cable for the first time yet, do you have .NET 2.0 installed, is the program file extracted into a directory with the rest of the files in the archive, among a few suggestions. Its likely your missing one of the files needed for the program to run (what I suggested are the most common reasons)
Oh and an error I can consistently reproduce, if your running the file from a network share you can get an error.. This is because of how .NET 2.0 handles files stored remotely.
Originally Posted by MalibuJack
Do you have the Tactrix drivers installed, have you plugged in the cable for the first time yet, do you have .NET 2.0 installed, is the program file extracted into a directory with the rest of the files in the archive, among a few suggestions. Its likely your missing one of the files needed for the program to run (what I suggested are the most common reasons)
I have the Tactrix drivers installed, and have used the cable with EcuFlash before.
What is .NET2.0? where do i dl
*edit: Nvm. I figured it out.
Thanks for your quick response.
Last edited by emagdnim8; Oct 24, 2006 at 05:05 PM.
okay.. I found a quick and easy way to fix the issue you guys reported, I also fixed the battery voltage dependency issue too (if the battery column isn't checked it will cause the load column to read xxx)
It took awhile because it had to be applied to the old code and the new code..
I will test it out tomorrow and likely release it either Thursday night, or Sunday night..
Basically what I did was kept the previous value buffered, and if the request is invalid, it will use the previous value logged. This may on very rare occasions have issues with calculations, but it should be much more rare than if the data is completely inappropriate. I feel your much better off getting the last value than a totally abhorrent value. Although its something I would typically ignore as noise, I can understand why it would bother you guys. However, now you won't have the ability to see "noise" or dropped data.. so if you find you get alot of repeated values, then you may still have to set the request wait setting.
I just hope I didn't introduce more problems by doing this..
It took awhile because it had to be applied to the old code and the new code..
I will test it out tomorrow and likely release it either Thursday night, or Sunday night..
Basically what I did was kept the previous value buffered, and if the request is invalid, it will use the previous value logged. This may on very rare occasions have issues with calculations, but it should be much more rare than if the data is completely inappropriate. I feel your much better off getting the last value than a totally abhorrent value. Although its something I would typically ignore as noise, I can understand why it would bother you guys. However, now you won't have the ability to see "noise" or dropped data.. so if you find you get alot of repeated values, then you may still have to set the request wait setting.
I just hope I didn't introduce more problems by doing this..
Last edited by MalibuJack; Oct 24, 2006 at 06:59 PM.
Originally Posted by MalibuJack
Certainly not arrogance, thats only for people who think their work is perfect, not those who know it (a HUGE "Just Kidding").. But end-users and developers certainly think differently.. I can run a program for months and never have a bug, and then someone turns up something because they try to do something I would never have thought of trying because I'm used to how the program "wants" to work.
I'm a clean and methodical coder, and am fairly certain things work as well as they can when I release things, but I never rule out the things I would never expect to try or do having bugs.. Developers are logical, and most humans are not, therefore things will get done that you'd never do yourself as a developer/tester.
I'm a clean and methodical coder, and am fairly certain things work as well as they can when I release things, but I never rule out the things I would never expect to try or do having bugs.. Developers are logical, and most humans are not, therefore things will get done that you'd never do yourself as a developer/tester.
. Anyway less chat...more coding from you!! I just like to needle developers when I can 
.
Last edited by codgi; Oct 25, 2006 at 12:08 AM.
Originally Posted by codgi
Which is why there are pro testers who think more like the end user and thats why we find stuff that you guys don't and never would have . Anyway less chat...more coding from you!! I just like to needle developers when I can .
. Anyway less chat...more coding from you!! I just like to needle developers when I can .
Well I finally had enough time in my schedule to finally get this downloaded. Looks like it will work just fine. Hopefully I can get more of a log with this than Evoscan. It seems to be a bit "short" on the amount of data.
I do have Bez' 62500 mod already in the Ecu so I think it should work out just fine, Ill report back after the races today.
I do have Bez' 62500 mod already in the Ecu so I think it should work out just fine, Ill report back after the races today.
Actually thats a good thing, I'm not running any of the Bez mods right now, and am relying on Bez to let me know if it works for him.. There's no reason for it not to work at the higher baud rate, however I'd be surprised if youd get any more resolution on the data, just more data (with data repeated until the ECU refreshes it)
The place where this higher baud rate will be useful is when you use 2 byte response mods, either the new protocol he suggested, or his current modified requestID's, they return two byte responses which means you get the full resolution data from the ECU directly, but 2 bytes means you would need a faster connection to get the same quantity of log items..
The place where this higher baud rate will be useful is when you use 2 byte response mods, either the new protocol he suggested, or his current modified requestID's, they return two byte responses which means you get the full resolution data from the ECU directly, but 2 bytes means you would need a faster connection to get the same quantity of log items..
Last edited by MalibuJack; Oct 25, 2006 at 10:18 AM.
Originally Posted by MalibuJack
Actually thats a good thing, I'm not running any of the Bez mods right now, and am relying on Bez to let me know if it works for him.. There's no reason for it not to work at the higher baud rate, however I'd be surprised if youd get any more resolution on the data, just more data (with data repeated until the ECU refreshes it)
The place where this higher baud rate will be useful is when you use 2 byte response mods, either the new protocol he suggested, or his current modified requestID's, they return two byte responses which means you get the full resolution data from the ECU directly, but 2 bytes means you would need a faster connection to get the same quantity of log items..
The place where this higher baud rate will be useful is when you use 2 byte response mods, either the new protocol he suggested, or his current modified requestID's, they return two byte responses which means you get the full resolution data from the ECU directly, but 2 bytes means you would need a faster connection to get the same quantity of log items..
Thats what Im looking for is just more data the Evoscan lacks in this area especially during a drag log. I think I got about 20-25 lines of data in a 12sec pass.
Edit: Im an idiot
Last edited by dryad001; Oct 25, 2006 at 11:51 AM.
More data may not be useful.. what I mean is, it depends on how frequently the ECU refreshes those registers, if your polling them faster then they can update, you'll get several lines of data with the same values, obviously you won't benefit much with that.
I do know that at higher RPM and loads, the ECU services requests a little slower, but MitsuLogger definitely logs more than 5 lines a second even under heavy load as long as the laptop is reasonably fast.. In 12 seconds you should get 40-50 lines or even more.. Even at the stock baud rate, **HOWEVER** it depends on what parameters your logging.. When your doing dyno or drag runs, you should disable any items not required for what your doing, such as the 02 feeback, fuel trims, Batt voltage, EGT Temp, etc.. That will increase the sample rate..
You'll have to try it with Mitsulogger and let me know if its doing any better, Considering the software is running as fast as the thread will loop on your laptop, the speed of the laptop and serial (USB) speed should be your limiting factor. This should not be that much faster than Evoscan all things considered, but I suppose it could be simply because I used as few loops as possible, and I used scripting to evaluate formulas which means it should spin its wheels minimally..
I do know that at higher RPM and loads, the ECU services requests a little slower, but MitsuLogger definitely logs more than 5 lines a second even under heavy load as long as the laptop is reasonably fast.. In 12 seconds you should get 40-50 lines or even more.. Even at the stock baud rate, **HOWEVER** it depends on what parameters your logging.. When your doing dyno or drag runs, you should disable any items not required for what your doing, such as the 02 feeback, fuel trims, Batt voltage, EGT Temp, etc.. That will increase the sample rate..
You'll have to try it with Mitsulogger and let me know if its doing any better, Considering the software is running as fast as the thread will loop on your laptop, the speed of the laptop and serial (USB) speed should be your limiting factor. This should not be that much faster than Evoscan all things considered, but I suppose it could be simply because I used as few loops as possible, and I used scripting to evaluate formulas which means it should spin its wheels minimally..
