M8 - Set Lambda during a CL to OL transient

[hrdtail78]

Closed loop is active during PE and even under DE, we filter decel out using min MAP threshold so it doesn't try to follow & learn what's happening during transients.

How do the tables of Closed loop AE DE freeze Level and Closed Loop AE DE Freeze Time come into play with this?  The software has a recommendation of setting to use with TT.  It recommends that if transient conditions last for 2 milliseconds to freeze closed loop operation for 15 engine cycles.  But I don't see a distinction between AE or DE.

Power enrichment mode activation is dynamic.  Which also makes the target AFR dynamic.  Since the most basic calibrations are based on TPS and time.  The clock starts when tps hits the parameter.  Meaning that the clock can start at various rpm's.  If main target AFR table is set to .880.  If we go 95% tps at 2000.  Time base target AFR from PE mode table has a new target of .870.  As rpm goes up.  A richer mixture is called out.  My understanding from what your have explained.  Corrections will be made in the trim tables.  But now we hit the tps parameter at 4500 rpm's and the clock starts and the target is .870.  But wouldn't the trim tables be set for when we activated PE mode at 2000 and at 4500 PE mode was targeting .840 at 4500 rpm's?  This is what I mean by a dynamic moving target, and can skew fueling trims and the predictions that the ECM does.  Sure the TT will straighten it out next time it is in the area but first it needs to read and make those calcs to trim it back in.  Instead of just using a mapped VE table for the air flow and shooting for a richer target over time after PE mode is activated.

Trim tables are on the air calculations of the ECM. Fuel Mass= Air Mass  x (STFT x LTFT)  Air Mass is represented by VE.  The above describes the very basic PE modes.  Later TBW cals can have PE mode activated with TPS and KPA.  Which could cover even more of the VE tables. Seems to me for what it is worth.  Close loop in the area where PE mode is activated at the same time can cause the trims in that area to really chase it's tail, and I can't see with my limited understanding of how TT works.  How it can be a better strategy than just proper mapped VE tables.  Or turning PE mode off w/ TT and just asking for a richer target in the main AFR target table as RPM increases.

I turn PE mode off when mapping VE on a NA engine.  On a dyno WOT pulls don't take as long and PE mode is rarely activated for enough time to go to much richer mixtures. 5-9 seconds depending on power output of the engine.  Compared to a 2500 to 6200 6th gear pull on the street.

[hrdtail78]

hrdtail78, you have put the finger on ! I sent you an email.

 

After going through the logs you have sent me.  It is targeting .981 in that area.  A couple of things with that.  There are multiple hits in that area but no two hits back to back.  I would suspect something to do with how Vision needs the base cal to build on, but I am not 100% on that.  I haven't seen this.  It looks like the changes made in the cal didn't take affect when loaded, or how the data is being read in the log.

If the vision uses the base cal and then has an adder table to change the Target AFR table.  The one hit might just be the base AFR table and might take more data hit in a row to see the adder table on top.  Not sure how it works but I think DJ would be interested in seeing this.

[hdmanillac]

...I think DJ would be interested in seeing this.

Sure, but I don't know how to get them to deal with this problem...

I tried but the guy that answered me did not undertood the problem.

[hrdtail78]

Well, at first I wasn't following. Reason for my answer about other tables.  Then you posted the histogram pic and I figured out what you were saying.  I did reach out to Dan H at DJ.  Maybe he will pop up or give me a call back. 

[hdmanillac]

Well, it's very nice of you and if it leads to something concrete I would be very satisfied.

I thank you very much for your help.

 

[Jamie Long]

Some quick clarification on how the PV sends the tune. It doesn't use the OEM calibration, rather it uses data within the calibration that's currently in the ECM versus sending all of the redundant files. When you initiate a flash it checks the existing file vs the file you are sending, any edits to the calibration that are different get sent, the rest of the files stay in place as these are values that are already there. This is why some tunes flash in as little as 15 seconds, however if you change tune strategies (i.e Level 723 to 921) it can take about a minute or so as its sending the full calibration in that case.   

[hrdtail78]

I changed the scaling up a bit to more pin point the area of concern.  Not many hits in this area at all and never two hits in a row. 

[hdmanillac]

I've got other logs with more hits in this area of concern.

But when you log on the road, you can't always stay in this critical zone for a long time.

[hrdtail78]

Does anyone else see what hdmanillac and I are seeing?  I will send to anyone that wants the calibration and log file to open it up with whatever you are comfortable with.  Have a couple of cals and log files.

[Jamie Long]

Does anyone else see what hdmanillac and I are seeing?  I will send to anyone that wants the calibration and log file to open it up with whatever you are comfortable with.  Have a couple of cals and log files.

send them to jamie@fuelmotousa.com and I will take a look

[hrdtail78]

You cannot view this attachment.You cannot view this attachment.

[hdmanillac]

so ? any idea ?

 

[Jamie Long]

I took a look at your log and I can see what you are referring to. I'm not quite able to make to a complete conclusion based on one log however I have a couple ideas what may be going on. The first thing I would have you try is to set the entire Lambda table as well as the PE table to .980 and take 10 minute log, then set both tables to .920 and take another 10 minute log, and post the logs so we can have a look. Being that you are overseas I'm assuming you have an HDI model and i'm also curious how your tune was derived; essentially what you used for the base map, the more info you can provide the better.

