Adamw

I see this one is on the wish list already but it is a fair way down.  I will add a +1 to it.  Due to the lack of requests it probably wont happen anytime soon.

Use windows explorer, right click on the layout file and set attribute to "Read only"  PC Link then cant save the modifications and it will revert back to the unmolested state every time you close/reopen PC Link.

The hardware is just not in the ECU to allow much or any improvement over what we currently have.  It will certainly be high on the priorities for the next generation ECU but that is still some time away yet. 

All 5v and gnd out pins are internally connected so you are free to mix and match

Our LS2 trigger mode is for the GM "58X" pattern.  
For the earlier 24X engine you would use one of our LS1 trigger modes.

Hi Guys,
Things are way too busy here at the moment for me to give this proper attention but I will take a closer look sometime in the next couple of weeks when some of the other staff are back.

Hi Jared,
Unfortunately no real way to make both methods work together at this time.  Although without thinking about it too deeply you could possibly use the launch control function for "latched launch" only and then use a GP RPM limit table to give you some effect quite similar to the "single RPM launch mode".
As Simon says it is on the working list but so are a million other important features so I suspect it is still some time off yet.

Ok, I agree this is not elegant and you will still miss some features such as decay rate, but there are a few ways you can add some retard to your GP limit.  Depending on which ignition tables you have left you could possibly use the dual ign table (nicest option) or the 4 or 5d ign table, set the activation to either the same DI as activates the GP limit or use a virtual aux to activate it with some other conditions such as timers thrown in for extra complexity... 

The Obd2 will need to be on its own CAN bus.  CAN Lambda, dash2pro & Gaugeart will all be fine together on the same Bus and there will be no speed implications.

Hi Mapper,
This bug wouldnt affect the common multi-fuel setups.  It is only when the dual fuel table mode is set to "overlay table", in this case no matter what value is in the table, the pulsewidth drops to zero and stops the engine.  This mode is rarely used so we think it shouldnt effect too many users and for those that it does effect it will be very obvious.
For multi-fuel setups the dual fuel table mode is "interpolate between" and this works as expected.
We have this fixed in the next release but it is still a little way off at the moment.  

Hi Mapper,
This bug wouldnt affect the common multi-fuel setups.  It is only when the dual fuel table mode is set to "overlay table", in this case no matter what value is in the table, the pulsewidth drops to zero and stops the engine.  This mode is rarely used so we think it shouldnt effect too many users and for those that it does effect it will be very obvious.
For multi-fuel setups the dual fuel table mode is "interpolate between" and this works as expected.
We have this fixed in the next release but it is still a little way off at the moment.  

Note, most of your questions will be answered by reading the help file.  All this is well covered.

 
Earlier you said your wide band calibration was 0.5V = 8AFR.  That data sheet shows 0.5V = 8.5AFR.  
 
The log suggests you might have a wiring problem, Im not sure but this may be causing the analog fault codes.  See below the battery voltage has little dropouts down to zero, that suggests a bad connection somewhere.
 

 
Also I see you are one older firmware.  You should update to the latest firmware.  (read the help file to learn how to do this).
 

Actually, I just thought about this a bit deeper and I think I might be wrong here.  I think for odd fire wasted spark a cam sync will be necessary, possibly direct fire will work though.  I will have to try some tests with a scope connected to an ecu to confirm.  I might be able to do that on Monday.

Can you give us a bit more info.  I'm assuming this is an Arctic Cat, but is it the 800 or 1100?
As for the fault codes, please follow the instructions here and do a log of it idling or if it doesnt run yet just a log of it powered up doing nothing should give me enough info:  https://www.youtube.com/watch?v=_P1LRANeO4A
Post your map and log file here once you've done that.

I personally would have powered the lift pump relay from the main fuel pump relay then get rid of the >500RPM condition.  That way the lift pump will at least still "prime" for a few seconds to ensure there is some fuel in the surge tank.  I would have thought if you leave the car sitting for a couple of weeks the fuel will drain out of the surge tank and it will never start...

