Scott33

I think I know the purpose of the charge temp approx table; I have read the help and other threads on the subject multiple times. I'm not sure what in my question gave you the impression otherwise. The point of the table is that both IAT and ECT contribute to the actual air temperature and thus density of air entering the combustion chamber. My question was just whether one can hold IAT constant and vary ECT (and monitor lambda) in order to tune the charge approx table instead of holding ECT constant and varying IAT. On the surface it seems that either method should be valid. As you point out, at idle (low load/RPM) the ECT contribution is higher, thus varying the ECT should show a large change in lambda if the charge temp approx table is set to 0. As the value is increased (and the corresponding values in the fuel table adjusted) then lambda shouldn't change as the ECT varies. My question is really just if changing the ECT would have other effects on how efficient the engine that wouldn't (or shouldn't) be captured by the charge temp approx table (but instead by ... ? what? a general ECT compensation table?)

My car has a controllable thermostat that can vary from 80C to 110C. Will I get reasonable results tuning the table by varying ECT instead of IAT? Or does ECT have other effects on volumetric efficiency that would yield poor results? I do have a separate oil thermostat and oil cooler so I expect the oil temperature to be fairly constant. I use case is road racing, so warmup really isn't that important. OTOH correct performance when ECT is varying (maybe I'm in a draft, maybe it's just hot outside and the radiator can't keep up) is important. I have gotten by for the last year with just warm up enrichment by ECT at 70C and below, and charge temp and IAT comp tables filled with 0.

Currently traction control allows for 1 or 2 tables. It'd be nice if it could be extended to support: 1. One table 2. Two tables, chosen by switch 3. Two tables, interpolated by third 2D table 4. Two tables, interpolated by third 3D table 5. Two tables, added. For example, if table 1 calculates to 5% slip and table 2 calculates -2% slip, then the actual target is 3%. 6. Two tables, multiplied. For example, if table 1 calculates to 5% slip and table 2 calculates 80% multiplier, then the actual target is 4% (0.05 * 0.80 = 0.04). Note this seems very similar to #4; but would actually support percentages greater than 100%. The first three are the standard for boost control. The last two would provide some interesting ways of allowing multiple variables, such as combining lateral G, speed, throttle position, and a driver operated traction dial (not just a switch). I would like this for G4+ (since there is no G4x Force GDI)

I see G4x already has this feature, but it'd be great to add it to G4+, and I don't think it'd take much (if any) CPU resource to make it happen (unlike math channels). Basically, if we could use the duty cycle of a GP PWM output of any aux output, then it'd allow for more complex logic when deciding boost, or accelerator position, or traction control slip target, or ... As a corollary, it'd be nice if Virtual Aux had GP PWM capability too so the output of those tables could be used as well without having to dedicate an Aux output to this purpose.

I have a RWD car with a limited slip. All four wheelspeeds are plumbed to digital inputs. I race on road courses with fairly low power (200rwhp with a 2500lbs/1130kg car+driver+fuel). I would like to tune traction control to help with mid-corner to corner exit. What should I use for the non-driven and driven axle speeds? Average or max? I started with average, but I do notice that on initial throttle, the inside wheel speeds up a bit before the LSD. I'm wondering if I should be using max, or maybe ideally I should be using "outside wheels". I know I can't set that up in Link, but I have another ECU that can process CAN messages and spit out whatever I want, so I could add inside/outside detection to the other ECU and just send back outside wheel speeds back to the Link ECU. Any ideas/tips? Thanks!

You can set Knock Control->Knock Setup->Ign Retard Limit to 0.

I emailed that along with a 6k rpm run to tech support. Hopefully it reaches you. I can really only test this on a dyno or race track, and I don't easily have access to either right now. I think the VVT is a red herring. I have tried lobe angles at -10 and +10 relative to what is in that tune (which is how far the exhaust VVT moves at 3k RPM), and it still drops off at the same point. Also, the 6k rpm run has VVT movement and works fine. I'll repeat what I said before - the GDI Pump Control is actually DECREASING while the pump pressure is dropping. It's almost like it's being forced down by some clamp. Thank you for the description on Spill Valve On Angle. I didn't realize the pressure keeps is closed until it isn't needed.

