Results 1 to 3 of 3

Thread: My first tune, Tacoma 2010 4.0 1grfe

  1. #1
    Tuner in Training
    Join Date
    Aug 2019
    Posts
    16

    My first tune, Tacoma 2010 4.0 1grfe

    Hi everyone, this is my first modification, I have a doubt, at approximately 3800 rpm the AFR becomes rich and remains until 6100 between 3800 to 6100 mark 12.5 12.3, before 3800 14.x, what can it be? The same thing happened to me with a Toyota 4Runner 1grfe over 3800 the AFR curve was going to be rich, is there a limiter that is not modifying?

    attached:

    Stock file
    Tune file
    vcm scanner file with test



    tacoma_seddik[38000] Stage 1.hptlog_autopista_a_fondo_tune.hpltacoma_seddik_stock.hpt

  2. #2
    Quote Originally Posted by Luis1grfe View Post
    Hi everyone, this is my first modification, I have a doubt, at approximately 3800 rpm the AFR becomes rich and remains until 6100 between 3800 to 6100 mark 12.5 12.3, before 3800 14.x, what can it be? The same thing happened to me with a Toyota 4Runner 1grfe over 3800 the AFR curve was going to be rich, is there a limiter that is not modifying?

    attached:

    Stock file
    Tune file
    vcm scanner file with test



    tacoma_seddik[38000] Stage 1.hptlog_autopista_a_fondo_tune.hpltacoma_seddik_stock.hpt
    The richer AFRs are due to PE mode; the commanded EQ ratio table is "Engine -> Fuel -> Power Enrich -> EQ Ratio (Gas)"



    As far as the RPM range for PE, that's a longer explanation, bear with me:

    The actual "activation" RPM isn't necessarily at ~3800 RPM, although the logs make it appear that way (PE is triggered by throttle in this case) - the reason it appears to activate around 3800 RPM comes down to polling intervals.

    A PCM can only provide so much requested data and only so often, and those intervals aren't necessarily synchronous between channels; when you're reviewing a log, VCM Scanner interpolates between these points (which is why when we zoom in a bunch on the charts, we see that they're really a series of connected lines, not smooth curves). Here's a little snippet from your log you posted as an example - if you follow the Absolute Load chart (bottom) you can see this pretty clearly: Charts Interpolation.PNG

    If we export the raw, logged data ("Log File -> Export Log File" and turn "Interpolate Data Gaps" OFF), we can see how it really looks without interpolation (which is also reflected in "Channels").

    Here's a small snippet from your log where you enter PE, with "Interpolate Data Gaps" ON: VCM Scanner Interpolation.PNG

    Here's the same snippet with "Interpolate Data Gaps" OFF (raw data) - notice how much less data is present here: VCM Scanner Raw Data.PNG

    And here it is once more with some intervals highlighted - notice that the intervals are not all the same length, and don't start/stop at the same times (asynchronous): VCM Scanner Raw Data Notes.PNG

    The challenge is that we don't know what's going on in those gaps, we can only guess (via interpolation); going back to the snippet above, we only know that we are in closed loop at timestamp 46.351 and open loop (PE) at 47.955, interpolation makes the transition appear to occur in the center of that range (which happens to be around 3800 RPM), but in reality it could happen at the very beginning or very end of the interval. The mismatched intervals explain why you have seemingly strange phenomena elsewhere in the log, like Commanded AFR dropping to the PE ratio while in closed loop, PE activating at low TPS%, etc.

    Your current effective polling rate of >1 Hz is workable for some things (e.g., knock correct learn), but tough/cumbersome/slow for most detailed work (e.g., fuel trims vs MAF, knock feedback) - interpolation works well when we have many, shorter intervals, and relatively poorly with fewer, longer intervals. There are a few things that can be done to generally improve those rates:

    1. Ensuring your important channels are at faster polling intervals (right click on the channel, select the polling interval from the menu). Using the default "fastest" polling interval for every channel slows things down.
    2. Reducing the total number of logged polling channels (almost all Toyota channels are polled vs broadcast - broadcast channels are always sent out via the PCM and can thus be read at any interval without penalty)
    3. Slowing the polling interval of less critical channels (Coolant Temp, for example)

    There is some trial and error to getting a good effective polling interval - how the PCM packages data isn't totally straightforward. Sometimes you can log many channels at a very high rate, sometimes you can only log few channels and still get a slow rate.



    I hope that clears things up a bit for you, a bit difficult to type up in a short post...

  3. #3
    Tuner in Training
    Join Date
    Aug 2019
    Posts
    16
    Thank you very much for having the time to answer my question, I will review very well what you tell me to keep moving forward. Tremendous response thank you