Davidv

Okay so there are a few stages to setting it up.
 
 
1. Wiring
Run one wire to the knock1 or knock2 wire on the link loom, and one to sensor earth, polarity unimportant. must must must must use shielded wire. The knock sensor outputs a very low voltage signal that's prone to interference.
2. Initial settings
Since you are using the 'wideband' knock sensor and an engine with an ~86mm bore has a knock frequency in the ~6khz range select your Freq Channel as 4-10khz Wide Band.
Set Ignition Retard limit to 0 degrees.
Set the RPM high and low lockouts however you like. (500rpm likely not ideal for the low setting)

 

3. Cylinder balancing
Your knock sensor is mounted closer to one cylinder than the others. It picks up vibrations, so the vibrations from that one cylinder will give a stronger signal than the others.
So what you need to do, is hold the motor at say 4000rpm (no load) and check the signal strength of each cylinder.
You can check the signal strength by pressing F12 to get to the runtime values screen and looking at these numbers, knock level cyl 1/2/34

 
 
See how in that example above, the numbers are 235 / 160 / 255 /145. You need to get these numbers as balanced / equal as possible.

You can adjust the values up or down by tweaking the numbers up and down in Knock control > Cyl setup > Cyl 1/2/34 knk level gain
 

 
 
Best to start with a value of 1 for the cylinder that's closest to the knock sensor, and increase the other values to suit. If one of the values reaches '2' (maximum) you can reduce some of the other numbers to less than 1.
4. Non knock noise levels
Since the knock sensor picks up vibrations, there are of course vibrations happening even when there's no knock. As RPM increases, the amount of 'natural' background noise increases too.
The ECU can tell that knock is happening, because there's an unexpected large spike in the 'noise' from the motor around the time of the iginition event. Soooo, you need to find out what the background noise level is for your engine.
According to the manual, a 2 row table with full throttle and 0 throttle is sufficient but this is up to you and how long you want to spend on it haha.
So head to Knock control > Knock target, right click on the table and select Axis setup to define your table similar to this (if you want)
 

 
Then you need to run a datalog through the rpm range at full throttle to see what the values are for this table. (and coast back down off throttle for the zero TP target, although I'm guessing not much knock happens at 0% throttle)
Open the datalog and bring up a screen to show engine rpm and the knock level global.
Knock level global has a maximum value of '1000'. If you find that you are hitting 1000, you need to reduce the Gain Channel number on the main knock sensing setup page to something a bit lower and try again. Remember that the '1000' has to be the maximum even including allowance for knock which is much stronger signal than the background noise so you need to allow headroom for that too.
 

 
Once you've established these background noise levels for the motor in your table, increase all of the numbers in the table by 20% to give it a bit of a margin against picking up normal engine noise as knock.
At this point, because you've set the maximum ignition retard to 0 degrees in your first step, the ECU isnt taking any action against knock.
Now that you've got everything setup though (unless I've missed a step here, haha) you can turn the knock sensing on by setting an ignition retard limit here, to say 3 degrees or 5 degrees or whatever you want:

Then as per reccomendations from the manual, it's best to test that knock sensing is working under a scenario that minimises risk of damage to your engine.
So you could drive along at low load / low rpm and induce knock by creeping the timing forward until it knocks and you can see from the runtime values table (F12) that it's working.
From here, it should all be working awesomely. (No responsibility taken for blown up motor though! This is just what has worked for me)

Hopefully it all makes sense though
Where are you based / what is the car used for? 
Keen to hear how you get on.

Hi guys,

We've done a wee release to fix a few of the pressing firmware issues.
PCLink hasn't changed so the release notes below will be for the previous release.
 
As always, here's how to update your firmware the best way:
 Post here if you find any issues.

You can only download one log file, but are you aware of the option to overlay a previous log against the one you're looking at? You can then align them as needed so you could look at both engines at once.

You open your first log, then open the 2nd. 
Then go to log file manager and put a tick in the box of the first log. 
Then it will show both. You can hold down mouse button on the time scale at the bottom to align the logs.

