Switched maps testers wanted

[Kenneth]

Right now I am going to bed.

That aside, I need some testers willing to alpha test switched maps. I'll most likely run them up on my car tomorrow to see if the car runs. After my car actually runs, I will need it verified and tested.

Maps
There are 8 maps for each

Fuel
Ignition
Load target
Wastegate duty
Load Limit


8 values for

Which of the above maps to use for high/low octane (except load limit which does not have high/low octane)
Mods setup (See below)
Injector Size
RPM Limit
Speed Limit On
Speed Limit Off
Max Ignition retard
CEL on KnockSum


Mods setup
There are setup bits for the following settings. Because of the way the maps are switched, Launch Control and No Lift To Shift are not configurable under this section.
Once the correct map is chosen, you can setup the following items for that map

Mods On / Off
CEL on Knock Sum On / Off
Gear Calculation (RPM / Speed) On / Off
Closed Loop On / Off


Initial testing shows that I am getting the settings loaded correctly.

A few things need testing. The stuff below is new. If one map set is switched correctly, then the rest should too. Be good to check the correct maps are used though. Would also pay for someone to double check my ROM allocation to make sure there are no odd cross overs of memory.

Closed loop switch works
Maps are switched correctly (be easy to test if closed loop is off and you switch the AFR map and log AFR with wideband)
Gear Calculation (RPM / Speed) works
complex map switching (try some more complicated stuff)

[foxdie]

Hi Ken,

Providing the chance of something going bang (with a sensible map of course) is highly unlikely to nil, I'll be able to help as of Friday 25th (when I get paid and can put a full tank of fuel in her) if the ROM will work on a 7202 as well as a 7203.

Am I right in presuming the closed loop switch keeps the car in closed loop all the time? This means wiring the wideband o2 sensor up to the secondary o2 sensor input? If so I can do that.

Regarding switchable map testing, is there a loggable MUT request that'll show us which map(s) are being used? That way I can get detailed EvoScan logs for you :)

Incidentally folks, I have 1 spare 7202, anyone else with a 7202 fancy helping test this on an exchange basis? (I pre-flash it, post it out, you post yours back to me)

[Seems Unlikely]

Mines a PFL so i would be happy to help with testing, mine is a 7202 yes? Am I needing diagnosis/datalogging capability for this?

Corin

[foxdie]

Hi Corin, forgive me for saying this, but in asking those questions I believe this is beyond your scope, however we all have to learn somewhere, so here's some help :thumbsup:

With a pre-facelift there's a small chance it's a 7202. If you locate your ECU (behind the flap by the foot pedals, above the gearbox), it's the topmost ECU with the 4x green connectors. If the box is made of metal then you have a 7201 and isn't covered by Kens mods (also, this ECU is only just approaching a reflashable status).

If it's black plastic there's a 50/50 chance it's a 7202. Remove the ECU (Unbolt the 2 x 10mm bolts on the right side and 1 x 10mm bolt on the left, slide the ECU out to the left, unplug the 4x green connectors) and gently lever the PCB/connector out of the casing with a knife or flat-blade screwdriver, it won't take much effort and may shoot out if you're not careful ;)

49648

Depending on what's on the main chip (highlighted above) will get you different answers;
MH7201FS = Known as a 7201, only reflashable with MMCFlash and will not run Kenneths ROM
H8/539 = Known as a H8, only reflashable with MMCFlash, will run Kenneths ROM without any issues
MH7202F = Known as a 7202, reflashable with EcuFlash, will run Kenneths ROM if you edit an XML file to remove 1 character
MH7203FA = Known as a 7203, reflashable with EcuFlash, will run Kenneths ROM without any issues
Will you need diagnosis capability? Most definitely yes, you'll need a laptop, a Tactrix OpenPort 2.0 diagnostic cable (In the region of £150 from the US) and the following software;

