http://banks.myzen.co.uk/88570008-v5-modsJB2SD3.zip

Above (untested!) contains my latest ROM and xml changes.

Note that NOP1 has gone, as has the mov 0x73,r2.

A fair few tables now, but still they can be applied using Ecuflash.

 

ECUFlash doesn't appear to have the XML for your ROM.

 

FTP server is being a nightmare.

Here it is attached to this post, endian is little as I still have 1.29a in use.

 

Hey John,

ok the 94% RPMVE has fixed the idle, now the trim is within %5... so I might make it 95% VE.

Also I DID notice my LTFT has started working, so not sure whats going on there?!?!

I still am having a problem at about 2000-2500rpm and 80kpa. Seems to worse when cold, I am looking through my hot logs now to see what sort of WB+STFT I am getting.

I havn't looked at your new xml's/maps yet - is there more than 8 bins?

Cheers
D.

 

No still 8 bins, 6 is prob enough. Easy to change for more, but 8 is more than enough to trouble us at present!

I notice no difference between 0C and 22C MAT in the way it drives, so I think you just need to work out if it is on average lean or rich at 2000-2500 and 80kPa. I get some weird knock at 60-70kPa at 2600 RPM when the engine is partly warmed up. It did it with the MAF sensor as well, but today I got it a few more times than usual, previously maybe every other drive would do it from cold. Given it was just a 4 I usually ignored it, but today I had a 10 and a 17, yet when warm it wouldn't do it. Odd. Will see if this comes back, take a few degrees out. It was also quite random on the knock sensor, but always in the same area, during warm up. Doesn't affect the octane number and I never hear any knock (I do hear anything over about 8 if using boost).

LTFT - I haven't plugged the laptop in today to see if it has done anything with it. I never pay much attention to it, it may just take many miles after a flash before it updates.

On Tephra 5 with my realtime patch I often have to kill the ECU power after a flash otherwise the CEL flashes for ages and the engine won't start. Is this fixed in 5.10? I've not tested it yet as I'd have to move all my realtime stuff over too...

 

yeah one of the bugs with V5 was that sometimes after a flash valet mode would be enabled.

this *should* be fixed in 5.10, but some users still report problems... I have never had the issue (with v5.10)

when i say cold - i mean coolant temp not upto like 80... I figure I will ignore drivability problems on coldstart initially until i get it hot tuned up

 

John - you forgot the XML change for mov #1, r2 - probably not important maybe just nop it..

 

also - I think your new VE LOAD scaling is wrong!?!?

the change in the code indicates you now are doing *115/64 in the map, however your scaling is doing something else?

original code:
RPMVE * 0x73 * MAPVE / 0x4000

new code:
RPMVE * MAPVE / 256

0x4000 = 256 * 64, so difference in code is 0x73/64

or am I doing something wrong?

 

You're doing something wrong.

The original code is:

8*(RPMVE * 0x73 * MAPVEold / 0x4000) = 0.0562*MAPVEold*RPMVE

The additional factor of 8 is a little further down.

The new code you have is correct, but the new MAPVE values are a factor of 14.31 larger than the old values. This gives:

0.003906*MAPVEnew*RPMVE*14.31 = 0.056*MAPVEold*RPMVE

 

duh... man how did I not see the shll's

Ok that makes sense. Its still a little off thou:

old sd for 266.8kpa:
266.8kpa = 200raw (1.334 scaling)
8*(0x80(100%) * (200 * 0x73)) / 0x4000 = 1437.5

new sd for 266.8 kpa: ((5/32*0.596) scaling)
266.8kpa = 2865raw

(0x80(100%) * 2865)/256 = 1432.5

ie 1432 vs 1437... probably just minor

 

I've just about finished porting jcsbanks SD v3 over to the 88590015 ROM. Its been a fair bit of work because there are some differences in the USDM ROM code that required me to handle the MAF and baro errors differently. I'm putting what I have up now, so people who have a MAT sensor installed can start preparing a ROM.

*I have one remaining item to finish before it can be used.* I still need to create a scaling for the GM MAT sensor that can be inserted into the IAT sensor scaling table so that I can switch the IAT values over to MAT values.

*NOTE* Once the port is complete (hopefully by Wednesday afternoon), it will only work in conjunction with my MAT logging patch (along with a GM IAT sensor installed somewhere along the intake track).

EDIT #1: Duh, I forgot to mention that the car needs to have my JDM MAP sensor patch + JDM MAP sensor installed.

EDIT #2: jcsb, just in case you are wondering, the NOP1 erases the move #1, r2 that tephra mentioned.

Patched ROM and xml are here (copy the tables from the patched ROM to your ROM):
http://se30.dyndns.org:8080/EVO/8859..._JCSBSD3M1.zip

ECUFlash screen shot:

 

MrFred - dont worry about the MAT scaling.

If you look at my MAT vs IAT graph a few pages back you can see the stock scaling works well for the GM sensor...

 

update -

ok so I havn't done V3 yet - was to busy at work today!

ran some updated numbers for my MAPVE and flashed it to my car.

initially I thought - hrmm car feels bad today... so after driving a while I flashed back to my STOCK MAF setup... car felt the same... so I guess its just a bad day! :P

John - if I am testing out high load areas (4000rpm) and I am seeing a lot richer than I expect does that mean I should reduce my MAPVE for that area? to get it back into line with the load that I expect?

 

Your logs did suggest about 100% VE (ie load=MAP) for the midrange - at least where there were a lot of data samples, but yes, if you're too rich you need to reduce MAPVE in that area if it is too rich at that boost across a variety of engine speeds, or you need to reduce RPMVE in that area if it is only too rich at that engine speed.

Nice work mrfred.

 

Most of the errors here will be due to quantisation of the old 8 bit signals.

Just to remind us where it goes after you produce your raw value:

Load = MAFSOURCEMAIN*0.596*10/32

So MAFSOURCEMAIN of 1432 becomes 266.7 load.