SD - first test success
hrmm the loads seem to be lower in the SD, which I guess means we need to bump up the MAP sensor VE map. But not sure why its going rich - I would have thought the other way round.
We really need a proceedure/fool proof way of tuning these maps, something like what Eric came up for tuning injectors...
edit - HIGHER load, hrmm it looks like my GMMAP-raw value is lower because the rpms are higher, but the same load is coming out... so yeah higher load in SD vs nonSD
We really need a proceedure/fool proof way of tuning these maps, something like what Eric came up for tuning injectors...
edit - HIGHER load, hrmm it looks like my GMMAP-raw value is lower because the rpms are higher, but the same load is coming out... so yeah higher load in SD vs nonSD
Last edited by tephra; Feb 8, 2009 at 03:47 AM.
Your raw of 83 is 5.05V*83/255=1.64V at say 100kPa.
Gradient from the GM info works out to be 1.22kPa per raw unit again assuming 5.05V.
This suggests you have a negligible offset.
I would suggest you change the Ecuflash scaling to:
<scaling name="MAP 16bit" units="kPa" toexpr="x*1.22" frexpr="x/1.22" format="%.0f" min="0" max="400" inc="1" storagetype="uint16" endian="big"/>
Do NOT change the MAP 8 bit scaling since you are wanting to replicate the JDM MAP sensor values.
Then change the top row (the MAP axis) so that the numbers match what they were before (ie so the table when displayed in Ecuflash looks like mine but with just the axis scaling changed in your xml).
Then if it doesn't work we need to check your code changes.
Gradient from the GM info works out to be 1.22kPa per raw unit again assuming 5.05V.
This suggests you have a negligible offset.
I would suggest you change the Ecuflash scaling to:
<scaling name="MAP 16bit" units="kPa" toexpr="x*1.22" frexpr="x/1.22" format="%.0f" min="0" max="400" inc="1" storagetype="uint16" endian="big"/>
Do NOT change the MAP 8 bit scaling since you are wanting to replicate the JDM MAP sensor values.
Then change the top row (the MAP axis) so that the numbers match what they were before (ie so the table when displayed in Ecuflash looks like mine but with just the axis scaling changed in your xml).
Then if it doesn't work we need to check your code changes.
Last edited by jcsbanks; Feb 8, 2009 at 04:02 AM.
so regardless of sensor brand we leave the MAP8bit as 1.334 scaling?
I have done this:
Top row didn't change - bottom row needed to be reset to your values of course
I have done this:
Code:
<scaling name="MAP 16bit" units="kPa" toexpr="x*100/82" frexpr="x*82/100" format="%.0f" min="0" max="400" inc="1" storagetype="uint16" endian="big"/> <scaling name="MAP 8 bit" units="kPa" toexpr="x*1.334" frexpr="x/1.334" format="%.0f" min="0" max="400" inc="1" storagetype="uint8" endian="big"/>
Yes leave the MAP 8 bit at 1.334 for now (without complicating the issue we could change it later if we also change the 0x73 multiplier).
When I change my MAP 16 bit scaling my top row changes and the bottom row stays the same. To correct for the GM MAP you need to then put the top row back to match the original values (except the 311 which is the max for your sensor, so copy the 311 to the bottom row also).
When I change my MAP 16 bit scaling my top row changes and the bottom row stays the same. To correct for the GM MAP you need to then put the top row back to match the original values (except the 311 which is the max for your sensor, so copy the 311 to the bottom row also).
yup - I worked that out in my brain, you have calc'd the rest of the code based on the JDMMAP signal, so we need to convert out MAP sensor signal into that scaling 
Yeah, I changed my 8bit BACK to the correct scaling so my bottom row changed
Worth using the 11bit ADC? probably not since we 8bit-ise the ADC in this table anyways!

Yeah, I changed my 8bit BACK to the correct scaling so my bottom row changed