EcuFlash (http://evoscan.com/ecuflash/) - Free, version 1.43.3150 (http://evoscan.com/ecuflash/ecuflash_1433150_win_beta.exe) seems to work best, install this AFTER EvoScan as EvoScan includes its own firmware for OpenPort cables
MMCFlash Kit 1 (http://evoscan.com/evoscan-gps-obdii-cables/details/32/1/performance-vehicle-pc-diagnostic-interfaces/mmcflash-software-for-mitsubishi,-kia,-hyundai,-suzuki,-mazda-reflashing) - About £140 - Requires EcuFlash to do the actual ROM editing though
EvoScan (http://evoscan.com) - About £16 and well worth it - Use it to monitor your cars performance post-flash

The laptop should be a Pentium 4 or better.

Hope this helps!

[Atik]

Its a bit beyond my competency, but if Jason wants to play with my car, I'm happy to use my car for testing purposes. Though the car isnt 100% yet.

[wintertidenz]

I would love to help, but I don't have an OpenPort 2.0 to flash, only a 1.3 to log :(

[Kenneth]

I would never say the chance of blowing your engine is low. These mods are much more likely to result in damage compared to previous mods.

Good news is that the Galant fired up first time! Was fine while warming up, then idled like poo. I went back and re-flashed it with closed loop enabled on the first map and viola, I can switch on and off crappy idle... lol.

[foxdie]

Hehe, glad it worked without blowing, but now I'm fairly certain you meant being able to turn off closed loop altogether :)

This might be good actually, mine idles like a dog on hot start (well, get the engine pretty hot, stop the car for 30-60 mins, start it up again), when it does this I've noticed the mixture is very lean (20:1 or so) however this only lasts for about 20-30 seconds as it slowly richens up to about 15.5 (what I have the LC-1 set to).

[Shtiv]

Email replied to (yes of course)

[lateshow]

could these be used for instance for following purpose:

I want to get the best fuel economy on cruise and want to tweak the ignition advance on that area to the best possible place. I have a set of maps that have lets say 0, +2, +4, and +6 to the original settings on load 0-70 and rpm 1500-3000 area. Then I just monitor fuel consumption on straight road and switch the ignition maps and see which map gives best fuel economy on straight road and @ certain speed..... what do you say?

[Adam.Findlay]

Im in for testing 7203FA in my legnum. PM or TXT me the details Kenneth. I have acess to evo scan for logging as i dont know how to log with the tactrix software like you do kenneth. let me know what you want me to do.

[Hotwire]

id be willing to test, and have wideband too.
PM me the details

[Kenneth]

Yep, that is around about what I intend to do though not for fuel economy :P


could these be used for instance for following purpose:

I want to get the best fuel economy on cruise and want to tweak the ignition advance on that area to the best possible place. I have a set of maps that have lets say 0, +2, +4, and +6 to the original settings on load 0-70 and rpm 1500-3000 area. Then I just monitor fuel consumption on straight road and switch the ignition maps and see which map gives best fuel economy on straight road and @ certain speed..... what do you say?

[Kenneth]

Instead of me PMing people to get you to PM me your email addresses (since you need the ROM and XML files) please just PM me your email address.

How you log is up to you really. I just need to verify that all the maps switch and that the gear calculation works. I am pretty confident about everything bar the gear calculation at the moment because it seems to work without issue on my car.


Im in for testing 7203FA in my legnum. PM or TXT me the details Kenneth. I have acess to evo scan for logging as i dont know how to log with the tactrix software like you do kenneth. let me know what you want me to do.


id be willing to test, and have wideband too.
PM me the details

[foxdie]

Updated the information above about ECUs.

Ps. Got the ROM from Ken a couple of days ago, complicated stuff, will try and test this weekend

[foxdie]

You know Ken, I've just come to actually creating the map to test with... how the devil do you actually check the gear calculation? I see you mention request 0xF640 in the setup bits but when I try and use or log that address I don't have any success.

As part of my testing for this map, I set up the following conditions;
Activation Lookup 1 is set to check address 0xF104 (Vehicle Speed) is equal or greater than 10 KPH
Activation Lookup 2 is set to check address 0xF640 (Gear Calculated) is equal or greater than 150 decimal (uint16)
Activation Lookup 3 is set to check address 0xFFFF to skip to the switch bitfield test
Switch bitfields are all set to OFF so this test passes
I changed my MUT 0xF0 request to log F640, it just kept returning 255 when logged with EvoScan, but I tried the above anyway and the rule matched regardless of gear (quite amusing bouncing off a 3750 RPM rev limiter in any gear all whilst building boost as it has an unintended anti-lag effect).

I set the value to 150 based on the formula RPM divided by SPEED, I created a quick Gear Calculation Lookup Table (http://is.gd/oSpc00) on Google Docs, a value of 150 or more should be firmly in the realm of 1st gear.

Also, I've noticed a weird issue with this ROM at idle, the car will faintly seek when idling, a couple of seconds at 750RPM, a couple more at 700RPM, changing between the two as regular as clockwork every couple of seconds (like it's on a timer or something).

A little bit of good news though, I managed to implement Anti-lag / Launch control with a bit of map tuning, banzai! :D

[Kenneth]

You can't use MUT addresses greater than 0xBF to request data. Anything higher than that is a special request and potentially does other stuff.

As a 16bit value you will either have to log 0xF640 and 0xF641 or just the latter will probably do as a 1 byte request.

Check if you are running closed loop Disabled on that map. It appears the ECU is pretty bad at idle when in open loop. In fact, my does similar ~500rpm. Likely to be because of the ~19:1 AFR it was running :P

[foxdie]

You can't use MUT addresses greater than 0xBF to request data. Anything higher than that is a special request and potentially does other stuff.

Ahh! You learn something new every day :)


As a 16bit value you will either have to log 0xF640 and 0xF641 or just the latter will probably do as a 1 byte request.

Understood, can you recommend what the best practice is to set this up? For example;
What should I add into the MUT table? Do you use specific cells?
What results should I see back from the above request? Was I on the ball or not with the spreadsheet I linked to in my previous post?

Check if you are running closed loop Disabled on that map. It appears the ECU is pretty bad at idle when in open loop. In fact, my does similar ~500rpm. Likely to be because of the ~19:1 AFR it was running :P

Ahh yes, I did notice the wideband going up and down like a yoyo at the time, here's a plot over 20~ seconds of the hunting issue (scale on the right is 10x for AFR, 0.25x for RPM).

49875

So whats the best way to address this? On that map (infact, on all 8 maps), closed loop is enabled (the "Disable closed loop" is set to "Off"). I'm guessing I should try disabling it so the car runs open loop when idling?

Also, as another question, is there a value we can log to see what map is selected? It'd be handy to be able to set up a logging request in EvoScan to show which map is currently active.

[Kenneth]

No best practice that I know of. Just don't overwrite ones you want to log. If any are repeated, then you could use them.
Yeah, it should be in the region of RPM / Speed. But it is pre-scaled RPM / pre-scaled speed.

Unfortunately I have made those last 2 items a bit confusing. Enabled = Closed loop On So if you have Disabled, then closed loop is off (which is your problem)

I'll rename those before doing the public release.

[foxdie]

Ahh thanks Ken, I've set MUT 0xBE to log 0xF640 and MUT 0xBF to log 0xF641, in EvoScan I'll set it to log BE as 2 bytes.

Regarding loops, if I set it to Enabled to enable closed loop, will it still go open loop under high load, or does it force it to closed loop the whole time?

And I'm guessing there's no way to log which map is active?

[Kenneth]

I haven't logged the gear calc, it might be that you find you only need to log 0xF641

That switch only disables closed loop. So if Enabled, closed loop will work as usual, switching to open loop where configured through the other tables.

Yes, the selected map can be logged. I don't remember the memory address off the top of my head though. Hopefully ill be able to get it some time tonight after I get home.

[Kenneth]

Selected map can be logged as a 1byte value from 0xF645
Scaling factor should be x + 1 (values are 0-7)

[foxdie]

It's 7:45am and against my better judgement, I'm going to try this now :)

[foxdie]

Okay, here's an update;

Logging the currently selected map worked a treat using the following steps;
Edit the MUT table in the ROM, locate cell BD, enter the hex address 0xF645
Add a new logging element in EvoScan with the following values: Display: KS Mod Map
LogReference: KSMODMAP
RequestID: BD
Eval: x+1
Unit: Map
ResponseBytes: 1
GaugeMin: 1
GaugeMax: 8
ChartMin: 1
ChartMax: 8
ScalingFactor: 100
Logging the gear calc though was a bit more involving;
Edit the MUT table in the ROM, locate cell BE, enter the hex address 0xF640, locate cell BF, enter the hex address 0xF641
Add a new logging element in EvoScan with the following values: Display: KS Mod Gear
LogReference: KSMODGEAR
RequestID: BE
Eval: x
Unit: Gear
ResponseBytes: 2
GaugeMin: 0
GaugeMax: 255
ChartMin: 0
ChartMax: 255
ScalingFactor: 1
This wouldn't work, as soon as I tried to log that EvoScan disconnected and reconnected to the ECU, and repeated to do so until I disabled that request. I tried logging just 1 byte, this worked but kept logging 0 (as it was trying to log the upper half of the bytes), I then logged just the lower half by logging request BF as 1 byte which then worked and started showing numbers that changed with vehicle speed. I'll post up a set list of speeds once I've logged this in more detail.

It's also worth noting I couldn't log the gear calc until I set "Disable Gear Calc" to "Enabled" on every map, otherwise it'd just return "255" constantly. This is a spelling mistake that Ken will correct before release.

The idling issue was solved by setting "Disable Closed Loop" to "Enabled", thus enabling closed loop as again, this is a spelling mistake and will be corrected before release :)

