Adamw

Ok, from that screen shot I would say realdash may have added some extra check on the VID of the usb/serial device so it is not happy with the vipec ID. It certainly wasnt fussy when I tested the original beta version for them a few years back and the current windows version doesnt do that. I will have to dig out my old andriod and do some testing when I get a minute. In the meantime you can try downloading one of the older versions via an apk site. There is a link to old versions somewhere a couple of pages back in this thread.

Please keep it civil guys, I believe cj.surr's concerns are valid, especially when some of the complexities he has stumbled upon are not well documented. cj.surr, I believe the reason it is done the way it is with gear cut taking priority is because with a progressive randomised cut strategy you can only have one limiter active at a time. The sequencing of the randomisation of the cut pattern has to be scheduled several cycles in advance and is hugely complex so you cant just tell it to to monitor all possible limit conditions and pick whichever one needs the highest % cut. Gear cut needs almost the highest priority as in some forms of racing where there are boost or RPM restrictions many competitors run nearly the whole race just touching the first few percent of these limits - since gear cut usually requires a much higher cut level (typically 90%), it has to be able to interrupt the active MAP or RPM limits to work properly in these conditions. I believe most ECUs that have a progressive randomised cut strategy has this same limitation and has to prioritise the different limiters with some type of hierarchy. In the latest 5.6.7 firmware there were a couple of extra safety over-rides added (one is the fuel hard cut Simon mentioned), that are constantly monitored and take priority over everything else. Im not sure if there is a reason why an ignition hard limit couldnt also be added to this list of high priority over-rides but there may be processing limitations or something else I dont know of - it is something that Simon will have to discuss with engineering. Be aware though, it is no quick fix, the limiter strategies are hugely complex and deeply interwoven all throughout the firmware code so the engineers are very cautious when it comes to changing any of it as there is a high risk of creating new bugs - and as you have found it is very difficult to test the interaction of every combination of limiters and all events around them. I personally still have my doubts that over boost would cause a rod to fail unless the torque bent it enough that the piston seized but I have never seen that happen with an aftermarket rod (certainly can happen with some poorly designed and low yield strength OEM rods). Compressive loads on a conrod are typically less than half the tensile load, so they nearly always fail in tension. The boost pressure doesnot effect the tensile load. As I said earlier I would be interested in seeing photos of some of the failed parts when you have it pulled down - not to say "I told you so", more for my general interest and to get you some closure. BTW, I am a materials scientist by trade and have worked 25 odd years as a metallurgist - so with my interest in automotive engineering I have a fair bit of experience with engine component failure analysis under my belt.

36-2 is no drama. As for "quick start" I suspect not. I assume this is some other brands terminology for a wasted spark start up - Link cant do that with the generic missing tooth type triggermodes - only some specific OEM triggermodes have this functionality.

Yes any CAN port and channel is fine. Note there are instructions in the help file how to set up the ECU master CAN. G4+ ECU Tuning Functions > CAN > Device Specific CAN Information>ECUMaster 8Ch EGT to CAN. The LTC dash set up instructions are on the same page. DI9 & DI10 will need to be set to off for CAN 2 to be available. You can load the GTR map into your Fury. The Fury features will added into the map once it is loaded into a live ECU. One thing to be aware of is you are going to have to build an external circuit to generate the TPS signal for the Attessa ECU, the GTR plug-in ECU has this circuit built in but a wire in ECU wont. I will post a bit more detail about that when I have more time.

And the wideband isnt working because you have it turned off.

If the widest slot is not at 24deg by default then you will need to turn on the eccs sync to allow you to change it, then turn eccs sync off again after making the change.

Do you have realistic RPM showing in the software when cranking (~200RPM)? A couple of things to fix: Trigger offset looks wrong, normally around 200deg on this engine, if you havent already checked with a timing light, set it to 200 and check with timing light. E-throttle target table is all zeros. Put something like 4% in the top row and interpolate to 100% in the bottom row as a starting point. Idle ign table is messed up. I suggest you just turn this off for now and fix it once you have it running. IAT sensor is not working. Fix it or turn it off if it doesnt have one. Otherwise the rest of it looks like it is close enough to get it to run. If it doesnt run once the above are fixed then do a short log of it cranking and attach it here.

