SD - first test success
Aug 20, 2009, 08:05 AM
#676
For my setup (larger turbo) I found it easiest to use a 1:1 ratio in the MAP/VE table and then adjusted the RPM VE table to get my wideband readings to match my fuel tables. I could do the opposite and adjust the MAP/VE tables and leave the RPM table alone, but I just found it easier to do it in the RPM table.
For example, if you are cruising at 3000 RPM at 20% throttle (under vacuum), your VE is going to be much different (let's say 70%) than if you went WOT at that same RPM, where the VE may jump to 90%.
What you did can work, but it isn't ideal. The two 2D tables certainly give us good adjustment to account for this, but a true 3D table would be best.
Aug 20, 2009, 08:51 AM
#677
That's not really a good method because you can have greatly differing VEs at the same RPM.
For example, if you are cruising at 3000 RPM at 20% throttle (under vacuum), your VE is going to be much different (let's say 70%) than if you went WOT at that same RPM, where the VE may jump to 90%.
What you did can work, but it isn't ideal. The two 2D tables certainly give us good adjustment to account for this, but a true 3D table would be best.
For example, if you are cruising at 3000 RPM at 20% throttle (under vacuum), your VE is going to be much different (let's say 70%) than if you went WOT at that same RPM, where the VE may jump to 90%.
What you did can work, but it isn't ideal. The two 2D tables certainly give us good adjustment to account for this, but a true 3D table would be best.
Aug 20, 2009, 09:06 AM
#678
Thanks fellas for clearing things up.
A few more questions though still linger for me:
1. So than to obtain kPa from MAP based data I have set my formula in excel to be MAP*6.8948+100. This seems to give me correct figures:
2. To obtain the correct RPM VE I understand that I would need to multiple the Load obtained from the MAP VE table by 100, which will give me the correct RPM VE, however, this seems to give me too high VE numbers:
A few more questions though still linger for me:
1. So than to obtain kPa from MAP based data I have set my formula in excel to be MAP*6.8948+100. This seems to give me correct figures:
- For example at 0.20372 MAP I am coming up with 101.4046 (which was multiplied by 6.8948 to convert it to kPa than 100 added in to account for atmospheric pressure) (I'm only at 310 ft above sea level, therefore, I don't feel as though there is a need to adjust for that minimal of an elevation above sea level). Based on this data my MAP VE table should reflect a kPa of 101 with a Load % of 80, since I'm seeing a 80% load at the 101.4046 kPa(?).
2. To obtain the correct RPM VE I understand that I would need to multiple the Load obtained from the MAP VE table by 100, which will give me the correct RPM VE, however, this seems to give me too high VE numbers:
- For example at 3902 RPM I'm seeing 116.25 Load but, if I multiple this by 100 I get 11,625, which is obviously in correct. However, if I set my formula up in excel so that I divide Load by the kPa than multiple by 100 I come up with more reasonable figures
- For example, using the formula to determine RPM VE of MAP/Load*100, at 80.3125 Load divided by 101.4046 kPa I come up with a VE of 79.20005, which is being seen at 3539 RPM at 57.2549% TPS. From this I assume that my RPM VE table should reflect a VE of 80 at 3500 RPM? The problem is though how does the TPS play a role? Obviously I would assume at 100% TPS the VE would change as the Load and kPa would be higher.
Aug 20, 2009, 09:25 AM
#680
Thanks fellas for clearing things up.
A few more questions though still linger for me:
1. So than to obtain kPa from MAP based data I have set my formula in excel to be MAP*6.8948+100. This seems to give me correct figures:
2. To obtain the correct RPM VE I understand that I would need to multiple the Load obtained from the MAP VE table by 100, which will give me the correct RPM VE, however, this seems to give me too high VE numbers:
A few more questions though still linger for me:
1. So than to obtain kPa from MAP based data I have set my formula in excel to be MAP*6.8948+100. This seems to give me correct figures:
- For example at 0.20372 MAP I am coming up with 101.4046 (which was multiplied by 6.8948 to convert it to kPa than 100 added in to account for atmospheric pressure) (I'm only at 310 ft above sea level, therefore, I don't feel as though there is a need to adjust for that minimal of an elevation above sea level). Based on this data my MAP VE table should reflect a kPa of 101 with a Load % of 80, since I'm seeing a 80% load at the 101.4046 kPa(?).
2. To obtain the correct RPM VE I understand that I would need to multiple the Load obtained from the MAP VE table by 100, which will give me the correct RPM VE, however, this seems to give me too high VE numbers:
- For example at 3902 RPM I'm seeing 116.25 Load but, if I multiple this by 100 I get 11,625, which is obviously in correct. However, if I set my formula up in excel so that I divide Load by the kPa than multiple by 100 I come up with more reasonable figures
- For example, using the formula to determine RPM VE of MAP/Load*100, at 80.3125 Load divided by 101.4046 kPa I come up with a VE of 79.20005, which is being seen at 3539 RPM at 57.2549% TPS. From this I assume that my RPM VE table should reflect a VE of 80 at 3500 RPM? The problem is though how does the TPS play a role? Obviously I would assume at 100% TPS the VE would change as the Load and kPa would be higher.
(map+baro)*6.8948
So, if your baro at sea level is 14.7 psi, then it's simply:
(map+14.7)*6.8948
2. To get correct RPM VE numbers, you have to look at your VE numbers from your maf based logs (load/map*100). Look at that 3D chart of map vs RPM vs VE (data). Around 3000-5000RPM or so, you will have 100% VE for simplicity sake. Now look at 50 kPa at 4000 RPM and 50 kPa at 1000 RPM. The VE will be different by a certain amount. For example, maybe 50 kPa/1000 RPM is 70% VE and 50kPa/4000 RPM is 85% VE. Well, that tells us your RPM VE at 1000 RPM should be roughly 15% lower than at 4000 RPM.
This is where I am talking about the two 2-d tables not working completely. You will notice that the VE differences for different map and RPM can't be completely captured by the two tables, but you can get it close enough.
A good starting point is just to use 100% RPM VE for the midrange, with the first couple of cells lower, like 90% or 85% and then the last few cells lower as well. Just compare to your VE chart that you hopefully made. If not no big deal, but if you do have it, just multiply the RPM VE and the map VE and that is your final VE that should match your chart.
Eric
Last edited by l2r99gst; Aug 20, 2009 at 09:46 AM.
Aug 20, 2009, 10:00 AM
#681
Ok so the psig to kPa formula should be (MAP*Baro)+100. I was using MAP*6.8948+100, which was essentially giving me the same figure as your formula 
As far as RPM VE values, for this particular car I'm working on I have no MAF based data to reference, however, it would seem as though I am still able to obtain correct data running SD based as I would have running MAF based:
My assumption is that I should forget about referencing Idle with anything other than 100% TPS so that the ECU can work out the interpolation for the other TPS related Loads?
As far as RPM VE values, for this particular car I'm working on I have no MAF based data to reference, however, it would seem as though I am still able to obtain correct data running SD based as I would have running MAF based:
- For example, at idle the engine is idling at 1070 RPM on average giving me a VE of 74% (which was obtained by dividing the Load (35.12172) by the kPa (47.9076) and multiplying by 100). With this data I presume I should adjust the 1000 RPM VE cell to 74%.
- However, based on what you had said, at 4000 RPM I've calculated the VE to be 90%, therefore, giving me a difference between my idle VE and cruise VE of 16% therefore, should I actually adjust the 1000 RPM VE cell to reflect 84%? Although the problem I see with this is that I was only under 73% TPS not 100% TPS load, which could skew the values slightly.
My assumption is that I should forget about referencing Idle with anything other than 100% TPS so that the ECU can work out the interpolation for the other TPS related Loads?
Aug 20, 2009, 10:25 AM
#682
If you don't have maf based logs, you can't really get the correct data. That's because your load is now being adjusted based on your SD VE tables.
What you need to do is just follow a base settings that has been posted in one of the SD threads and then use STFT to dial in the VE tables for idle and cruise. Then use the wideband to dial in the AFRs for WOT. For WOT, use the RPM VE table for your adjustments, then your fuel table if need be. The MAP VE can be kept as 1:1 in the higher RPM ranges.
What you need to do is just follow a base settings that has been posted in one of the SD threads and then use STFT to dial in the VE tables for idle and cruise. Then use the wideband to dial in the AFRs for WOT. For WOT, use the RPM VE table for your adjustments, then your fuel table if need be. The MAP VE can be kept as 1:1 in the higher RPM ranges.
Aug 20, 2009, 10:47 AM
#683
Damn I was afraid of that. I assume though I am on the right page for obtaining VE data from MAF based logs, right?
Unfortunately I haven't been able to find any 35R VE settings that have been posted, however, using the values in the patch, the idle is damn near perfect (average 14.7xxx afrs with a trim of -4.89
). The cruise afrs were ok as well at 14.7253 but, the trim is at -11.5234 so it looks as though the cruise VE settings need to be adjusted.
To dial in the trims for cruise I would adjust the MAP VE table correct (?) since I would be cruising at 3 to 4K but, at lower loads than if I were at 3 to 4k but, at 100% TPS and much higher loads.
Unfortunately I haven't been able to find any 35R VE settings that have been posted, however, using the values in the patch, the idle is damn near perfect (average 14.7xxx afrs with a trim of -4.89
). The cruise afrs were ok as well at 14.7253 but, the trim is at -11.5234 so it looks as though the cruise VE settings need to be adjusted. To dial in the trims for cruise I would adjust the MAP VE table correct (?) since I would be cruising at 3 to 4K but, at lower loads than if I were at 3 to 4k but, at 100% TPS and much higher loads.
Aug 20, 2009, 11:00 AM
#684
The cruise afrs were ok as well at 14.7253 but, the trim is at -11.5234 so it looks as though the cruise VE settings need to be adjusted.
To dial in the trims for cruise I would adjust the MAP VE table correct (?) since I would be cruising at 3 to 4K but, at lower loads than if I were at 3 to 4k but, at 100% TPS and much higher loads.
To dial in the trims for cruise I would adjust the MAP VE table correct (?) since I would be cruising at 3 to 4K but, at lower loads than if I were at 3 to 4k but, at 100% TPS and much higher loads.
What I would do for that car is to cruise at a bunch of different map levels if you could. Then you can adjust the table accordingly.
Eric
Aug 20, 2009, 12:27 PM
#686
Evolved Member
Thread Starter
More resolution? I think you mean bigger tables? Resolution is already 16 bit variables using the max 10 bit ADC the hardware can do.
Bigger tables... personally I think most people's problems (aside from Eric's oscillation) are due to them not managing to tune the existing small tables properly. A large 3d table might look good, but I think most people would get worse results. The trends in VE are mainly between over-run/idle and high speed cruise, they should be progressive and smooth. Bigger is not convincingly better here. I had the option to do a 16*16 table, I chose not to because I've done it before for VE tables and it is overwhelming to my small brain.
Feel free to recode it however you want though!
Bigger tables... personally I think most people's problems (aside from Eric's oscillation) are due to them not managing to tune the existing small tables properly. A large 3d table might look good, but I think most people would get worse results. The trends in VE are mainly between over-run/idle and high speed cruise, they should be progressive and smooth. Bigger is not convincingly better here. I had the option to do a 16*16 table, I chose not to because I've done it before for VE tables and it is overwhelming to my small brain.
Feel free to recode it however you want though!
Aug 20, 2009, 01:06 PM
#687
Hey, John, hope all is well and the GT-R is coming along well. You have to post up some pictures at least.
As far as the 3D instead of the two 2D tables...I emailed Thomas Dorris (DSMLink creator) and they have implemented SD via DSMLink as well (I think they call it ECMLink now). They, too, started with the two tables, map ve and rpm ve, but eventually moved to a 3D table because of various issues. By no means are the two tables not doing their job, and I know they are not related to my IPW issue, but I am just thinking about future development to give more granularity to the the tuning ability for those who know what they are doing. Just a suggestion at this point, not a necessity.
Since I have you here for now (damn, you're offline now...I need to type faster
), I also asked Thomas if he had any input on why he would think I was getting the oscillating IPW issue and this is what he said...I am quoting from his email to me (hope Thomas doesn't mind):
Obviously people call things differently, but in your maf to IPW disassembly, did you happen to see anything similar to what is being explained here by Thomas in the Evo code?
Thanks,
Eric
As far as the 3D instead of the two 2D tables...I emailed Thomas Dorris (DSMLink creator) and they have implemented SD via DSMLink as well (I think they call it ECMLink now). They, too, started with the two tables, map ve and rpm ve, but eventually moved to a 3D table because of various issues. By no means are the two tables not doing their job, and I know they are not related to my IPW issue, but I am just thinking about future development to give more granularity to the the tuning ability for those who know what they are doing. Just a suggestion at this point, not a necessity.
Since I have you here for now (damn, you're offline now...I need to type faster
), I also asked Thomas if he had any input on why he would think I was getting the oscillating IPW issue and this is what he said...I am quoting from his email to me (hope Thomas doesn't mind):
I have some guesses, but nothing at all definitely related. The factory
code includes what we've labeled in our own disassembly as "predicted
airflow per rev" logic that tries to guess at what AFPR should be and
then tries to adjust injector pulsewidth (directly) based on the "rate
of change" of airflow. It's really goofy logic that does not like to
see the airflow signal change too quickly or else it gets really upset.
I saw this first when I was testing GM MAF integration code. I saw wild
swings in injector pulsewidth that could not be correlated with anything
the ECU *should* have been doing. And, of course, this caused all kinds
of annoying side effects. So for our implementation, I just simply
disabled that code when not running on a Mitsubish airflow sensor.
I have no idea if that might be your problem or not, but the two
symptoms sure sound similar.
code includes what we've labeled in our own disassembly as "predicted
airflow per rev" logic that tries to guess at what AFPR should be and
then tries to adjust injector pulsewidth (directly) based on the "rate
of change" of airflow. It's really goofy logic that does not like to
see the airflow signal change too quickly or else it gets really upset.
I saw this first when I was testing GM MAF integration code. I saw wild
swings in injector pulsewidth that could not be correlated with anything
the ECU *should* have been doing. And, of course, this caused all kinds
of annoying side effects. So for our implementation, I just simply
disabled that code when not running on a Mitsubish airflow sensor.
I have no idea if that might be your problem or not, but the two
symptoms sure sound similar.
Thanks,
Eric
Last edited by l2r99gst; Aug 20, 2009 at 01:22 PM.
I see where your coming from and your probably right.
Aug 20, 2009, 02:48 PM
#689
Evolved Member
Thread Starter
You have all the tuning granularity you need in the main fuel and timing maps though. But don't let me stop you changing it to 3d
I'd need to dig out my old charts of the IPW stuff, I glossed over it to be honest, looking for the "straight path" in the normal case and ignored a lot of boring compensations. One of these may be the one that is giving you troubled.
Trouble is I've not been into this part of the Evo code for months, and I have a good short term memory for this stuff, but not long term. If I do a tune for someone and they don't get back to me with logs for a few weeks I forget completely where I was. Just too much new stuff each day...
I'd need to dig out my old charts of the IPW stuff, I glossed over it to be honest, looking for the "straight path" in the normal case and ignored a lot of boring compensations. One of these may be the one that is giving you troubled.
Trouble is I've not been into this part of the Evo code for months, and I have a good short term memory for this stuff, but not long term. If I do a tune for someone and they don't get back to me with logs for a few weeks I forget completely where I was. Just too much new stuff each day...
Aug 20, 2009, 02:52 PM
#690
Evolved Member
Thread Starter
Just had a look, and it is all gobbledy gook to me now, and I'm not sure I ever had the bit Tom is talking about. Sorry, but if I had a month of what was previously my spare time to do this I could go into it, but really that is about how long it would take.