Opensource 32bit Speed Density now available!

Vermont

New member
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?
 

HolyCrapItsFast

Drinks beer!
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?

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.
 

Td_d

Commander In Chief
Ah, red eye flights for the win :( on my way to the airport, hence up since 4am. I've got a 3.5 bar MAP sensor, so I know I've got the resolution and size required. I've got 1 variable, map delta, and I'm done!
 

Td_d

Commander In Chief
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

Off the top of my head, it should be capable - I think you would add in code just after the hook to the SD code to check if the CL/OL switch is open or closed, and if closed, reroute it straight back to the MAF routine.
 

wo^tron

New member
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.
+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 :p
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
 

Td_d

Commander In Chief
Hey Reks, I'm basically one variable short of getting this working on an EDM 08, after which it should be quite easy to port to a USDM.
 

Td_d

Commander In Chief
Ok, I think I've found the elusive MAP_delta parameter - I'm going to do some logging tomorrow for a sanity check.
 

Td_d

Commander In Chief
Let me know. I can send you a copy of my stock 09 ROM if you need and see if it can be done.

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.
 

Vermont

New member
Oooo send me one send me please.... Me and rek are both usdm 09. the EDM roms don't seem to be that different from the usdm ones.... I do not for see any problems.
 

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?
 

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.
 
Last edited:

Td_d

Commander In Chief
I've got yours already - started disassembling it some time back. Send me your Rom just in case.

I'm going to start working on porting the 08 USDMs now, and just waiting for some clarity on the RAM variables from Merp.
 

Mart

New member
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:

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 :D

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!
 
Top