in a sense it is a limiting factor if indeed your limited on how many dats you can log. What if I incorporate thermocouples on the input/output of intercooler ect.... and want to log all of these. Then I would not be able to get a good representation on what is going on unless I include other means then gather all info together to make adjustments.
lets take the 15 as you sugested. Say I want to log

1. boost
2. speed
3. TP
4. input temp of intercooler
5. out temp of intercooler
6. knockSum
7. Voltage
8. wideband
9. knock voltage
10. load
11. EGT
12. RPM
13. oil pressure
14. coolant temp
15. Oil temp
16. Conversion of time domain to frequency domain of filter #1
17.Conversion of time domain to frequency domain of filter #2
18Conversion of time domain to frequency domain of filter #3
19.Conversion of time domain to frequency domain of filter #4
20.Conversion of time domain to frequency domain of filter #5

thats already 20.

 

There are usually practical limits to everything. You have to make due with what's available until something better comes along. If you really feel that its necessary to log 20 items, then you'll have to settle with a maximum sampling rate of 9 samples/sec per item which isn't too bad. If you want a better sampling rate, then you'll have to reduce the number of parameters that you log.

The main point I was trying to get across is that the ECU is in fact very fast at providing data, and EvoScan is fast at obtaining the data from the ECU, apparently faster than the current version of Logworks.

 

Knock sum on lift off, and wideband during acceleration enrichment could do with being fast. Nothing else would be any more useful by being logged quicker IMHO.

To focus on these two issues (if you need to) a log of the lambda, TPS, RPM, boost and knocksum only would be at 36Hz.