jaypat01

@0x33 So it is a flex fuel setup, but it is currently running E13 as we were tuning the pump gas map and never got to the high ethanol content map. That being said, I have heard of a lot of people running 600whp on a 3s with these coils on ethanol, so its hard for me to imagine they don't have to power to ignite it. Additionally, my dwell times at 14v was 3.0ms and I bumped everything up to the settings someone else had been using for a while on their 3s with 1zz coils which made it 3.6ms at 14v. I did that right before this pull to see if it fixed it, but it didn't so I will probably drop it back down. Also, the injectors are brand new (ID1700xds), but we pulled them off regardless and flow tested them at the shop where we were tuning it. All were matching. Are you saying to run 2.2ms at 14v? What would you make the 13v setting? So what am I misunderstanding here, when I look at the help section in the software it would seem that my polarity is correct by looking at the trigger scope and this. @Adamw can you help me understand where I am wrong in this so I know for the future?

Alright, so I think I might have found something. I went out and logged a pull going past 5k rpm and it broke up a bit and then cleared up, but you will see I hit the MAP limit at about 6800rpm. But the break up did happen in the first pull around 3.8secs into the log. This was about 4800 rpm. Spoiler alert... fueling is about 5% lean from my target lambda value but I don't believe this would cause a misfire. So what I think I found was a very small downward spike in the rising portion of the trigger 1 waveform that is above the arming voltage (4.5v) at about 7.5ms into the trigger scope log. You can see it happens twice above 0v ref, but the second one is below arming voltage. If I am understanding trigger arming correctly, does the trigger arm for the ecu to count the next tooth once the voltage rises past the arming voltage and then the ecu counts the next tooth once it sees the first decrease in voltage (falling edge)? So could this be my issue? Maybe I am over thinking it, but I would assume that the ecu ignores the correct falling edge after that transient downward spike because it never dips below the arming threshold until the next tooth passes....so this is why I don't get a trigger one error. You will have to look at the trigger to see what I'm talking about. Basically, I'm thinking that its possible for the ecu to miscalculate engine position and speed for a short duration and not give a trigger error with what happened in that trigger scope. Trigger Scope Log 2021-06-7 12;08;13 pm.llg Log 2021-06-7 12;05;38 pm.llg MR2_06-5-21(I-0,E-R7).pclr

That’s what I need...a trigger scope capture of it. My tuner did that capture on his laptop and we looked at it but he never saved any of them. I have a log from the other day but it’s quite lengthy. So I will go out today and take a log of just a pull where it breaks up and then I will perform a trigger scope capture. Wish this Thunder was a G4x so it would do that all at once

Will do. I will try to get one today or tomorrow.

So I’ve been struggling with a 5k rpm break up on my Gen 2 3sgte running a Link G4+ Thunder ecu. I had it on the dyno the other day and we couldn’t get the car past 5k rpm without it breaking up. This was a consistent problem and happened whether it was in boost or in vacuum. We were only running 12-13psi of boost at this point and still on pump gas 93. We hadn’t even got to the Ethanol mapping yet. First thing that came to mind was a trigger issue. I am currently running a factory 5s crank trigger (36-2) and matching VR sensor for the crank trigger and I am using the factory 3sgte distributor for my cam sync signal. What is odd is I never get a trigger error for either the crank or the cam signals and when I pull a trigger scope while it is breaking up, the trigger signal looks perfect and the sync pulse isn’t close to the missing tooth (I’ve seen an issue with belt stretch causing the sync pulse to fall on either side of the crank missing tooth edge on another car so I new to check for that). We started tuning it on NGK V-power coppers gapped to .022 and had the issue and tried a set of NGK Iridiums gapped to the same measurement (yes we know how to gap iridiums without damaging them) and we had the exact same issue...nothing changed. I am running 1zz coils (ordered 4 new ones from Toyota before the tune and I even tried my older ones, but had the same issue). I’ve rewired the coils again and increased the 12v supply to them and have even logged the voltage of the 12v supply at the coil to see if the voltage dropped ever, but voltage stayed above 14v the whole time...even during the breakup. When we connected the timing light...you can see the strobe increasing frequency in a smooth manner until we hit 5k rpm and then it looks like the frequency cuts in half. This to me looks like the ecu is performing and ignition cut. So we turned off all limiters and I logged “% IGN cut” and “% Fuel Cut” and they stay zero’d during the entire log and through the breakup. Fueling is close enough when this happens that it shouldn’t be causing the break up and EGTs show all cylinders running pretty identical and the spark plugs confirmed it. My question is to Link, is it possible to have a trigger issue without getting an error? I’ve thought about sensor gap, but the oem VR sensor is bolted to the oil pump with a “collar” on the mounting hole that centers it and I don’t see how there is anyway of adjusting the gap. This issue is really starting to boggle my mind. It even has my tuner stumped and he is a really intelligent person. I’ve never met an electrical problem I couldn’t solve and as an electrical engineer, this problem has really humbled me. I know this is going to turn out to be something really stupid. If anyone can shed any light on my dilemma, I’m open to anything. I will add my coils are grounded on the cylinder head and I have tried two different ground points on the head and haven’t seen a change.

