Inline 5-cylinder, sequential ignition with camsync
Primary trigger: 60-2 w/ VR sensor.
Secondary trigger: Single tooth w/ Hall sensor.
The rising edge of the cam wheel hits the sensor after cylinder three fires and before cylinder one does.
Firing order is 1-2-4-5-3.
MembersPage/RonnieH has set up VEMS on a very similar motor also with seq. COP. After some additional reading, his settings seem obsolete due to code changes.
Primary trigger settings
Field name | Variable name | Value [decimal] (Value [hex]) | Comment |
Primary Trigger | primary_trigger | 1 (0x01) | For multi-tooth trigger without filtering (I think). 0x09 is with filtering? Which should I use? |
Edge | Rising | ||
Type | Multitooth | ||
Filtering...Bit7 | Disable | ||
TDC after the trigger | ign_tdcdelay | 60 (0x3C) | The GenBoard needs to know ahead of time when a cylinder is going to be at TDC. This is to allow for a certain amount of ignition advance. It needs about 60 degrees of 'lead time'. ign_tdcdelay is this lead time. Look at the tooth under the sensor at TDC of cylinder one (16 in my case), count backwards toward the missing teeth until you are ~60 degrees BTDC. In my case this is exactly 10 teeth and 60 degrees. |
Number of teeth on wheel | tooth_wheel | 58 (0x3A) | 60 "total teeth" - 2 missing teeth = 58 actual teeth |
Trigger tooth | trigger_tooth | 5 (0x05) | TDC of cylinder 1 (tooth 16) occurs 15 teeth after the first actual tooth following the missing teeth. 15 teeth is 90 degrees. ign_tdcdelay is already 60 degrees, leaving 30 degrees (or 5 teeth). This is trigger_tooth. Confusing as shit, I know. See illustration below. More concise explanation here: InputTrigger/MultitoothTriggerWheel |
Next trigger tooth | another_trigger_tooth | 24 (0x18) | (from GenBoard/UnderDevelopment/FirmWare/TriggerRelated, 60 (teeth on the wheel) * 2 (wheel revolutions per cycle) / 5 (ignition events) = 24 teeth between events |
Crank min. period | crank_minper | 188 (0xBC) | 60 (seconds) / 8000 (max rpm) / 5 (number of engine events) * 2 = 0.003 (seconds) = 3000 (microseconds). In units of 16usec, so 3000usec / 16 = 188 [decimal] = BC [hex]. Can someone confirm this is the correct formula? Or even what this value means? |
Tooth normal relative min % | 25% | ||
Tooth normal relative max % | 150% | ||
Tooth missing relative min % | 200% | ||
Tooth missing relative max % | 413% |
Secondary trigger settings (these are not used in 1.1.x, so only here for future use)
Field name | Variable name | Value [decimal] (Value [hex]) | Comment |
secondary_trigger | (0xFE) | For rising edge trigger | |
tooth_wheel_twidth1 | 24 (0x18) | Width of a single tooth on wheel, in quarter degrees (360/60 = 6 degrees per tooth, 6*4 = 24 quarter degrees per tooth, 24dec = 18hex) | |
tooth_wheel_twidth2 | 0 (0x00) | Not sure on this one either, changelog says set this to 0, but why? | |
Rising Edge | cam_sync_r_edge_phase | 2 | See: Note |
Falling Edge | cam_sync_f_edge_phase | 6 | See: Note |
Engine phase, when to reset | reset_engphase_after | (0xF0) | See: Note |
Note: According to GenBoard/Manual/InputTriggerCamSync
Re-iteration for this section: The rising edge of the cam wheel hits the sensor after cylinder three fires and before cylinder one does.
Firing order is 1-2-4-5-3.
Ign. outputs will connect as follows (for 2+6 configuration, according to PhatBob's User Guide):
Cylinder | Ign. channel | ECU Pin |
1 | 00 | EC36/35 |
2 | 10 | EC36/33 |
3 | 40 | EC36/11 |
4 | 50 | EC36/12 |
5 | 60 | EC36/24 |
h[2] is ignchannel array, h[2] = 00 40 60 50 10 00 00 00. So the array is traversed backwards starting at '10' (cyl. 2) (since "Ignition outputs to use in h[2]" will be '04..00'). Because the ignchannel traversal is reset after the ignition event following the cam-sync, cylinder one needs to fire last in the order.
Differently stated: h[2] = 00 <cam sync occurs here> 40 60 50 10 <traversal begins here> 00 00 00
I drew a pretty picture:
According to the changelog for 1.1.x: h[1] is the reference tooth array (trigger_tooth and ign_tdcdelay is added to this to get TDC), for each output specified in respective h[2] entry.
h[1] = 01 61 49 31 19 00 00 00 (Note: These numbers are in hex)
Stated in decimal, h[1] = 01 97 73 49 25 00 00 00
Confirmation on the above values would be greatly appreciated.