Switched maps testers wanted

[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;

1. Edit the MUT table in the ROM, locate cell BD, enter the hex address 0xF645
2. Add a new logging element in EvoScan with the following values:
   1. Display: KS Mod Map
   2. LogReference: KSMODMAP
   3. RequestID: BD
   4. Eval: x+1
   5. Unit: Map
   6. ResponseBytes: 1
   7. GaugeMin: 1
   8. GaugeMax: 8
   9. ChartMin: 1
   10. ChartMax: 8
   11. ScalingFactor: 100

Logging the gear calc though was a bit more involving;

1. Edit the MUT table in the ROM, locate cell BE, enter the hex address 0xF640, locate cell BF, enter the hex address 0xF641
2. Add a new logging element in EvoScan with the following values:
   1. Display: KS Mod Gear
   2. LogReference: KSMODGEAR
   3. RequestID: BE
   4. Eval: x
   5. Unit: Gear
   6. ResponseBytes: 2
   7. GaugeMin: 0
   8. GaugeMax: 255
   9. ChartMin: 0
   10. ChartMax: 255
   11. 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

[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?

[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
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 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

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

[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