Adamw

If you want knock control I would strongly suggest stretching the budget to a Storm. An Atom plus an extra standalone knock device then the extra wiring and tuning of two devices will work out about the same or higher cost as a storm with built in knock control. The integrated knock control functions would be hard to match by any standalone system. For lambda my suggestion is to avoid innovate controllers (noisy analog, short sensor life) and preferably go for something that can communicate via CAN. Right now the AEM X-series would be my pick, although there has been a few hints on this forum that there might be something new from Link soon too.

The schematic above is not complete enough to say with certainty but from what you have shown I would expect it to work ok provided the "blackbox" is programmed correctly and it behaves like a mechanical relay (i.e its outputs do truly go open circuit when off and its inputs aren't even weakly tied together or to anything else (pull ups etc)). It seems like the black box it is a fairly new product so there may be some odd bugs/behaviour that is not documented... You havent shown the coils/ignition system in that schematic - how is this connected?

If you still have the same problem with all aux's disconected (f/pump, fans, boost solenoid etc) then it must be something else odd with your injector or ignition supply. I suggest you post a schematic of how you have wired the main supply relay and associated connections to ecu, inj & ign. Even just scribble on paper and post a photo. That will make it quicker & easier for tech support to work out the problem.

Note it's a holiday here in NZ today so link support won't reply today. Most likely it is some device wired to one of the aux outputs that is back feeding - are they all wired per the pclink help? You could try pulling all aux out pins out of the ecu connector to confirm that

Hi Nader, I havent much experience with downshift but have tuned a few cars with seq upshift GC. You might find this document helpful in how to tune the GC function from logging: http://www.motec.com.au/filedownload.php/CTN0004 Gear Change Ignition Cut.pdf?docid=3437 I have found if you have a roller dyno with a reasonable amount of inertia (heavy rollers or a road simulation mode) you can tune GC quite well on dyno then just fine tune at the track. If you had some logs that you can share I might be able to help

Since both cams have been ground with the same profile, assuming they have been timed up correctly then it will be perfectly fine and absolutely no different to a more correctly assembled head.

Also, you could use a frequency divider. Something like this would do it without breaking the bank and should still allow ABS to work (will need one for front and one for rear): https://shop.vems.hu/catalog/hall-p-162.html

Perhaps the definition of diameter will help?:

You know this function is already built in right? Look up help on "quick trim". Select the cell or range of cells in your fuel table that you want to adjust, then hit "M" key. This will bring up the quick trim dialog where you enter your measured or "logged" AFR, it then compares it to the target AFR (either taken from your target table or you can enter some different target) and adjusts the cell values to correct the difference.

I just took a quick look over purely your TC settings. RPM lockout, TP low lockout and Speed lockout don't appear to be sensible values to me. I have never set up TC with a G4+ before so I'm stabbing in the dark a little but I would suggest starting with values around 2000RPM, 30%TP & 30Kph and tune from there. Edit: sorry Scott, I see you must have posted as I was typing mine...

Here's how I would attack this; I would set Trig 2 to "none". Set Fuel mode to "multipoint group". Set Ign mode to "wasted". Then at least that narrows down your diagnostics to only one of the triggers. If you then still don't see RPM, then try swapping polarity on the VR sensor. If it still wont register RPM after these steps then you are probably going to have to get a scope on the crank trigger to see why it doesn't like it. PS. also check ECU hold power is not active.

I believe Evo 6 & later should be 13KHz narrow. Right now you have your ECU looking at 6KHz, from a sensor that only ouputs around 13KHz.

Skiza, I have a couple of cheaper devices you might be interested in. I have an old "The Knock Box" dual channel system. It's probably 15years old or more but it is still a very good device. I bought it direct from the manufacturer about 10 years ago as an ex-demo and they told me at that time that their current one still has all the same internals, just a different enclosure and connectors. This is still very good and my go-to tool but I want to upgrade to something that has an analog output that I can play with on my dyno. They don't have adjustable filters etc like some more modern stuff but I have never had any issue clearly detecting knock with it. I would want about 350NZD for this one with the aviation headphones, two knock sensors etc. New they are 900AUD. I also have the first gen Link Knockblock - again dual channel and it has adjustable frequency filters. It came in a box of misc dyno parts I bought years ago, it appears unused but I have never tried it to tell you how good it is at detecting knock. 100NZD for this one. It has two knock sensors but no head phones included (has 3.5mm audio jack from memory). I have used a Phormula before (note sure which model but the audio one) and I didn't find it much good. Certainly not as clear as my old knock box that I was used to anyhow, it didn't seem to have much, if any filtering. PM me if you want to know more.

Oh yeah, reading it again you are probably right. You are obviously a better mind reader than me...

Since a 12 injector ecu may never be a big enough mover to justify a new hardware platform, another option might be firmware/software based solution that allows 2 ecus to be linked together in a master/slave configuration. 2 x Storms linked together would be a relatively cost effective option for those that need 16cyl sequential?

I'm curious to hear what the logic is behind this request? I only have involvement with a couple of high powered methanol drag cars so don't have a large pool of experience to draw from but why would you expect a methanol fuel system to be any less reliable than a petrol system? Maybe the mechanical pump? If that is the case why not just use differential fuel pressure as a GP limit? Fuel flow sensors are relatively expensive and I think it is a variable that would be pretty difficult to nail down tight enough to make it useful as an effective safety. i.e, functions like RPM limit, gear cut, warm up corrections etc are all going to throw many more dimensions into the equation on what you need to consider to arrive at expected fuel flow. I would have thought Lambda and dif fuel pressure would have been a better way to monitor the fuel system (although in my experience Lambda based safetys aren't particularly useful either it would be more consistent than fuel flow).

I suspect you are 360° out. Try adding 360 to your trigger offset.

I think the "stepper motor type" setting is meant to hide when an aux is assigned as ISC solenoid so maybe you have found a small bug. It seems to hide ok for me. In any case I think you can just ignore that setting and everything will still work fine.

Not sure how you missed the wiring: Set your aux output to ISC solenoid and select a suitable frequency. Most of the settings under Idle speed control apply to both stepper or solenoid types.

Sounds like ECU hold power or maybe the anti-theft function. Check no digital inputs are assigned to anitheft and read help about ecu hold power function so you can make sure that is set up right. Edit: Actually just noticed in your screen shots above ECU hold power is active so that your problem.

If your trigger systems uses a vr sensor I would say most likey your vr sensor is wired back-to-front.

I'm not sure if Dave is hinting that something similar to what I am suggesting is coming but at present most "external loggers" that are available cost nearly as much as the ecu itself (or more) and then you must use some 3rd party logging software. What I'm talking about a very low cost external logger who's log files open natively in the PC Link application. You then have something that is accessible to most users and you can continue to use the PC link tuning functionality such as the mixture map etc just like it was an "internal log". I'm sure something like this would even be a big bonus to your Atom customers.

Another ECU brand that I sometimes use allows you to use a $USD59 serial recorder for increased logging: https://www.keelog.com/serial_recorder/. I think some of the link data streams have about 70 channels so that would certainly be much better than the present 25, there may even be room in that datastream to squeeze in more channels... I don't see why Link couldn't implement something like this reasonably easily? It would only need a small change to the logging part of the software to allow reading/conversion of the raw serial log.

I agree with you then warmup, this can't be blamed on "wiring" when all three are standalone devices with "integrated" displays - there is no way wiring can influence any of these displayed readings. Since it does appear to be more of an offset type error rather than a multiplier error then I still think it would be worthwhile doing the inert gas test I mentioned earlier as that at least confirms the "zero" point. So you now have an interesting situation - which one do you trust?? After my personal experiences with innovate over the years I would tend to trust the fury more, but that's just my gut feeling...

I maybe stating the obvious, but have you checked all devices are set to convert to AFR using the same stoichiometric ratio (14.7)? I think the AEM might not be adjustable but G4 and LM2 certainly are. It might be a good idea to set all to display lambda units to eliminate that possibility. If you have nitrogen or argon (welding gas) handy you can also use that to test all devices read same at lambda = 1. Most devices use 14.7 by default but there are some exceptions that I've come across such as the NGK afx for instance uses 14.56. I have heard reports that the AEM reads a little rich on the rich side of stoich but have never had a known reference to test against.