The 16 heated too long is often caused by the power supply, but the other 2 errors are a bit odd and I havent seen them before, I think I would suspect the sensor in this case. Make sure you get a replacement from a reputable seller, not ebay or amazon, there are many fakes out there now.

Yes, it can drive saturated 4 port injectors in sequential instead of DI injectors.

What does it say in the ECU status tab of the runtimes screen for Lambda 1 status and lambda 1 error?

Seems to work ok for me. Did you powercycle the ECU after having the iVTS connected? Here is me testing it on a vipec just now: https://1drv.ms/v/s!AiYbYlZQuRHPqxc73n7Vk2cV3beG?e=NgmTrC

What/where does it say not supported? Your ECU is effectively a G4+ so it will work the same as most here.

So you have an i series Vipec? It will work out of the box. If you have a v series then it will still work - the only proviso is you will need to be on firmware 4.9.9 or later

Connect to any analog input.

I dont have much info in my files and I believe the AC800 ecu was completely unique hardware designed specifically for that vehicle so a lot of my Vipec general knowledge doesnot cross over. However, I would start by looking at the runtimes screen (F12) Auxilary tab and you will see Power valve position on the right hand side. I suspect this may only be commanded position rather than actual position but Im not 100% sure on that. I do see in the schematics there is a powervalve position sensor connected to the ECU but I dont know if that can be viewed in the software or is just something that works in the background. The power valve motor is connected to pins 29 & 30 on the B connector, so you can check across those pins for voltage - I would expect the multimeter to show +ve voltage when moving in one directon and -ve voltage when moving the opposite way.

It is a problem with the trigger, it is clocking up multiple trigger errors. Did you set up the triggers to match the later engine? Have you run power to the cam sensors (i think they are hall effect in the EJ25 AVCS engine)? Can you attach a copy of your tune (.pcl file).

Yes, it will need the mod to output any CAN. I will PM you some instructions.

Im not sure sorry, it sounds plausible. Whats the serial?

Hi Ben, I will PM you some instructions. Edit - added later: Note you can also connect the dash via serial and it will work without the CAN mod, this is just a bit painful though as you cant have the laptop and dash connected at the same time - you have to unplug the dash when you want to tune.

That suggests the idle valve is not working or the base position table is not correct. If you put it in open loop made and adjust the idle base position does the idle speed change?

The CAN mod is free of charge to have done at Link HQ (NZ), but you will have to pay shipping both ways. A local dealer may do it for a small fee or I can give you instructions if you know someone who is experienced at working with surface mount electronics - it is quite a simple process, just removal of 2 or 3 small capacitors from memory. Someone like @Richard Hill at BHP might be able to help.

I usually leave the end cut at 100%, set the start cut to the lowest setting possible that doesnt cause RPM overshoot. Retard and decay are user preference but those are about where I expect.

Can you attach a log of it running. Im not convinced from your description that it could be caused by the sensor. It sounds more like one cylinder has a slight misfire or something which causes the CLL to correct too far. What happens if you change the lambda aim at idle up or down? Typically a failed sensor will still read reasonably accurate near stoich mixtures but will get slower to respond and less accurate as you move further away from stoich (or not work at all).

Only the Kurofune ECU has native programable analog outputs. You could in theory use a GP PWM but it would need some filtering and probably a pull-up and voltage divider but it would take some knowledge and/or trial and error to get it to work - I dont know if it would ever be accurate. You could use a CAN bus gauge such as this much easier: https://www.aemelectronics.com/products/gauges/digital-gauges/x-series/aemnet

Its not much of a log but it doesnt look to far off working now. A couple of suggestions: In the idle control settings, chjange the AP/TP lockout to 1%. Fix the ignition table and the idle ignition table. Remski's idle ign table above is what I would expect to typically see. For the ignition table I would expect to see numbers around 10deg in the area I have marked pink, and 30-40deg in the area I have marked green (with some blend in between these areas and the surounding cells).