[hdmanillac]

Ok I'll do that asap. The temp ouside is very cold at the moment and I hope I don't turn into ice.

As I said before:
- whether I use my original 824 cal or this 823 cal from the previous model, the problem remains the same.
- I have also observed this phenomenon on all the M8 motorcycles that I have tuned.

[hdmanillac]

From the DJ Technical Support:

"With the latest information received from you, I got our engineers involved again.  As it turns out, they were able to identify the specific issue and already have the solution.  This should be included in the next round of updates, which will be coming soon.  Thank you for pointing this out and helping us to more clearly understand the issue.

I suggest that you either connect that PV to your computer once a week to check for updates, or keep an eye on the following downloads page for updates.  Once updated, give it another try.

If you have any further questions or concerns, please feel free to contact us again."

This is very good news and I look forward to the next update of my PV.

 

[hrdtail78]

You cannot view this attachment.You cannot view this attachment.

Looking through the log.  At 243200 (2643) (First number is the time stamp.  Other is row in excel) You can see that the engine is 2100 rpm's, 64 kpa and set lambda is .981.  Throttle is opening slowly.  Rpm and kpa are climbing. At 245789 (2671) Engine is 2490 rpm's, 84 kpa and set lambda is still .981.

The calibration is set for .800 from 70 kpa to 100kpa for all rpm's.
Set lambda was .981 for 2.5 seconds.

You cannot view this attachment.

You cannot view this attachment.

When we look at other times the engine is in this area. 418519 (4512) to 419139 (4519)  Engine is 3011 rpm's at 71 kpa.  Set lambda .981. 

272567 (2958) to 279808 (3035) Engine is 1999 rpm's and 75 kpa.  Set lambda .981.  Both of these last two seem to shoot for .801 once hitting in the 80kpa's.

Some other interesting data as you are looking.  This bike is running on narrow band sensors.  Set lambda never did go to .800.  Maybe .801 is the limit.  Bad news for corn guys.  WBO2 front and rear are reporting and VE new is changing.  1223448 (13152) and 1223809 (13156) are just two example to view in excel.  This can easily be seen with MLV.

You cannot view this attachment.

I hope they got it fixed and am glad they recognized that there is a problem.  I went from "that is a lugging area" to "I had no idea this bike was not set up for target tune."

You cannot view this attachment.

[hdmanillac]

In conclusion, do you think that the problem comes from the fact that the ecm is partially configured for a TT cal while it is a cal for narrowband probes?

This reminds me of a cal reflash problem.

I noticed that WBO2 F and Front O2V are correlated in the log.

[hrdtail78]

I really haven't came to a conclusion.  This might not be a calibration problem at all.  Might be how the PV requests and gets data from the ECM.  From what I have seen and discussed with other tuners.  This has seem to be a problem in the past.  Case in point might be AE and DE traces that PV is unaware of the m8 putting out.  It would be interesting to collect data with DTT ad look at it's log.  That is how I collect data when doing a PV tune, and then I use my tune.  This has always worked out for me better than using what is supplied in the PV software.

Usually when I am collecting narrow band and there is no wide band data or a wide band controller goes off of line.  The trace reads the leanest the controller puts out.  The leanest the frt is reporting is .815 and rear is .808, but the rich's they report is .685.  But as was explained earlier by Jamie.  WB's have a range and this is reporting out of that range.

TT uses closed loop over the entire AF/Lambda table regardless of Lambda value; closed loop will follow any commanded AF value in the calibration as long as the command is within the range the sensor can measure (.70-1.15 Lambda/ 10.5-17.0 AFR).

Seems if this bike was running as rich as indicated by the log.  Narrow band sensors should be showing the same extremely rich condition, and the trim tables should be showing it in the closed loop area.  So, I really don't know and hope they figure something out. 

[hdmanillac]

To be honest, I don't use autotune either because it produces VE tables that are too rich in the open loop area. I use another personal technique based on narrow band probes. And this technique uses, among other things, the "Set Lambda" signal. If the signal is false, the VEs will be false.

Dynojet said they found the problem and they have the solution. So we cross our fingers and wait for the next firmware of the PV...

[hrdtail78]

To be honest, I don't use autotune either because it produces VE tables that are too rich in the open loop area. I use another personal technique based on narrow band probes. And this technique uses, among other things, the "Set Lambda" signal. If the signal is false, the VEs will be false.

Dynojet said they found the problem and they have the solution. So we cross our fingers and wait for the next firmware of the PV...

That is why it would be interesting to collect the data with another device that will show set lambda.  This could possibly tell us if it is just a data collection problem or a calibration problem.  If another device collected it and set lambda was displayed as we think it should, based on AFR lambda table.  Ding ding.  Yes, set lambda is very important to a speed density EFI system.  The whole system is based on having this correct.  VE's are for nothing without it.

[hdmanillac]

Personally I don't have any other device to make recordings on this motorcycle.
But I will ask friends if they can do it.