[Shtiv]

I used these settings for gear calc, sort of in the middle of gap between gears (if that makes sense), by all means check it yourself.... greater than 50 = 1st, greater than 33 =2nd, greater than 22 =3rd, greater than 16 =4th, 5th is around the 13,14 mark so I said greater than 10 but you could just have the next map being 5th without a limiting condition. The gears are far enough apart to deal with the speed resolution easily which is what we were all worried about!

Jason I found an issue with the BDEL tables, I've email Kenneth what my thoughts are so we'll see what he comes up with as there may be more to it in the code. Logging just the lower byte of the gear calc should be fine but I just logged all of it as I didn't know what the numbers would be....
I did later wonder what would happen if the gear calc wasn't enabled everywhere, I figured it was a simple calc so it wouldn't slow things up and just applied it everywhere :P

[foxdie]

Well I found an interesting "gotcha" in the gear calc system. (On my ECU at least) the vehicle speed request only updates roughly every 0.75 seconds, whereas engine RPM updates much more often (probably as fast as you can log it).

What this results in is the gear calc "skews" if engine speed changes rapidly (ie. hard acceleration). I set a test to trigger a map with a 3750 RPM rev limiter if the gear calc value went above 80 (50+margin), and sure enough in first gear I'd hit the rev limiter as planned, when I changed into second gear and accelerated slowly the rev limiter didn't kick in (as expected), but when I floored it in second gear the rev limiter kicked in producing an effect on par with fuel cut. The gear calc value spiked because the vehicle speed variable updates at a slower rate.