Worth using the 11bit ADC? probably not since we 8bit-ise the ADC in this table anyways!
The net result of all this should be that your load=MAP in kPa when you have 100% in the RPM VE and the top and bottom rows of the MAP VE table display the same and you are about 25C on your IAT (or your replacement IAT value if you've done that).
11 bit ADC, I did wonder, but as you point out the IPW is a bit coarse anyway, and I didn't want to complicate a first patch. With closed loop working well with sensible trims (at least on mine and hopefully soon on yours) it probably isn't necessary, MAF sensor readings at low flow are quite coarse also.
my IAT is in the manifold so my temps are a lot higher than MAFIAT. Not sure if that's a big deal, probably not. temp doesn't play a massive part on air density... probably will be more accurate anyways (hopefully)
Mine is effectively the same in the code. Obviously you didn't go the MAT to IAT change then.
Note that if you have the MAF sensor plugged in the dropping baro at high RPM will make you leaner. I would suggest once you're happy with the low speed manners you tune with the MAF unplugged, ECU will substitute a standard atmospheric pressure (but no CEL of course). I really don't think we need the baro but we'll need some mountain climbers to check in due course
Note that if you have the MAF sensor plugged in the dropping baro at high RPM will make you leaner. I would suggest once you're happy with the low speed manners you tune with the MAF unplugged, ECU will substitute a standard atmospheric pressure (but no CEL of course). I really don't think we need the baro but we'll need some mountain climbers to check in due course
yeah I did the IAT -> MAT change - so I *could* disconnect the MAF if I wanted... ie my MAF_IAT log is NOW the same (but less steppy/updated) as the MAT...
yeah I was wondering about the sensors still being plugged in. I guess we can just nop the baro adc_read...
thanks for this, going to test tomorrow
yeah I was wondering about the sensors still being plugged in. I guess we can just nop the baro adc_read...
thanks for this, going to test tomorrow
I'm sure you know your arrangement/wiring/ADC channels, but just to confirm, you need your IAT reading to be whatever the inlet manifold temp is, whether you have:
1. The JDM IX arrangement - an OEM MAT sensor and you just change the IAT ADC so it reads MAT, which is what I'm doing.
2. You wire a MAT sensor into the IAT input and make no code changes.
I don't quite follow your arrangement?
----
I just tested with the wideband, everything is as it was with the MAF. I've not retuned anything.
I will recheck with the wideband when the weather warms up to make sure it stays about right.
1. The JDM IX arrangement - an OEM MAT sensor and you just change the IAT ADC so it reads MAT, which is what I'm doing.
2. You wire a MAT sensor into the IAT input and make no code changes.
I don't quite follow your arrangement?
----
I just tested with the wideband, everything is as it was with the MAF. I've not retuned anything.
I will recheck with the wideband when the weather warms up to make sure it stays about right.
1.
However I am hijacking the FuelTemp ADC, which is a USDM thing, but uses the same ADC as the JDM MAT ADC.
Then I have changed the ADC_Stuff routine to 0x0E so that when it reads MAF_IAT it actually just re-reads the MAT ADC.
If you log the scaled MAT vs MAF_IAT(replaced by MAT) then you can see much more resolution/update speed with the MAT. I'll try and post up a pic of what I mean..
However I am hijacking the FuelTemp ADC, which is a USDM thing, but uses the same ADC as the JDM MAT ADC.
Then I have changed the ADC_Stuff routine to 0x0E so that when it reads MAF_IAT it actually just re-reads the MAT ADC.
If you log the scaled MAT vs MAF_IAT(replaced by MAT) then you can see much more resolution/update speed with the MAT. I'll try and post up a pic of what I mean..
My MAT and IAT now move together, but I log the non-linear raw ADC values, my Pocket PC logger linearizes them and displays them. Some of the linear and processed values may introduce smoothing and lag, is this what you're seeing?
Re your MAP filtering/smoothing, will be interesting to see what you find. The substitutions we make are after the MAF sensor signal has been filtered:
new value = (x*present value+y*old value)/z
... so there is no filtering on the MAP signal to reduce response time. Given that the MAF gets advance warning before the MAP of an inlet manifold filling spike on a throttle transient, we must not delay the response too much of the MAP signal. You'll notice I'm using the raw MAP sensor signal.
Re your MAP filtering/smoothing, will be interesting to see what you find. The substitutions we make are after the MAF sensor signal has been filtered:
new value = (x*present value+y*old value)/z
... so there is no filtering on the MAP signal to reduce response time. Given that the MAF gets advance warning before the MAP of an inlet manifold filling spike on a throttle transient, we must not delay the response too much of the MAP signal. You'll notice I'm using the raw MAP sensor signal.
EvoM Guru
iTrader: (50)
Joined: Mar 2006
Posts: 9,675
Likes: 132
From: Tri-Cities, WA // Portland, OR



