Adamw

When we first released G4X the math blocks were more simple and ran at 1000Hz. Their rate was reduced to 250Hz later when more complex functions were added and the character limit was increased. There were some oversights when that change was made - for example the documentation stated cnt increases by 1 every 1ms, but it was actually only updating by 1 every 4ms. So that has been updated - it still only updates every 4ms, but its count increases by 4 each update.

In G4+ we used to have a virtual aux condition that would look for the "hottest EGT", so you could set up your safety strategy to kick in if any of the TC's went above a set temperature. I dont see a clear way to do this in G4X. It is possibly just me overlooking something obvious though. I was hoping to bounce it of one of the smarter engineers but I didnt get time today. We will possibly need to add this function if there is not a good way to do this.

Can you give us a short log.

It may well have always done that, and now with a faster CAN lambda you just get to see more of it. I suspect you might need a little more accel hold and possible accel sensitivity and clamp. You cant change it, with analog widebands they need to limit the range to try to get acceptable accuracy and resolution. With CAN you dont have that limitation so the range doesnt need to be limited. For your cold start I would increase the CLL ECT lockout to say 50-60C so that closed loop is not working when its cold. If you attach your tune I can probably give some suggestions to solve that big oscillation you have shortly after start up.

Follow this guide. https://youtu.be/_P1LRANeO4A

Yeah that seems very odd. Whats the effective PW showing at idle?

Give us a short log of it cranking and a copy of your tune. Is it a blue plug ecu? Trigger offset is usually around -85 for most RB's.

What voltage would the boost pot have been set to in that log? Can you attach the aim log file.

Yes. AC request would be received as a CAN DI assuming it only needs off/on statuses, then you assign the AC Request input to the CAN DI. Basically anything you like can be sent out of the ecu.

No, our altezza plug-in ECU has a CAN to BEAN converter built in.

Unfortunately it wouldnt be so simple. There are two significant differences. The Honda ecu has highside drives fitted to aux 5 & 6 for the vtec and intake solenoid. The Evo needs aux 5&6 to be lowside drive for the idle stepper motor. The Evo needs a relatively complicated main relay control circuit so the ecu can stay alive for a while after ignition is turned off so it can park the stepper motor ready for the next start up. The Honda ecu doesnt have this circuit. For an ecu that could be shared between these two cars you would be better with a wire in ecu like the Storm with a basic adapter harness for both cars.

Do you have an ecu log? It would be beneficial to see what ignition timing and wastegate DC are doing around the problem areas. It looks like you have some overshoot coming on to boost in most places where you are close to WOT. I suspect it is possibly just those "90's" in your boost table being held until too close to target. Its only a 0.5bar spike isnt it - not 1.5bar? It looks like you are mixing MGP & MAP. Normal MAP is 2bar and the overshoot reaches 2.5bar. Still excessive, but not 250%...

The idle looks pretty smooth to me for most of that log. I dont see any hunting so I assume the problem just wasnt happening when this log was taken? I do have a couple of tune suggestions though that will improve idle control. The first one is the idle base position table is not even close. In the pic below where my yellow cursor is you can see RPM is sitting right on target, with the idle position at 31.9%. Yet there is a value of 47% in the base position table. So you can see just to the right of the cursor when the throttle is blipped, the idle position jumps to 47% (the commanded base position), this makes the RPM settle above target on the way back down and it takes a solid 30 seconds to slowly come back down to target. So two changes needed here: 1. base position should be 32% for this temp, likely the whole table is wrong, not just this one cell. 2. You need a lot more integral so that the closed loop works faster to bring the RPM to target as quick as possible. I dont have much experience with the MR2, but your integral gain is currently set to 0.1, I suspect you will be able to increase that to at least 0.4, possibly a lot more. Secondly, the idle ign is not doing much, the proportional is too low. It wont be fast enough to catch sudden load changes or stall events like this. Your proportional gain is currently 0.1, 1.0 is more typical. I would also increase idle ignition max clamp to 30deg as that will be much closer to MBT than the current 20. The other thing that looks odd in the log is after the throttle blips the lambda pegs at max lean for quite some time before it recovers. After the second blip it takes ~15seconds for the lambda to come back down to target. Yet the RPM, MAP & injector PW is stable the whole time (ie air flow and fuel fuel should be stable), so something is fishy there. It could be a wideband issue, fuel pressure issue, air leak? Since it still appears to be idling ok in that area I suspect maybe the wideband is most likely since it would unlikely keep running if the lambda really was 1.25

Attach your tune and a log.

You really need to set up ecu logging so you can confirm first if it is the MAP limit, then secondly if so, how high does it go. You can make your MAP limit table a 3D table with a timer on one axis if you wish to vary MAP limit over time at boost or whatever.

Yeah ok trigger looks ok now. Your most recent log suggests the engine should have everything it needs to run. Do your injectors click if you use the injector test function? Do you have a spark out of the coil if you use the ignition test function? Do you hear the fuel pump run at key on?

The hum or whine is normal. Set it to quiet throttle if it bothers you.

Correct. In G4+ the bulk of your idle throttle opening should be in the main target table, then the idle base position is mostly used to correct throttle position when the engine is cold. FYI this is different in G4X just in case your question does not relate to G4+.

Can you set the max clamp to 100% and try again.

Can you attach a copy of the map that was in the ecu when you done these logs.

What dash do you have? It might be easier to just swap the template in the dash? With a standard CAN message you can only send one frame per Channel/ID. So 0x600 would be set up as transmit user stream 1, 0x601 transmit user stream 2 etc. In your stream set up you need to change the frame ID position to none. This frame ID is only used for compound/mutliplexed messages where you sen a bunch of frames all on the same CAN ID. But otherwise the rest of your stream setup looks good.

Yes a multiplier of 62 would give you the same scaling as the ECU master example.

The pin labels on the expansion ports are correct, just the socket has the locking tab on the wrong side.

Your ignition table is set up with MGP on its load axis (Manifold Gauge Pressure), so -100kpa is total vacuum, 0Kpa is atmoshere, any positive value is boost. If your megasquirt table only started at zero kpa then that would likely be MAP rather than MGP. For ignition MGP Vs MAP on the load axis wont make a lot of difference to most users that dont drive over large altitude changes. MAP would be the more correct load reference for ignition as that is what affects ultimate cylinder pressure (knock). Some users (mostly americans) prefer to use MGP just so -ve numbers is vacuum and +ve is boost. MGP is good to use on the fuel table load axis as you get a more correct VE look up with altitude or baro changes. So the ignition table looks ok with a flat 15deg around the idle area. Be aware however when idle conditions are met the ignition timing will be controlled by the idle ignition function anyway - ignition table will not be in use. This is set up a bit slow in you map but I dont think it would cause hunting. Most other settings dont look too bad. It would be best to do a PC Log showing the issue, then we may be able to offer some direction.

Sweet, that will do a much better job. Do you still want me to help set up timed shift with the existing sensor or do you want to wait for the new sensor?