I tried to add some more margin to this to cover this slower update rate, setting the map to only trigger if gear calc went above 120, this appears to have solved the issue, the result is a map which only comes into effect if you accelerate hard in first gear (maybe good to limit torque?). Might be a safe thing to add TPS > 80% into that map test as well to ensure it doesn't trigger inadvertently.

Incidentally, how many times are 7202 ECUs reflashable? I think I read 100 somewhere, anyone got any comments on this?

Steve, I'm in chat if you want a natter about the BDEL :)

Edit: Thinking about it, I'm wondering if the slow vehicle speed updates are due to the fact I've got a KPH to MPH converter fitted, maybe that's sampling the VSS and only updating every three quarts of a second. Anyone else able to confirm if their ECU has this update delay?

[Kenneth]

Oopsie!
You were right Steve, I had the target engine load maps around the wrong way. Was just testing you mate ;)

Thanks for picking that up. I have corrected that and it will be fixed in the public release.

So everyone testing needs to reverse the high / low octane references for target load. Or just leave it until the public release...

[Shtiv]

I've reflashed my ecu I would think at least 500 maybe even a thousand times.... But now it's in another car so I get to start again....

testing the testers huh? :P

[Shtiv]

Kenneth, I think I found another issue, could be me but I don't think so, you have an email....

