Tim D

My 2 cents:  If it doesn't have an apparent difference while testing I wouldn't get too worried about it.  If the default setting is working, I would go with that.  Ultimately when mapping or tuning, you're going to set the ecu to what the engine responds to for values in the timing table, and that's what matters most.
Having perfect timing offset means that the timing values in your timing table are accurate all the way to redline versus the real world mechanical crank position.  Having it incorrect may mean there is some difference between what the ecu is commanding or "thinks" the timing is versus the actual real world.  What is the practical difference in this potential couple degress of difference?  In my opinion, not much since as stated previously you're going to tune to what the enigne wants in either case.
This also only can be checked/set when the ecu has a fixed timing value.  You'll need to have the ecu set so that the trigger calibration window is open while checking this to fix/hold ecu timing.

For what it's worth, I wrote up my experience of setting up knock control on my Impreza STI 2007.  It's all based on the Link help files... I believe what I have done is correct (comments welcome!)  Feel free to have a look at the attached word doc...
BTW, I found the sound levels of each cylinder to be quite 'noisy', so had to have a fairly large headroom in threshold to prevent false knock detection.
Knock Setup.docx

I've recently picked up a G4X, as well as having my existing G4+.
I was wondering if I could make use of the some of the advanced features of the G4X, such as long-term Closed Loop Lambda, to improve my G4+'s tune.
If I were to use Modelled Mode, enter the same injector data, target lambda, charge temp approximation etc, could I run the G4X in the vehicle, flesh out the fuelling table, then apply this to the G4+ and have a reasonable result?
I appreciate things like warmup, throttle transients, wall wetting etc may not translate, but the raw fuelling table - would that be close enough?
Or, does the G4X calculate fuelling fundamentially differently to the G4+, and I'd be wasting my time, and it'd be better to just stick with doing it the "normal way" in the G4+ with logs + Mixture Map?

I was having crashing issues - but all disappeared when I upgraded to windows 11 - go figure Microsoft fixed something ! 
my old win 10 machine still buggy will update that ones soon and report back.

This is how I normally look at it:
 
Logged values list.mp4

I would say yes it is most likely actual knock.  Track or circuit racing is going to be relatively high duty cycle at high load and knock can happen the longer you run the car hard.  
 
If you want to see if it gets better, try retarding ignition in the particular cylinder 2 degrees in that region and add 2-3% fuel on that cylinder in that region.  If you run another track event in similar weather and it happens less, then you had some knock there, and pulling 2 deg all the times is better than 5 degrees more of less all of the time.  Not that one would be making power knocking anyway. 

This.  

The retard is just be because you passed through the same cell in your knock trim table again that already had the 5 deg retard from the last knock event.  That retard will stay saved in that table until either you have driven long enough in that cell with no knock detected that it advances back again - or until next power up when it will clear the trim tables.
The count doesnt increment because there hasnt been any knock detected.    

Thank you, much appreicated.  I installed the latest PCLink and updated the firmware as you suggested.
I did experience some strange behaviour though:
A while back, I set Lambda Mode OFF  to do some refinements to fuel table
Once complete, I set Lambda Mode Auto Mode (Wide Band) and the following tables were missing:
 CLL Pos Trim
 CLL Neg Trim
 CLL Update rate
 
I found that by setting FTrim Tables to OFF, then back to 3D Table again, the missing tables re-appeared.
Not sure if this is expected behaviour but it confused me.
 

Hi All,
The default layouts in the current G4+ PC Link are pretty dated, I recently done a couple of new ones that will be included as the defaults in the next PC Link update.  But in the meantime here they are so you can use them now.
FYI, if you use both G4+ and G4X ecus and you have highly customised layouts, you can copy the same layout into both PC Link versions by just changing the file extension.  G4+ extension is .llg and G4X uses .llgx.
Feel free to add to this post if you have any layouts you want to share.
 
1366 x 768.llf 1920 x1080.llf

Thanks Adam! The 1920x1080 one looks great on my XPS13 (3200x1800) running at 150% display scaling, just a few unused pixels at the bottom of the page.
That does mean I can drop everything down a little and expand the table areas so I hopefully won't need to scroll!
New G4+ PCLink version... ooh does that mean a few of the wishlist items & outstanding bugs might be included? I understand your primary focus is the G4X range, but please don't forget us G4+ people too quickly!

With E-throttle idle control the base position table should be near zero at normal operating temp, the main idle throttle opening required should come from the main E-throttle target table.  
So you need to subtract about 1.5-2.0 from all the numbers in your base position table and add 1.5-2.0 to the top row of your E-throttle target table.

had a quick look and it happened when you moved from the idle control being locked out by your vehicle speed to being in closed loop idle control, the blip is the 2% idle base position being applied then after 2 seconds the closed loop idle kicks in and pulls the idle speed down.
To fix it consider reducing your ISC Base Position values in the 80-100deg c range

