jigga009

OK an update - I was able to solve this issue by putting the purge solenoid on a delay timer. 
Seems that purge solenoid activation can catch the closed loop fuel correction out briefly if a second purge event is triggered within close temporal succession to the end of the first purge event. More specifically, if the second purge event occurs while the ECU is still busy pulling fuel in response of the first purge event. 
So by putting the purge solenoid on a 3 second timer delay that starts when the conditions are met for the purge solenoid to be activated (timer starts counting when ECU determines that it is time to purge, and actually activates the purge solenoid 3s later), and resets at the end of the purge event, you now force the ECU to have a minimum delay of 3s between purge events, regardless of whether the purge conditions are met sooner. This allows the ECU a minimum of 3s after the solenoid closes to continue stabilizing fueling before a subsequent purge event can be triggered (at which time closed loop fueling starts pulling the appropriate amount of fuel again). 

I would start with an update rate around 1-2 at idle, ramping up to 10Hz at higher RPM.  Get the gain as high as you can without overshoot or oscillation.  Start with 1.0 right across, you will probably be able to go significantly higher than that but that should be a good place to start.  

Hey Just wanted to post up and share my evo 9 for anyone who is interested. Fully built by me to my custom spec. Engine is a true 2.1l at 2100.5cc. Not rounded up or down. Just installed a Link g4x plug and play ecu so I’m learning how to get everything set up properly so this vehicle runs as good as it should!  If anyone has any questions or interest in the car, parts, setup, or engine please feel free to ask. 

Ok, finally had a chance to implement your suggestions, and after some trial and error, it works!
Turns out the MXG is in fact quick enough to send the RPM and EMAP data to the Can Lambdas to keep them from turning on when the key is at the ON position. It is sending the RPM and EMAP data to the Can Lambdas, and they are all staying disabled while the engine is off. Thanks to this, I still have a few streams for sending data over to the MXG. 
 

I've never personally done this but I believe it is possible if you have enough spare CAN slots, I discussed this with engineering a while ago for someone else.  You will need 2 "user streams" to send out pressure of bank 1 & 2, then 5 user streams to receive the 5 lambdas.   And you will need 2 ID's for each lambda.  So I think if you put 2 lambdas on the bus with the dash and 3 on the other bus you should have just enough streams and ID's to do it all.  
The CAN lambdas apparently will receive exhaust pressure either globally on ID958 or individually on 958+index.  So in this case we wouldnt want to use the built in "Link CAN Lambda" stream as that broadcasts pressure on ID958 so all lambdas would use it.  
What we have to do is first program the lambdas to "lambda 2-6" (we dont want any programmed as lambda 1 ID as its index is 0 so it would need press on 958 which will mess up the others).  If we program them to be identified with Lambda 2-6 ID's then the exhaust pressure will be sent out on ID959-963. You would send the same pressure user stream to the 2 lambdas that work in the same manifold.  
We can still receive the lambda data into the ecu as channels "lambda 1-5" (even though they are programmed as lambda 2-6), so the number relates to cylinder numbers or whatever.  
Start by reprograming the lambdas to 2-6 and I can give you a hand with the CAN side if you need it.  

I would start by adding say 10-15% to the whole fuel table to get the lambda somewhere closer to target.  The idle valve is maxed out at 90% for the whole log so I suspect you will have to adjust the throttle stop so that the throttle blade is a little more open.  Ideally you want the idle valve somewhere around 20-50% when warm.  