Jason, that gear calc issue you raise, would only be a problem for first which is anything over 50 (so that doesn't matter) or maybe 2nd down a hill, worst case of it I got was a 47 for one data value and it was going pretty hard (admittedly slightly uphill) so I don't think it's a problem, in the higher gears you won't have the problem as the acceleration is not there and worst case it reads one map out for when accelerating downhill or something, maybe your metric ->imperial thingy makes it worse, I'm not sure what you are doing there.... Given your gear maps would be massively different one ear to the next I would think it fine, you could probably raise first to 51/52 if you are worried....

[foxdie]

Hi Steve,

Even though it's logged as KPH (and the ECU thinks it's KPH), the signal it gets is MPH, so the gear calc code is indeed reporting different values for me, however it should be constant so I can adjust it to suit.

Can I just check, does your ECU speed value update in stages (ie. every 0.75 seconds or so) rather than for every request like RPM does? I'm trying to work out if it's my speedo converter thats collecting an average of VSS samples or not.

[Nick Mann]

Jason - my car still reads in KPH, no converter is yet installed. You are welcome to come over and log it?

[foxdie]

Jason - my car still reads in KPH, no converter is yet installed. You are welcome to come over and log it?

I could do but not sure when I can get over there (may try for this weekend because I know you wanted to see me of something else), if you've got 5 mins though and still got your cable, the next time you go out could you log a quick acceleration burst? Just log RPM and SPEED :)

[foxdie]

Ken, just a quickie, do you know if it's possible to do a bitfield test on one of the addresses? I'd like to check address F327 for the state of the bit 16 (xxx0xxxx / xxx1xxxx), that way we can test if the aircon is set to turn on (but not necessarily active, I believe it turns off automatically above a certain engine speed anyway) to possibly switch maps without even fitting wires ;)

[Kenneth]

Hi Jason.

I can't remember off the top of my head which variables get checked for the input bit masking (that *could* be one of them) as I did look at some which would normally be used by other stuff (like air con) which could be taken out. I can't check until Friday evening at the earliest though.

There is another way... I wasn't going to mention it unless someone asked though :P
In the XML definition, if you check the Bit Mask On and Bit Mask Off addresses, you will see that they are 4 consecutive bytes of ROM. The 2 bytes BEFORE that in the ROM (by default it will be 0xF62C) indicate the variable to bit mask. You will of course need to do a 16 bit check and so use 0xF326.





Ken, just a quickie, do you know if it's possible to do a bitfield test on one of the addresses? I'd like to check address F327 for the state of the bit 16 (xxx0xxxx / xxx1xxxx), that way we can test if the aircon is set to turn on (but not necessarily active, I believe it turns off automatically above a certain engine speed anyway) to possibly switch maps without even fitting wires ;)

[foxdie]

That's some complicated stuff, I'll take a look at that this weekend.

Incidentally, and I know this is slightly off topic here but I'm wondering if this may be possible. I noticed that the following outputs differ between the Evo 5/6 7202 ECUs and VR-4 7202 ECUs, is it possible to get these working too? The code could possibly be taken from an Evo 6 ROM fairly easily?

What I'm thinking is it'd be pretty freaking awesome if we could have a pin that goes live to turn, say an intercooler spray with a particular map or something else :)

Pin 6 = Secondary Air System solenoid on Evo's
Pin 20 = Radiator Fan High Speed
Pin 33 = Alternator Enable (Evo 5 only)
Pin 34 = AirCon Fan High Speed (Evo 6 only)
Pin 39 = Fuel Pump High Speed (VR-4 has a separate pin for this)
Pin 40 = Alarm Warning Light (Evo 5 only, maybe not present at all given conflicting information)

[Shtiv]

Sorry I'm on here so rarely.... yes about 0.75sec per update on speed so the calc is not perfect but the problem would only exist in lower gears when it can't keep up so it might think it's in first not 2nd, no big deal for what I'm doing. Besides like I said I only saw a max value in 2nd of 47's (actually I found one 49 and admittedly I was AC on and heaps of crap in the car but still I wasn't hanging about).

I don't see it being a problem for anything I can think of sing the gear calc for. Going downhill in 2nd maybe but again, so what if it uses the first switch, what are you going to have that is that different and you're talking going seriously quick and at relatively low RPM (my 49 was at 3500RPM) for it to be an issue. But in answer to your question your ecu is behaving like mine. :)

[foxdie]

Well I can doubly confirm that KS Mod 2.0 works on a H8/539 ECU as I tested MMCFlash for the first time :)

