Searching for G4+ logfile (question to mixture map) and logging

[T4700]

Hi,

we are looking for a replacement for our VEMS ECUs.

As VEMS user "VEMS tune by statistics" is a very handy tool to analyze logfiles and refine the VE table and put that data direct to the config file.

I think Link provides a similar function with the mixture map?

I have the Link G4+ software on my laptop and want to get familar with the  mixture map to get a better view of it.

Unfortunately the provided demo logfile has no lambda data so I can not use it for this testing.

Can anybody provide a logfile to me to play with the Link mixture map?

How are the Link calibration file and the logfile connected? How will I get the results of a analyzed logfile back to the calibration file? 

In VEMS a logfile always contains the full config file data (aka calibration file), so after a run I can make changes direct in the logfile and save a config file from that. The logfile will not change from this. I alway get a new calibration file.

The logfile also shows me all changes I made to any calibration data during a run. So if I playback a logfile, I can see changes I made for any recorded time stamp. f.e. to VE table, ignition table, limiters etc.... So I can record one logfile, and test different settings in a run and in the logfile playback I can see all changes and effects in real timeline.

How is that implemented in LINK?

best regards

Edited January 18, 2016 by T4700

[Scott]

Hi,

Attached is a log file with some lambda data. The tune is not complete, but is will give you something to use for experimenting with Mixture Map.

The log file and base-map file are opened in the same software, it is up to you to make sure you open the correct pair of files.

Mixture Map compares the target lambda with the measured lambda. It then looks at the current value for that point in the fuel table, does a calculation to determine how much of a change in value is required, and then applies the change to the fuel table. There are customisable filters that can be used in Mixture Map to improve the process, for example, ECT > 85 C, No accel fuel, no over-run fuel cut, minimum number of samples, etc.

When you apply a change to a fuel table cell using Mixture Map the colour of the cell changes in the Fuel table, so you are able to see which cells have been changed.

PCLink has a base-map compare function, so after you have made your changes you can choose your old (saved on your laptop) base-map and compare the values that have been changed in the fuel table.

test.llg

[T4700]

thanks a lot... I will try this and report :-)

 

update

 

Ok seems like this is what I was looking for. Thanks. Now I have to play a little bit with the software...

Edited January 20, 2016 by T4700

[f8.]

An example of the Mixture Map tab where if you right click it has an option to Correct Fuel Table based on Target and Actual Lambda values. Myself I post-process the logs with a data analysis program called Matlab and it then re-writes a new tune file but I guess this does the same. So tune files iterate with more logs with the aim for error to reduce down.

[Scott]

You can also double click a cell in the Mixture Map to apply a change to the relevant fuel table cell.

[Rob W]

An example of the Mixture Map tab where if you right click it has an option to Correct Fuel Table based on Target and Actual Lambda values. Myself I post-process the logs with a data analysis program called Matlab and it then re-writes a new tune file but I guess this does the same. So tune files iterate with more logs with the aim for error to reduce down.

 

 

That is awesome. I had no idea you could do this.

[mapper]

Rob LINK is awesome! I guess you have dozens other features to discover! 

[f8.]

Yes very neat! I'm just running an Atom so Knock control is unavailable to me, but for the more advanced ECU's with knock control, is this coupling between logged knock values and target with option to correct ignition table available? ie the ignition version of this fuel tuning method.

[Scott]

Hi f8,

The knock control monitors the knock level and once it exceeds the user defined knock threshold the ignition timing is retarded. The actual use of it looks different to the Mixture Map.

[mapper]

And I should add from a tuning perspective, knock control should be never used  to compensate for a bad tune. The proper tuning of the ignition table should always be done with audio knock detection on a good load dyno. 

Knock control is a proactive system, that are there to save the engine, if something goes wrong. It's no excuse to do the tune lazier. 

[T4700]

And I should add from a tuning perspective, knock control should be never used  to compensate for a bad tune. The proper tuning of the ignition table should always be done with audio knock detection on a good load dyno. 

Knock control is a proactive system, that are there to save the engine, if something goes wrong. It's no excuse to do the tune lazier. 

And from mapping so many Motronic cars with OLS300 emulator yet I dont agree.Many Motronic cars hit the knock detection already with oem calibration.

The knock detection in modern ECUs is not only a safety feature. Knock control is to ensure the most efficient combustion. With knock control, modern engines have always a few knock events and if you switch knock control of there they wouldn'nt survive under normal condition. The engines can be mapped for best case (and not worst case) and the rest deg. of the knock limit will be detected by the knock control. But you also need a long term trim function for knock control so the ECU learns its limit. I agree with "you should not hit the knock control all the time" but there is no issue to  hit the knock control under extreme conditions for a few degrees.

 

[f8.]

Agree with T4700: "ensure the most efficient combustion". Would like to add with statistically significant (large) samples. If we apply the approach of iterating the fine tuning of fueling via the use of lambda with real-world driving data, why can't we attempt the same with ignition?

