Hardware limitations - Revision history

PRJ at 15:17, 16 December 2017

2017-12-16T15:17:55Z

PRJ: /* RPM limit */

2017-11-01T12:06:07Z

RPM limit

PRJ: /* RPM limit */

2017-11-01T12:05:25Z

RPM limit

PRJ at 12:03, 1 November 2017

2017-11-01T12:03:56Z

PRJ: /* RPM limit */

2017-11-01T12:01:52Z

RPM limit

PRJ: /* RPM limit */

2017-10-31T23:59:22Z

RPM limit

PRJ: /* Dwell time */

2017-10-31T23:54:41Z

Dwell time

PRJ: /* RPM limit */

2017-10-31T23:52:31Z

RPM limit

PRJ: Created page with "=== RPM limit === The fast diag puts quite a bit of strain on the boost/knock processor, which is already very strained.
It is possible to modify the code, but the curren..."

2017-10-31T23:51:44Z

Created page with "=== RPM limit === The fast diag puts quite a bit of strain on the boost/knock processor, which is already very strained. It is possible to modify the code, but the curren..."

New page

=== RPM limit ===
The fast diag puts quite a bit of strain on the boost/knock processor, which is already very strained. 
It is possible to modify the code, but the current implementation does not run fast enough to deliver fast logging data past 8000 rpm, even at greatly reduced sample rates. 
With fast logging disabled the meaningful limitations on the engine revs is about 8500 rpm. 

=== Dwell time ===
Due to the solid-state distributor design, the fuel/ign processor outputs a pulse just like a normal distributor based system. 
This means that it needs to output 5 spark events every cycle. This sets some limits on the theoretical maximum dwell time: 
{| class="wikitable"
|-
|RPM (1/min)
|Dwell time (ms)
|-
|1000
|24.00
|-
|2000
|12.00
|-
|3000
|8.00
|-
|4000
|6.00
|-
|5000
|4.80
|-
|6000
|4.00
|-
|7000
|3.43
|-
|8000
|3.00
|-
|8500
|2.82
|}
Realistically the actual maximums are a little lower. For high output applications it is recommend to use the VAG TFSi coil packs. 
They are fully charged between 2.5 and 3ms, they are cheap and they give a very strong spark.

=== ECU Speed ===
The boost/knock control chip runs crank-synchronous in real time. 
The fuel/ign control chip injection time and ignition output runs crank-synchronous in real time. 
The fuel/ign control chip main loop (map lookup) runs at 100hz or best effort. 
It can keep updating 100 times per second up to about 5000 RPM, after which the final injection/ignition output calculations start to take more and more processor time and the main loop gives way. 
At 8500 RPM it still runs at over 30hz. Plenty fast enough for the global low-impact calculations.

← Older revision		Revision as of 15:17, 16 December 2017
Line 50:		Line 50:
	It can keep updating 100 times per second up to about 5000 RPM, after which the final injection/ignition output calculations start to take more and more processor time and the main loop gives way.<br/>		It can keep updating 100 times per second up to about 5000 RPM, after which the final injection/ignition output calculations start to take more and more processor time and the main loop gives way.<br/>
	At 8500 RPM it still runs at over 30hz. Plenty fast enough for the global low-impact calculations.		At 8500 RPM it still runs at over 30hz. Plenty fast enough for the global low-impact calculations.
		+
		+	=== ECU precision ===
		+	Ignition precision target is 0.75 degrees. Knock retard precision is 0.5 degrees.<br/>
		+	Injection precision in the fuel/ign chip is near infinite, because it is represented using an exponent and mantissa. How precise it is in the sequential injection driver is unknown.<br/>
		+	RPM precision is 1 trigger tooth.<br/>
		+	Boost precision is 8 bit, meaning for a 400kpa sensor, it is roughly 1.6kpa.<br/>

@@ Line 3: / Line 3: @@
 It is possible to modify the code, but the current implementation does not run fast enough to deliver fast logging data past 8000 rpm, even at greatly reduced sample rates. If you push it, the ECU will hard reset.<br/>
 The reason is that the fast logging code runs off of the RX/TX interrupt and the RX/TX interrupt calls are not only expensive, but they get higher priority than many other calculations, thus the ECU does not have data ready at some point for the next cycle. To fix it, the byte send code needs to be injected in a few places elsewhere. This is already done in the fuel/ign processor.<br/>
-With fast logging disabled the meaningful limitation on the engine revs is about 8500 rpm, after that you run into dwell issues.<br/>
+With fast logging disabled the meaningful limitation on the engine revs is about 9000 rpm, after that you run into dwell issues.<br/>
 === Dwell time ===