Also, there's an oddity I'd like to check with people, this isn't specific to this particular ROM but is somewhat specific to all Kens ROMs, I wired up a switch to the ECU connector D-1 aka Pin 71 (http://www.clubvr4.com/forum/showthread.php?59222-Definitive-EFI-ECU-Pinout-(KS-Mod-friendly)) to start testing switching maps based on external switches however I didn't get that far because of some unusual side-effects;

Engine not running - switch off = No abnormalities
Engine not running - switch on = Fuel pump running

Engine running - switch off = No abnormalities
Engine running - switch on = Car feels like the throttle is being pulled back slightly when the switch is enabled, also the car seems to burble / pop a little more on overrun (I managed to get a few backfires just by blipping the throttle whilst stationary, fun but not what should happen), however the wideband gauge doesn't report any difference in fuelling :quasi:

Now the above pin is labelled as an inhibitor switch on auto gearbox cars, but permanent +12V on manual gearbox cars. The ECU itself (H8/539) came from an auto car, I'm wondering if there's some weird PCB difference between MT and AT ECUs that prevents us from being able to use Pin 71?

Incidentally, managed to hit 1.6 bar boost whilst testing this ECU, these are unsafe levels of boost but goddam did the car shift like a scolded cat :dance:

[Shtiv]

Careful with boost control on these ROMS Jason, that's where I'm seeing some weird stuff going on, Kenneth is looking into it....

Also widebands get confused by misfires and can report lean results due to the raw fuel in the mixture being unmeasured, something to bear in mind.

[foxdie]

Careful with boost control on these ROMS Jason, that's where I'm seeing some weird stuff going on, Kenneth is looking into it....

Also widebands get confused by misfires and can report lean results due to the raw fuel in the mixture being unmeasured, something to bear in mind.

Yep, remember you saying, you mind joining me in chat and telling me what you've observed regarding the target load tables?

I've just reconnected Ecu Connector D-1 back to it's stock wiring loom, it was causing issues with starting the car (as in, it took 5 seconds of cranking to start), have changed for a non-illuminated switch and gone for a ground switching method.

[Adam.Findlay]

Yep, remember you saying, you mind joining me in chat and telling me what you've observed regarding the target load tables?

I've just reconnected Ecu Connector D-1 back to it's stock wiring loom, it was causing issues with starting the car (as in, it took 5 seconds of cranking to start), have changed for a non-illuminated switch and gone for a ground switching method.
did changing to a non illuminated switch fix the strange backfiring problem. I have my 3 switches just still need to find the time to install them.. the

[foxdie]

did changing to a non illuminated switch fix the strange backfiring problem. I have my 3 switches just still need to find the time to install them.. the

Sorry, looks like you finished mid-sentence :)