I have a logic set up for my per cylinder widebands. My G4+ controls a relay that powers the per cylinder wideband controller on 25 sec after the engine is running from cold (Engine Run Time > 25s), and turns it on immediately when the car is fired up AND coolant is up to temp (i.e. RPM>500, ECT>60 deg C). 
I also have a Link Lambda in my downpipe also has a 15s delay built in to it, but the ECU controls the staging of that directly so as not to get any error codes from the ECU regarding unexpected function of the wideband. The delay is whatever Link builds in to them from the factory. Not so concerned about this one coming on sooner since it is located behind the turbo.
I got the rough logic a little over a couple of years ago reading through some patent documents that were filed by GM or Suzuki (can't recall anymore) that explained how exactly they were controlling their oxygen sensors for max durability and efficiency on their passenger cars.
It's more complicated than above as Adam rightly suggested (I doubt he remembers, but Adam helped me with implementing what we could of what the OEMS are doing based on the illustrations from the patent docs I was able to dig up), as they are playing with voltage over time to effect how quickly the sensors heat up, but there were some elements of what they were doing that could be duplicated by the ECU, albeit in a less granular manner.
 
 

Yes, mixture map can be used from road logs.  Set up a Transient filter Eng speed < 250rpm/sec and another with TP<5/sec will get rid of a lot of the inconsistent data. 
Here's a video I done for someone else earlier with some further info:  https://1drv.ms/v/s!AiYbYlZQuRHPszz5hTxJ8ec0MitL?e=2JbDVh

You could perform a visual test and know that it works for sure.
Remove the coil pack from the engine, attach a spark plug to it, ground the plug onto the engine (rest the plug threads on the intake manifold or somewhere on the block so that it can be grounded just as it would be if installed in the head), then run an "ignition test" through the ECU software, turning on one cylinder at a time. The ECU will then fire whatever cylinder you want repeatedly until you turn off the cylinder. When you turn on a cylinder, simply go over to the engine bay to visually confirm that it is firing.
 

Part of the problem is our exhaust stack is very short in length of the tubes (think P-51 Mustang Rolls Royce).
 

Attached is the stream 1 file to assign the AEM device to Lambda 1-4.  You can re-program the Link CAN lambda to lambda 5 in the "CAN devices" tab of the CAN setup.
AEM 4ch stream1 - Lam1-4 ID31.lcs

It is not possible to decode them all since they are sent as bit fields.  The stream below will give you the common errors for Lambda 1 using the CAN DIG inputs (you can view these on the runtimes screen).  Set it up with ID 431, extended format.
CAN DIG 1 will indicate "AFR1 Ready"
CAN DIG 2 will indicate "AFR 1 Heater open Error"
CAN DIG 3 will indicate "AFR 1 VM Error"
and so on down the list.
The LED's on the device give pretty much the same information so Im not sure how useful it is.

AEM Errors ID431.lcs

We see lots of wideband controllers here, the worst for sensor failure are AEM, Innovative seem to be better, there is a noticeable difference as you really don't see sensor failing that often on the LINK CAN Lambda, we put the sensor failures down 100% to the heating strategy not shocking the sensor and allowing time for residual water / condensation to be cleared.
The other thing is that the AEM sensor supplied with the kit does not appear to be bosch, but although you could argue that is the reason they fail, replacement genuine bosch dont seem to last that long either. That is the main reason we try and get people to buy the Link sensor and we always ask about the placement of their Lambda bung.
PLUS you get EGT with the Link CAN Lambda an invaluable device that has saved my customers $1000's in turbo rebuilds.

Many devices have configurable bit rate.  The Link CAN Lambda can do 100, 125, 250, 500k & 1M so it should work with nearly any other device.  The 14point7 one I believe will be configurable bit rate.  The AEM X-series is not configurable as it was originally only designed to work on their "AEMNet".  Emtron (HV Electronics) is configurable, Motec is configurable, Ecotrons is not.
 
I believe that is possibly bad wording to not give away his source. I believe they come from an OEM application, they have all the correct markings on them and none of the signs of the typical clones.  They have a longer cable on them than the common aftermarket LSU4.9.  I have installed probably 10 of his Spartan 1 & 2's over the last few years and have not had one fail or play up.
 
The Lambdatronic LT4 is their highend one, the retail is around $4000.  They have a more consumer level device, the LT2, for about $1000.  https://www.streamlineautomotive.com.au/lamdatronic-lt4-lambda-to-can-module
 
Really, it seems like you may be over thinking things.  Any of them mentioned in this post will do a fine job.  The Link one will give you a few more fail-safes in terms of CLL control if you intend to run CLL full time and possibly longer sensor life due to the more correct heating strategy.  The 14point7 one duplicates our CAN Lambda stream so that will have the same fail-safe functionality.   The AEM one is faster than all others I have used but will not disable CLL when there is a sensor error and there may be a possibility of shorter sensor life depending on who you believe.  I know a couple of professional tuners here and in Australia that use the Ecotrons ALM as their main tuning tool and rave about how good they are and I have never heard a bad thing about them so they seem good.  I know Innovate have a CAN bus one coming out soon (LC3) but I would avoid that at all costs based on experience with their previous products.  
 
 

I will give some comments.
The Link CAN Lambda was designed specifically to work with our ECU, it has bi-directional communication so not only is data received from the device but the ECU also sends data to it.  This allows the proper warm-up strategy to be applied during start up, EMAP compensation can be applied correctly for situations where there is back pressure and if a sensor is reporting an error condition the ecu can disable CLL or in the case of multiple sensors, ignore the failed one from "lambda average" calculations.  The stuff like temperature, heater voltage, etc are mostly only used for diagnostics. 
Most of the 3rd party devices will have no receive - they only transmit data so they dont know if the engine is running or how long it has been running for to apply the correct warm-up strategy (potentially shorter sensor life).  Many of the 3rd party devices will send some sort of error or status message but in many cases it is not in the format that our ecu needs it to be able to do stuff like disable CLL.  In some cases you will be able to log these errors but unlikely act upon them.
I have used a few of the X-series AEM's on budget installs and they have worked ok for me to date but I do hear/see some reports of short sensor life with them more often than others.  To get the extreme response speed they certainly dont use a Bosch chipset or control the sensor in the way Bosch designed it to be so sensor life is possibly a side effect that.  Some claim they are not using a genuine Bosch sensor either.
 
Yes, an ecu controlled relay is a good idea.  It still wont give the proper heat up strategy but it is better than nothing.  
 
No.  Free-air cal is not particularly useful in my opinion, it was something made famous by Innovate as they didnt use the Bosch fitted calibration resistor.  Air has about 21% O2, exhaust gas has none when less than 1 Lambda.  So it only calibrates on the lean side of the curve and even then it is like trying to calibrate your precision 1volt voltmeter using a 2000V source...
 
Ecotrons ones have a good reputation - I have never used one myself but only ever hear good comments about them.  If you are not in a big hurry I know 14point7 are releasing a CAN bus "Spartan 3" soon, I tested a prototype a while ago.  I use his analog ones for most of my budget installs and have very good success with them.
 
 
 

Another thing to consider if your using the Can (as i  found out the hard way )  is the data rate  for communication , its not often listed in the specs  but critical if your using more than 1 devise
AEM X series  is 500kb 
Link CAN Lambda is 1000
I have a mounted but unused AEM if you  need one

I don't see any problem with the set up.  Why is Aux 7 set to high polarity tho? if it works like that it would suggest there is a problem with the wiring.  polarity = high means it works inverted to normal, so the aux output is off to command the fuel pump to turn on?

you  can def activate more than 1 aux in test mode.  but the way you have it set up now, your aux 1 is sending out a ground when on, aux 7 is sending out 12v.

This is how i would wire it. Start with basic triggering before PWM pump so you know all 4 work. Sorry about the crap paint skills

For quite a while I've had an issue with an oscillating idle especially during the winter months with a built Subaru application. We first came across it on my V88 ViPec ECU, but could not do too much about it given that I was out of tables on the ECU to bring online certain features such as idle ignition control. Since moving to the G4+, I have been able to activate the Idle Ignition table, which seems to have helped things out especially on warmup from cold, but I'm finding that when up to temperature, the oscillation seems to return, and the ECU appears to be bouncing into parts of the ignition map (i.e. at 2500rpm) that it shouldn't really be doing, given that target idle is more like 1200rpm, which is contributing to the oscillation.  As is now, when sitting at traffic lights, other motorists could easily be forgiven for thinking that I was trying to instigate a race, given how it sounds as if I am constantly blipping the throttle.
This isn't much of an issue at all while the engine is warming up, but tends to become a lot more prevalent once at operating temps.
I have taken a log and map for your perusal. If any of our resident experts knows what I need to be adjusting, I would very much be grateful. 
Map 1.1.pclr
Map 1.1 Idle log - Log 2018-01-20 9;54;42 pm.llg

Thanks Adam, will do. I will set the idle ignition lockout back to the previous value which kept it off. I know the idle is not perfect yet, but compared to where it was before, it's a night and day difference so far. The map was ported over from my Vipec V88 where it was controlling the fans as they should.  It seems there are a few settings that get lost in the translation when making the upgrade. I will report back with logs and the updated map soon.
Thanks everyone for your contributions so far. I'm extremely grateful!

Ok thats starting to look better, the main issue now seems to be that you have very poor vacuum, do you have a leak, or is the MAP sensor reading incorrectly ?
 
 

The ecu is not entering idle control or idle ignition control because the base position table is commanding the valve open too far so the engine settles above the RPM lockout.
Change all the settings in red below to match this example.  It will likely still not work correctly but hopefully will be getting closer and we may get some more useful data from a log.  Do another log for us with these settings.

You are not getting into idle ignition control as your have it set for below 700rpm, change this to something like 1500 for now.
I would, turn off or unplug you ISCV and then set the idle screw on your throttle so it can idle.
Then set your idle ignition up, currently you have it set to enable below 700rpm, I would raise this to 1500rpm  then tweak the table, it is not uncommon to have zero degrees in the centre (0)  and then negative degrees towards the left hand side, but all cars are different so you will need to tweak this, once you can rev the engine and it falls back quickly to the centre (0) 
Then you can turn on your ISCV back on and set that up, but even with just idle ignition control it should be fairly stable.

Look at Ignition - Idle Ignition Control its the lockout there we are talking about.
You can add Idle ignition Control to your logging view to watch when this becomes active.