The main thing to keep in mind is the more samples that you have, the better the data will be.  So you can log at a high frequency for a short time or you can log at a lower frequency for a long time and end up with pretty similar data.  Usually higher frequency will allow you to capture more samples in some of the cells that you may not visit much under normal driving. 

My method would not take into account the multiplier or the clamp, but I would have thought since these are very simple math you could do that on the fly in your head or at worst with pen and paper? 
 
 
The only way I can think to keep the fuel pump running in normal mode (like the engine is running) is to make a fake trigger.  One method - You could temporarily set trigger mode to "multitooth", jumper a PWM aux out to trig 1. Set trigger 2 mode to none.  Set aux out to test PWM.  ECU should then see RPM...

Iecku, I just thought I would mention a little bit of info that many people miss.  These kits appear to use the Honeywell 1GT101 sensor, these sensors are much slower on the rising edge than the falling edge.  The datasheet quotes a 15µs rise time Vs 1µs for fall time.  So for at least trigger 1 (that controls the timing) it would be more correct to set the trigger edge to falling. Even though 15µs is only like 0.9 deg at 10000RPM, if you can get extra accuracy just by a simple setting change - then you might as well use it...

We dont have a separate timing map for the secondary injectors at the moment.
 
How about use an RC servo, like this type of thing: https://www.pololu.com/product/1057.  You would need to give it a separate power supply since most can only take 5V but a PWM aux out will control its position.  I've never used one but in theory it should work.  If you use a 100Hz PWM, then 10%DC will give you full anticlockwise, 15% will be centered, 20% will give you full clockwise. 

 

They used to call these a "knobs box", most ecu brands used to offer them but they went out of fashion about 20 years ago.   I do still find doing injector timing or ignition timing with them a little easier since you can do big changes quickly but for fuel mapping you just need to learn your hot keys...  Space bar jumps to the active cell.  Q to increase, A to decrease.  If you have a lambda connected then use quick tune manual mode and hit F10 - job done.
For those that dont know what I'm on about:

It is not a preconfigured input.  It is just a place for the settings that are specific to ethanol sensors (i.e normally DI's dont have fault settings etc).  So you still need to set up a DI just as you have shown (except dont forget to turn the pull-up on!), then you can make further tweaks in the "ethanol sensor" settings menu item if required to make it behave they way you want. 

I forgot to mention also you could probably use the same switch for both launch and flat shift - this might be something like a clutch switch or gear knob switch

Below is the pinout for the GTR expansion connectors.  You might need 2 x XS looms depending on how you want these functions to work.  For instance for Launch control, some users like to have this activated by a switch (a DI is needed), others may choose to activate it by existing conditions alone such as Vehicle speed (no extra DI needed).
Any switches should have one terminal connected to GND and the otherside connected to a DI - notice the expansion connectors only have 2 x DI's in each connector so that's why I say you might need 2 x XS loom.
Your wideband analog output would connect to GND and any of the "Volt" inputs.

LSU4.9 Tech info:  https://1drv.ms/b/s!AiYbYlZQuRHPixMg31pUx3HxmQI2
 
You are correct in that the CJ125/135 chipsets dont control the heating but Bosch does give guidelines for how that should be done to achieve the quoted sensor performance and life.  Unfortunately many aftermarket manufacturers seem to ignore those guidelines.  As Steve has pointed out here also many of the standalone controllers dont have any way to know when the engine is running so they cant do the recommended "reduced heating during water condensation phase".
In my experience though the CJ125/135 based controllers that followed the recommended implementation usually give good reliable performance - some even without the reduced heating phase.  
Then there are some manufacturers that have thrown the Bosch book out the window and do some really unique sensor control/interface in an effort to get better response time but they often consequently get very poor life too.  Inno* is one such example that seems to fall into this category.   

GS101201 is the version with integrated metripack connector, GS101202 is the pigtailed version (seems a little harder to find).