The backfiring issue was because the ECU thought it was constantly being cranked and was running the injectors in batch fire (http://www.stealth316.com/2-fuelinjection.htm#j2b) mode.

I've since switched to simple ground-switched switches connected to ECU pins B-11 and B-14, these work great, I've tested and got working the following setup (with exception to Valet mode as I need to buy a keyswitch);

MAP 1 = Valet mode (Valet Switch on, low load target, little boost, 40 MPH speed limit)
MAP 2 = Sport mode, first gear torque limiter (Map Switch on, Speed > 4 KPH, GEAR > 120, TPS > 15%)
MAP 3 = Sport mode running (Map Switch on, Speed > 4 KPH, TPS > 15%)
MAP 4 = Sport mode overrun (Map Switch on, Speed > 4 KPH, Closed Loop Disabled, Rich overrun with negative timing)
MAP 5 = Sport mode Anti-lag and Launch control (Map Switch on, TPS > 75%, Clutch down, Closed Loop Disabled)
MAP 6 = Sport mode idling (Map Switch on)
MAP 7 = Eco mode running (Speed > 10 KPH, low load target, little boost)
MAP 8 = Eco mode idling & failsafe

The only thing wrong is the closed / open loop mode, I'm gonna nail that down today, it's intermittent whether the label is incorrect or not.

[Kenneth]

The label for Disable Closed loop should be the same on all. It is not labelled incorrectly nor does it not work, it is just written in a way that some find difficult to understand. It has been changed for the official release.

Perhaps you are referring to the fact I didn't set everything to the same value before shipping out the test ROM?

[foxdie]

The label for Disable Closed loop should be the same on all. It is not labelled incorrectly nor does it not work, it is just written in a way that some find difficult to understand. It has been changed for the official release.

Perhaps you are referring to the fact I didn't set everything to the same value before shipping out the test ROM?

No there's definitely something weird going on.

For Maps 1-7, setting "Disable Closed Loop" to "Off" lets the ECU enter closed loop mode when it can (expected behaviour).

For Map 8, setting "Disable Closed Loop" to "Off" keeps the ECU in Open Loop mode permanently, setting it to "Enabled" lets the ECU enter Closed Loop mode when it can (unexpected behaviour).

[Kenneth]

"0 = Disable Closed Loop" is the text. That isn't so helpful because that doesn't directly relate to the 2 option states on the right.

Off = 0
Enabled = 1

So
Off = closed loop permanently disabled.
Enabled = closed loop NORMAL operation.

Once you get your head around that, it works as expected. As I said, this is a confusion (wording) issue and not an operational one. The option replaces the Periphery option which is just one of the flags which is tested to see if Closed loop can operate. If just one of those flags is 0, closed loop will not operate.

[foxdie]

"0 = Disable Closed Loop" is the text. That isn't so helpful because that doesn't directly relate to the 2 option states on the right.

Off = 0
Enabled = 1

So
Off = closed loop permanently disabled.
Enabled = closed loop NORMAL operation.

Once you get your head around that, it works as expected. As I said, this is a confusion (wording) issue and not an operational one. The option replaces the Periphery option which is just one of the flags which is tested to see if Closed loop can operate. If just one of those flags is 0, closed loop will not operate.

No I get that bud, the labels will change, I'm telling you though there's an issue with Map 8, it's as if the bit has a NOT applied to it.

Map 7 is my eco driving around map, I have "0 = Disable Closed Loop" set to "Off" and at cruise it perfectly maintains the AFR target of 0.5V on the o2 sensor pin (14.7 AFR typical, mines actually set to 15.6).

Map 8 is my eco idle / fallback map, I have "0 = Disable Closed Loop" set to "Enabled" and it maintains the AFR as above too.

If I set Map 8's "0 = Disable Closed Loop" to "Off", it starts hunting like we talked about in previous posts [1 (http://www.clubvr4.com/forum/showthread.php?60947-Switched-maps-testers-wanted&p=674758&viewfull=1#post674758)] [2 (http://www.clubvr4.com/forum/showthread.php?60947-Switched-maps-testers-wanted&p=674762&viewfull=1#post674762)]

[Kenneth]

Are you logging the map selection variable to confirm you are using map 8?

It works fine on mine when using map 8 and normal closed loop operation is on. It was set to off originally and I got the hunting then.

Another thing to keep in mind is that the method I have used to reference the selected map/values is the exact same way the OEM ECU code does it. The only difference is where the FIRST one in the list is kept. This means that if the ECU switches correctly between 2 maps or values, it will do so for all of them.

So unless there is a problem with ALL of the Closed loop switches, there is not going to be an issue with just one of them.

I will double check the ROM references later though, but I do think the problem is elsewhere.

[foxdie]

I did take a log of all of that but it doesn't seem to be playing back / graphing the map mut request :/

I'll do another one tomorrow lunchtime but I really don't think I'm hallucinating this :)

[BCX]

That's some complicated stuff, I'll take a look at that this weekend.

Incidentally, and I know this is slightly off topic here but I'm wondering if this may be possible. I noticed that the following outputs differ between the Evo 5/6 7202 ECUs and VR-4 7202 ECUs, is it possible to get these working too? The code could possibly be taken from an Evo 6 ROM fairly easily?

What I'm thinking is it'd be pretty freaking awesome if we could have a pin that goes live to turn, say an intercooler spray with a particular map or something else :)

Pin 6 = Secondary Air System solenoid on Evo's
Pin 20 = Radiator Fan High Speed
Pin 33 = Alternator Enable (Evo 5 only)
Pin 34 = AirCon Fan High Speed (Evo 6 only)
Pin 39 = Fuel Pump High Speed (VR-4 has a separate pin for this)
Pin 40 = Alarm Warning Light (Evo 5 only, maybe not present at all given conflicting information)