@Adamw I am currently doing exactly as you say, but it is consuming a PWM output, a digital input that can handle the frequency, and a 3D table in the software just to do one simple calculation. Hence why I believe the math function should be added, but whether it should be added or not, it doesn't matter if the hardware won't support it. So I get that.

I had asked a while back when the G4x wasn't released yet if Link could add a way of comparing two analog values to control an output (in my case I am controlling IC fans with the differential temperature of two temp sensors) and I never heard anything back on whether this could be implemented. I realize a majority of the requests on the wish list cannot be added, but this seems like a pretty basic and highly useful function to add to the software. So recently I was poking around in the G4x software and noticed you added the "Math" functions in the "ECU Settings" tab which is exactly what I was looking for to be added to the G4+ software. I upgraded to a G4+ Thunder during the time that the G4x platform was rolling out, but it was only on the "smaller" ecus and I was assured by Link that it would be a long time until the G4x Thunder was released. So since I needed an ecu with the amount of functionality that the Thunder had and I couldn't wait for the G4x version to be released...I made the decision to just buy the G4+ version. Now that I am stuck with this platform, could Link seriously consider incorporating these "Math" functions into the G4+ software before they discontinue firmware updates in a years time? I realize there could be a hardware limitation with the slower processor and possibly less memory, but if there is not...this would be a really valuable addition to the software and something I believe should have been there all along.

@Adamw...Sorry this took longer than I expected, but here is a log from today. This is a base map that is surprisingly close up to 10psi and in light throttle, but I was wary of taking it to redline with the tune being the way it is. I did however take it up to 5k rpm and historically, this motor has been the noisiest around 4200-4500 rpm. You will see a noise spike right as I let off the throttle, but I am assuming this is normal or can be disregarded; because there is virtually no load. Log 2020-06-23 8;29;25 am.llg

Hey, thanks for the fast response. I will most likely be taking the car out today and I will log it. I will upload it once it's done.

Can anyone tell me what knock level gains they used for each cylinder of a 3sgte when using a Bosch 2-wire knock sensor? I have everything else set up, but I would feel more sure about myself if I could verify the values that I came up with. I am a beginner in the tuning aspect of things, but very competent on the electrical and programming side of things. When dialing in the knock level gains, I am not confident that I am adjusting for the noisiest rpm of the motor or if it is actual knock. So I don't want to set my gains to low that a knock event doesn't surpass the threshold. Just for reference this is a Gen 2 3sgte (I will take any information from any revision 3sgte) and the knock sensor is a Bosch Motorsports KS4-P.

9 virtual outputs sounds higher than what I have currently. I think it is something around 6. I will have to do a firmware update tonight. Thanks for the info.

Would it be possible to add more Virtual I/O to the existing amount on the Link G4+ platform. I am running out as I like to use them for latching purposes, mostly for outputs that do not have 3 logic rules and I sometimes use them for additional logic if I just can't fit all of my conditions into one output logic structure. I'm not sure if this is an easy task or not, but I'm sure I am not the only one on here that ran out of virtual outputs to use. (FYI...I am running a G4+ Xtreme, not sure if the amount of Virtual I/O) is different for each ecu model)