Then you could align the "splits" from when engines get turned off/on in order to check the results from each race. 


 

You can only download one log file, but are you aware of the option to overlay a previous log against the one you're looking at? You can then align them as needed so you could look at both engines at once.

You open your first log, then open the 2nd. 
Then go to log file manager and put a tick in the box of the first log. 
Then it will show both. You can hold down mouse button on the time scale at the bottom to align the logs.

Then you could align the "splits" from when engines get turned off/on in order to check the results from each race. 


 

Sounds like you're overcomplicating it TBH.

Also you dont want it turning on *just* with throttle position as you want to move the cam through the rev range. 
You'll want it to turn on at WOT at some point in rev range (probably 3k onwards) then turn back off again somewhere around peak torque (so probably off again 6-7k)

You can test with your wideband to see which cam setting is best through the rev range. 
So set no advance, do some runs to stabilise your AFR. 
Then turn on the VVT through the rev range, the areas where it now runs leaner (meaning more air is now entering engine) are where you'll want to have VVT turned on. Any areas where it runs richer, you want VVT turned off. (Note: This only applies to full throttle)

Once you have best cam switching rpms set, this happens predictably and consistently. 
So you just need your fuel and ignition maps to represent the VE of which cam position you have at that rpm and load combo. Rathr than having two seperate maps or whatever.

I would leave coolant temp completely out of the equation, it's likely only for emissions reasons that it would avoid introducing more overlap at low ECT. But I would wager that you're not planning on thrashing your car when it's cold anyway. Closed loop lambda correction can fix up the AFRs if you did want to turn VVT off for cold engine.

To visualise the changes that VVT makes, here is an example using airflow meter to datalog my VVTI engine with various cam angles. 

Imagine that in your instance you will only have two possible lines which are 12 and 40.

Peak torque happens on my engine at 6000-6500ish so you can see how pulling cam timing back at this point is beneficial for power past that point.

Hey people, 
Just thought I'd post up a quick note about something I did recently that worked out well.

I was wanting to optimise ignition timing for cruise, so using some switches on my dash to trigger a combination of datalogging, 4D ignition, 5D ignition and the 2nd ignition table set to overlay mode.

With the idea that I could add or remove timing from the main table in varying amounts without having to stop the car, and datalog the whole lot easily.

Like so: 



Since you can turn on more than one ignition trim table at once, using those three you can get a combination of timing settings which I then marked on the switches. 

So +1 degree, + 3 degrees, +5 degrees, etc. 
I completed a run on a particular stretch of motorway that has lots of ups and downs, with cruise control turned on at a speed that's at 3250rpm in 6th gear.
Then flicked the first switch, did it again.
Flicked second switch, did it again, and so on. 

When home looking through the data, bringing up a time plot with instant fuel consumption and throttle angle it was very easy to see which timing gave best economy. 


However a secondary method of checking fuel consumption overall is to create a "statistics" page and bring up wheel speed and instant fuel consumption, and look at the mean values:


Then from here I've made a quick excel sheet that converts it to Litres per 100km:



Then from here, collated the results from each run.


So based on this it's pretty clear that an additional 9 deg advance made the engine pretty happy on those particular cells, so updated my ignition table and readjusted some of the surrounding cells to more sensible values too.

It was a fairly time consuming exercise but it's amazing to see how much fuel I have been throwing down the toilet just based on under advanced ignition. 
It was also interesting to see that at 100kpa my car only has 14 deg ignition at that rpm, but then by 70kpa it's wanting 33. (The goal AFR changes though, to be fair... 15.2:1 goal AFR for cruising)

Since changing the timing the car is a lot quieter too! 
I am guessing because when you dont have enough timing, the flame front is still expanding when the exhaust valves open. So instead of having energy push the piston down, it's coming out the exhaust as noise and heat. 

Hey people, 
Just thought I'd post up a quick note about something I did recently that worked out well.

I was wanting to optimise ignition timing for cruise, so using some switches on my dash to trigger a combination of datalogging, 4D ignition, 5D ignition and the 2nd ignition table set to overlay mode.