There's lots of ways of achieving what you want and I am happy to share my approach which works well.  I stream 56 bytes (7 frames) from ECU to dash, then broadcast this data over bluetooth (if laptop is running, the data is logged).
I'm guessing you don't have other CAN devices on the same CAN bus as your dash?  In this case, the concept of priorities is not that relevant (there won't be any other CAN traffic to contend with).
In my MBED dash, I stream 7 frames all on the same CAN ID of 1300 (arbitrary ID).  These byes are streamed 'end to end' (as observed on oscilloscope), leaving a lot of time after the last frame to do my processing.
All that's required is to write your arduino firmware to recognise the stream.
My dash also broadcasts the data wirelessly to my laptop, giving error free datalogging (I chose to stream this at 10 Hz).
You are welcome to look at my CAN setup:
https://drive.google.com/open?id=1pjCW7otZjlRO3j8JqtsJj-2yhvleHtnw

I would add log status and log memory use to the ECU logging parameters. 

Thanks all for your help guys!
It turned out to be fuse number 11 in a fusebox I didn't know existed!  Hidden away behind the immobiliser keypad, which you have to pull off it's hinges to reveal the fuses.
Apparently this fuse feeds Engine ignition system and SRS airbag.  It pretty much immobilsed the whole car!
Not sure why it blew, perhaps I have an underlying fault that will come back to bite me!
Thanks too to https://shopbhp.com/ - great tech support as always

I have actually had some great success tuning with the CLL information for fine adjustment on my own car.
So I use the car to drive around everyday creating a log and every now and then I grab that log of an evening and see where the CLL is making the most changes and I alter the map where it is adjusting the most, eventually you will get it down to the CLL only making tiny adjustments.
This fine tuning is something that is normally not done as dyno time is expensive, it is sometime also parts of the map where its hard to get into on a dyno.

HI Adam
is there a way to get mixture map to "add back" the correction that CLL has applied and is registered in the log and then apply to the fuel table?
 
am leaving CLL on as cheap insurance but want to ensure I am as close as possible with the map.
 
thanks
Marc

Hi, 

Currently with mixture map you set a threshold so that samples within say 25% of the centre of a cell vertically and horizontally.
This pool of results are used to contribute towards an average value in the centre of the closest cell. 
However this means that you've got 25% variation of rpm and load, contributing to a static value in the centre - and you need to throw away 75% (?) of recorded values.
I have another idea that can let you use all of the data instead, and improve the results.
For simplicity's sake imagine a 4x4 grid, and our current load and rpm point is 25% of the way towards the lower RPM value and 25% of the way towards the lower Load value. 
If we interpolate these values, as per what the ECU does. 
Note: I have just titled the columns and rows with percentages to show what percentage of the each cell we are interpolating from.



We get a value of (25% * 25* 10) + ( 25% * 75% * 30) + (25% * 75% * 20) + (75% * 75 * 40)
= 0.625 + 6.075 + 3.75 + 22.5

= 32.95 is the table value that interpolation produces. 

Now lets say that you wanted to add 10% to this value.

If we just adjust the closest cell by 10%, as per current Mixture Map strategy. Then our bottom left cell changes to 44 so our table now looks like this:



If we do the interpolation again, but with the new value to represent running the car again after the update:
We get a value of (25% * 25* 10) + ( 25% * 75% * 30) + (25% * 75% * 20) + (75% * 75 * 44)
= 0.625 + 6.075 + 3.75 + 24.75

= 35.2 as the new overall value. Which is only makes 6.8% difference to the interpolated value, rather than the 10% we wanted.

On the other hand...

If PCLink De-interpolated the 10% that it wants to add.

Instead of adding 10% to the one cell, we split the 10% addition across the 4 cells based on the same percentage that the value was interpolated from initially. 

So:
Top left cell: (10 * 1.1 * .25 * .25) = 0.6875
Bottom left cell: (30 * 1.1 * .25 * .75) = 6.1875
Top Right Cell:   (20 * 1.1 * .25 * .75) = 4.125
Bottom Right Cell: (40 * 1.1 * .75 * .75) = 24.75


= 35.75 is the table value that de-interpolation produces. 

We were trying to add 10% and this new value produced is 10.5%. So that's pretty good!  
(The 0.5% error comes from rounding to 3 decimal places in my example)
So it's accurate to the provided data in every instance. Which is especially relevant when it's applied 1000s of times across all of the cells. You dont need to throw away any of your recorded data, it all contributes to the cell values.

Mixture map is pretty good for roughing out a map initially but because of the inaccuracies of the "nearest cell" method I don't really use it that much anymore when trying to dial in a fuel map. You always overshoot or undershoot unless you set your cell tolerances impossibly tight and have millions of samples.

And, since this is all only done in PCLINK rather than the ECU, there's not really any worry about the overheads of the extra maths involved. It's worth having it chug away for a few minutes longer if you can get an awesome result on first or second iteration of Mixture map logging.

So - that's my Friday night suggestion. 
Thanks for reading if you got this far, haha.

 
 

Did you mean this...
 

Take a log and capture these parameters (assuming you're running closed loop), it makes analysing and tweaking a piece of cake!

For what it's worth, I wrote up my experience of setting up knock control on my Impreza STI 2007.  It's all based on the Link help files... I believe what I have done is correct (comments welcome!)  Feel free to have a look at the attached word doc...
BTW, I found the sound levels of each cylinder to be quite 'noisy', so had to have a fairly large headroom in threshold to prevent false knock detection.
Knock Setup.docx

Just an idea... Perhaps you could try logging to ECU at 100 Hz, only logging the relevant parameters at this rate though.
Might help to understand whether the PC just can't display/log data fast enough (as Adam was suggesting)?
 

Hi, I only skimmed through this post, apologies if you've already fixed this...
 

Clint, 
Thanks for your advice, the new Lambda sensor did the trick, Lambda is spot on again!  
Great service from BHP too.