Don't worry about my rom man. If you have time you have time. I am still doing a lot of reading on SD compared to MAF and MAP setups. I do know that on MAF cars that the MAF can be used as a form of a intake air temperature sensor. This negates the need for a secondary one. Since a MAP sensor is also need we are covered there as well. What I am wondering about is if the stock MAP sensor has the resolution need for a SD setup. I am also wondering about the advantages/disadvantages over a MAF based system. As so far as I have read it seems to be superior in every single way..... I am worried about properly populating the VE table (volumetric efficiency). Any one on here familiar with SD tuning in general?
Opensource 32bit Speed Density now available!
- Thread starter Td_d
- Start date
SleepyBear
New member
so this would be a good idea for my setup since i have a stock size intake?
HolyCrapItsFast
Drinks beer!
SD FTW!!!
Advantages are...
SD:
- As Fuji mentioned you can run any size intake or run open turbo. It is highly adaptive toward any intake and turbo configuration and is not limited by plenum size.
- Not susceptible to leaks in the intake system. No matter what the leak, SD will always apply the appropriate amount of fuel based on manifold pressure.
- You can use a vent to atmosphere BOV
- can be easily tuned for huge power.
MAF:
- Better suited for Daily Driving and emissions
- Not sensitive to changes in atmosphere and temperature or air density
- more consistent fueling over all
In advanced systems they utilize a hybrid of both systems. When in closed loop the ECU derives fuel based on MAF input but when it reaches a defined g/s the MAF is clamped and the MAP sensor takes over. It would be interesting to see if it is possible for someone to come up with that kind of logic for our ECU's but I think that is wishful thinking right now.
I have tuned many a speed density in my day but that was mostly on a Dodge Daytona IROC RT and a 72 vette with a FAST computer and a BG blower. Most recently I have been tuning AEM using SD on Nissans.
The only susceptibility you will have with the MAP sensor is A. if it is not big enough for the turbo being used and B. if it is scaled properly. This is very important.
SleepyBear
New member
i wanna get tuned for Speed Density on my UTEC!!!!!
+1234567
Nothing more awesome to me then being able to blow off an intercooler pipe on a test run and then being able to cruise back to the shop and redo it, as opposed to being stuck on the side of the road. Even though thats only happened to me twice so far
My car doesnt seem to like MAF based maps at all...it would stall alot no matter how much the scaling was adjusted. But when I switched to SD it ran like a champ, solid idle and everything. Strangest thing ever. Most likely has to do with the fact that when the maf was extended the old owner used butt connectors instead of soldering. Only time I'll go back to MAF based is if I run blow thru, which is eventual
SleepyBear
New member
See I knew you were a genius.... Best use for a UTEC as of yet....
Td_d
Commander In Chief
Cool, please do, I'm testing the last variable today, and then I can try and port it for the USDMs if it's all kosher.
Td_d
Commander In Chief
Alright - I'm pretty sure that I've got the right parameter for MAP_delta. Merp just alerted me to being quite careful in terms of where I place the new SD parameters in RAM, in terms of identifying open locations, so I need to follow the process he suggested, hijacking an SSM routine to make sure it's not referenced at all. Damn, they are making my head hurt :tard:
Mart - I know that you actually pointed Merp in the right direction in terms of how to hijack the roughness monitor SSM routine - I'm going to go read up that thread now, could you give me a 2 cent tour how to go about it?
Mart - I know that you actually pointed Merp in the right direction in terms of how to hijack the roughness monitor SSM routine - I'm going to go read up that thread now, could you give me a 2 cent tour how to go about it?
Td_d
Commander In Chief
Well, I've got it all coded up and it's running properly in the simulator SimH - pulls the correct g/s figure from the MAF scaling table. I've not yet tested the RAM locations - have found a spot with no evident references, but still need to get my head around what Merp was stating in terms of testing them.
And I'll be damned - the ROM location for the MAF function in the USDM 08/09 Rom is identical! I'm going to start disassembling the USDM rom in the meantime, but it looks like it might be identical in many respects, save for certain maps being different for emissions etc. This might be very quick.
EDIT: yeah, this will be dead easy to port across to the USDM 08. The RAM addresses for the various variables are different - but refer to basically identical code - so I can find the non standard parameters very quickly (already have MAP_delta, identical code). Empty spots in ROM for dropping the patch and RAM for the new SD parameters are also available.
And I'll be damned - the ROM location for the MAF function in the USDM 08/09 Rom is identical! I'm going to start disassembling the USDM rom in the meantime, but it looks like it might be identical in many respects, save for certain maps being different for emissions etc. This might be very quick.
EDIT: yeah, this will be dead easy to port across to the USDM 08. The RAM addresses for the various variables are different - but refer to basically identical code - so I can find the non standard parameters very quickly (already have MAP_delta, identical code). Empty spots in ROM for dropping the patch and RAM for the new SD parameters are also available.
Last edited:
td_d:
how to hijack the SSM routine, the stupid and lame way:
you want to redirect the SSM routine to another address to validate some value. I selected SsmGet_Roughness_Monitor_Cylinder_3_P69 to hijack in my ROM for absolutely no particular reason. It returns the value @ FFFF6896 in my ROM.
I wanted to read GPIO Port E because I was looking for the CEL port. it is located at FFFFF754 according to the hardware specification
1.- Opened up my ecuflash xml for my ROM and added the following:
2.- then opened up my ROM in ecuflash and look at that "table". I changed the value to 0xFFFFF754.
3.- Save and flash
4.- Fired up romraider and monitor Roughness cylinder 3
now be careful, it is only a 8 bits value. if you need 16 bits, you will need to hijack another routine like Roughness cylinder 4 and point it to the next address to get another 8 bits.
Does it make sense?
and btw, this could be all done in an hex editor if you are talented (not like me).
Mart
how to hijack the SSM routine, the stupid and lame way:
you want to redirect the SSM routine to another address to validate some value. I selected SsmGet_Roughness_Monitor_Cylinder_3_P69 to hijack in my ROM for absolutely no particular reason. It returns the value @ FFFF6896 in my ROM.
I wanted to read GPIO Port E because I was looking for the CEL port. it is located at FFFFF754 according to the hardware specification
1.- Opened up my ecuflash xml for my ROM and added the following:
Code:
<scaling name="uint16" units="units" toexpr="x" frexpr="x" format="%x" min="0" max="65535" inc="1" storagetype="uint16" endian="big"/>
<table name="P69 value" address="44564" type="2D" level="1" scaling="uint16">
<table name="X" type="Static X Axis" elements="2">
<data>Hi</data>
<data>Lo</data>
</table>
</table>2.- then opened up my ROM in ecuflash and look at that "table". I changed the value to 0xFFFFF754.
3.- Save and flash
4.- Fired up romraider and monitor Roughness cylinder 3
now be careful, it is only a 8 bits value. if you need 16 bits, you will need to hijack another routine like Roughness cylinder 4 and point it to the next address to get another 8 bits.
Does it make sense?
and btw, this could be all done in an hex editor if you are talented (not like me).
Mart
Last edited:
Td_d
Commander In Chief
Hey Mart, that's genius - I figured out from Merp's thread how to do it, but I've been digging around with hex editors - didn't think of using Ecuflash as a quick and dirty. The real question I have (I've left a note for Merp) is whether the aim is to basically replace the address (as you did with the port address) with the RAM addresses that I'm aiming to use for the SD output parameters, and then 'check a CEL' to see whether it allows writing to that address or not (Merp warned that some addresses are blocked off from the SSM writer). Make sense?
Td_d
Commander In Chief
Okeydokes - I've ported the 08/09 USDM hex
Still need to pull together the Ecuflash, and logger XMLs, but I've got to run now - to a whiskey festival Yeeha!
If I'm still sober enough, I can probably put up the hex later on tonight - but with the proviso that those RAM addresses have not been tested yet!
Still need to pull together the Ecuflash, and logger XMLs, but I've got to run now - to a whiskey festival
Yeeha!If I'm still sober enough, I can probably put up the hex later on tonight - but with the proviso that those RAM addresses have not been tested yet!