Firmware 5.6.7.3631, software 5.6.7.3632, though I didn't see anything in the notes for 5.6.8.3671 about GDI changes. I have a weird issue where the fuel pressure tracks just fine at 6k RPM, up to 0.0696 g fuel/cyl with a 5.188ms injector duty cycle at 200 bar, but it won't track at 3k RPM, above 0.055 g fuel/cyl with a 4.070ms injector duty cycle. It's a Bosch HDP5. It seems that it should be able to handle the same fuel flow rate per cycle in either case. Interestingly, it looks like the GDI Pump Control makes no attempt to make up for the fact the fuel pressure is falling (see log). I will admit most of my GDI parameters are guesses, but it seems the GDI Pump Compensation table can (crudely) mask deadtime (at one voltage) and pump calibration. I have tried other lobe TDC angles to no avail (usually makes it worse). I also tried other maximum cc/lobe values (thinking perhaps I was exceeding a the upper limit on duty cycle) but it didn't help either. As it is, the cc/lobe * # of lobes * fuel g/cc is well above the required numbers above. If it matters, the pump is driven by the exhaust cam, which is trigger #2 and VVT. However there are VVT changes on the 6k RPM run and pump control is relatively steady there. Attached is a log where RPM was held at 3k RPM while throttle was progressively fed in. Also, what is "Spill valve on angle?" Is it a minimum amount of time to energize the pump? In which case why is it different than "Minimum pump angle?" losing_gdi_200ang_250cc.llg

What exactly is the "GDI Pump Control" logged parameter mean? I assume it is the PID correction applied to the GDI pump control model (after utilizing all the lookup tables), and not the actual duty cycle of the GDI pump itself. I haven't seen it list any values below -10% but I don't know if that means values <-10% simply aren't logged or whether the PID is clamped to -10%.