@@ Line 2: / Line 2: @@
 The fast diag puts quite a bit of strain on the boost/knock processor, which is already very strained.<br/>
 It is possible to modify the code, but the current implementation does not run fast enough to deliver fast logging data past 8000 rpm, even at greatly reduced sample rates. If you push it, the ECU will hard reset.<br/>
-The reason is that the fast logging code runs off of the RX/TX interrupt and the RX/TX interrupt calls are very expensive. To fix it, the byte send code needs to be injected in a few places elsewhere. This is already done in the fuel/ign processor.<br/>
+The reason is that the fast logging code runs off of the RX/TX interrupt and the RX/TX interrupt calls are not only expensive, but they get higher priority than many other calculations, thus the ECU does not have data ready at some point for the next cycle. To fix it, the byte send code needs to be injected in a few places elsewhere. This is already done in the fuel/ign processor.<br/>
 With fast logging disabled the meaningful limitation on the engine revs is about 8500 rpm, after that you run into dwell issues.<br/>

@@ Line 2: / Line 2: @@
 The fast diag puts quite a bit of strain on the boost/knock processor, which is already very strained.<br/>
 It is possible to modify the code, but the current implementation does not run fast enough to deliver fast logging data past 8000 rpm, even at greatly reduced sample rates. If you push it, the ECU will hard reset.<br/>
-The reason is that the fast logging code runs off of the RX/TX interrupt and the RX/TX interrupt calls are very expensive. To fix it, the byte send code needs to be injected in a few places elsewhere.<br/>
+The reason is that the fast logging code runs off of the RX/TX interrupt and the RX/TX interrupt calls are very expensive. To fix it, the byte send code needs to be injected in a few places elsewhere. This is already done in the fuel/ign processor.<br/>
 With fast logging disabled the meaningful limitation on the engine revs is about 8500 rpm, after that you run into dwell issues.<br/>

@@ Line 2: / Line 2: @@
 The fast diag puts quite a bit of strain on the boost/knock processor, which is already very strained.<br/>
 It is possible to modify the code, but the current implementation does not run fast enough to deliver fast logging data past 8000 rpm, even at greatly reduced sample rates. If you push it, the ECU will hard reset.<br/>
-The reason is that the fast logging code runs off of the RX/TX interrupt and the RX/TX interrupt overrides some other logic due to speed. To fix it, a scheduler needs to be created that would avoid vectoring to the interrupt for sending every byte.<br/>
+The reason is that the fast logging code runs off of the RX/TX interrupt and the RX/TX interrupt calls are very expensive. To fix it, the byte send code needs to be injected in a few places elsewhere.<br/>
-With fast logging disabled the meaningful limitations on the engine revs is about 8500 rpm.<br/>
+With fast logging disabled the meaningful limitation on the engine revs is about 8500 rpm, after that you run into dwell issues.<br/>
 === Dwell time ===

@@ Line 6: / Line 6: @@
 === Dwell time ===
 Due to the solid-state distributor design, the fuel/ign processor outputs a pulse just like a normal distributor based system.<br/>
-This means that it needs to output 5 spark events every cycle. This sets some limits on the theoretical maximum dwell time:<br/>
+This means that it needs to output 5 spark events every cycle, because as the logic output goes high, the coil starts charging, and as it goes low the spark is fired.<br/>
 {| class="wikitable"
 |-
@@ Line 40: / Line 41: @@
 |}
 Realistically the actual maximums are a little lower. For high output applications it is recommend to use the VAG TFSi coil packs.<br>
-They are fully charged between 2.5 and 3ms, they are cheap and they give a very strong spark.
+They are fully charged between 2.5 and 3ms, they are cheap and they give a very strong spark - enough for over 700 hp on Ethanol.
 === ECU Speed ===

Hardware limitations - Revision history

PRJ at 15:17, 16 December 2017

PRJ: /* RPM limit */

PRJ: /* RPM limit */

PRJ at 12:03, 1 November 2017

PRJ: /* RPM limit */

PRJ: /* RPM limit */

PRJ: /* Dwell time */

PRJ: /* RPM limit */

PRJ: Created page with "=== RPM limit === The fast diag puts quite a bit of strain on the boost/knock processor, which is already very strained. It is possible to modify the code, but the curren..."

PRJ: Created page with "=== RPM limit === The fast diag puts quite a bit of strain on the boost/knock processor, which is already very strained.
It is possible to modify the code, but the curren..."