Maximum calculated load - what it does and how to override it .
10-11-2013, 12:08 PM
#52
Yes that was with Baro set at 1.5. I have since maxed out Baro and IAT to see what happens. So far nothing adverse. I figure if it isn't causing problems then why risk potentially going over. Not that I really think we can get that high, but if it doesn't matter then I see no reason to go through the exercise of picking an arbitrary lower number.
Last edited by slash128; 10-11-2013 at 12:21 PM.
10-11-2013, 12:32 PM
#53
after you set your baro sensor slash, was the tune off at all?
10-11-2013, 06:24 PM
#56
That is an interesting point. That could be a reason for setting tables to something just north of the max load you are targeting. Instead of a guessing exercise we could set everything at full max, log to see what you hit, then dial back down. Does the granularity give us anything useful? I imagine in lower load ranges it is a fuel economy/emissions thing? In boost not so necessary?
10-11-2013, 07:27 PM
#59
Oh I just figured it would linearly interpolate where it didn't have specific values. In boost we cover a broad range of rpm and load so fast I didn't think it would matter that much.
10-11-2013, 07:32 PM
#60
10-11-2013, 07:50 PM
#61
If it automattically adjust the max load you wouldn't want it to be any greater than necessary. The reason is that the incremental tolerance (granularity) becomes larger.
Not sure I'm expressing it accurately, so an example would be that if the PCM can break down the range in 100 increments and the load range is 100%, then that equates to 1% per increment of control. If you set the load range to 400% that increases to 4% per increment. So it would generally be best not to have the range set any higher than what you project the system will ever experience.
Not sure I'm expressing it accurately, so an example would be that if the PCM can break down the range in 100 increments and the load range is 100%, then that equates to 1% per increment of control. If you set the load range to 400% that increases to 4% per increment. So it would generally be best not to have the range set any higher than what you project the system will ever experience.
Setting it to 200 vs 400 vs 1000 makes zero difference to the tune .
Do some tests yourself .
This time do it properly !
10-11-2013, 07:56 PM
#62
Here they are. The 1.53 log is with the Baro table stock. The 1.53_B log is exaclty the same, except Baro table set at 1.5 across.
Last edited by slash128; 10-11-2013 at 08:25 PM.
10-11-2013, 08:07 PM
#63
More on the granularity topic and the Baro and IAT tables. I have a couple thoughts there. I am open to discussion, these are just some conclusions I came to.
1) If we are going to have granularity then we have to have values for all specific areas of that granularity. Those values need to come from somewhere. If we don't go to the trouble of figuring out what those values are then the granularity is useless.
2) The granularity can only be as fine as the tables that we have to put the values in. If we have granularity of 100 possible values when the ECU calculates load but the corresponding tables only have 10 possible values then what good does the granularity give us?
3) If we quickly sweep through a load and RPM range then there is only so much time to address discrete values. At some point a higher level of granularity is no longer addressable.
EDIT: Before someone beats me to it I realize the granularity is what gives us the interpolation between values, but my point is if we keep this in context of boosted areas then we are dealing with a difference of 1 degree of timing then does it matter if the ECU can interpolate 1.01,1.02,1.03, etc...? Same for fueling.
Regarding the actual fuel and timing tables I only have 2 columns/rows in all of my tables that are above 100%. They are currently 150% and 250%. This originally came out of necessity because the '06 ATR has far less values available in the tables than previous years. For instance my timing tables only have 14 columns where previous years have 20.
1) If we are going to have granularity then we have to have values for all specific areas of that granularity. Those values need to come from somewhere. If we don't go to the trouble of figuring out what those values are then the granularity is useless.
2) The granularity can only be as fine as the tables that we have to put the values in. If we have granularity of 100 possible values when the ECU calculates load but the corresponding tables only have 10 possible values then what good does the granularity give us?
3) If we quickly sweep through a load and RPM range then there is only so much time to address discrete values. At some point a higher level of granularity is no longer addressable.
EDIT: Before someone beats me to it I realize the granularity is what gives us the interpolation between values, but my point is if we keep this in context of boosted areas then we are dealing with a difference of 1 degree of timing then does it matter if the ECU can interpolate 1.01,1.02,1.03, etc...? Same for fueling.
Regarding the actual fuel and timing tables I only have 2 columns/rows in all of my tables that are above 100%. They are currently 150% and 250%. This originally came out of necessity because the '06 ATR has far less values available in the tables than previous years. For instance my timing tables only have 14 columns where previous years have 20.
Last edited by slash128; 10-11-2013 at 08:24 PM.
10-11-2013, 08:15 PM
#64
I would like Team to try demonstrate that this granularity effect exists . As far as I can see the only granularity is in the fuel and timing tables themselves . In which case I would agree that keeping those close to actual max at the top end makes sense.
The reason that I gave for the existence of the Max calc load table makes a boat load more sense than what Team persists with.
Between Slash's results and my own I'm pretty sure we have already shown that the previous thinking on how that table worked was totally wrong .
The reason that I gave for the existence of the Max calc load table makes a boat load more sense than what Team persists with.
Between Slash's results and my own I'm pretty sure we have already shown that the previous thinking on how that table worked was totally wrong .
Last edited by Brettus; 10-11-2013 at 08:25 PM.
10-11-2013, 09:19 PM
#65
I jumped on aboard and made the change on my baro table as well, did a wot run logging, and calc load was what I would normally expect. so yeah this is the answer for sure. granted I am only in the 177% range....
10-11-2013, 10:24 PM
#67
zoom zoom. after official numbers come out I would love to see how many people say REW is the way for more power....
Posted From RX8Club.com Android App
Posted From RX8Club.com Android App
10-12-2013, 12:46 AM
#68
Park that thought , do you own tests based on what we have found out here and make up your own mind .
I'm all ears if you find any evidence to support it.
10-12-2013, 01:42 PM
#70
The fact you don't have a turbo is making it hard for you to figure this out - you could do the same test on your NA and see the same results at lower loads.
Secondly , we both increased the Baro comp by 50% !!!!!!! No change in calc load or AFRs .
Thirdly . Research 'hot wire maf' . Baro and IAT are not needed to calculate load .
Last - think about why Mazda even have that table . It is basically a load that they wanted to be slightly above the actual loads Mazda knew their engine would run at . They needed IAT and Baro compensation to calculate that in all conditions . They wanted to protect the Cat from over rich conditions at WOT - simple.
Think it through team - you will get there ....
Last edited by Brettus; 10-12-2013 at 03:06 PM.
10-12-2013, 03:00 PM
#71
Quoted from Wikipedia . Same info is to be found elsewhere BTW before you dis the source.
Some of the benefits of a hot-wire MAF compared to the older style vane meter are:
responds very quickly to changes in air flow
low airflow restriction
smaller overall package
less sensitive to mounting location and orientation
no moving parts improve its durability
less expensive
separate temperature and pressure sensors are not required (to determine air mass)
There are some drawbacks:
dirt and oil can contaminate the hot-wire deteriorating its accuracy
installation requires a laminar flow across the hot-wire
responds very quickly to changes in air flow
low airflow restriction
smaller overall package
less sensitive to mounting location and orientation
no moving parts improve its durability
less expensive
separate temperature and pressure sensors are not required (to determine air mass)
There are some drawbacks:
dirt and oil can contaminate the hot-wire deteriorating its accuracy
installation requires a laminar flow across the hot-wire
Last edited by Brettus; 10-12-2013 at 04:09 PM.
10-12-2013, 03:26 PM
#72
I think I understand what team is thinking, I was thinking the same.
I mean I would like to imagine that the baro table would change the load a little bit to compensate for the less dense air at high altitudes. the same about air intake temp.
however with the tests done, that is not the case, the mass airflow sensor and STFT & LTFT system are what compensate for the climatic changes.
however, the inputs from baro sensor and AIT sensor may be used in other parts of the system neither of which would have to pertain to the BARO and AIT comp tables, furthermore COBB just labeled those tables, mazda may have a different name for them.
I would love to have a copy of ME to fish through to find some other settings that might use those sensors, but they might not be there, in which case we would need someone like oltman to read through the programming code to see where the system would call upon the BARO and AIT sensors.
I wish we could tag people on this fourms, I wonder if oltman has a copy of the entire code. we wouldn't have to test anything just read the code as is......
I mean I would like to imagine that the baro table would change the load a little bit to compensate for the less dense air at high altitudes. the same about air intake temp.
however with the tests done, that is not the case, the mass airflow sensor and STFT & LTFT system are what compensate for the climatic changes.
however, the inputs from baro sensor and AIT sensor may be used in other parts of the system neither of which would have to pertain to the BARO and AIT comp tables, furthermore COBB just labeled those tables, mazda may have a different name for them.
I would love to have a copy of ME to fish through to find some other settings that might use those sensors, but they might not be there, in which case we would need someone like oltman to read through the programming code to see where the system would call upon the BARO and AIT sensors.
I wish we could tag people on this fourms, I wonder if oltman has a copy of the entire code. we wouldn't have to test anything just read the code as is......
10-12-2013, 03:52 PM
#73
I think I understand what team is thinking, I was thinking the same.
I mean I would like to imagine that the baro table would change the load a little bit to compensate for the less dense air at high altitudes. the same about air intake temp.
however with the tests done, that is not the case, the mass airflow sensor and STFT & LTFT system are what compensate for the climatic changes.
however, the inputs from baro sensor and AIT sensor may be used in other parts of the system neither of which would have to pertain to the BARO and AIT comp tables, furthermore COBB just labeled those tables, mazda may have a different name for them.
I would love to have a copy of ME to fish through to find some other settings that might use those sensors, but they might not be there, in which case we would need someone like oltman to read through the programming code to see where the system would call upon the BARO and AIT sensors.
I wish we could tag people on this fourms, I wonder if oltman has a copy of the entire code. we wouldn't have to test anything just read the code as is......
I mean I would like to imagine that the baro table would change the load a little bit to compensate for the less dense air at high altitudes. the same about air intake temp.
however with the tests done, that is not the case, the mass airflow sensor and STFT & LTFT system are what compensate for the climatic changes.
however, the inputs from baro sensor and AIT sensor may be used in other parts of the system neither of which would have to pertain to the BARO and AIT comp tables, furthermore COBB just labeled those tables, mazda may have a different name for them.
I would love to have a copy of ME to fish through to find some other settings that might use those sensors, but they might not be there, in which case we would need someone like oltman to read through the programming code to see where the system would call upon the BARO and AIT sensors.
I wish we could tag people on this fourms, I wonder if oltman has a copy of the entire code. we wouldn't have to test anything just read the code as is......
I didn't come up with this revelation over tea and scones as Team seems to think . I spent a huge amount of time sifting through the tables , researching online , doing tests , analysing results etc . It wasn't till Slash started nudging the 200% load "barrier" at elevation that the last piece of the puzzle clicked into place for me . Still hard to believe the simplicity of it all and even harder to believe that Team doesn't get it given the overwhelming evidence provided in this thread.
Last edited by Brettus; 10-12-2013 at 04:11 PM.
10-12-2013, 08:51 PM
#75