I've mapped the pins of the H8 at a processor level with their respective input/output on the ECU pinout.

I'm in progress of testing this and making sure i've got my info straight before I release the info. Stay Tuned...

[Kenneth]

Good work. :thumbsup:



I've mapped the pins of the H8 at a processor level with their respective input/output on the ECU pinout.

I'm in progress of testing this and making sure i've got my info straight before I release the info. Stay Tuned...

[foxdie]

I did a quick log this morning after parking up at work, and okay, maybe I am tripping balls (http://www.youtube.com/watch?v=_yjOAj0RiNw) here;

50225

That's showing Map 8 (eco idle), followed by switching to Map 6 (sport idle) halfway through, with "0 = Disable Closed Loop" set to "Enabled" on both maps. It's hunting slightly but generally maintains 15.2~15.8 AFR (target is 15.6 on the Innovate WB controller), before when Map 8 was set to "Off" this would sweep between 13~19 AFR (that's expected behaviour).

Whats weird is I hit 15.6 AFR at cruise perfectly (15.4~15.8 AFR) on Map 7 (eco driving) and Map 3 (sport driving), those both have "0 = Disable Closed Loop" set to "Off". Before I set Map 7 to "Off", it would hunt (13~17 AFR) but I have no log of this. I'll try and get a log at lunchtime as originally planned to prove I'm not (totally) insane in the membrane :)


I've mapped the pins of the H8 at a processor level with their respective input/output on the ECU pinout.

I'm in progress of testing this and making sure i've got my info straight before I release the info. Stay Tuned...

Looking forward to this! I've got 3 x 7202 ECUs (1 is from a N/A V6) and a H8/539 ECU if you need me to help verify, can take high resolution pics of the top / bottoms of the boards if it helps?

[foxdie]

Well I knew I wasn't tripping balls, Ken, there's definitely something screwy going on ;)

Firstly, this is how Map 3 and 7 are set up (Map 3 on top);

50240

The below graph was done testing Map 3 and Map 7 at a steady 40 MPH on a flat road, it tails off at the end because there was a downhill stretch at the end of the road I was testing on.

50239 50241

As you can see, it's sticking very close to my AFR target of 15.6:1 and is in Closed Loop, yet the bit is set to disable Closed Loop for these maps, if I set it to "Enabled" it'll hunt like I mentioned before (13~19:1 AFR) :)

[Kenneth]

I am not entirely sure what you are getting at.

Your first screen shot shows you have normal closed loop operation enabled for maps 7 and 3. This being the case, you should get normal closed loop operation.

By definition, closed loop hunts for the correct AFR. How much it hunts depends on your O2 sensor. Open loop on the other hand should give a fairly steady AFR (given steady load/throttle etc) as it uses the value from the table lookup.

[Shtiv]

Jason, My map 5 issue is that it seems to overly react to bdel and ignore the limits to WGDC, or something like that, really haven't had time to go through it and Kenneth is aware so I'm sure he'll work out what is wrong when he gets to it. Actually for what i want it to do it works great the way it is ;)

[foxdie]

It's okay guys, I tested this against a stock ROM today and it too hunts for the AFR, sorry Ken :)

50273

[veegeeta]

would like to give your mapps a try in australia any chance of a look?

[veegeeta]

would like to give this a try for you email me shanerost@hotmail.com

[Kenneth]

Hi Shane.

Thanks for the offer, unfortunately I am not wanting testers at present. I am waiting for some results from previous testers which will hopefully give the all clear to fully release. It shouldn't be far away now.

[veegeeta]

gday got any fuel mapes am new to tunnig and am just after a good tune to flash to car am willing to pay for a good one

[foxdie]

Shane, it doesn't work that way bud, each car is unique and needs its own unique map.

What I recommend you do is post a new thread in the Australian Parts For Sale / Wanted (http://www.clubvr4.com/forum/forumdisplay.php?260-AU-Parts-for-Sale-Wanted) part of our forums requesting someone map your car :thumbsup:

[zedy1]

I have original FG Tech and i will have a peep see if i can read flash. Also lot's of ecu's in stock.

[kennyt123]

any of you guys got a mapped ecu for sale that you can ship to north east uk cheers