With the idea that I could add or remove timing from the main table in varying amounts without having to stop the car, and datalog the whole lot easily.

Like so: 



Since you can turn on more than one ignition trim table at once, using those three you can get a combination of timing settings which I then marked on the switches. 

So +1 degree, + 3 degrees, +5 degrees, etc. 
I completed a run on a particular stretch of motorway that has lots of ups and downs, with cruise control turned on at a speed that's at 3250rpm in 6th gear.
Then flicked the first switch, did it again.
Flicked second switch, did it again, and so on. 

When home looking through the data, bringing up a time plot with instant fuel consumption and throttle angle it was very easy to see which timing gave best economy. 


However a secondary method of checking fuel consumption overall is to create a "statistics" page and bring up wheel speed and instant fuel consumption, and look at the mean values:


Then from here I've made a quick excel sheet that converts it to Litres per 100km:



Then from here, collated the results from each run.


So based on this it's pretty clear that an additional 9 deg advance made the engine pretty happy on those particular cells, so updated my ignition table and readjusted some of the surrounding cells to more sensible values too.

It was a fairly time consuming exercise but it's amazing to see how much fuel I have been throwing down the toilet just based on under advanced ignition. 
It was also interesting to see that at 100kpa my car only has 14 deg ignition at that rpm, but then by 70kpa it's wanting 33. (The goal AFR changes though, to be fair... 15.2:1 goal AFR for cruising)

Since changing the timing the car is a lot quieter too! 
I am guessing because when you dont have enough timing, the flame front is still expanding when the exhaust valves open. So instead of having energy push the piston down, it's coming out the exhaust as noise and heat. 

Hey there, 
I ran some tests on a VVTI motor by connecting up a MAF sensor, and then datalogging the output at varying cam advance angles. As per below. 
So it should be fairly easy to see where it's adding airflow (power potential!) without a dyno by looking where you need to add/remove fuel to reach goal AFRs at differening cam angles.

(Then head to dyno to optimise ignition timing etc) 

 

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:

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.   

Yes with internal Lambda or our lambda CAN device there is a built in start up delay that times out after RPM is detected.  I couldnt tell you what the time period is off the top of my head however.
Yes your assumption about "goal temperature" is correct but in my experience I have never seen the need to have any further controls or influences on the heater setpoint.  I have ETAS controllers on my dyno that display sensor temp so I do regularly get to observe the EGT influence.  
For the LSU4.9 the normal control temp is 780°C, but the sensor is rated for continuous use with exhaust gas temp up to 930°C with up to 250hrs accumulated at 1030°C, so its going to need some fairly serious external heat influence to achieve that.  I would probably be more worried about my molten pistons than my O2 sensor by that point....

Hi David,
Can you elaborate more on this statement.  I just tried myself on the test bench and fuel cut on the secondaries seems to work as expected.  

I have had confirmation from Engineering this morning that this was an oversight and we will fix it.  Hopefully for the next release.
 
Hi DavidV,
I see most of your suggestions above are already on our request list.  They are relatively low priority for now though and not being worked on yet. 

AEM just got one out in the $300 dollars price range... is calle Vehicle Dynamics module PN: 30-2203
3 Axis Accelerometer 
3 Axis Gyroscope 
5Hz GPS/Glonaass
Can 2.0 Output
The good thing about this is: AEM published its AEMnet CAN protocol, The VDM may work with 3rd party programmable engine management system and data loggers....  
 

Hi Anthony,
sorry but I am a little confused with what you are asking here.
So you have a G4+ THUNDER ECU, you have the KNOCK SENSORS terminated but you have the KNOCK CONTROL turned OFF.
You wish to know if you can log these two parameters outputs correct.
You can select the 2 knock sensors to be logged but you will not get any data from them as they are TURNED OFF.
To log the KNOCK sensors they must be turned on and setup.
If you do not want the knock sensor to influence the tune just make sure that the KNOCK tables are set to 0.
That way you can log the knock events and have no influence on the tune.
Hope this helps.
Regards
Dave.

Installed new PClink, now plugging into ECU it says that my ECU needs an unlock code.
Thoughts? Was working fine yesterday on previous version, have restarted ECU and laptop.

