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