##   
         
    ##   
    ##   
    ##   
    ##   
    ##   
  ###    

  ____  
 |  _ \ 
 | | | |
 | |_| |
 |____/ 
        

  _______ 
 |__   __|
    | |   
    | |   
    | |   
    |_|   
          
          

______ 
| ___ \
| |_/ /
|    / 
| |\ \ 
\_| \_|
       
       

         
         
 # ###   
 ##   #  
 ##   #  
 # ###   
 #       
 #       

IMPORTANT: enter the case-INsensitive alphabetic (no numbers) code AND WRITE SOME SHORT summary of changes (below) if you are saving changes. (not required for previewing changes). Wiki-spamming is not tolerated, will be removed, so it does NOT even show up in history. Spammers go away now.


Visit Preferences to set your user name
Summary of change:
'''Developer information for timing from the last possible tooth''' * Timing from last tooth * and overlapping dwell * the restrictive cam-sync condition was also dropped (that required campulse to clear from the spark-advance window). Now the only restriction is that the campulse must not race with the primary trigger tooth0 (tooth right after the missing tooth) is implemented in stable1_1 branch (eg. 1.0.63 firmware release). * 15-1 was done first (with camsync) for a 5cyl racecar that needed this * other N-1 and N-2 also implemented (60-2 running on car) ** more tooth is more demanding => with '''60-2 trigger, 8cyl, 24800 RPM was possible''' (primary_trigger=01; tooth_wheel=3A; another_trigger_tooth=0F; fortunately my soundcard likes 96000 sps because normal 44100 sps is not enough for this test !) * Auditrigger 135 tooth also implemented. More tests needed. ** with 135 tooth, the limit is appr 20800 RPM (appr 3x higher than earlier; possible to push further if needed) '''Should follow soon:''' (these are supported by the old firmware, but not yet supported by the overlapping dwell code) * auditrigger with 142 tooth * distributor (overlapping dwell not possible anyway, but timing from last tooth would be nice and we want to maintain only one branch) * coil type trigger ---- '''Test cases''' There are many setups to test, eg. * odd-v6 [http://www.vems.hu/files/Firmware/design/MultiTooth/EngineV6_36_overlap.txt output example] In the example, dwell is overlapping between cylinders 90 degrees apart, but not overlapping between cylinders 150 degrees apart. * '''rotary''' * 4..16cyl wasted spark * 4..8cyl COP spark throughout * RPM ranges (including continuously changing RPM so the proposed_spark_tooth changes) * ignition advance * dwell * position of missing tooth. This means many combinations. We added test-code that verifies the dwell, ignition advance, overlap etc... so less manual verification is necessary. ---- Good sides: * multitooth support: InputTrigger/MultitoothTriggerWheel * basic camsync support (with some limitations) But it's still limited in several ways. * oddfire V6 * rotary * GenBoard/Manual/InputTriggerCamSync condition could be dropped * the best possible precision with fastest accelerating engines The '''target is to remove limitations, add support for practically the most exotic configurations with precision unthinkable''' for competing ECMs. ---- '''The good-old multitooth code is at the very core we build on''' Simple m-n tooth wheel decoding has been operational since October 2003. However even though the simplistic implentation worked good in practice, it had the same drawbacks as a ''simple'' trigger: ''the fixed distance in crank degrees from trigger to spark-fire, makes it sensitive to changes in rpm''. Compensating with the derivative of rpm helps the problem, but doesn't solve all problems. The intention of this page is to describe how the ''fixed distance'' is reduced, by trigging from the last tooth possible on the multitooth trigger wheel. ---- '''Kindergarden review - basic specifications''' To architecture a good toothwheel interface, let's try to collect the demand: basically the '''end of known length''' (dwell and injector-pulsewidth) '''pulses need to be timed to exact engine-position'''. If the RPM changes somewhat (this is generally a very small effect, generally neglected), this will not be dead-sharp: * for '''injection we insist on the pulsewidth'''. If RPM changes in the meantime, the injection will not be ending sharply timed to the valve-close, but measured quantity is exact. (but we make the end of injection configurable, of course) * for '''ignition we insist on the precise end of the pulse timing''' (because that releases spark) even if the length of the pulse will be somewhat off (should the RPM change somewhat in the meantime). InputTrigger/TriggerLog showed that RPM variations can be surprisingly big even within 100 degrees of crank rotation. This justifies the "timing from last possible tooth" approach. However this makes little difference in the output of fuel and ignadv calculations, so there is no need to make sure they are done within the last few degrees (last 250 degrees is very fine) ---- '''The trig from last tooth consists of:''' * m-n tooth wheel decoding * engine phase update * actuation according engine phase and state machine * trigger phase calculation (userspace) '''tooth wheel decoding''' [multitooth.c: tooth_detection()] :Measure the time ''t'' between two interrupts (teeth). If ''t'' is significantly longer then the previous ''t'', then the missing tooth has been found. This is by tooth_detection() signalled by the return variable. One flag (in the return variable) of particular interest is when the missing tooth is found for the first time (eg. during the synchronization), see engine phase. '''engine phase''' [timing.c: update_engphase()] :A variable ''engine.engphase'' holds the engine phase. While the crank rotates 0..720 degrees (2 crank rotations), it will go round and round, 8 bit is enough: :* 0..215 (mod216 for 36 tooth, += 3 at every tooth) :* 0..239 (mod240 for 60 tooth, += 2 at every tooth) :* config.reset_enginephase_after in general :When tooth_detection() signals that the missing tooth is found during synchronization, the engine phase variable is initialized with the value of config.engphase_sync. At the same time, igncount is initialized and the ''first'' (trigger phase, trig2spark) set is loaded. [timing.c: engphase_trig()] :If the engine phase matches the precalculated ''trigger phase'', the ignition schedule handler will be activated. [timing.c: next_engphase_trigger()] :''After'' the ignition handler has scheduled the IGNDEACT event, the variable igncount is updated and the next (trigger phase, trig2spark) set is loaded. This is the only place where ''engine.igncount'' is modified (except update_engphase() during tooth wheel synchronization), thus synchronization issues is non-existing. '''trigger phase calculation''' [ve.c: calc_trigger()] :The purpose of calc_trigger() is to lookup at what engine phase the tdc will occur (from the tdc-engphase table), and compute how many, N, teeth are needed to step back from tdc, such that N*[degrees/tooth] >= ignition advance. In case the computed engine phase corresponds to the missing tooth, further back stepping will be done until an engine phase that matches a real tooth is found. [ve.c: decrease_engphase()] :Helper function; decreases engine phase and handles overflow. [ve.c: phase_in_missing_tooth()] :Helper function; returns the distance (in engine phase units) from suggested trigger phase to the tooth before the missing tooth. In case the suggested trigger phase doesn't overlap the missing tooth, nothing is done. minor syntax question: should we use a typedef for engphase variables? (but uint8_t for now). Both for clarity and for future (maybe it worths to use more bits for some reason on other processors). ---- '''Dwellstart overview''' With the timing from last tooth, the early_dwellstart can be activated at any low RPM if the dwelltooth is not determined independently: not good (dwell might be longer than desired). Dwellstart for the most generic case is somewhat more complex than igndeact. * calculation of proposed_trig2dwell[] and proposed_dwellphase[]: similar as calc of proposed_trig2spark[] (in ve.c) * actuation: DONE. same way as deact is scheduled: using condition engphase_trig(trigger1.dwell_phase) * early_dwell: for '''every spark (dispatcher igndeact), dwellstart must be scheduled right away if''' ** the '''time available for dwell is less than 200 usec + desired dwell''' ** or '''the next dwellstart should happen earlier than the next tooth comes'''. '''TAFD''' - time available for dwell (TAFD) is particularly interesting: * h[2]=02 03 02 03 (TAFD = 360 crankdegrees) * h[2]=05 04 02 03 (TAFD = 720 crankdegrees) We calculate TAFD at the same time we calculate proposed_dwellphase and proposed_trig2dwell. '''h[2] must be traversed''' to see when the same output channel is fired. '''The relevant elements from h[1] must be looked up, and the difference is the TAFD itself'''. notes: * assuming ignition advance is the same * overflow must be considered, namely adding config.reset_engphase_after if needed This '''same algorithm applies for COP, wasted spark, distributor or oddfire-V6'''. Check <code> JTune CVS org.vemsgroup.firmware.engine.UserspaceCalc.nextIndexWithSameIgnout() </code> http://www.vems.hu/files/Firmware/design/MultiTooth/lasttooth_marcell_1.png As you see, there are 3 scenarios, represented with 2 flags: dd2ds (dwellstart => spark), ds2dd (spark => dwellstart) * 1,0 very low RPM: same tooth schedules act, and fills sparkat: act schedules deact, same 0-1-2 as the simple trigger we always had (dwell_phase == spark_phase but there are no tooth between them) * 0,0 normally a tooth schedules act, and a later tooth schedules deact. dwell_phase != spark_phase * 0,1 at very high RPM the deact can schedule next act: (3-4-2, or early dwellstart) dwell_phase == spark_phase, and there are tooth between them (these are found automaticallyl when looking for the dwell_phase) Issues: '''where to decide ?''' * userspace (The dwellstart phase does not look good in irq).This is agreed on. * or irq ? NO! ---- '''Ignition state machine in detail''' - do we keep the explicite ignstate[] array and what is the exact state-machine Note that the ignstate might be redundant with the * igncount and igndwellcount variables (not arrays, just 2 numbers; very efficient for the irq-routine) * knowing current engphase * and point of execution However there might be benefits from having explicit ignition state (array): * simplicity (easier to code and review) * speed: simpler conditions for the processor: faster execution The decoupled (non-independent) flags that are of interest: * heap-state: lower 2 bits: what is actually scheduled (0/1/2 for nothing/dwellstart/spark as used in old code) for the given cyl. * coil-state: '''is the coil actually activated/being charged'''? Might be useful at several places, but particularly important when early dwellstart is active, at the race between trigger and ignact (ignstate==4 or ignstate==3 in the old code). Userspace suggestions or in-irq decisions that effect the actuation: * dd2ds: '''should igndeact be scheduled from the dispatcher ignact''' action (using sparkat), or igndeact scheduled from a later tooth * ds2dd: ''' should ignact be scheduled from the dispatcher igndeact''' action (early dwellstart), or ignact scheduled from a later tooth The new ignition-state concept (more spectacular than the old, but still only 5 states) is discussed in detail: <code> JTune CVS org.vemsgroup.firmware.engine.IgnitionState class </code> ---- '''Limitations''' Only 1 channel is allowed to start/schedule dwell or spark from any given tooth. This has always been this way. Actually, it only takes a "while" line around the ''engphase_trig(dwell..); engphase_trig(spark..);'' actions, but I don't know where it's needed. Maybe it could be a my_make option. * rotary: with 24-tooth wheel, the trailing spark traditionally comes 15 crankdegrees after the leading spark. Consider: slight change in dwell or ignadv could cause collision and therefore a tooth-miss with the simple engphase_trig() implementation ? maybe the while is a good idea :-) * Alpha twinspark: what is the desired crankangle (or time?) between the sparks? Are they simultaneous ? ---- '''See also''' * GenBoard/UnderDevelopment/FirmWare/TriggerRelated * AdvancedIgnition/ThetaDyno
Optional: Add document to category:
Wiki formatting: * is Bullet list ** Bullet list subentry ... '''Bold''', ---- is horizontal ruler, <code> preformatted text... </code> See wiki editing HELP for tables and other formatting tips and tricks.