I'm a bit curious and concerned about what auto tune is going to do. It's my assumption, and I believe accurate, that if all the ecu's components are working correctly it will result in actual AFRs that match the fuel maps. That's the whole point of the system right? Obviously the AFR can't match exactly all the time but it should probably average out pretty close to whats on the map. My concern is that people will use autotune to correct for incorrectly set K, void, and vq maps. I suppose the end result AFR is the only real concern but it seems to me that if you could get the maps to match up with the real AFR it would be easier to tune.
Now my understanding so far is that autotune will average wideband readings for each cell and change the fuel value accordingly to match the target value. I can see where this would be necassary for fine tuning areas of the map that simply dont match up with the actual afrs even when everything is set correctly.
Since it's not completely implemented yet I'm wondering...
- Will/can there be a fuel map window with each cell and its "offset percentage" showing how much each cells actual afr average is from the ecus set afr?
- Is it possible/advantageous to calculate and display a "global alpha value" similar to the value used in the z32 ecu.
I think both of these features would help pinpoint K values and void constants before autotune is used to compensate for other issues.
Autotune concerns. How will it work?
Moderator: Matt
In my case when injecting methanol the afr's are always going to be different from the calc'd afr's. It won't be consistant in my case either because the controller varies the alcohol as the maf voltage. I've been looking at the ford maf based systems which are very similar to ours and what those guys do is tune the maf as well to match the commanded afr's. I'm not sure that's the correct way to do it but it is a way. Does our ecu track/monitor the corrections made in closed loop? Kind of like the GM ecu's BLM values.
our ecus apparently do some trimming on the tables, but i dont see like a 16x16 trim map of anything doing those ram traces or code. but there would be some set of trim values which come off the O2 sensor somewhere there.
theres got to be more people knowledgable about how nissan trimming works....
there are a whole bunch of coefficients which are multiplied against the fuel table, so in real life i doubt you will get the exact AFRs calced on this table.
okay the autotune feature is an experimental feature (that was in the enhancements list) but only just started and coded in one night, as you can see all the graphics are done. the AFR trace table will record the last measured AFR at each load/rev point visited
the autotune table is based at the start from the 'target AFR' values but this does not mean that these target AFR values are actually what is done by the ecu. its just a starting point
autotune will only be for the primary fuel map (not k constant, vq etc)
the idea is to take the current AFR displayed for that value and gradually increase/decrease the injector pulsewidth in the primary fuel map until the desired autotune value is reached
theres got to be more people knowledgable about how nissan trimming works....
there are a whole bunch of coefficients which are multiplied against the fuel table, so in real life i doubt you will get the exact AFRs calced on this table.
okay the autotune feature is an experimental feature (that was in the enhancements list) but only just started and coded in one night, as you can see all the graphics are done. the AFR trace table will record the last measured AFR at each load/rev point visited
the autotune table is based at the start from the 'target AFR' values but this does not mean that these target AFR values are actually what is done by the ecu. its just a starting point
autotune will only be for the primary fuel map (not k constant, vq etc)
the idea is to take the current AFR displayed for that value and gradually increase/decrease the injector pulsewidth in the primary fuel map until the desired autotune value is reached
I think what I'm hoping for is a sort of a passive version of autotune that could be used to help the user make their own changes to the K or void constants. Think of it as a passive version of the nissan fuel trimming but using a wideband. Instead of having autotune actually change the fuel cells could you have it record the trim percentage in a table? I could then look at the table and see that most of my cells are off by a certain percentage and I could adjust my K accordingly.
Also, other than acceleration enrichment, what other coefficients would have an effect on the final afr relative to the table? Once the car is up to temp and the engine is in a steady state I cant think of anything.
Also, other than acceleration enrichment, what other coefficients would have an effect on the final afr relative to the table? Once the car is up to temp and the engine is in a steady state I cant think of anything.
the AFR you get is at a particular load/rpm point. you should not use this to adjust a global constant (such as K and void) without affecting anything else. i think this would be a bad thing to do
the tuner should monitor the A/F ratios whilst exercising the map range and then adjust K constant in small steps whilst monitoring mixtures in the entire range
what would the auto tune use to measure the trim percentage? the 'targeted' A/F ratios against measured A/F ratios would give an 'ideal' figure against measured.
dont think of the fuel maps 'as this is your A/F ratio' (maybe i should remove that display) but as an injection revision for that particular load/rev range based off previous calcuations. this is what the table from japanese translation is called - a 'revision' table
what this means is that X A/F adjustment on load/rpm point cannot directly be mapped against measure A/F ratio to an accurate trimming percentrage.
the only way to get autotune to do this, (a) is to change fuel revisions, (b) measure and then repeat until you reach your target against measurement
yes temperature is one factor, O2 sensor is another, fuel temp, TPS variable resistor, acceleration enrichment etc and other sensors inputs could also come into play. the calculations are detailed in the nissan patents for most type of vehicles how they are calculated.
the tuner should monitor the A/F ratios whilst exercising the map range and then adjust K constant in small steps whilst monitoring mixtures in the entire range
what would the auto tune use to measure the trim percentage? the 'targeted' A/F ratios against measured A/F ratios would give an 'ideal' figure against measured.
dont think of the fuel maps 'as this is your A/F ratio' (maybe i should remove that display) but as an injection revision for that particular load/rev range based off previous calcuations. this is what the table from japanese translation is called - a 'revision' table
what this means is that X A/F adjustment on load/rpm point cannot directly be mapped against measure A/F ratio to an accurate trimming percentrage.
the only way to get autotune to do this, (a) is to change fuel revisions, (b) measure and then repeat until you reach your target against measurement
yes temperature is one factor, O2 sensor is another, fuel temp, TPS variable resistor, acceleration enrichment etc and other sensors inputs could also come into play. the calculations are detailed in the nissan patents for most type of vehicles how they are calculated.
the A/F ratio display for the wideband i got working last night. currently it records current, max and min values internally. i can also add averages internally
what i was going to do is display current as a greyish cell when we get an AFR for that particular point. when you hover your mouse over a well you will be presented with min, max, average also
i havent got a unit to plug into logworks so i cant play around with that software much. if you can post some screenshots of what you see to this thread and i can probably do something similar
what i was going to do is display current as a greyish cell when we get an AFR for that particular point. when you hover your mouse over a well you will be presented with min, max, average also
i havent got a unit to plug into logworks so i cant play around with that software much. if you can post some screenshots of what you see to this thread and i can probably do something similar
you can download it and play our logs... there's a few that have been posted, if memory serves.
when replaying a log, go to "view" "new chart" set the max rpm, 16 steps, then change the other axis to 'boost' 16 steps.
when replaying a log, go to "view" "new chart" set the max rpm, 16 steps, then change the other axis to 'boost' 16 steps.
- Attachments
-
- lm1chart.JPG
- charting screenshot
- (61.88 KiB) Downloaded 5431 times
no probs. i can see how it fits together. will try those logs out
i can probably display min,max,ave as a click on display in the window rather than a hover over graph (would be easier to implement)
for the main window i could do a drop down combo box to determine what the grid currently displays (curr,min,max,ave)
i can probably display min,max,ave as a click on display in the window rather than a hover over graph (would be easier to implement)
for the main window i could do a drop down combo box to determine what the grid currently displays (curr,min,max,ave)
Here's my understanding of how the fuel map is used. Please correct me where I'm wrong. First, the ecu gets the afm value so it knows how much air is coming in the engine. Then, since its knows how much air it has it calculates the injector pulsewidth for stoich in a calculation using the K and other variables probably. This is the tp thats used as a load value correct? The ecu then uses the tp and rpm values to lookup the fuel "revision" table and find out what extra amount of fuel we want actually injected. The ecu takes the revision value and calculates a new pulsewidth based on the original stoich pulsewidth and the pecentage of fuel we want added/subtracted. Finally this final pulsewidth is modified with the temperature, acceleration, and other trims/enrichments before its sent to the injector controller. Is this correct?Matt wrote:the AFR you get is at a particular load/rpm point. you should not use this to adjust a global constant (such as K and void) without affecting anything else. i think this would be a bad thing to do
the tuner should monitor the A/F ratios whilst exercising the map range and then adjust K constant in small steps whilst monitoring mixtures in the entire range
what would the auto tune use to measure the trim percentage? the 'targeted' A/F ratios against measured A/F ratios would give an 'ideal' figure against measured.
dont think of the fuel maps 'as this is your A/F ratio' (maybe i should remove that display) but as an injection revision for that particular load/rev range based off previous calcuations. this is what the table from japanese translation is called - a 'revision' table
what this means is that X A/F adjustment on load/rpm point cannot directly be mapped against measure A/F ratio to an accurate trimming percentrage.
the only way to get autotune to do this, (a) is to change fuel revisions, (b) measure and then repeat until you reach your target against measurement
yes temperature is one factor, O2 sensor is another, fuel temp, TPS variable resistor, acceleration enrichment etc and other sensors inputs could also come into play. the calculations are detailed in the nissan patents for most type of vehicles how they are calculated.
My main point is that minus the tims/enrichments that are calculated later on the ecu's calculation of pulsewidth for a particular amount of air should be accurate so what is on the "revision map" should match the actual afr readings. This is assuming the K, void, and whatever other variables that are used to calculate the pulsewidth are accurate for the afm and injectors being used. If we are able to minimize the affect of the temperature, acceleration, and other tims/enrichements I think its reasonable to assume that the actual afrs should remain spot on with the revision map. Many of these trims/enrichments can be minimized or cancelled by turning them off (O2 sensor) or monitoring the afr when they have a minimal affect like when the engine is up to temp (no enrichment) or under constant load (no acceleration ).
That being the case...If we collect afr data during these conditions it's reasonable to assume that it should reasonably match the revision map if the ecu's K and other variables are correctly set. It also means that if we are doing a custom injector/afm setup the closer we get the K and void the closer the actual afrs will match those on the revision map.
Here's what I'd like to see as a function of nistune. Think of it as a statistics tool to nail down a correct K value.
- Nistune would monitor and averange the actual afr of each cell as you operate using the built in maptrace and wideband. So what you would end up is something similar to the logworks graph posted above but it would be a nistune version based on load/rpm.
- Nistune would then compare the afr that was actually read to the afr the ecu is aiming for on the revision map( fuel map). This could result in a percentage difference.
- Nistune would not change anything. All it would do is plot the variation percentage between the fuel map and the map of measured afrs.
Based on that information I think I could make educated changes to my K and void. This would be done manually. For example
- If all my cells read 2% richer than their target afr I could assume that my K is too high. I could change my K and do the tests again until the cells match spot on.
- If the cells in the lower pulsewidth areas of the map read leaner and the higher pulsewidth areas read fine I could assume my void is too low.
Does that make sense? Feel free to straighten me out.
The only reason I can see that this wouldnt work is that the trims/enrichments could throw things off. But as I mentioned I think those can be minimized.
The above technique is more or less what I've been using to narrow down my K values. I set the entire fuel map to 12.5 AFR and change my K until my actual afrs average as close to 12.5 as I can get them. The problem is I have to set the entire map to a certain afr to make it easier to match things up. Since nistune can match afrs directly to their cell it would be much easier.
okay what I can do is....
in addition to displaying the current, average, max and min AFRs on the 'grey' grid I can add a delta option
the delta option would take the measured average AFRs collected and then display them as +/- differences against the fuel map target AFRs/pulsewidth adjustments
this would do exactly what you want. im going to leave the autotune window for now, and just do this as it is fairly easy to implement
in addition to displaying the current, average, max and min AFRs on the 'grey' grid I can add a delta option
the delta option would take the measured average AFRs collected and then display them as +/- differences against the fuel map target AFRs/pulsewidth adjustments
this would do exactly what you want. im going to leave the autotune window for now, and just do this as it is fairly easy to implement
Okay most of the wideband stuff has been implemented.... including logging and playback. I've just bench tested all this stuff tonight. The 2D graph displays various views for average, min, max and delta off the autotune grid map A/F ratios (derived from main grid A/F ratios)
There are two auxillary input tables available for other sensors. They can be whatever you like, just use aux1.csv / aux2.csv. This is a table with first value being the raw voltage input and second the values they correspond to (boost sensor etc). the values from the table are linearly interpolated to fill in gaps between values
The only thing left is the 2D grid which will be a dyno grid. This will display A/F ratios against RPM.
It also provides scope for doing an on road dyno readout in the future (taking a vehicles weight and drag coefficient by rpms and speed from consult for doing a dyno approximation similar to gtech etc). I dont know the calc for this but people writing add in s/w for other aftermarket ecus have done this before. This is an enhancement and wont be done yet until bugs are fixed!!
There are two auxillary input tables available for other sensors. They can be whatever you like, just use aux1.csv / aux2.csv. This is a table with first value being the raw voltage input and second the values they correspond to (boost sensor etc). the values from the table are linearly interpolated to fill in gaps between values
The only thing left is the 2D grid which will be a dyno grid. This will display A/F ratios against RPM.
It also provides scope for doing an on road dyno readout in the future (taking a vehicles weight and drag coefficient by rpms and speed from consult for doing a dyno approximation similar to gtech etc). I dont know the calc for this but people writing add in s/w for other aftermarket ecus have done this before. This is an enhancement and wont be done yet until bugs are fixed!!
-
Twin-turboZ
- Posts: 43
- Joined: Wed Feb 22, 2006 6:38 am
- Location: Vancouver Canada
Hey Guys,,
Matt, i had made the sugestion about integrating a in vehicle dyno to Eric from DTA matorsports (conZult)
Using the weight of the car and without getting into compensating for the aerodynamic drag it would be a relatively simple calculation to figure out average HP based on how long it would take to accellerate from one known speed to another.
He told me that he had thought about it, but the speed sensor resolution was not suficient to have any kind of acuracy.
Would be a nice feature though.
Matt, i had made the sugestion about integrating a in vehicle dyno to Eric from DTA matorsports (conZult)
Using the weight of the car and without getting into compensating for the aerodynamic drag it would be a relatively simple calculation to figure out average HP based on how long it would take to accellerate from one known speed to another.
He told me that he had thought about it, but the speed sensor resolution was not suficient to have any kind of acuracy.
Would be a nice feature though.