Can I use multipoint group on a direct injection engine? It seems like the 2nd firing would be at exactly the wrong time (and probably wouldn't work since I think only one of two injectors can fire at a time, given the needs of the high voltage driver for GDI injectors).

To answer my own question - 1. Measuring deadtime is about measuring actual lambdas and pulsewidths at two different settings (same RPM/load, but different fuel amounts), and seeing where that goes. 2. Measuring fuel charge cooling coefficient is about measuring target vs actual lambda and making sure those track each other. Of course you get to throw in charge temp approximation table too, but that involves changing air or water temp and observing changes in lambda. Luckily I have a lambda sensor!

I noticed the help on how to tune fuel charge cooling coefficient is similar to how I would tune injector deadtime - vary target lambda and observe actual lambda (well, more specifically measure fuel/air ratio at various injector pulse widths to determine what the pulse width would be for 0 fuel). Assuming I can't measure my injector deadtime properly, is there a suggested way to determine those two parameters? I was thinking of changing the target lambda and testing two different load points, under the assumption that deadtime would have a greater effect at lower loads while fuel charge cooling would have a greater effect at higher loads. I assume I'll have to go back and forth a couple times to iterate on what the answer is. Or maybe (since I'm doing this on a GDI motor) I can vary the target fuel pressure and use the same load point so I can either have the deadtime be either the major or minor factor in the injector's pulsewidth depending whether I'm trying to measure deadtime or fuel charge cooling. Also, is fuel charge cooling relevant to direct injection motors? Is the effect smaller or about the same as port injection?

Has anyone connected their Link ECU to a Dynapack OBD adapter? I was wondering if the dyno can log the ECU data stream or not. Might make it easier to see the effects of ignition or fuel changes as it relates to power output, esp as the air temp is increasing. I know Dynapack has a separate CAN adapter, but the shop I'm using doesn't have that. They only have the OBD adapter, and I'm not sure if it expects K/L-line or if it can read CAN too. Thanks!

In the documentation for the gear ratio table, it says "Gear Ratio = Engine Speed (RPM) / Speed sensor frequency (Hz)" and "Engine Speed/Speed Sensor Frequency". However, as far as I can tell it's actually Engine Speed (RPM) / Wheel speed (kph). This is what is actually displayed in the Runtime Values box under the Misc tab.

You can find BMW wiring diagrams here: https://www.newtis.info/tisv2/a/en/ If it's anything like the N20 sensor, it should be hall effect with the pull up resistor enabled. I think it's dealer's choice whether you choose rising or falling edge; at least with the N20 the pulses are just spikes, not related to the size of the tooth. Are you running port injection? I didn't think Link ECUs could run piezo GDI injectors, let alone 6 of them.

Perfect, thanks!

Helping out a friend, and before I make changes to the stock wiring I just wanted to check a couple things: 1. Pin 27 is supposed to control the engine module relay, but there isn't anything listed in the wiring pinout about pin 27. Similarly, pin 56 is ignition switch input, and nothing is listed in the wiring about that pin either. Are those two linked internally so that the ecu only has power when the ignition switch is on? 2. The oxygen sensor input is connected on the right pin (pin #13); does that mean the oxygen sensor relay (pin 38) is connected somehow? I don't see a connection listed in the help file. Is it only active when the car is running?

In order to make sure the AEM UEGO controller is only running when the engine is running, one normally wires the power to the UEGO controller with a relay, which is controlled by an aux output of the ECU. However, the current requirements of the controller are pretty low - 1.2A. Instead, can we just wire the ground of the controller directly to the aux output of the ECU? Controller power will have to be switched so that it is not on when the ECU is off (otherwise ECU could receive phantom power). Also I would use CAN to communicate, not analog, in order to avoid the slight ground shift between the controller and ECU. To reduce the load on the aux outputs, the controller ground could be split between two aux outputs that are configured the exact same way. Not only would that divide the heat between two mosfets, but would actually cut the total heat in half (P=I^2*R - half current in each mosfet means a quarter of the heat per mosfet, 1/4 * 2 = 1/2).

Thanks for all your help. I don't want to remove the pump as I have to replace a $70 fuel pipe if I do. Not sure why, but the factory manual says so. I looked at pictures of a cam on ebay and estimated the lobe angle. I also guessed that the lobe is a perfect sine wave. After that I started getting fuel pressure. I had guessed at the timing based on pictures from the factory manual on the position of the trigger wheels at TDC, combined with what I saw in the trigger scope. Something somewhere was wrong (either the factory picture, the Link manual on missing teeth + cam level, or my interpretation of one or the other) but once I reversed it 360 degrees it fired up every other time. I also lost GDI pressure. Then I realized since I changed the definition of TDC, I had to change the GDI cam lobe position and now it starts and runs perfectly. Now on to the fun stuff!

FYI you can use a 74HC393 which has two 4-bit counters in one package. Saves space if you need all 4 wheel speeds. In a TSSOP package, the board fits on the end of an AT04-12PA-BM* header, making for a compact addition to a wiring harness.

Thanks for the responses. My take away is I need a whole lot more fuel. I had hope I could run it without high pressure. I haven't characterized the pump or the cam profile at this point, and was hoping to do it through deduction on the running motor (see what duty cycles are needed to maintain the right pressure at various angles, and use linear regression to estimate the profile). I have gotten pops and even had it run for a second or two after I ran the injector test. I think the residual rail pressure was enough that the cylinders got some fuel. But maybe the injector time limit of 20-24ms will be too short to get enough fuel when the rail is at 5 bar. Given the occasional pops I've heard I also think I've gotten the air out of the system by now. Do you have any crank/start logs from the VW GTI GDI or Ford Ecotec GDI motors? I'd take anything at this point just to understand what "normal" is.

I'm trying to get a motor running with Force GDI. I haven't gotten it to start yet, though I have verified that injectors and spark work. I wanted to verify a few assumptions before I push forward. It's a street car motor without any internal modifications - a BMW N26 if it matters. Unfortunately I don't have much technical data to go off, so I'm trying to derive as much data as I can from the motor itself. I started with the VW GTI map and have been making modifications along the way. 1. The MAP sensor never reads much vacuum when cranking. The lowest I've seen is around 60kPa at 270RPM. Is that normal? I assume more vacuum is generated at proper idle and especially at high RPM. Because of this, I added an extra column to the fuel map at 400 RPM so I could enter much lower VE %. Otherwise I was getting "injector duty cycle too long" error messages, which is what led me to think that 60kPa is actually not normal. I did open valvetronic up (before that, MAP read 97-99 kPa). 2. Is it possible to run a GDI motor without controlling the GDI pump? When I run the fuel pump, I see both the low and high pressure gauges read 5 bar, which tells me fuel is getting to the injectors even without controlling the pump. I recognize I won't be able to run at a high RPM or open throttle but it should be enough to start and idle, right? If it matters, I adjusted injector timing to be 180, so that the injection happens when there is relatively little pressure in the combustion chamber. 2b. If I get a "GDI pump failed to maintain pressure" error, will the ECU still try to run the motor or will it give up? AFAICT it was still trying to inject fuel but I just wanted to make sure. 3. What's a ballpark injector duty cycle for start at 5 bar on a 2L 4 cyl? I recognize this heavily depends on the injector flow rate (which, of course, I do not have), but I know an N55 (same injector, but 6 cyl instead of 4 cyl) has a duty cycle of around 1.8ms at idle. I scaled that up assuming idle is at 50 bar to be 5-6ms at 5 bar. I guess my next step after this is to get a timing light. I was hoping to avoid it but I'm running out of things to check/fix and it's still not starting. I've attached my attempt to start log in case anything jumps out (note this one has the injector pulsewidth at around 1.5-2ms instead of 4-5 but I've tried bumping it 20% at a time up to 10+ms and it still didn't fire). Do you have a log file from starting a GDI motor, and if so could you post it? Attempt Start Log 2020-03-31 5;38;56 pm.llg

I have seen multiple comments that Link G4+ includes a CAN terminating resistor. However is that just for CAN1 (the separate 6-pin connector) or does is that true for CAN2 (the one that doubles as digital inputs) too? I have a G4+ Force if it matters. I don't think I can measure this - I assume the resistor (if it exists) must be disabled when using the digital inputs as inputs, which I assume is the default state when the ECU is unpowered. Once I power it though, then the CAN driver will take over the pins, and my multimeter won't be able to induce a voltage difference across the pins in order to calculate the resistance.

The cams are stock, but the engine does have VVT. No ITBs. Is MGP still the preferred load axis for fuel?

I will be tuning a turbo direct injection engine where it may be necessary for me to change the boost levels from race to race. Rather than retune the engine, my plan is to use TPS as the main load axis in the fuel table and use a 4d table to compensate based on MGP, or possibly MAP/BAP if I can make it happen. This is the suggested setup for turbo engines with unreliable MAP pressures, so at least I'm not going too far off the beaten path. My question is what to do for the ignition table load input. The manual suggests using MAP, as opposed to MGP, which I guess makes sense as it should be more related to the quantity of air entering the chamber, while MGP is more useful for determining how efficient the engine is. (Side note - the VW GTI Force map uses MGP as the load axis for ignition). It seems there's another input that is reasonably related to how much air is going into the engine, or at least related to how much air we THINK is going into the engine -- Inst Fuel Consumption. Would tuning based on fuel quantity be a reasonable idea, or should I just stick with MAP? Or should I go with MAP + TPS as suggested by the help file?