Alright so I figured this out right after my last post, but I ended up with a little different solution than I planned. I figured I would post this on here so anyone else that needs to accomplish this can use my method. There is a CON to this method...it will use up an PWM capable AUX Output and a Digital Input. So attached below are the configurations I set up. Basically I used my AUX 7 channel as a PWM output, in which I keep the Duty Cycle constant at 10% across the whole table (I have one AN Input on one axis and another AN Input that I am comparing to on the other axis). Then I utilized a table for the frequency of the AUX 7 PWM output and I kept each axis the same as the DC table, but this time I entered the difference of the two AN values, plus 10 (I will explain that in a second) in each cell. In my application I was comparing two temps in which I was turning an IC fan on, so you will see in my table that I left all the cells in the lower left corner of the table at 10hz (which means 0 differential temp), because I don't care if the IC heat exchanger water temp discharge is colder than the ambient air temp (because I don't need to turn the fan on in that case). So the reason that all my cells are offset by +10hz is because apparently 10hz is the lowest number you can enter into these cells. So I just make 10hz my 0 degree differential temp reference. For the wiring portion, you just need to jump the PWN capable AUX Output that you use to a free Digital Input. I used DI 8 in my case. Unfortunately, you can not simply set your DI channel to a "Frequency" input, because you cannot reference that frequency in any other logic (kind of weird), so what I used was "GP Speed" and you have to scale it. Supposedly, entering 360 into the "Calibration" field will give you a 1:1 scaling of your frequency, but it was a hair off in my case and 356 got me closer (I'm not sure why). But in the end, this worked fantastic and now I can turn my GP Outputs on that control my IC HX fan's high and low speed by referencing my differential temp signal coming into DI 8.

It would be nice if a user could add an algebraic expression in the G4+ PC Link software somewhere that can be stored as a general value (such as Virtual AN Input). Essentially I am looking for a user defined algebraic function that you can use values from other inputs on the PCM to convert into a value that can be used to control auxiliary outputs. For instance, "|(AN Volt 1) - (AN Volt 2)| = (Virtual AN Volt 5)"...….this could be used to control an output off of differential temperature. I don't know which would be the easiest way to allow for this, but I feel like a "Virtual AN Input" would be the ticket. Also, if there is a way to accomplish this already, please let me know. I think there is a way to accomplish this with another CAN device (such as a digital dash) to transmit values to, perform the equation in the dash, and then send the result of the equation back to the PCM, but I currently only have a CAN-Lambda module connected to the CAN bus of my G4+ Xtreme.

Alright I think I have this solved and there are multiple ways of doing it. In the PWM output function...there is an option to vary frequency of the output which is defined in a table. I can make each axis the two temperatures I am comparing, but this time the table will be defined to proportionally increase the frequency output based off of the differential temp. I think I will increase the frequency 1hz per 1 deg of differential temp (See table below). This will give me the temp range I need. Then I will either feed that frequency output back into a digital channel and assign that channel as a Frequency input. This way I can trigger my fan’s high and low speed off of the Frequency reference. Only thing that would make this better is if I can reference the output frequency directly without using an DI channel or even better, I could write the frequency output to a virtual channel and reference that...then I wouldn’t use any external I/O channels. I know the first thing is possible, but I will need to look at the program later to see if I can accomplish the last thing I suggested.

I had the same idea about making my switch over point in the table only 1 deg apart, but the table would not give me the temperature range I needed.

Just realized you we’re suggesting using the PWM output as essentially a discrete signal (on or off). This I think would work as long as I keep the switch over point from 0 to 100% duty cycle linear in the table and the ecu does not store temperature values as anything other than an integer. I’m going to have to try this in excel first to see if it’s possible. Essentially the table will look something like this as long as both axis are scaled the same and have the same offset for temp. On another note, what is the resolution of the AN Volt channels?

This brings up a good topic. Are you saying you can connect SSR to a PWM signal from the ecu to create your own PWM speed controller? I was wondering if the frequency wouldn’t be high enough. On the other note about the dash...I was thinking of going with the AIM MXG 7” since Link does not have their own 7” dash on the market yet. Is there anything plans to release a Link 7” dash to the market to compliment the 5”?

It is not essential, you are right. I am either going to use the value to give a visual alarm on the digital dash that the A2W IC system failed (which wouldn't need a value) and I might use the value to calculate heat dissipation from the IC heat exchangers (I have temp sensors all across the IC system). My end goal here is to optimize the A2W IC system over time...so I want to log the temperatures throughout the system and water flow. I could use "g/s" as "gallons per second", but that would make it a very small number. lol

So I am looking to control an GP Output (A2W Heat Exchanger Fan) with the differential temperature between two temperature inputs. I would be using the logic that when the differential temperature between the ambient air temp and the IC Heat Exchanger water output reaches a certain level, I will turn on the fans. My question is, how do you compare these two analog input channels in the G4+ software to control the output. Worst comes to worse, I wire the two sensors into a voltage divider type circuit externally (which would feed a single differential signal back to the ecu), but I would rather do this comparison in software so that I can still view and log the individual temperatures in the ecu and/or digital dash. Is there a solution to this? Another possible solution I think I have found is to feed those two signals into a CAN I/O expansion module and I believe you can add an algebraic expression to manipulate the CAN transmission value which means I could transmit a temperature differential signal back to the ecu. I could be completely wrong on this.

I'm interested in this topic because I am going to input a flow meter (which has a pulsed output from a hall sensor) and I would like to label the units in GPM. I could convert the frequency produced by the flow meter to a 0-5V analog signal, but will I be able to create a custom unit in the Link software?