Announcement

Collapse
No announcement yet.

16x16 VE table fuel tuning on MAF based cars?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • 16x16 VE table fuel tuning on MAF based cars?

    after working with PRJ's creation as much as i have i had a thought about tuning for MAF based cars since not everyone wants to convert to the full speed density software for some strange reason or in the case of the 3B 200 20v that cannot be speed density because of code space limitations. My thought is if it would be possible to have a VE table for fuel tuning as well because fuel tuning on the original software is pretty stupid to me with no place to actually fine tune the fueling. all i can see is you have to play with FGAT0, TVUB and a few MAF scalars and hope for the best when it comes to getting the fueling the way you want it. ever since using the speed density software with a VE table in play it made things a million times easier to calibrate the fueling exactly how i wanted my car to be.

    From what i understand of the VE table in PRJmod is that it is essentially replacing the 3 MAF tables. the only difference here is from what i understand just replacing the MAF scalar tables will screw up everything including the load calculation. i have been trying to follow a disassembly of PRJmod motor chip to see if i could make something like this work on the 3B but i have not had any luck personally. after pointing the MAF code at a 16x16 VE table and trying to make all the proper moves i just get lost in it all because i understand there are still dependiencies that the MAF needs where as the speed density software does not need. now since i removed the linearization mapping itself and replaced it with the 16x16 table should the linearization code be bypassed as well? it seems like the right thing to do but when i tried it the car gets even more unhappy. maybe PRJ can chime in on this one since this area is his specialty.
    "The really good drivers got the bugs on the side windows." Walter Röhrl

  • #2
    "..the original software is pretty stupid to me.." - the original soft is one of the best just it's propose is that.
    "..just replacing the MAF scalar tables will screw up everything including the load calculation." - Unfortunately It's not that simple!!!! Load calculation is the Main calculation and it's never be "screw up" - just input parameters for recalculation are different and to have proper/correct values Dmitri add VE table, VE multiplier, VE addend, IAT correction and etc. and etc.

    To understand what is avoided and what is added just put together (by offset) disassembled stock ADU code and PRJ SD code. You will find which procedures are skipped and which procedures are fully modified/added - like: timer interrupt to poll the throttle pedal, delta tps instead of delta maf , re-calibrated from scratch all transient compensations and so on. All described from Dmitri in M232.org.
    If you think that with just one 16x16 VE map you can adjust all variables and parameters this is frivolous.

    Look carefully in comparison of the codes and you will find how many procedures are different.

    Comment


    • #3
      you make it sound way more complicated than it really is. i did manage to make a VE table for fueling just like in PRJ's SD code.

      his VE table does replace the 3 MAF scalars, here's where they replace the access to the 3 MAF scalars and the MAF linearization code.
      Code:
      00002293          Added table accesses for VE table and SD IAT correction table.
      code:00002293
      code:00002293          Custom_05:                              ; CODE XREF: Data_Logging_Code_05-5FC8↑j
      code:00002293 7A 00                    mov     R2, #0          ; Move (Op1 <- Op2)
      code:00002295 12 0F F9                 lcall   TableAccess_02  ; 0xA050 VE table
      code:00002298 F5 46                    mov     FKH, A          ; Move (Op1 <- Op2)
      code:0000229A 12 0F F9                 lcall   TableAccess_02  ; 0x9022 Iat Correction
      code:0000229D F5 7B                    mov     FUH, A          ; Move (Op1 <- Op2)
      code:0000229F
      Here is the original access to the 3 MAF scalars which is no longer accessed in SD code. also you can see that the values from these 3 tables are placed into RAM FKH just like the VE table is in SD code.
      Code:
      code:000022F3 7A 00                    mov     R2, #0          ; MAF Table 01
      code:000022F5 20 46 07                 jb      Flag4.6, code_22FF ; Jump if Bit is set
      code:000022F8 7A 01                    mov     R2, #1          ; MAF Table 02
      code:000022FA 20 47 02                 jb      Flag4.7, code_22FF ; Jump if Bit is set
      code:000022FD 7A 02                    mov     R2, #2          ; MAF Table 03
      code:000022FF
      code:000022FF          code_22FF:                              ; CODE XREF: code_21BA+13B↑j
      code:000022FF                                                  ; code_21BA+140↑j
      code:000022FF 12 0F F9                 lcall   TableAccess_02  ; Long Subroutine Call
      code:00002302 F5 46                    mov     FKH, A          ; Move (Op1 <- Op2)
      In the master map table the VE map, the IAT correction map and and unknown map thats all 0's with an RPM and Load axis are replacing the 3 MAF tables.
      Code:
      code:00008848 A0 50    VE_RPM_Axis_0:  .word VE_RPM_Axis
      code:0000884A 90 22                    .word IAT_Correction_Axis
      code:0000884C A1 80                    .word Zero_Table

      as for the delta TPS i have no use for it because the car still has the MAF so it can stay delta MAF. in all honestly i have a working VE table using all of the info above and a few other things keeping the code delta MAF. the other thing i had to do was uncap load and that helped put everything back in check.
      "The really good drivers got the bugs on the side windows." Walter Röhrl

      Comment


      • #4
        “you make it sound way more complicated than it really is” - Unfortunately it is !!!!
        “his VE table does replace the 3 MAF scalars” - if you looking on technically and only on this point you are right! They are just replaced, but if you looking on logically the values in VE map and map it.s self is not the same like values in MAF maps. Why?

        Let's think more about this called from me Main fuel calculation (known as Load or IPW). What is that - this is Injector Pulse Width which corresponds to other parameters (like air, temps and etc.) to achieve proper mixture in combustion chamber. I.e. this is math calculation of values and finally is represented like parameter TIME.

        How it's start - by multiply two 8 bit values i.e. Injector constant and one value (80 hex) and final result is 16 bit value. Why 16 bits, because it's more precise than 8 bit. Why in both stock RS2 or AAN, ABY is 80*80, because this is the middle of the range from 0*0 to FF*FF. In this way, the developer has provided a maximum range for correction, for both - increase or decrease. This is Base time open for current injector setup to achieve proper mixture in combustion chamber. That is why if we change injectors, this is the best point to reflect that.

        Then this base value stat to correct by desired/wanted/settled by maps values. Some values are only added (enrichment maps), others are subtracted or added (AFR, MAF, VE map, from Lambda sensor calculations and etc.) depending on the parameters which they reflect. Most of 16*16, 16*8 and etc calculations.
        It's a good idea to trace the whole calculation path from beginning to end to see how many maps/parameters are relevant to this calculation and to find where the developer multiplied the values i.e. this TIME with some constants values to adjust them and keep this TIME in proper condition. Every time this value represents not value of the initial parameter (Amount of air i.e. signals from MAF for example) - they reflect the effect of this parameter onto the TIME of injector i.e. this values are TIME in their essence.

        If you want to reflect a change of some parameter/s on this calculation, you have to keep in mind just how precisely its modification actually influences the main fuel calculation.
        If you what to replace only MAF maps by VE map, by values in VE map you must keep the proper values for the main fuel calculation. But haw you will adjust values from VE map + values from delta MAF and etc. maybe you know.

        I went this way at the beginning and after I followed the whole path of Load/IPW calculation in code and I did a few tries like yours and when I saw the results, I realized that things were not that simple.

        If you did that trace you will find where developer adjust Main fuel calculation for different hardware (Injectors and MAF for example) i.e. RS2 or AAN, ABY or 3B even for 4.2 motor with Motronic2.3 and haw with the same start 80*80 finally developer achieve proper IPW.

        Wow how much writing little is the superficial explanation, but I tried to touch the most important
        Not that I have succeeded )



        a few words more - when trace the Main fuel calculation you will find where and how MAF values are used in which procedures/subroutines and how Dmitri replaced this procedures and most important how recalculations of Main fuel is adjusted by calculation from scratch and VE map, VE multiplier, VE addend, IAT correction delta TPS and etc. and etc..

        Last edited by d_anev; 30 November 2018, 14:57.

        Comment


        • #5
          great information and input d_anev! my goal is to make a simple way to adjust fueling nothing more. most of the world thinks that the lambda table is the main fuel table when in reality it does nothing once the lambda/load map is exceeded and the ECU goes into open loop. the lambda map is almost useless in my opinion because of the fact that the ECU is hardware limited to by the narrowband sensor on the range of AFR it can read. like if ECU wants 11.20AFR the sensor cannot see that low, all it knows is rich, nothing more.

          if a way was made to using the way i input the narrowband input into the ECU for logging than use the that 10.00AFR to 20.00AFR value and just force the ECU to stay in closed loop and target AFR all the time would be a really really easy way to adjust fuel. simply put the AFR you want in the cell at the load/RPM you want and the ECU just targets it. i know making that idea actually works is not easy and it would take even more work than what PRJ has done to achieve it but nothing is impossible. this whole idea is above what im capable of making work but i understand how it could work.
          "The really good drivers got the bugs on the side windows." Walter Röhrl

          Comment


          • #6
            "most of the world thinks that the lambda table is the main fuel table when in reality it does nothing once the lambda/load map is exceeded and the ECU goes into open loop. the lambda map is almost useless in my opinion" - this is wrong. Look on the code. The program allways read AFR map and this is main fuel map. If you have non expected result for AFR in data log file and different AFR from AFR req your settings are wrong.....

            Comment


            • #7
              The "load" is a theoretical injector opening time - calculates a mixtures for lambda 1 filling of an ideal engine; that's why the load delimitation makes sense, in lower engine speed you have more time than the 12.75ms available and the calculation jumps back to the beginning - other ECMs also struggle with this when the don't use a "injector timing fuel table" (KMS do this... I don't like this :-D)

              The fuel map is a "lambda correction map" - when the equation didn't fits perfect you correct the mixture. Lower than 128 is leaner, more is richer... like a signed value.
              For wot you have a "load" based enrichment cause the calculation is still active.

              I'm unsure if the topic or the question in this thread is correct. The fuel "correction" calculation is working great. The "load" calculation - MAF related or MAP/SD related is another story.
              I only notice some struggles at WOT cause of different air density the "load" raises a little bit. So mixture becomes richer in winter and leans out in sommer...
              A coolant/IAT map which impact the load calculation could bring some benefits and could called VE correction map...

              But I didn't checked the load/fuel stuff yet cause ignition was mire interesting for me.

              However running only lambda controlled without proper fitting fuel table (or removing it cause lambda will solve it) is a stupid way to let the engine work.
              At the engine no correction or enrichment will set correct - only **** filled caused lambda will solve - will give a great disaster when the lambda sensor fails.

              Comment


              • #8
                Originally posted by d_anev View Post
                "most of the world thinks that the lambda table is the main fuel table when in reality it does nothing once the lambda/load map is exceeded and the ECU goes into open loop. the lambda map is almost useless in my opinion" - this is wrong. Look on the code. The program allways read AFR map and this is main fuel map. If you have non expected result for AFR in data log file and different AFR from AFR req your settings are wrong.....
                but the issue is that the ECU cannot know an AFR below like 13.0 if i remember correctly. the oxygen sensor cannot read any lower than that so the ECU would just be guessing from MAF readings at what the AFR actually is.hence the why it is called a narrow band oxygen sensor. i know the ECU references the map in boost but its technically impossible for it to know a proper AFR in boost without the addition of a wideband controller and custom code so that it can see the full range from 20.0AFR to 10.0AFR.
                if this table is true for a narrow band sensor than anything below 12.0AFR is a guess by the ECU in the case of it knowing what the actual AFR really is under boost to follow the lambda table properly? all of my cars run 11.99AFR's and down under boost.



                Originally posted by Acki View Post
                The "load" is a theoretical injector opening time - calculates a mixtures for lambda 1 filling of an ideal engine; that's why the load delimitation makes sense, in lower engine speed you have more time than the 12.75ms available and the calculation jumps back to the beginning - other ECMs also struggle with this when the don't use a "injector timing fuel table" (KMS do this... I don't like this :-D)

                The fuel map is a "lambda correction map" - when the equation didn't fits perfect you correct the mixture. Lower than 128 is leaner, more is richer... like a signed value.
                For wot you have a "load" based enrichment cause the calculation is still active.

                I'm unsure if the topic or the question in this thread is correct. The fuel "correction" calculation is working great. The "load" calculation - MAF related or MAP/SD related is another story.
                I only notice some struggles at WOT cause of different air density the "load" raises a little bit. So mixture becomes richer in winter and leans out in sommer...
                A coolant/IAT map which impact the load calculation could bring some benefits and could called VE correction map...

                But I didn't checked the load/fuel stuff yet cause ignition was mire interesting for me.

                However running only lambda controlled without proper fitting fuel table (or removing it cause lambda will solve it) is a stupid way to let the engine work.
                At the engine no correction or enrichment will set correct - only **** filled caused lambda will solve - will give a great disaster when the lambda sensor fails.
                when i tested replacing just the X3 MAF tables with a 16x16 VE table i did have really high load readings so added the load uncapping modifications to the code and that put all my load readings right back in spec. the car starts fine, runs fine but the only issue i found is still a small lean condition at high RPM under boost that i cant seem to trim out of it.
                Last edited by vwnut8392; 1 December 2018, 20:19.
                "The really good drivers got the bugs on the side windows." Walter Röhrl

                Comment


                • #9
                  For the narrow band the motronic has the VSR and a simple lean/rich switch. That's why the signal isn't stable at lambda 1 when everything is fine.
                  The software is using a pre programmed P and I - a PI controller with delta P limitation.
                  You can find some Bosch patents from the late 70s which explains it very easy for everybody (some part of the software structure you can find 1:1 explained).

                  BE07 isn't direct wired to the lambda probe as you may remember. Think about why this is needed and you need to change to it from a fixed target to a moving target (according to a table for example)...

                  And we already discussed it months ago: https://www.s2forum.com/forum/techni...-into-motronic

                  To the VE stuff, I don't know what you did and what it means for the calculations.

                  Comment


                  • #10
                    Guys, guys .. time out!!!
                    Please, let’s forget for Lambda, AFR, Air density, temps and all other parameters for a while.
                    ECU is just one arithmetic device in his core, nothing more, nothing less! He calculates values and don't know nothing about AFR, Lambda, stoich value, Air density, all temps and etc. It just use numerals to calculates values. That is all!!!!! Remember this. The developer and tuning guys must know about this parameters.
                    To have proper/desired/wanted values for some physical parameters like amount of air, Air temp and density, engine temp, amount of fuel and ets. you MUST represented it with proper value in that calculation. In every moment the code of ECU just calculates numbers and he don't care about physical parameters. That’s why if we what to have proper calculation we must set/represent every physical parameter with proper value in this calculation. In main case this is done by initial initial product of 80 * injector constant (for physical parameter amount of fuel)and one by one by maps (TVUB for delay, IAT, ECT for temps, MAF or VE maps (for amount of air) and etc. and etc. Why maps, because this is the better way to represent variables of this physical parameters whose variation is dependent on at least one other parameter like RPM for example.
                    Then we must maintain/correct this calculation.
                    AFR map is the main value which don't depend from physical parameter and this is your way to affect into calculation (not the one, but main). But this is one value which not represent (Acki) lean or rich above 128 or below it just a number which is in the middle of the range 0 to 255. This value will represent lambda = 1 or AFR14,7:1 by 128 only if we set correct values for initial parameters for calculation like injector constant, TVUB, amount of air for SD and etc. and etc. In every other cases this is just a number which affect the main fuel calculation. Developer use 128 to represent the stoich value to be able to have enough range for correction, nothing more or less.

                    I hope now you will understand Dimitri's words about Fuel calculation from scratch. To have 128 = lambda 1 he did all recalculation and setting to be able to use 128 like stoich value in AFR map. You must understand that very carefully. If we have wrong initial setting of calculations and maps, value 128 in AFR map is far away from stoich. You set it to 128 and expect lambda 1 on exit. It can only be done with correct settings, otherwise you are waiting for the impossible!!!!
                    That is why many of the boys have problems with the fuel-air settings and can not catch up AFR req and AFR from wide band lambda sensor ))

                    Then lambda control calculations are the main corrections + few more mps. Lambda sensor is always connected to AN 7 (Acki) and its value is not a part of main fuel calculation (Matt). There is no lambda sensor values represented in ECU code (not 22:1 not 7:1). The value is used just an indicator for one of five levels - rich, lean, very rich or lean and "no problem"
                    Depending of this 5 levels ecu code have few subroutines which finally changing Main fuel calculation depending of RPM and Load.
                    Example: if lambda control in On and lambda sensor says rich or lean.. the code start decreasing/increasing one 16 bit value with one step every 10 ms. Value of this step is read from 3 maps. If engine is idle the step is about 3 from first map if is in middle rpm is about 50 and more. If lambda sensor value is changed from rich to lean or vice versa the code use the other two maps and recalculate value from both then use map 1. This is the simple expiation, the code is more complicated, even in lambda control off (engine is still cold) there are procedures which correct Main fuel calculation. If you look carefully in lambda control code you will find how ecu code set the fuel trim on which xram store the values, where is the limits for adjustment and fault codes and haw code reset xram for fuel trims in some conditions.

                    Conclusion: Ecu code monitors by lambda sensor states and depending of this states and rpm and load increase or decrease step by step one 16 bit value then adds this value to Main fuel calculation. How fast increase or decrease this value, depends of rpm and load!! You can see the speed of adaptation if you use a wide band lambda probe and BDlog. That's why you have a delay in adaptation. As worse are the settings, the more adjustments by this slow adaptation you have and in WOT in high RPM final result readed from WBO2 is terrible or too different from AFR requested.

                    But everything is just one arithmetic calculation which in the end is named like LOAD and transferred with one recalculation to one parameter Time. Don’t forget this when you thinking about all this.
                    I hope now you will stop thinking with physical dimensions when read ecu code. Everything is a math inside this ecu and in universe
                    Last edited by d_anev; 3 December 2018, 10:54.

                    Comment


                    • #11
                      Originally posted by d_anev View Post
                      But this is one value which not represent (Acki) lean or rich above 128 or below it just a number which is in the middle of the range 0 to 255. This value will represent lambda = 1 or AFR14,7:1 by 128 only if we set correct values for initial parameters for calculation like injector constant, TVUB, amount of air for SD and etc. and etc. In every other cases this is just a number which affect the main fuel calculation. Developer use 128 to represent the stoich value to be able to have enough range for correction, nothing more or less.
                      For understanding is sued this example - I think we are telling the same.
                      The issue is that copy cats don't understand cause they don't look into the code and try to understand the basics

                      Then lambda control calculations are the main corrections + few more mps. Lambda sensor is always connected to AN 7 (Acki) and its value is not a part of main fuel calculation (Matt). There is no lambda sensor values represented in ECU code (not 22:1 not 7:1). The value is used just an indicator for one of five levels - rich, lean, very rich or lean and "no problem"
                      Yes only a simple switch algo with PI controller (coded controller! this fact makes things like wideband lambda much much easier!).
                      The switch algo only needs to be adjusted with a offset from a table and then it should work with wideband signal direct feeded via another port.
                      The later motronic have the heater controller on board and this makes it look complicated - my understanding so far.

                      Conclusion: Ecu code monitors by lambda sensor states and depending of this states and rpm and load increase or decrease step by step one 16 bit value then adds this value to Main fuel calculation. How fast increase or decrease this value, depends of rpm and load!! You can see the speed of adaptation if you use a wide band lambda probe and BDlog. That's why you have a delay in adaptation. As worse are the settings, the more adjustments by this slow adaptation you have and in WOT in high RPM final result readed from WBO2 is terrible or too different from AFR requested.
                      Exhaust gas needs less time to reach the O2 sensor in higher rpms and load
                      In other ECU like Megasquirt you can tune this time delay with table switching and then checking the log file - make the mixture richer and check the time until you see the impact.
                      Lambda correction delayed or turn off and you can optimize this step by step.

                      But yes the lambda "correction" areas are very limited (3 as far as I know) and I see a lack of free memory to generate more area and some kind a "autotune" but the question is do I really want a "autotune"?
                      It's a often discussed question - do I want to optimize the "theoretical injection time" equation or do I want to adjust the results via lambda.
                      I think lambda adjust for the beginning and later adjust the beginning - the equation and the lambda is only a control of the system with limits if something goes wrong.
                      At the V8 you don't recognize a bad spark plug at full load on the Autobahn for example. You could hear some difference from the exhaust sound but that's all...

                      But everything is just one arithmetic calculation which in the end is named like LOAD and transferred with one recalculation to one parameter Time. Don’t forget this when you thinking about all this.
                      I hope now you will stop thinking with physical dimensions when read ecu code. Everything is a math inside this ecu and in universe
                      We call it load but it isn't load - that makes much confusion but helps also to prevent that everybody things he can tune a engine in a good way - as you can see in this discussion

                      Comment


                      • #12
                        “The issue is that copy cats don't understand cause they don't look into the code and try to understand the basics ”
                        “We call it load but it isn't load - that makes much confusion but helps also to prevent that everybody things he can tune a engine in a good way” -
                        I’m not agreeing with these sentences. I do not think myself better than anyone in this forum. Main idea of Dmitri’s M232 is everybody to be able to tune his car. Just before do that is a good way to learn how to do that correctly. This is the place to help each other, not to hide what we know or don’t.
                        “The switch algo only needs to be adjusted with a offset from a table and then it should work with wideband signal direct feeded via another port” - but main logic in ECU code will be the same and final result will be the same also!! Trust me, like Eddy Murphy says in Beverly hills’ cop I tried it few times
                        To use wide band O2 sensor/controller we need new logic. I have more than 10 tested version (now v.11) of new code - it work, not perfect, but works somehow ) . But I need more free time to adjust timers, remove code for stock fault codes and add new code to disable lambda control ( wide band O2 sensor/controller) in case of short to ground, open circuit and etc.(5 states) and add new fault codes to prevent engine damage. But there is no free time for this.
                        “But yes the lambda "correction" areas are very limited (3 as far as I know) and I see a lack of free memory to generate more area” - areas!!! What is that? Lambda correction is limited by the logic and limits- FRxxx and FRAxx. There are tons free xram’s and ports in motor plate and code. What is this lack of free memory?
                        FRMAX: .byte 0xA0
                        FRAMX: .byte 0x9A
                        FRAMN: .byte 0x66
                        FRMIN: .byte 0x60
                        “It's a often discussed question - do I want to optimize the "theoretical injection time" equation or do I want to adjust the results via lambda......I think lambda adjust for the beginning and later adjust the beginning ” - Better way for lambda adjusting is to disable lambda control, make the best settings of injector constant, TVUB, VE map and etc. to achieve desired lambda by AFR req and then enable lambda control which will capture/correct the transient processes and changes in external parameters that have not been set fully correct or add new code for WB02 which will do the same a little bit better than narrow band sensor.
                        “At the V8 you don't recognize a bad spark plug at full load on the Autobahn for example.” - knock monitoring is one way to recognize a bad spark plug. Not every time, but if knock detection works in most cases you will have knock issue on that cylinder with bad spark plug at full load. Unfortunately, not in any case!

                        Comment


                        • #13
                          Originally posted by d_anev View Post
                          “The issue is that copy cats don't understand cause they don't look into the code and try to understand the basics ”
                          “We call it load but it isn't load - that makes much confusion but helps also to prevent that everybody things he can tune a engine in a good way” -
                          I’m not agreeing with these sentences. I do not think myself better than anyone in this forum. Main idea of Dmitri’s M232 is everybody to be able to tune his car. Just before do that is a good way to learn how to do that correctly. This is the place to help each other, not to hide what we know or don’t.
                          I understand your point but you don't know some facts, we can PM about.
                          I think this is also the reason why nobody really shares something at the moment.

                          “The switch algo only needs to be adjusted with a offset from a table and then it should work with wideband signal direct feeded via another port” - but main logic in ECU code will be the same and final result will be the same also!! Trust me, like Eddy Murphy says in Beverly hills’ cop I tried it few times
                          To use wide band O2 sensor/controller we need new logic. I have more than 10 tested version (now v.11) of new code - it work, not perfect, but works somehow ) . But I need more free time to adjust timers, remove code for stock fault codes and add new code to disable lambda control ( wide band O2 sensor/controller) in case of short to ground, open circuit and etc.(5 states) and add new fault codes to prevent engine damage. But there is no free time for this.
                          I can't follow you - diagnostic for this is already included in the code.
                          You can share you "beta" stuff, I will test it.

                          I have one simple idea which I will test soon:
                          Stock code is focused on VSR (0.449V, 92), VSREF (0.479V, 98 - rich), VSREM (0.420V, 86 - lean) VSRMX (1.099V, 225) and VSRMN (0.088V, 18) and FRMAX and FRMIN (max integrator steps).
                          My idea is, with wideband you have other resolution but you can still run the "rich/lean" game to reach lambda 0.9 for example (but you have to use another cpu port or bypass the "lambda switch logic before and then you have to filter the lambda signal a little bit).
                          You can use VSR on your own (from a table via rpm, tl-load) with moving target for the rich/lean switch (table calculated value for VSxyz). Other stuff could nearly stay the same.

                          I'm in the moment focused on the measuring blocks for the V8 - has some communication issue in the diag routine but then it will run.
                          The next is the lambda stuff on my list.

                          “But yes the lambda "correction" areas are very limited (3 as far as I know) and I see a lack of free memory to generate more area” - areas!!! What is that? Lambda correction is limited by the logic and limits- FRxxx and FRAxx. There are tons free xram’s and ports in motor plate and code. What is this lack of free memory?
                          FRMAX: .byte 0xA0
                          FRAMX: .byte 0x9A
                          FRAMN: .byte 0x66
                          FRMIN: .byte 0x60
                          Which area you see as free in the external ram?

                          You have 3 areas - B1, B2 and B3... You may remember the DTC lambda correction rich/lean add or multi. This areas are limited by rpm, tl load and air mass. The section from the Funktionsrahmen was already shared in this forum.


                          “It's a often discussed question - do I want to optimize the "theoretical injection time" equation or do I want to adjust the results via lambda......I think lambda adjust for the beginning and later adjust the beginning ” - Better way for lambda adjusting is to disable lambda control, make the best settings of injector constant, TVUB, VE map and etc. to achieve desired lambda by AFR req and then enable lambda control which will capture/correct the transient processes and changes in external parameters that have not been set fully correct or add new code for WB02 which will do the same a little bit better than narrow band sensor.
                          “At the V8 you don't recognize a bad spark plug at full load on the Autobahn for example.” - knock monitoring is one way to recognize a bad spark plug. Not every time, but if knock detection works in most cases you will have knock issue on that cylinder with bad spark plug at full load. Unfortunately, not in any case!
                          Knock won't recognize a plug which isn't firing... lambda would do but enrichment isn't a solution, total lambda is maybe 1 again but the cylinder isn't still burning so a DTC would be the right in this moment.

                          Comment


                          • #14
                            Here are a few pages from a factory audi document covering the basic function of how lambda control works in M2.3.2. trying to make a contribution for others who are trying to understand what the rest of us are talking about.

                            M2_3_2_Page_04.jpgM2_3_2_Page_23.jpgM2_3_2_Page_24.jpg
                            Attached Files
                            "The really good drivers got the bugs on the side windows." Walter Röhrl

                            Comment


                            • #15
                              For those of you who speak german or care to translate these for those if us who cannot read german here is all the information about lambda control from the M2.3.2 damos.



                              Attached Files
                              "The really good drivers got the bugs on the side windows." Walter Röhrl

                              Comment

                              Working...
                              X