Ok, Here goes nothing...
First, for Bruce:
...is the code running continuosly or on a series of interupts.
Definitely interrupt driven. Timing is even more crititcal in aftermarket applications. How many OEM ECMs see applications on engines that spin to 12K or 15K RPMS? Especially with strange crank signals like a 60-2 tooth wheel. Think about the measurement and calculation interval for the crank signal on a 15KRPM * 60 Tooth application.
Are they actually doing PW corrections as the injector is firing.
That and much more.
Are any of the programs really turbo specific?.
How about a strategy that allows control of MAP via a programmable rev limiter in order to cause a turbo to spool up instantly on the starting line?
If you read thur what GM has been doing for years, are they even trying to match them?. GM has had a Power enrichment multiplier for time in PE since the GNs came out.
GM Racing has been using the DFI 7+ box to run their FWD drag cars since their inception. Here is how the last race went:
PRO FWD Class
Hot Rod FWD Class
Note that the Civic that beat the PRO FWD Cavalier also runs the DFI 7+ system.
TCC stuff has been ignored just until lately by the aftermarkets.
DFI has had TCC control in the Gen 7 box since it box came out.
I see from the last post the 8 to 32 bit advantage seems to be in datalogging...
32 Bit processors are very rarely used for engine controls. Tried and true 8 and 16 bit mcus are much more cost effective, and provide plenty of speed/resolution. Advantage of 32 bit procs is floating point math, but that requires much higher clock speeds, and quickly becomes financially unfeasible. On the other hand, Analog-to-Digital converter resolution is very important, and it takes a decent processor to give you at least 10-bit A/Ds. This has limited the use of 5 BAR MAP sensors due to the coarseness of MAP measurement that would be seen with 5 BARs at 8 bits.
OK, how many frames a sec will the new aftermarkets record at?, and how many parameters?. Will they accept extra channels.
Depends on whether or not the system has internal SRAM ($$$) for onboard data storage, as well as the number of free analog and digital inputs on the processor. Higher end systems record internally at 50-100 Hz, for short periods of time. These systems usually offer a few unused analog and digital inputs to be configured as extra datalogger channels. In the case of the DFI class systems, no SRAM internally, so no onboard data storage. Likewise, no extra pins for datalogging, so data is xmitted via serial link and RFI limits the effective bandwidth.
Why don't they release the Source Code, for people to look at?.
Ask Microsoft, Apple, Sun, Adobe...etc the same reason, and you'll get the same answer. Proprietary Intellectual Property. OEMs make no profit specifically on their engine control systems, so they lose no real money by releasing the details of it's operation to the public--long after the fact.
Some other random thoughts about things brought up in this thread:
On the original topic of this thread, Mr. McCall, your car is not tuned properly! Look at your warmup enrichment, Air Temp correction, and Fuel Map for starters.
OEMs typically take several thousand hours to generate a calibration for a single platform. Aftermarket calibrations, when done by someone who knows their stuff, can be finished in a day.
On the DFI Gen 6-FAST link, maybe someone from FAST can explain why DFI's parent company is CURRENTLY paid a royality by FAST's parent company for each and every FAST unit sold today. Not trying to slander/badmouth anyone, but that is just how it is. Draw your own conclusions.