Well ... there was certainly a considerable back and forth on this subject. Some of it I understood, some ... not so much.


But, I'm sure we do not have an answer to the initial question.


I've sent FVD some of this thread, but don't see that they have responded to Tom's statements that the ECU eventually responds to the changes the piggy-back module institutes and 'de-tunes' the tune ... so to speak.


I wonder if any of the piggy-back module manufacturers will enter this thread and defend their position?

 

Just a quick observation: The piggyback module overriding the stock ECU's signals (like fuel injector pulse widths) is one thing. But the incoming O2 sensor signals (voltages) also have to be overridden, made to look "normal", so the ECU doesn't interpret the readings arising from the piggyback module's changes as something that needs compensation.

This would result in the stock ECU and the piggyback ECU fighting each other to impose their will on the engine.

One way to possibly avoid this would be the piggyback module has restrictions as to when it can impose its will on the engine. This might be limited to say only during extreme throttle openings during which time the stock ECU would switch to open loop mode and temporarily ignore the sensor readings and the piggyback module could get away with -- so to speak -- modifying the fueling and timing and possibly variable intake timing to extract more power from the engine. (There is the question of does the stock ECU also ignore camshaft timing?) Once the extreme throttle opening goes away and the ECU switches back to closed loop mode the piggyback module ceases its override function and becomes acquiescent.

If the piggyback module was able to overrule the stock ECU at other times it is possible the stock ECU would attempt to adjust for this and in some way undo or diminish what the piggyback module was doing. If this condition continued too long at some point the stock ECU would reach its adaptation threshold and enter limp mode.

 

Macster ... not to diminish your observation, but where do you get this information?


And, do you have an proof that this actually happens? And, if so ... how do the manufacturers of the piggy-backs continue to sell modules without outrage from consumers who bought same?

 

I'm pretty sure I answer the initial question several times.

I've just stopped responding to the thread at the request of (and as a courtesy to) FVD. (Apparently some of what I've said has caused quite a stir).

 

Here are Vbox numbers I took just the day that I finished posting on this thread just to prove my car didn't get de-tuned in a month or so. The half mile top speed was 157mph and I started slowing down just before the end of it. I don't have a good measure of distance when I make the runs so I have to judge by speed and I was getting close to the end of my road and had to slow down just a tad early. The trap speed was still 155 even though the terminal speed was down to 151 so clearly, the car probably could have hit 158 or even 160 in the full half mile if I hadn't braked early.

In fact, my quarter time on the day I got the car back from adding the mods was 10.571 @ 129.54 with a 60ft of 1.59 and three weeks later it was 10.65 @ 130.63 with a 1.68 60ft so the only difference in ET is the 60ft but the trap speed is 1mph faster three weeks later so you might conclude the car got faster. No de-tuning there. When someone offers real proof then we can discuss it, until that time it's just a baseless claim. My data show my car got faster with time, which counters the claims made about the ECU adapting the module out.

 

^ Completely agree. I have gotten 3 tuning boxes from companies that have been in business for years with positive reviews and never a mention of going into limp mode over time.

 

I do not have any proof. I was speaking more theoretical.

But I have done some firmware engineering (been doing it since the late 1980's) and have implemented several firmware programs that mimic behavior of some legacy devices when working with newer/different devices.

The legacy incoming signals/requests get transformed into signals/requests compatible with the new hardware and any responses when received from the new hardware get transformed back to look like legacy responses. New errors, if any, are transformed into legacy errors.

The usual goal is to avoid having to rewrite considerable higher level code when a change is made at the lowest level.

So this translation in both directions is done transparent to the rest of the (higher level) system.

(Most recently I was involved in supporting J1939 CAN communication while trying to retain as much of the J1979 CAN look/feel of the rest of the (higher level) system as possible. My vehicle communication firmware received legacy commands from the higher level code which were in J1979 Mode/PID format and had to obtain the desired info using J1939 interfacing and upon receiving this info then morph the data back into what would look like legacy J1979 CAN data so the higher level code was unaware it was actually receiving the engine/drivetrain telemetry from a J1939 CAN vehicle. IOWs, firmware/vehicle communication was J1939 CAN compatible, but I couldn't just turn around and dump this J1939 CAN data back on the higher level system software. It had to be translated, morphed into what the higher level code expected to avoid a non-functioning system.)

Back to the car and ECU: The ECU is mostly in closed loop mode. In closed loop mode the ECU strives to fuel the engine with an air/fuel mixture that is ideal for the proper operation of the converters. The ECU uses the #1 O2 sensor readings to know it has control of the engine fueling and it uses the #2 O2 sensor readings to know the converters are operating efficiently. In what the ECU receives in the way of sensor readings has some influence on what it signals to the engine.

With an OBD2 code reader/data viewer you can observe this, you can observe the short term fuel trims and then remove the oil filler tube cap and watch the short term fuel trims go positive as the ECU adds more fuel to compensate for the extra and unmetered air. You can then replace the cap and watch the ECU undo this adaptation. Well, I should say you can do this with the NA engine. Removing the Turbo's oil filler tube cap doesn't have this effect as the oil tank to which it leads doesn't appear to be connected to the engine's intake system.

If there is something overriding what the stock ECU signals to the engine, it seems to me this something must be prepared to upon receiving feedback from sensors to translate this sensor feedback into readings the stock ECU expects to see.

Otherwise the stock ECU will then begin to adjust to compensate. This can become quite a mess as then the piggyback module must deal with a stock ECU that is attempting to adjust to what the piggyback module has done.

As I noted in my previous post if the piggyback module was limited to overriding the stock ECU under open loop conditions -- the ECU goes open loop under hard acceleration -- it might manage to get away with *not* having to spoof sensor readings as the stock ECU ignores at least the #2 O2 sensor readings.

Or perhaps under some conditions the piggyback module just takes over and fuels/times the engine as it sees fit and counts on the stock ECU being exposed to this I assume worrisome disconnect between what it expects to see vs. what it actually sees for too short a time to really affect the stock ECU. By the time the stock ECU is ready to trip a CEL and enter limp mode the piggyback module has backed off and the stock ECU then sees more reasonable sensor data and begins to unwind whatever adaptation it had begun.

That some owners report the stock ECU entering limp mode suggests enough variation between engines that the piggyback module doesn't have the same amount of time to assume control of the engine with no repurcussions.

Based on admittedly my limited knowledge of the inner workings of the ECU -- I have never done any automotive ECU firmware programming -- what is or could be going on I would think a company that can create a piggyback module that doesn't fall prey to this scenario must have a real good understanding of what's involved to avoid mis-fueling or mis-timing the engine and to avoid letting anything from any of the critical sensors make it back to the ECU that would upset so to speak the stock ECU.

 

This is exactly the case. The engine can be studied in a controlled environment to determine it's open loop response to the sensor inputs. Once that response is understood, it's possible to design a control which includes the ECU response based on filtering of the sensor signals appropriately. This is how many things are controlled. The engine with it's ECU has an open loop response, once known, the loop can be closed and the response modified with the third party control in the loop.

My car performs quite well so far with just such a product. I plan to track my car on Jan 17th at the Texas World Speedway with the M club guys from Houston. We will see if it goes into limp mode under more extended hard driving conditions. I don't think it will but I will report back.