Showcase: Speed Density Auto-tuning VE map code

[mitsu90]

Not yet. He just sent it to me last night. I'm not the smartest when it comes to tuning so I'm playing it safe and waiting until he get back in town.


He seems to really be interested in it. The last time he tuned my galant,he kept mumbling something about checking out what the swede is doing..

 

[swe_gvr4_1991]

Cool. Keep me posted on the results please. /ubbthreads/images/graemlins/smile.gif

 

[EgonOlsen]

tried to sign up on dsmecu, think the password mail got lost in transit?

 

[swe_gvr4_1991]

The DSMECU has manual review of new members. You should be activated soon if all is OK in your profile.

 

[mitsu90]

Will the auto tuner be able to transition between e85 and 93 or is it strictly single fuel tuning?

 

[swe_gvr4_1991]

Since it targets the AFR you can use any of those fuels, and any ratio of E85/gas mix since the needed fuel injector pulse to provide the desired AFR is calculated in real-time. /ubbthreads/images/graemlins/smile.gif
No more dicking around with mapping after each fill up.



Latest video demo to show real numbers: click

Thanks for watching! (Yeah i know, it's ECU freak porn...) /ubbthreads/images/graemlins/wink.gif

 

[cheekychimp]

Kim,

I remember talking to a member on here before about a similar type of AFR tracking function on the MAFT Pro translator. One of the concerns he had (which I thought was valid) was what happens if your wideband (or more likely your sensor) fails. Is there any chance you could damage something as a result of the software adjusting for a bad reading and going too lean?

I understand risks exist in any type of tuning but is there any sort of failsafe here that prevents the mixture being leaned out too far i.e. can it be capped at a non-critical value that would perhaps rob you of optimum performance but prevent detonation in the case of a sensor failure?

Very interesting project though. After all of the problems I have had with my project car I'd be really interested to see if there is anything you might be able to do to help me get something like this set up on my JDM ECU to run a 2.3 litre stroker.

Paul.

 

[presterone]

Good point maybe a default to ve table if it goes lean at a certain throttle or boost level

 

[swe_gvr4_1991]

That's a valid concern for a non-feedback system. My system has full feedback at 50 times/second at this stage. When the auto-tuner and closed loop code is finished it will have feedback at 400 times/second under light load, and 800 times/second under heavy load.

In the event of the WBo2 failing or during startup when there may not be a valid WBo2 signal, then the "stock" VE map is used. No worries there.

The idea is not to run closed loop under WOT conditions after the VE has been mapped in.
Once the VE map has been mapped in the ECU uses that map for fueling.
Then you can run the auto-tuner in "maintenance" mode and let it adjust just a few % of the VE map value to match the AFR taget.


My SwD code has all sort of user customizable fail safes like over-knock protection, over-boost protection, over-lean protection, etc, etc.
If out of bounds the spark and fuel is cut.

 

[swe_gvr4_1991]

Holy thread clean up!
Or has the forum been reverted back to a earlier state? I noticed connection error the past 2 days.

 

[swe_gvr4_1991]

New video is up with me driving the car while the auto-tuner does it's thing.
When it's done i drive home with that very same tune, totally untouched by human hand.

In car "action" and tune/log review: click

.

 

[swe_gvr4_1991]

Some screenshots of the GUI and two example maps.



Armed and waiting for triggers.

All trigger criteria met, mapping.

Example VE map and a O2 history map.

Thanks for folloing my dev work! /ubbthreads/images/graemlins/smile.gif

 

[belize1334]

I'm curious to know what method you use for getting the code to converge on your target fuel map. Do you have a running mean for AFR in each cell? Also, as the auto-tuner is running is it using the adjusted values on the fly or is it just determining the appropriate correction and then waiting for you to commit the changes? If it's on the fly do you use an Euler step with a safety factor every time a cell gets a hit?

 

[swe_gvr4_1991]

The required fuel is calculated on the fly, in real-time while you drive the car.
Code has a target AFR map in the ECU, which it aims for. Cell by cell according to RPM and MAP pressure.
That's the basics.

It's a fully automated system that only requires me to set the triggers, and drive the car.

There is a much more advanced code in the works that will determine if a cell deserves to get updated depending on ECT, IAT, MAP, RPM, TPS, time elapsed since last updated, procentage of change, and those kind of settings and so on. The code has just gotten out of Proof of Concept stage.

Just to make this clear once and for all. This is a real-time mapping system. No manual work is needed. The manual work comes later to fix cells that are out of bounds etc.


Thanks for showing interest in my work. /ubbthreads/images/graemlins/smile.gif

 

[belize1334]

^^ I think everyone understands the way the final tuned product works. You have a target AFR and you have a fuel table for each RPM / MAP position, which dispenses fuel. In closed loop the resulting AFR is compared to the target AFR and then the ECU trims the fuel to keep it at the best value. This is exactly the same way that the OEM ECU works with the substitution of a VE table instead of a MAF input.

The question that I was asking was more about the tuning side. When you run the autotuner does it continually rewrite your fueling table as it goes or does it compute a suggested alteration and then ask you to accept it? (Here I'm referring to the text on the screen at 2:52 in your video). In other words, when you're running the autotuner and the ECU compares the current AFR to the target AFR and then calculates the new VE, does it then apply that new VE immediately or does it wait for you to authorize the change? If it applies it immediately, do you jump straight to the new value or do you use the average of old and new? This latter method is typically preferred when converging to a value because it keeps the solution from jumping around and overshooting...

 

[swe_gvr4_1991]

Ah ok now i get it.

Yes the auto-tuner updates the cell directly, no confirmation needed. At 2:52 i close down the auto-tuner and download the BIN into TunerPro so i can review it since my code does not yet display the VE map in graphics, only in ASCII.
Both TunerPro and my app cannot run at the same time since the Ostrich is a serial port. It needs to be released by the active program first.

Only the fresh new VE is used att all times in that video. No prediction, no pre-tuned safe maps, etc. This is so i can be really sure i am using only the auto-tuner. (And it's better for me to blow sh*t up than some beta tester, in a case of failure... Trust is earned.)
But here's the beauty of it, you can if you wish run it in closed loop simultaneously. That way the ECU calculates the closed loop fuel requirements and the auto-tuner calculates the new VE map for use later on.
This on the other hand is possible to do at the same time since closed loop is done in the ECU.

As of now there is no converging code or averaging code. But that will come later as i described in my last post.

 

[belize1334]

^^ Nice. The only thing that I would suggest is that you put in a two-step convergence straight away. Leave the rest the same but instead of

NewVE = OldVE*AFR/TargetAFR

try

NewVE = (1/2)*(OldVE*AFR/TargetAFR + OldVE) = OldVE*(1/2)*(AFR/TargetAFR + 1)

This is effectively the same as a running mean with a window length of 2. What this does is, instead of estimating what the correct VE should be and jumping straight there, it estimates the correct value and plays it safe by jumping to a value that is between the old one and the new one. That way the noise in the wideband reading is suppressed and the VE table is more stable. If the wideband has NO NOISE and there is no hysteresis it takes about 5 steps to converge on the to the same value. And realistically that should take very little time for a high-frequency sampling. On the other hand, if the wideband does have noise the VE will keep jumping around, as it will in every case, but the excursions will be smaller so you'll be closer to the ideal value in most cases.

Either way, this is very exciting for me. Can I assume that you'll be sharing the definition files at some point so that people can implement this with their own ostrich? Are you intending on offering this as freeware? shareware? or for purchase?

 

[swe_gvr4_1991]

Thank for those tips! Stuff like this is always welcome.

I did a similar thing when i wrote my improved Vehicle Speed Sensor code. Since the VSS reading are so erratic i did a code that smooths the response and stores it back to the VSS logger item. The result is just mindblowing.
Raw data result, no smoothing applied, no resolution increasing code: click
Final VSS code is going to be in the next SwD release.


The program is a stand alone app for PC. For now. Android is coming later. There is no TunerPro definitions for this one. You use you stock ones.
This app will probably be a purchase app, sorry.

 

[belize1334]

So what do you use to put the ecu in sd operation in the first place?

 

[swe_gvr4_1991]

I use my speed density code called Swede Density (Not me that came up with that name, but it's fitting) which i have talked about before.
This software is not comparable with the older versions of SD code that used the MAF signal code to do all it's calculations and therefore are not even close to SD.
My code is totally clean from MAF code. It uses the MAP sensor and IAT to calculate the fuel required. Just like a stand alone EMS like AEM, Haltech, MS, etc.
There are ofcourse other factors like ECT, TPS enrichment, etc involved in the end.

It's not in the public spotlight as the other SD codes out there, but it's helluva lot better and faster. And has more usable features.

Tester base is pretty big also so i get solid feedback on issues and improvements that users want.