Using a red G4+ xtreme.
Ahhh  sorted it. Had to factory reset the ECU then load new firmware on it,then my basemap back on it.

Post removed to avoid confusion.

+1 to this, more virtual aux would be great, but if there were more than 3 conditions available then you wouldnt need to stack them together.

Example... I'm wanting to setup a warning light that is triggered by different conditions.
So for example, if rpm is xyz and oil pressure is below abc, then flash the light.
But then also trigger the light for other functions like maybe excessive coolant temp / oil temp, etc etc.

+1 for HPA. 

 

The mixture will be richest when the engine is burning the most fuel. As the injector timing is being adjusted (and not the volume of fuel) when the reading is richest the engine is burning the most fuel, and not wasting it by passing it through unburnt.
Scott

Did a compression test once it had warmed up, 
ResulResults were good so was hapoy with that! 
Cyl 1- 180psi
Cyl 2- 180psi
Cyl 3 -185psi
Cyl 4 -182 psi
The old plugs had been in for around 3 years thinking about it, done 30000kms on them (5 track days!)and had brown rings above the threaded part on the porcelain almost like compression lekage etc, fitted new plugs so will see how that goes  dunno why i overlooked those...
Brendon 

I will add a little more info here since I have quite a bit of experience in this strategy.
I agree with ECU settings as per Scott's suggestions, but I would say nearly always it would be worth while to have a "MAP sensor" connected also.  In this case however you don't connect the MAP sensor to manifold, you connect it to the airbox (your FPR reference should also be tee'd to this same measurement point).  The ecu and FPR will then keep fuelling more consistent when the airbox is subjected to aerodynamic effects.  If airbox and general intake design is good I often see 4-10Kpa positive pressure (ie you will need 4-10% more fuel) on high speed sections so it can be a significant effect.

This is a pretty complex addition which ultimately wont tell you the actual power of your car.
Virtual dyno is interesting but back to back runs in my car on the same flat piece of road on the same day in the same gear (Down meremere drag strip) provide quite different results.
As in, even the shape of the power curve looked different between runs, as well as varying by say 5-10% power. Even with the smoothing set aggressively.
Virtual dyno is very complex as it takes into account tyre size, diff/gear ratios, coefficient of drag, vehicle weight, driver weight, etc... It's a lot of things to add to PClink for what is not going to be an accurate output.

I think there's merit in keeping the integrity of the information in PClink, as in, it reports IAT and that's what IAT is.

Rather than stating that it's possible to calculate power when it's really a bit wishy washy how it does it.

Just an update on this...

Recently I've found that closed loop feedback from the wideband sensor hasnt been working, I saw that there was potentially a firmware issue so presumed that was the cause.
Updated to next firmware, but still the same issue. Hmmm.
I check the runtime values and find that the wideband is disabled because launch control is armed. (weird?)
I find out that part of the launch control setup (I havent used this in 6 months) was to be partially activiated by Virtual Aux 2 which I've since reused for something else as I assumed it was unused. Hence launch control armed, hence wideband not working.
I never thought to look under the launch control menu because I thought from memory launch control was only activated by a DI.
If under the menu of virtual aux 2 though, it told me that it currently triggers the launch control condition. I would have known straight away to disable it. (or use a different virtual aux)
Currently the only way for me to find out if virtual aux 2 is used by something is to scour through every single menu.
Maybe each DI / cal table etc could have something like this?

Having the "links" between DIs etc would be an extra safety net to help prevent some absent mindedness on my part (and other peoples) from causing some unexpected issues!
On a similar topic, being able to label DIs and cal tables etc is now a bloody awesome addition, and certainly cuts down the odds of the above situation happening hugely. So thanks for that.
Part of the reason I had this problem above is that I had not labelled the virtual aux when I was using it for something else. So I make sure to always label everything now, 100% of the time.
But I still think it would be nice to have some sort of extra safety net, especially for people running the Thunder etc where there are so many inputs and outputs to manage, which can be set up for all sorts of weird and wonderful things.

Thanks