94170008 ROM 2 byte load mod for dummies (like me :)
#16
Evolved Member
Thread Starter
iTrader: (5)
Join Date: Nov 2003
Location: Birmingham, Al
Posts: 849
Likes: 0
Received 0 Likes
on
0 Posts
I also use the latest version of Evoscan and have no issues with a spike. I remember reading somewhere about there not being an "answer" or something like that everytime and it could cause some weirdness. I believe that both MJ and evo4mad addressed this issue in their loggers, LW probably has not since we are having to add the 2byte math in ourselves. Try using mitsulogger.
#17
Evolved Member
iTrader: (18)
I'm using the LW OpenPort 1.3 pluging from LW2 (it works fine with LW3) and added the xml lines to the protocols.xml [zip file] and use the formula included in zip file to caculate ECU_load while reviewing the data.
Run openport 1.3 / select MUT III, add channels loadmsb and loadlsb + timing,knock sum etc.(you'll have to add one at a time)/ hit start to log. Then run LW2 or LW3/new realtimelog.
[The protocols zip has the xmls lines to get EVOscan calc load method or MJ Mitsulogger calc load method]
Run openport 1.3 / select MUT III, add channels loadmsb and loadlsb + timing,knock sum etc.(you'll have to add one at a time)/ hit start to log. Then run LW2 or LW3/new realtimelog.
[The protocols zip has the xmls lines to get EVOscan calc load method or MJ Mitsulogger calc load method]
#18
Evolved Member
iTrader: (11)
I also use the latest version of Evoscan and have no issues with a spike. I remember reading somewhere about there not being an "answer" or something like that everytime and it could cause some weirdness. I believe that both MJ and evo4mad addressed this issue in their loggers, LW probably has not since we are having to add the 2byte math in ourselves. Try using mitsulogger.
#19
Evolved Member
iTrader: (18)
I also use the latest version of Evoscan and have no issues with a spike. I remember reading somewhere about there not being an "answer" or something like that everytime and it could cause some weirdness. I believe that both MJ and evo4mad addressed this issue in their loggers, LW probably has not since we are having to add the 2byte math in ourselves. Try using mitsulogger.
#21
Evolved Member
iTrader: (18)
I got these off the innovate forum openport pluging thread
MJ mitsulogger method
?Injector Scaling = inj_scale[513]
?Injector Latency = inj_latency[0.432]
?i Name of Injector Pulse Width channel = inj_pulse[Fuel_Injector_Pulse_Width]
?i Name of AFR MAP channel = afrmap[AFR_MAP]
# engine load
calcload = 5 * inj_scale * (inj_pulse - inj_latency) / afrmap
MC(ECU_Load;%;0;350) = calcload
Evoscan method
?Injector Scaling = inj_scale[513]
?i Name of Battery Voltage channel = battery[Battery_Voltage]
?i Name of Injector Pulse Width channel = inj_pulse[Fuel_Injector_Pulse_Width]
?i Name of AFR MAP channel = afrmap[AFR_MAP]
# injector latency
inj_latency = (-0.1026*battery)+1.8741
# engine load
calcload = 5 * inj_scale * (inj_pulse - inj_latency) / afrmap
MC(LoadCalc;%;0;500) = calcload
MJ mitsulogger method
?Injector Scaling = inj_scale[513]
?Injector Latency = inj_latency[0.432]
?i Name of Injector Pulse Width channel = inj_pulse[Fuel_Injector_Pulse_Width]
?i Name of AFR MAP channel = afrmap[AFR_MAP]
# engine load
calcload = 5 * inj_scale * (inj_pulse - inj_latency) / afrmap
MC(ECU_Load;%;0;350) = calcload
Evoscan method
?Injector Scaling = inj_scale[513]
?i Name of Battery Voltage channel = battery[Battery_Voltage]
?i Name of Injector Pulse Width channel = inj_pulse[Fuel_Injector_Pulse_Width]
?i Name of AFR MAP channel = afrmap[AFR_MAP]
# injector latency
inj_latency = (-0.1026*battery)+1.8741
# engine load
calcload = 5 * inj_scale * (inj_pulse - inj_latency) / afrmap
MC(LoadCalc;%;0;500) = calcload
Last edited by Jorge T; May 23, 2007 at 07:42 PM.
#23
Evolving Member
Join Date: Sep 2006
Location: Germany
Posts: 152
Likes: 0
Received 0 Likes
on
0 Posts
My theory of the spikes:
https://www.evolutionm.net/forums/sh...=234060&page=8
Post 108 and 112
I think this is a kind of transition error bcause we log the bytes one after another. So this value can go wrong when the low byte is near 255.
https://www.evolutionm.net/forums/sh...=234060&page=8
Post 108 and 112
I think this is a kind of transition error bcause we log the bytes one after another. So this value can go wrong when the low byte is near 255.
#24
Evolved Member
iTrader: (18)
So what exactly are you storing in the array with the calcload formula?
My theory of the spikes:
https://www.evolutionm.net/forums/sh...=234060&page=8
Post 108 and 112
I think this is a kind of transition error bcause we log the bytes one after another. So this value can go wrong when the low byte is near 255.
https://www.evolutionm.net/forums/sh...=234060&page=8
Post 108 and 112
I think this is a kind of transition error bcause we log the bytes one after another. So this value can go wrong when the low byte is near 255.
Last edited by Jorge T; May 24, 2007 at 05:00 AM.
#25
Evolving Member
Join Date: Sep 2006
Location: Germany
Posts: 152
Likes: 0
Received 0 Likes
on
0 Posts
I think it is a good idea to log time critical values as near as possible.
For example: load lowByte, load HighByte, RPM, knock, AFRMAP and Ignition inline when you want to tune the maps. AFR should also be as near as possible, but I think in LW this is not possible.
After these values you can add additionally parameters such as octane nr., ...
But, not sure if this is such important.
For example: load lowByte, load HighByte, RPM, knock, AFRMAP and Ignition inline when you want to tune the maps. AFR should also be as near as possible, but I think in LW this is not possible.
After these values you can add additionally parameters such as octane nr., ...
But, not sure if this is such important.
#26
Evolved Member
iTrader: (11)
I think it is a good idea to log time critical values as near as possible.
For example: load lowByte, load HighByte, RPM, knock, AFRMAP and Ignition inline when you want to tune the maps. AFR should also be as near as possible, but I think in LW this is not possible.
After these values you can add additionally parameters such as octane nr., ...
But, not sure if this is such important.
For example: load lowByte, load HighByte, RPM, knock, AFRMAP and Ignition inline when you want to tune the maps. AFR should also be as near as possible, but I think in LW this is not possible.
After these values you can add additionally parameters such as octane nr., ...
But, not sure if this is such important.
?Target AFR = tafr[11.3] <--11.3 can be changed to your target afr
MC(Tafr;AFR;7.4;22.4) = tafr
and it will put a straight line at 11.3 afr and when your actual afr traces across the log you will see how close are far you are away from target. If I were at my comp I could actually post a demonstration but I am not. And also logworks3 is great. It is currently in beta, but still so far working fine with VISTA woot!!
#27
Evolving Member
Join Date: Sep 2006
Location: Germany
Posts: 152
Likes: 0
Received 0 Likes
on
0 Posts
Sorry, misunderstandig.
(That happens when a german speaks english )
I mean you cannot arrange the AFR with the other openecu channels.
But I also think that dosent matter, because the AFR came from another source so that there is no time critical problems.
(That happens when a german speaks english )
I mean you cannot arrange the AFR with the other openecu channels.
But I also think that dosent matter, because the AFR came from another source so that there is no time critical problems.
#28
Evolved Member
iTrader: (9)
You may be right, but more so I think as not being important.
What LW does do which I haven't seen with any other logger is log each parameter on an indivividual axis, this makes life so much easier for a human to interprete and analyze data.
All the other loggers I see will graphically display on same axis so you have a steep airflow line but the AFRs appear a solid straight line from 10.0 to 14.7.
Joe Bee, I guarantee if you try LW for a week you will continue to use it
As far as spikes are concerned I wish I could find the source of my dip in AFR at peak load/tourque - no matter lean spool enabled/disenabled, value in fuel map, maf smoothing, scaling, BE, and so forth - I allways get a dip in AFR at peak tourque/load.
All I can think of is it's mechanical, Perhaps this is the max pressure the FP regulator see's and therefore most fuel pressure
Any idears?
What LW does do which I haven't seen with any other logger is log each parameter on an indivividual axis, this makes life so much easier for a human to interprete and analyze data.
All the other loggers I see will graphically display on same axis so you have a steep airflow line but the AFRs appear a solid straight line from 10.0 to 14.7.
Joe Bee, I guarantee if you try LW for a week you will continue to use it
As far as spikes are concerned I wish I could find the source of my dip in AFR at peak load/tourque - no matter lean spool enabled/disenabled, value in fuel map, maf smoothing, scaling, BE, and so forth - I allways get a dip in AFR at peak tourque/load.
All I can think of is it's mechanical, Perhaps this is the max pressure the FP regulator see's and therefore most fuel pressure
Any idears?
Last edited by C6C6CH3vo; May 24, 2007 at 07:44 AM.
#29
Evolved Member
iTrader: (11)
Its ok hahaha, I guess I should have been more open minded when I saw your location lol. But also C6C6CH3vo is right, logworks is very user friendly and as of right now the gauges in logworks 3 are 2nd to none. They respond pretty fast and also show you peak spots and mark them automatically on the gauge.
#30
What can logworks not log? All that you have mentioned can be logged by logworks. It can log anything you can log thru mut protocol via the openport plugin and all add on sensors thru the mts chain using other innovate products. You can also add math calculations such as this
?Target AFR = tafr[11.3] <--11.3 can be changed to your target afr
MC(Tafr;AFR;7.4;22.4) = tafr
and it will put a straight line at 11.3 afr and when your actual afr traces across the log you will see how close are far you are away from target. If I were at my comp I could actually post a demonstration but I am not. And also logworks3 is great. It is currently in beta, but still so far working fine with VISTA woot!!
?Target AFR = tafr[11.3] <--11.3 can be changed to your target afr
MC(Tafr;AFR;7.4;22.4) = tafr
and it will put a straight line at 11.3 afr and when your actual afr traces across the log you will see how close are far you are away from target. If I were at my comp I could actually post a demonstration but I am not. And also logworks3 is great. It is currently in beta, but still so far working fine with VISTA woot!!
Go to Tools->Marker Lines->Channel name in the log window. You will see 2 movable marker lines. Each channel has its own set but only the set of one channel is shown at a time. But their position for each channel is preserved. You can move them to whatever point in the scale by grabbing them with the triangular handle on the right end of the line and moving them up and down.
A shortcut to invoke the marker lines is to click on the channels current value in the measurement pane to the right of the graph pane. Clicking on the empty area below the measurements in the pane switches marker lines off.
As for scales. Using the magnifier tool on the scale of a trace itself allows you to "magnify" the scale of a trace to your liking to see details. You can then move the channel trace or scale up and down with the hand tool.
Another LW3 trick:
To get your log data into for example excel, select the area in the log you want to copy. Select Edit->Copy in the log window. Then open Excel (or whatever, including a text editor) and click on the upper left cell you want the log data to be in. Select Edit->Paste and you are done.
- Klaus
Last edited by klatinn; May 24, 2007 at 01:02 PM.