[EFI-Unlimited]

I haven't had a chance to conclusively test this, but I think the row indexing may be off by one. In a customers car that I recently worked with, I noticed in the datalog, that commanded lambda was following the table, but was following a row greater than what it should have.

Again, I haven't setup a test case to conclusively prove this, nor have I looked at the code, because I expect that someone who is already familiar with the patch code can quickly look at it and determine if this is the case. Also, the column indexing should be checked for the same thing.

Brian
EFI-Unlimited

[cgrey8]

I haven't noticed this, but then again, I haven't verified it with a fine toothed comb either since I don't drive in OL for long periods. 99% of my driving is CL, so a bug like this would be easy for me to miss.

A test scenario would be to rescale the table to really tight RPM/Loads and see if the numbers are following.

[EFI-Unlimited]

I still haven't made a specific test case, but I have continued to observe this behavior in other cases. I am fairly confident the row indexing is off by one row.

Brian
EFI-Unlimited

[cgrey8]

That could be possible. I haven't looked into it heavily, but if the thing is off by a row, then that is possible.

[EDS50]

Has anyone gotten a chance to look into this? Just curious.

[decipha]

IIRC i think that was solved many a moons ago

in any case, its not an issue anymore

[86GT]

If this is not an issue anymore than what was the fix. I have not been updated with whatever the fix was. I do not want to send out a FN1360 that is old and does not work.

[mpaton]

If this is not an issue anymore than what was the fix. I have not been updated with whatever the fix was. I do not want to send out a FN1360 that is old and does not work.

As someone who used FN1360 tuning before FN1307 tuning, I like the concept of the FN1360 patch.

As to the implementation however my comments based off a fresh download today are:

1 Again, I think users would want to know who made this patch, so they can get some idea
of whether they should trust it. Clint, you distribute it, did you also write it?

2 The Readme.txt file has a typo for where to insert table_data.bin.
ECU address 0x9EF2 does not match BE address 0x7EA2
The correct values are 0x9EA2 and 0x7EA2.

3 The provided values for FN1360 while probably safe, don't have the
high rpm richening even at low load that most stock FN1360 tables
have. Obviously, it's up to the tuner to set these sensibly.

4 Compounding the problem in point 3 is that this patch uses the existing function
FN070(N) to scale rpm. Later FN1360 stock bins use a
dedicated function FN070B(N) for this. This allows FN1360 to vary Lambda over
the full operating range of the engine. I would have thought this would be a
useful and relatively simple addition to the FN1360 patch. Changing the values
in the existing FN070(N) doesn't seem practical.

5 In the patch I just downloaded, I don't see any problem with the row selection.
That doesn't mean there wasn't a problem with an earlier patch. Patch versioning
would be a good idea.

[86GT]

I believe Derek is the ones who came up this. I am not positive. I will fix the error in the address. If people placed the table in the wrong address then yes I could see the values not being correct and the logic in the cal would operate in the range it is supposed to but the values would be wrong.

I agree if there was a new function to define the RPM normalizer that would be good.

After looking at this more this logic disables the 1307 and 1306. How does enrichment occur at startup if 1306 and 1307 are disabled or is 1306 and 7 only disabled after the FLG_ECTSTABLQ is set. If the later is correct then 1306 and 7 should not be hidden in the strategy if 1360 is enabled?

[cgrey8]

This is the file I intended for the FN1360 patch to contain:

FN1360 Application Instructions.doc

If there's a different application note, then yeah that's probably old and needs to be replaced.

[86GT]

Same error on the 9EA2 address in the doc.

[mpaton]

After looking at this more this logic disables the 1307 and 1306. How does enrichment occur at startup if 1306 and 1307 are disabled or is 1306 and 7 only disabled after the FLG_ECTSTABLQ is set. If the later is correct then 1306 and 7 should not be hidden in the strategy if 1360 is enabled?

The result of FN1306 is subtracted from the intermediate Lambda value. In later strategies using FN1360, this enrichment is provided by multiplying the intermediate value by the result of FN325(ECT), which is part of the patch.

FLG_ECTSTABLQ is only evaluated once the patch is enabled. If FLG_ECTSTABLQ evaluates to false, then the logic reverts to FN1306 and FN1307, and the FN1360 table is not accessed.

I don't know if you would want tables appearing and disappearing based on variables.

[mpaton]

I believe Derek is the ones who came up this. I am not positive.

I believe I would trust patches from Derek. At the very least I would have someone to go to if I had questions.

Substituting data values in scalars functions and tables is a quantifiable risk.

However I believe code alterations are an order of magnitude more risky, and 2 orders of magnitude if you don't know who did them.

Many of the Z_ scalars cause code to be changed. Logging code causes code to changed. Done correctly, this is fine. Some patches in recent GUFx public defs are NOT fine. They can cause random unpredictable failures in anything controlled by the ECU.

Ford tested their code. Do you want to be a tester of some new code written by an anonymous person, without knowing how much of the new code was independently reviewed or tested?

I go on about this because I once got a new def file equivalent for proprietary Tweecer software. It was supposed to only correct some variable addresses so I could log them. Everything was fine until I drove the vehicle, when it would not shift out of 1st. For all that I read about people mistuning their cars so that it is so rich their eyes water, the consequences of an ECU controlled transmission deciding that 1st is a good gear to be in at 70mph don't bear thinking about.

That all being said, and seeing the documentation that was intended to go with this patch I can only say that if I had written a significant patch which relied on things outside my control in order to work correctly, then if those other things didn't work in a way I considered acceptable, I wouldn't want my name anywhere near that patch.

[86GT]

After looking at this more this logic disables the 1307 and 1306. How does enrichment occur at startup if 1306 and 1307 are disabled or is 1306 and 7 only disabled after the FLG_ECTSTABLQ is set. If the later is correct then 1306 and 7 should not be hidden in the strategy if 1360 is enabled?

The result of FN1306 is subtracted from the intermediate Lambda value. In later strategies using FN1360, this enrichment is provided by multiplying the intermediate value by the result of FN325(ECT), which is part of the patch.

FLG_ECTSTABLQ is only evaluated once the patch is enabled. If FLG_ECTSTABLQ evaluates to false, then the logic reverts to FN1306 and FN1307, and the FN1360 table is not accessed.

I don't know if you would want tables appearing and disappearing based on variables.

Ok that make sense. so if the 1307 and 1306 are conditional based on the ECTSTABQ then the 1306 and 1307 should always be enabled. You must be able to adjust the values if needed. Either that or get rid of 1306 and 1307 altogether out of the patch code