As a simplification, lets say we adopt an imaginary equivalent of lambda metric for knock, called k where k=1 ideal level of knock, k>1 too much knock, k<1 too little knock. For any given load-rpm site, lets say we can reliably log k and automatically step ignition advance/retard by say 1 degree based on each log file's statistically reliable number of samples, won't that iterate towards the most optimal ignition table.

And beyond, we might even have a self tuning capability for ignition(by looking at k) in the same vein as idle control(by looking at rpm) or boost control with proportional and derivative gains.

Maybe this is already done?

[T4700]

I think ignition timing is to complex to be done by a self tuning function in the ecu but what you mention is - so to speak - the sellf learning function to adapt a existing ignition map to different operating conditions.

OEM ECU recognize significant knock events and can learn to handle bad conditions like lower ROZ fuel f.e..

First you have knock control. If a knock event is recognized, ECU retards ignition by -X degree. If its still knocking another retard by -X degree. ECU gets the retard value from a map. Values are between -1,5 and -3,0 degree per knock event, dependant from rpm.

After that and no further knocking ECU is trying to advance ignition by Y degree, step by step, back to map value - learn value. How fast this all will happen is also read from map values. ECU learns the optimal retard value and stores this into permanent memory.

If engine is knocking violently and knock control is exceed, ECU cuts max permitted load. This is a extremly simplified explanation.

Keep in mind - OEM spends supremely money and effort for every engine in perfect working knock control.

But I see there is a non permanent memory in Link for knock retard values. Maybe if you analyze these values after a few runs (ECU must stay powered) you can use these values to refine your ignition map by hand.

But before you can use that, you have to do a reliable ignition map with headphones because you need a basemap that you know its not knocking. This is necessary to calibrate the knock control himself. Without that, ECU knows nothing about your engine behaviour.

This ist much more difficult than lambda ;-)

 

[mapper]

That's gone be an intressting thread! 

I can't completly agree with T4700. I just seen to many blown engines and pistons from other tuners, due to knock. Most likely they just tune on the street or on the dyno with to less load (to fast ramp runs). Problem is as soon you start to push you engine very hard, the combustion temperature gets much higher and so the knock threshold lower. Means if you tune to the knock limit on the street, you are going to be quite alot over the knock threshold on the race circuit or german autobahn. 

Of course, on a low powered engine light knock doesn't harm the engine much. But as more specific power per liter you make, as more harmfull can a single knock event be. For example, a single knock event can be enought to push a head gasket out or do other damage on a 300hp+ per liter engine, since the combustion pressures will skyrock during a knock event. 

Beside of that every knock event hammers down to the rod bearings. In my experience that leads to road bearing failure over time. I suppose thats the reason for the many rod bearing failures you see on tuned Subarus. Similary on Mitsubishi Evo's. It seems most Mitsubishi tuners rely much to much on the OEM knock control and put in very agressive timing. Works on the road on a engine with std. internals. But I've seen much to many melted pistons from other tuners, after the first serious use after the agressive tune of on the track.  As more hardware you change on an engine as worse the OEM knock control works, because the fequency can change. For an example the OEM knock control on a EVO 6-9 are useless if you stroke the engine. That's the reason I use always audible knock control, also on non modified cars for tuning. 

Regarding the LINK knock control. It's a excellent system, but it needs to be fine tuned, and it can pic up false knock as any other system does. You need to spend many hours and apply knock over and over again to fintune it (which already can harm the engine). Anyway I don't think that you can tune an aftermarket knock system as good as OEM can do it with Motronic, since they are using combustion pressure sensor to do that job. And in the end its a proactive system, means knock must apply first, before it can react.

So due the reasons i mentioned above, i wouldn't use this function to fine tune your ignition table. 

I don't mapp Mototronic ECU's. But have measured and dataloged many. I found that most "chiptunes" are quite bad. Much to lean, bad boost control and the worst, they retard the timing a lot due to detonation. Surprisingly most of this engines hold together quite long with such a map. Think there are two reasons for that. First,these cars are just used on the street, where there don't see very high load for long times (which leads to high combustion temperatur and much lower knock treshold). Second, the Motronic ECU's has in fact, a very very good knock control. 

It seems the Chiptuning market differs a lot from the "Dyno custome tuning market" . Its usual to just put on a file an let the car out. (Thats what most big Chiptuner do, like APR, Revo, German Tunners etc.)  Surprisingly most Chiptuned cars holds together. Think the European Ecu's are doing realy a better protection, in case of a bad tune. Seems like Japanese cars are blowing up much faster with a bad tune somehow. 

Edited January 27, 2016 by mapper

[T4700]

@mapper - true post, I have nothing to add

Motronic knock control is supherb. Fortunately in Germany you can push a RS4 Turbo up to 300km/h on the autobahn. We do this gently uphill trough all gears to get maximum stress.

OLS Emulator does a good job because you can live tune via Laptop.These cars handle around 550-700 hp and there are a few with more than that. I had never one molten oem piston. (forged rods, bigger exh, bigger inj, bigger turbos etc etc)

