Jump to content

Tim D

Members
  • Content Count

    100
  • Joined

  • Last visited

  • Days Won

    5

Reputation Activity

  1. Thanks
    Tim D reacted to Adamw in TP / Idle control   
    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.

  2. Thanks
    Tim D reacted to Vaughan in TP / Idle control   
    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
  3. Like
    Tim D got a reaction from cruz177 in dashboard arduino   
    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
  4. Like
    Tim D reacted to Ducie54 in Internal logging issue   
    I would add log status and log memory use to the ECU logging parameters. 
  5. Like
    Tim D got a reaction from TechDave in New ECU has died   
    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
  6. Like
    Tim D reacted to ClintBHP in Polishing the tune   
    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.
  7. Like
    Tim D reacted to MarcD in CLL fuel correction %   
    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
  8. Like
    Tim D reacted to Davidv in Suggestion: New Mixture Map logic for improved results   
    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.

     
     
  9. Thanks
    Tim D got a reaction from Booston in Covert llg file to csv?   
    Did you mean this...
     

  10. Thanks
    Tim D got a reaction from Booston in Boost trace log   
    Take a log and capture these parameters (assuming you're running closed loop), it makes analysing and tweaking a piece of cake!

  11. Like
    Tim D got a reaction from Ted in Subaru knock problem   
    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
  12. Like
    Tim D got a reaction from Ted in Subaru knock problem   
    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)?
     
  13. Like
    Tim D got a reaction from Ted in Subaru knock problem   
    Hi, I only skimmed through this post, apologies if you've already fixed this...
     
  14. Like
    Tim D got a reaction from ClintBHP in CAN Lambda Error 54 Excess pump current   
    Clint, 
    Thanks for your advice, the new Lambda sensor did the trick, Lambda is spot on again!  
    Great service from BHP too.
     
  15. Like
    Tim D got a reaction from TechDave in CAN Lambda Error 54 Excess pump current   
    Clint, 
    Thanks for your advice, the new Lambda sensor did the trick, Lambda is spot on again!  
    Great service from BHP too.
     
  16. Like
    Tim D reacted to Adamw in Subaru GC8 STI V6 Type RA - Engine Fan always on + idle at 1500 + Lambda not working   
    When you blip the throttle the idle valve will return to whatever position is in the base position table.  If the base position table is incorrect then the engine RPM will settle outside of the control range so closed loop will never engage.  It appears your base position table hasn’t been tuned at all.  You need to switch idle control mode to open loop and tune the base position table properly before switching to closed loop.  There is a guide in the help file.
  17. Like
    Tim D reacted to Simon in knock detection device   
    Finally after far to long we have some recordings off the G4+ KnockBlock
    These recordings are off our well abused 1UZFE VVT test engine.
     
     
    Engine background noise.m4a
    Mild Knock with bad tune.m4a
    Severe Knock with bad tune.m4a
  18. Like
    Tim D reacted to Adamw in mixture map vs autotune; road tuning only   
    Hi Rich,
    Quick tune is really designed for steady state tuning on a dyno, mixture map is the tool you want for tuning from logs.  
  19. Like
    Tim D got a reaction from b3tuning in ''Laggy'' software   
    At last, my graphics issues are fixed, despite having latest geforce drivers, it was the windows setting for text scaling, it needs to be 100%, not 125%.

  20. Like
    Tim D got a reaction from MagicMike in ''Laggy'' software   
    At last, my graphics issues are fixed, despite having latest geforce drivers, it was the windows setting for text scaling, it needs to be 100%, not 125%.

  21. Like
    Tim D got a reaction from TechDave in ''Laggy'' software   
    At last, my graphics issues are fixed, despite having latest geforce drivers, it was the windows setting for text scaling, it needs to be 100%, not 125%.

  22. Like
    Tim D got a reaction from mapper in ''Laggy'' software   
    At last, my graphics issues are fixed, despite having latest geforce drivers, it was the windows setting for text scaling, it needs to be 100%, not 125%.

×
×
  • Create New...