banaro

Hi Adam, I had applied a timer to an axis of an rpm limit protection table so i could have timed progressive rpm limits, but when it hit the limiter more than anticipated I investigated and found that the rpm being called out from the table along the time axis was delayed & would update infrequently compared to the actual timer value, and I was logging both at a high rate, the data matched the symptoms the car experienced. If you think about the architecture of most processor system, not all calculations will have the same priority, fuel tables and executing an rpm limit would likely be high, but recalculating a position on an rpm table maybe way lower. The reason i raise all of this is that I wish to use the ecu calculated value "wheel speed acceleration" as an axis in antilag ignition cut tables, but firstly it needs to be calculated, secondly evaluated in the table, then thirdly acted on, so time unknown. Thanks

Considering implementing an 8 pulse per tailshaft rotation sensor to improve resolution over the current 2 pulse, considering this is not a differential signal, and the data input rate would be approaching 1.5K are there any down sides to the ecu processing of this into reliable wheel speed acceleration data? I have had problems with the length of time the ecu takes to recalculate its position along engine protection RPM limit tables for progressive time based limiting, nearly .1sec behind at times, and I wonder whether the ECU might give a higher priority to calculation updates in the antilag tables for example? Thanks

Thanks Adam, I searched the logs and have test logs that show the afr's were intially uneffected by the turbo integration, but then i realised not so after the converter is tightened, so the answer to my question is that the engine is under greater load through the rpm range due to a way tighter converter, hence the need for more fuel at the corresponding rpms. I assume I was too far way for the mixture table to get close with a single suggested map update? Thanks

Have for many years run a centrifugal supercharger (SC) and when boost at an rpm is altered the ecu accurately recalculates the fuel requirement without intervention. I have now added a Turbo (T) feeding the same setup with the SC spinning slower, and i have starting testing with simular engine boost numbers to the SC in the past. Using the previously established base fuel map under load the engine is way lean and is requiring 25% increases to the table, at part throttle burnout time the map needs large decreases to the table presumably because the engine is drawing less air through the now very long length of intake pipe work? Previously with the SC only, when I asked the mixture table to adjust cells on the fuel map it was always close, but when I ask it to adjust the fuel table now, it goes no where near far enough, seems to go about half as far as required each time. ECU fuel mode is traditional and load is map I am missing something here, another influence, can anyone help me understand what's happening? Thanks

I used both conditions within aux14, rpm greater than 4000rpm and TPS greater than 60%, i tend to test outputs by varying the conditions temporarily rather than going to "test on", gives me more confidence, so no.

Thanks Adam, definately no low drive out on my aux 14, moved it from aux3 to aux14 to free up a low number aux, then back to aux 3 when it did not work, maybe our hardware and software revisions are slightly different Adam, i have found a number of bugs that you have confirmed in the last 15 months, i also came across the issue of the individual fuel cyl trim tables being disabled by activating dual fuel tables in the traditional tuning mode the other day, are you able to publish a list of all the known bugs so we can avoid them? Thanks

Thanks Adam, can you confirm that the timing applied below 400rpm is from the active ignition tables

When i use either aux 13 & or 14 as gp outputs i can see there outputs are correct in runtime values, but are always off when another aux uses them as an input, or you try to low side drive a relay. Is this a known fault, or could my ecu be faulty?

I have not yet recorded any data below 500rpm, but it seems that during cranking my ign timing value may be being determined by the "idle ign table" which i use for idle control, can someone confirm that? I had assumed it would come from the main ign map Thanks

Thanks for your help Adam, thats what i needed to know

Adam, are you able to comment on this, if i set timer or delay functions of say 10ms, is the likely result 10 to 50ms?

Perfect, thanks for checking Adam

The help says that processing timer values under 50ms is unreliable, i have for example n2o injected some distance before the engine and i implement timer functions to delay the change to ign timing until the n2o reaches the cylinders and in reverse on the turn off, the calculated times are obviously way less than 50ms, so am i wasting my time doing this? Thanks for your help

Thanks Adam, if you can confirm by bench testing that only a single upshift is triggered irrespective of how long the DI then remains active that would be great

Thanks Adam

Can someone confirm that if i use a DI to trigger an upshift torque reduction, and that DI then continues to remain active, that another upshift event is not triggered at the end of the maximum allowable "reactivation timeout" of 500ms??

I am unable to get a resistor spark plug in the heat range that i need to move to, can i use non resister plugs with a LINK ecu reliably?

Adding some Nitrous to help get up on boost, using a dry system with the 8 engine fuel injectors to provide the additional fuel, would have liked to just add a fixed injector DC increase across the effected rpm range, but can probably only add a percentage to the main map via the 4 or 5d tables which is messy as i have to estimate the engines power at each rpm cell to determine a percentage change for each one, then if the base engine power changed ie boost change, the added percentage will be incorrect, any ideas?? Black strip dyno only

Ok thanks Adam, external is all could come up with as well, are you able to add something like the following to the development wish list to solve problems like this: The ability to read and write values to memory that can be at least used by the virtual aux outputs

Hi Adam, i am bringing in vehicle height via an analog in no problem, but need to also determine whether the vehicle is rising or falling at any instant, to determine an appropriate ecu action.

I need to determine whether a input value is rising or falling to distingiush between two very different actions, to do this i need to compare the current input reading with a previous reading, is there a way to achieve this?

Hi Adam, thanks for your reply, i was trying to make sure my understanding is not where the problem is to start with. Have worked through the recordings now and understand how base DC% is applied in both dc mode 2 and 2-3. Because i am boost controlling a 4000cfm belt driven supercharger using 2 large valves, i do not have control over the drive source like a turbosetup, so the issue is that i have to control a larger volume of compressed air than normal. Seems that the volume of pressurised air in the pipework and aftercooler takes time to increase or bleed off that volume of air. Therefore i need to track the target closely or it takes too long to reaquire the target even if i allow large boost solinoid DC swings. So i think the issues are mine. Thanks

WGate DC is not necisarily the addition of the wastegate table DC + D + I + P, when in stage 3 operation in Base DC Mode stage 2, what else is influencing it?

can you expand over the help on how base DC, is applied during stage 2 mode, and stage 2-3 mode

Is recorded WGate DC% the final % applied to the boost solinoid output?, i have different boost outcomes when using "base mode dc mode" stage 2, or 2-3, when the same WGate DC% is recorded