Also exhaust temperature control does a brilliant job and is not only a safety feature. You can map two lambda targets and switch automatically to a richer target map at higher EGT. If the EGT is still rising, the EGT control kicks in. If the EGT still rising, load is cut. But when mapping, you have to secure that EGT control catches the EGT at around 970-980 deg C. I have seen chiptunes with 1015 deg EGT - thats to bad! Also many of them have issues with intercooler - IAT.

Unfortunately If one knows such nice features, he also wants to find them on the aftermarket ECUs

But If I learned right from reading. LINK Thunder has two EGT inputs and I can use them for EGT control via 4D fuelmap. Simply change one axis from load to EGT

The only issue I see is, there is no EGT dependant Lambda Target table. So If I use lambda control up to max rpm/load and EGT is richen the fuel, lambda control will turn it back to target

Edited January 28, 2016 by T4700

[mapper]

Of course there is a possibility to make that happen. Much much more is possible with the LINK platform, than what you may expect in the beginning. You can get very creativ with GP inputs, outputs,virtual aux, GP-limit table, and overlay tables. As an example use GP limit table to set an oil pressure minimum vs RPM or differential fuel pressure limit. 

 

Use the target overlay table and span the axis EGT vs what ever you want. This way the target are changed and closed loop controll does follow the new target. 

Usually i use target overlay  to put some additional fuel in at high vehicle speed and use 4D ignition to take out some timing. Usually load and consequently combustion temperature are much higher and high road speeds. 

Motec has a very nice "load average" function. I like to see such a function also on the LINK platform. Mathematical its just an integrator for load. 

[Ducie54]

I'm only new to tunning but won't the below work

Set the fuel equation to modelled- multi fuel than just change the axis of the multi fuel blend ratio to thermocouple 1. Initialize the axis so it does not interpolate under your EGT target switch temp.

 

Than as mapper said just use a GP limit with EGT as one of the axis

 

 

[mapper]

I'm only new to tunning but won't the below work

Set the fuel equation to modelled- multi fuel than just change the axis of the multi fuel blend ratio to thermocouple 1. Initialize the axis so it does not interpolate under your EGT target switch temp.

 

Than as mapper said just use a GP limit with EGT as one of the axis

 

 

not sure if you can set up axis this way. I'm sure Scott can check that for you. 

However why do that such complicated. Just use the Lamba target overlay as I descripted above and ad some full. Think an additive table gives anyway more freedome since you can progressivly add fuel instead of just switching maps. 

[T4700]

Of course there is a possibility to make that happen. Much much more is possible with the LINK platform, than what you may expect in the beginning. You can get very creativ with GP inputs, outputs,virtual aux, GP-limit table, and overlay tables. As an example use GP limit table to set an oil pressure minimum vs RPM or differential fuel pressure limit. 

 

Use the target overlay table and span the axis EGT vs what ever you want. This way the target are changed and closed loop controll does follow the new target. 

Usually i use target overlay  to put some additional fuel in at high vehicle speed and use 4D ignition to take out some timing. Usually load and consequently combustion temperature are much higher and high road speeds. 

 

woha...  I will look at this in PC Link asap ;-)

[T4700]

target overlay map = AFR/Lambda Target Table2 ??

 

I nice additional feature would be a EGT Limit under Engine Protection.

Because if a richer lambda target table is not able to catch the EGT (maybe a failure in fuel delivery) a load limiter by EGT would be a solution

[mapper]

You can do that too! Just span WG duty cycle vs EGT or if you use closed loop boost control (recomend that) target boost table with EGT on one axis. 

Remember if you use closed loop boowt controll you span usually WG duty cycle table  Target boost vs RPM. Fill the table too reach each boost target with the right WGDC. If you do that you can just put im your target map numbers in the target map and use the axis settings for things what you want. E.g. Egt vs rpm. 

Regarding the target overlay map. You have to activate it first under "fuel main" > Lambda Target Table Overlay" > ON 

Now you find the table in the menu "FUEL, same place as AFR/Lambda Target Table. 

[T4700]

Ok.  I tryied that in PCLink. Nice thx

But when I do this, I have no boost vs rpm map anymore and can not calibrate a boost curve

"Remember if you use closed loop boowt controll you span usually WG duty cycle table  Target boost vs RPM. Fill the table too reach each boost target with the right WGDC. If you do that you can just put im your target map numbers in the target map and use the axis settings for things what you want. E.g. Egt vs rpm. "

Edited January 28, 2016 by T4700

[mapper]

Have a look a this closed Loop boost control example! Best is if you read through the closed loop boost section of the help file, too. 

If you want use openloop, just span the Y-axis to EGT. 

Regardless of control method, you must setup an EGT iput first for EGT, an chose than the Input as an axis. 

 

 

Edited January 28, 2016 by mapper

[T4700]

Ahhh, sorry  I made a big mistake in rpm axis calibration.  My fail - I dont tell you what happened, its to stupid

everything is clear now

EGT input was already clear

thank you mate