Digital programmable CDI ignition for 2-stroke engines

[bob weir]

now that a better ,-71 deg , reference point is known the actual delays needed for every rpm-range
can now be measured. the MPASM timing tool will be used to do this.

the sizes of these delays determine the nature of the subroutine that will be used to
implement them. a table of these values will be the next posting

 

[bob weir]

ok troops , a preview of the delay time calculations is in order. so you can start thinking
about whats going on here . this is being done in lieu of a table of numbers. that will
follow in a later post. today you get a glimpse of what they are based on.

lets look at code execution time and compare it to the amount of time the code has to wait
until its time to send a 'fire' signal to the coil

see the aug 18 post for the actual mpasm range-test code. let rpm = 3000 so the nmbr
returned via TMR0 is 156 ( line 14 ). the t2 test code will detect this value to be in its
capture range. and the code will then jump to line 57 , a 2750 where the wait code will
be located. this wait code will be posted a bit later. for now it is important to know
the full range of wait delay values. this information is needed for the subroutine code
that does the waiting.

via playing with the mpasm stopwatch tool you can measure code execution time.
using 'set pc at cursor' and ' run to cursor' with line 14 set to 146 and the code built.

ex.. line 13 to line 17 takes 3 usec.
ex. line 13 to line 20 takes 6 usec
note - here the pc points to line 20 , the goto command. but this command is not executed yet
ex. line 13 to line 25 takes 9 usec
ex. line 13 to line 57 takes 11 usec.
note- the skip 's' in btfsc takes only one usec , and goto's take 2 usec.

ok , so we have used 11 usec to get the nmbr value located into the t2 range.
plus moving forward to where the delay code is going to be placed.

3000 rpm is 50 hz . and the period is .020 sec . .020 / 128usec = 156 = nmbr
anyway .020 sec / 360 deg = 56 usec / deg.

so at 3000 rpm the flywheel moves 11/56 = .20 deg . during the time it takes for the code
to figure the rpms are 3000

looking at the BTDC vs rpm graph we see a 'band' of allowed timing range for every rpm.
the band is about 2 deg wide. so our .2 deg of exec' time travel is well inside this range.

ok , recall too the range test code began to run at -71 deg btdc . and from the btdc vs rpm
graph we see that for 3000 rpm the advance angle is about 17 deg.
thus the code has to wait from -71 deg to -17 deg until its time to fire.
71-17 = 54 deg. and at 3000 rpm the flywheel is moving at 56 usec / deg.
54 deg x 56 usec /deg =- 3024 usec. this is how long the code has to wait
while running at 3000 rpm until its time for the fire signal.

the math here is easily checked. 54 deg / 360 = .15 and 3024 usec / 20000 usec = .15

now compare the 11 usec of exec time to the 3024 usec we have to wait until its time
to send the fire signal. the exec time is negligible. and with its .20 deg being
well inside the 2 deg range i think we are safe to ignore it. the 'it' being the
execution time of the range test code. doing this will make the focus be on
the wait time only. and not include the range test execution time

 

[bob weir]

tn is the test range number. 0 to 11 , for the rpms from 2000 to 5100.
and whats new now is the 7th column.
it is the wait time for that test until it is time to fire the plug. the last column is the number
of 20usec units of time in 8-bit decimal equivalent numbers.

the reader is left to figure out why 20usec was chosen for the unit of delay

there is a problem using a small unit like 20usec with this baseline uC and its single timer. delay code
typically loops and tests some decremented variable each pass. to see if it is zero yet or not.
then , if not , jumps back up to repeat the loop.
for long delays there can be several loops nested. the problem is that depending on the size of the
delay one wants the number of jumps ( gotos ) changes. and the 2usec addition of each goto
affects to total delay.

you'll find this out when you try it yourself, to code for a small delay ( 20 usec )
that you want to use repeatedly from 1 to 255 times in a row.

if we were using an intermediate category of uC with a 16-bit timer the job would be simple.
just load it with a value = 2exp16 usec minus the desired delay in usec , then set an interupt
for when the timer rolls over. the interupt routine will be coded so then what follows is
the fire command.

my approach with the code will be to use the mplab timer tool and experiment to find the column
8 number that actually results in the desired time delay. whether it be the exact column 8 value or not.

 

[bob weir]

sept 23 2015

delay code for 19usec delay per w-value



w delay , usec
10 195
20 385
50 955
100 1905
150 2855
200 3805
250 4755

the code :


1 movlw .100
2 call dly20u
3 nop

4 dly20u movwf d2
5 p2 movlw .5
6 movwf d1
7 p1 decfsz d1
8 goto p1
9 decfsz d2
10 goto p2

11 retlw 0

when in MPASM right click and apply 'set PC at cursor' to line 1
next apply 'run to cursor' at line 3
see the elapsed run time in the stopwatch window
as seen here for w = 100 the result will be 1905 usec
providing in the settings the clock is set for 4 mhz

by the table in the last post that lists time delays needed for each range test
you can see that for 2000 rpm we dont quite get the 5200 usec called for.
thus the code shown here needs some work. first off recognize that the largest
the w-value can be is 255. anything bigger just rolls over. ex. w=300 becomes 44 ( 300 - 256 ).
the first thing i'd try is edit line 5 movlw .5 to be movlw .6 and see what that does.

this link will show you where i learned to use the stopwatch tool. the video is lo-res fuzzy.
despite that the audio is rich with content of a how-to nature.

sorry too for the above formatting of the w/ delay list and code ... i used the editor here to
pretty it all up only the changes didnt last past the 'save changes' click step

 

[bob weir]

we're just about done with the code .
the next post will address the signal to fire the spark plug. this preview is to let you know the
energy involved. from the CDI circuit board designer, dr tony a. , it was learned that 30 mJ is enough,
so for now that value is what i'm working with.

'mj' is millijoules. joules are what you get when you multiply volts times farads.
the operating formula is energy = 1/2 * farads* volts-squared

example : farads = 2.2 uF and volts = 300
e = 1/2 * (2.2exp-6) * 300 * 300 = .099 joules or 99 mJ
99 mj makes a nice fat spark, but is way more than we need.

one thing we gain by charging C2 to a lower voltage is less time to get
C2 ready to a fire level.

as rpm's go up there is less time to charge C2. eventually not only does
C2 not have enough voltage for 30 mJ but there is not enough time for
the code to fire the plug when its suppose to.

remember this 12f508 is a 'baseline' uC and they all run at 4mhz max.
one goal of this whole project is to learn how well a baseline chip can
do the ignition job. and we are catching on that the first limit we reach
is at the upper rpm range. i.e. how fast can the code spin the motor.

right now my guess is we are ok up to the 6000-7000 rpm range.
we'll have this number pinned down better once the final program is
known and built


a lower voltage on C2 , say 200 instead of 300 , means we can spin the motor
at a faster rpm and have enough energy ready to maintain motion

the other major fact to work with is how long the fire signal needs to last.
we need to turn on the n-FET long enough for all the charge in C2 to get to the coil.
to find this out some experimenting has to be done . the variables then are size of C2 in ufarads,
the voltage
that C2 is charged to and the width of the fire pulse. the first 2 of these 3 items are an electronics matter,
and the 3'd is a coding matter. the size of C2 is whatever you buy and solder onto the board. the
voltage it gets charged to is a function of the size of the feedback resistors that send a 2.5 Volt
signal to the comparator. and for the pulse width i think we will be using the 20usec delay code again
for that too.

 

[bob weir]

on review the sept 15 post with that table of 8 columns of numbers ... there is an error in the bottom 2 lines ...
the paragraph that begins " my approach with the code ... " it refers to column 8 when it should say
column 7. the 7'th column is the delay to wait for that particular range of rpms. we're waiting
until the time is right to fire the plug. the time is right according to the timing-advance curve.

the 8'th column was created to show if the w-register value could fit in an 8-bit number. this w-reg
number is the number of times the 20usec delay subroutine runs in a row. the squeeze is on for low
rpms. we have to use a delay sub' big enough in unit-size such that 255 or less of them is enough
for the 5200 usec delay called for at 2000 rpm.

before the 20usec subroutine is called the number of times we want it to run is placed in
the w-register. ex. if we want it to run 100 times the code is " movlw .100 "
the 'l' in movlw is 'literal' and is what MPASM calls numbers. the '.' in '.100' tells
MPASM the following number is decimal.

ok , today i want to look at the fire-the-plug code block in the flow diagram of the july 25 posting.
not the actual code . but some pseudo-code in plain english. so we can read what the
actual code is suppose to be doing.

basically we are outputting a pulse on one of the 12F508's 5 i/o pins . this pulse goes
to the cdi circuit board and turns on the n-FET so that the charge stored in C2 can surge into
the primary of the ignition coil. upon which the secondary of the coil voltage increases
instantly into the multi-thousands and jumps across the spark plug gap.

in a later post will be a circuit diagram showing just where this pulse is connected.

by now from working with the gooligum baseline lessons you know how to code a pulse.
one way is to declare an output pin to be an output. then make it high, and keep it high for
a set period of time. than make it low again. the width of this pulse has to be just long
enough for the charge stored up in C2 to drain. in this case the time will be what is needed
for 30mj of energy to transfer from C2 to the ignition coil.

note that every range test is followed by some delay and then no matter how long the delay
was the next step is to go to this fire-the-plug subroutine.

once that's done. the spark plug firing , that's it for one revolution of the crankshaft.
so next the code jumps back to the very start and waits for the -71 deg btdc pulse.
and this entire sequence of steps in the flow diagram repeats.

and , yes , you read it right. the plug fires every revolution. and this code is for my
4-cycle yamaha engine. so one spark is wasted. its wasted because only every other
rev does the spark do any good. it does good on the power stroke only.

 

[bob weir]

another misprint that would have been caught by someone reading more carefully.
its the 4'th from the bottom paragraph of the most recent post. on sunday sept 27.

the line begins "by now from working ... " . and the misprint is " ... declare an
output pin ..." . it should read "...declare an i/o pin to be an output ... "

some tech jabber ... the uC , a 12F508, is an 8-pin device. and 6 of them are
available for i/o duties. 5 of those 6 can be programmed for either direction , input
or output. the 6'th is GP3 and is available for input only. this GP3 pin doubles as the
/MCLR reset pin. and we can use it if we want to. since the -71 deg signal is an input
one we have the choice of any of the 6 i/o pins. if we use GP3 for it then the gain is
an input pin with Schmitt characteristics. the tradeoff is being able to wire GP3 for a
pushbutton to reset the code.

on p. 13 of the data for this uC is table 3-2. it shows
which pins are of (ST) Schmitt input type. actually , now on re-reading this table i have doubt
i'm interpreting GP3 right. i think to use GP3 for /MCLR it has to be programmed for that
function. this is done in the Configuration word. and for it being used in a TTL function
one just uses the tris assembly directive to declare it as an input or output TTL pin.

this will be cleared up during the code test phase. this is coming up soon. we have
all the flow diagram blocks covered. so its time to string them all together into one single
assembly list program and build it .

then the uC chip will be programmed. and tested .

for the testing phase the chip will be fed a TTL square wave/pulse with a function generator.
this fct-gen signal simulates the flywheel -71 deg signal.
and the scope will be used
to monitor this signal and the output 'fire - the plug '' pulse.
using the math features of the
scope the rpm's can be determined and the time difference between these 2 signals.
they will be checked to see how close they come to the delays posted on sept 15.
the column 7 'A*B wait' . for each range of rpms .

if they are off then some code editing of the time delay will follow. or anything else
thats needed in the event something thats been overlooked turns up.

one thing does come to mind. having to do with the very first TMR0 value.
the reader is encouraged to give this circumstance some thought.

if the the measured delays are close enough then the next step is to connect
the uC to the CDI circuit and fasten them both to the motorcycle engine.

 

[bob weir]

the different flow-diagram blocks of code were put into one program. and it built. then was
tested with a signal generator and the rigol 1054 scope.
to see if the -71 deg simulated signal from the flywheel would lead to a fire signal.
nothing. no fire signal pulses were observed.
oh , there could of been a been a pulse way later than the viewed
scope timebase would have displayed.

this failure led to taking a closer look at the code. there it was found that there were both lines
not needed, and possibly causing problems. also a lack of needed code lines(s) was found in at least
one instance. these lines are leftovers from the individual blocks of code being tested one at
a time. then thrown together obliviously to un-needed testing leftover lines of code.

this faulty code is being posted. some of you may welcome the chance to study it as is to find
out what you think it needs in the way of fixes. its the same sort of exercise common to most all
coding projects. and is included for its reality nature.
in my view you are being cheated out of good lessons when the code works right
the very first time.

sure , it was a pisser to not work fresh out of the starting blocks. however once that fact is
absorbed then one can begin to look at it all and think what is wrong.
and take what it does do as a clue .

on doing this several new lessons were learned. valuable ones. for instance it was learned :

a. what is causing the 'Set PC at Cursor' and 'Run to Cursor' to grey out during the stopwatch tests.

b. that successive stopwatch tests can be run from the same starting point to a different stop point.

c. seeing the code in terms of 3 stretches of code with known run times. and these should add
to longer run times as the stop point for the stopwatch test is moved outward
the 3 code stretches that add up are 1. range test 2 . delay to fire 3. the fire pulse

c.1 to discover how valuable the simulator/stopwatch is for code testing
before you get to a hardware test.

d. also in the code building and then programming a 12F508 i learned the actual size of the code.
this is a big question to have an answer to. this uC has only 512 memory locations.
and this version of the ignition code used only about 120 of them. this was a lot smaller
than i expected it to be. now it is known there is plenty of space to add more range tests.
that is the range size can be reduced from 300 rpms to 200 or less. it'll take running
this version on the engine to learn if this change is needed or not

e. close to this was discovering how the number of lines of assembly code are a rough
approximation of the final size in the uC. 148 lines of code vs 120 uC ml's used.

i forgot to include a foto of the programmer screen. next time one will be posted. and
you can see how the uC memory contents are displayed by the PicKit-3 programmer s/w

 

[GPG]

View attachment 20189

The divider resistor/signal needs a bypass cap to remove the hash.

 

[bob weir]

here is a screen foto of the PICkit-3 s/w screen after a successful transfer of the cdi ignition
hex file to a 12F508 chip

the cursor points to '800' which is the last memory location used.
its address is 078 hex. which is 7x16 + 8 = 120 decimal
at this point this is all the program space our cdi ignition program uses

there is a lot of unused space on this uC chip. 512-1-120 = 391 memory locations

the '-1' in the above line is due to the location 01FF hex (512 decimal ) being permanently used
by the factory-loaded OSCCAL value. which you can find on the screen as having a value
of 0C28

 

[bob weir]

here is the cdi ignition code from the other day with a few changes. one reason no fire pulse was
output was due to the lack of 'call dly25u' at line 138. also there was some mis-use of a goto
when a call was needed. there's been some re-labeling of the delay code , lines 90 - 123
to make it more readable.

 

[bob weir]

this sheet shows test results of using the MPLAB stopwatch tool. all 12 delay paths were tested.
the time delay as measured by the stopwatch was compared with what was expected.
this expected value is simply the decimal
number in the movlw lines multiplied by 25u. and the 200 u fire pulse time added to that.
as you can see the difference between expected time and the stopwatch is the execution
time of the code that is handling these 2 delays.

 

[bob weir]

there are a few more tests to perform before connecting the uC to the cycle.

first is to simulate the nmbr value returned by the TMR0 code and verify the range test
correctly locates them all. the results of this test will be posted

second is to use the simulator with the watch window and see if the GPIO,2 pin
changes from line 136 to line 141. lines 137 and 138 will be commented out
to avoid having to step thru the 200uS delay

3'd will then be a hardware test with the fct gen and scope. and re-verify the time-delay to
fire for the different range-test rpm values. some of these screen shots off the scope
will be saved and posted here.

if the plug doesnt fire when its suppose to the engine could knock badly / be damaged.
so this h/w test will be the last thing done with the code/chip as a final assurance its
ready for wiring it all to the cycle.

 

[bob weir]

hey guys , the work on this project has slowed. in fact nothing's been done since the last post. same as for you , there
are a lot of other things to do that are grabbing for my time. including camping trips to the mtn's here in colorado.
a major storm is upon the land this week with snow in the high country that could well end the camping season.

a review of my files for this project was done earlier this morning. and turned up a number of items that
need a closer look . the code needs some simulation work. values for nmbr will be added to the code.
one at a time. the simulator may allow real-time signals. i dont know. at my present level of knowledge
it is lots easier to just code one nmbr value at a time and run it. to see the stopwatch exec-time.
and make sure the correct range test catches that test nmbr value.

first though the nmbr values to use have to be determined.
in a file a 7-column table of data was found of range test values. and it appears they have not been posted.
this table shows the literals used in the code. ex. the literal .91 in line 90.

also the 2 pulse signals connections to the cdi circuit board are being looked at.
the delayed -71 deg and the -9 deg signal. an idea at this time is to run them both to a 2-input
nor gate. doing this will solve the matter of interference if both signals went to the same u2 pin. the cost of
doing this is an extra chip to wire up. also by using a nor gate and not an or gate we are spared introducing
a delay equal to the width of either of these 2 0-1-0 pulse signals. we want a 1- to - 0 pulse edge to trigger the 'fire' action.
i.e. a leading edge. some bench testing is called for to verify the idea

something else that caught my eye was a possible error in the code. it has to do with the last range test. t11
and where the code next goes if nmbr is less than 91. remember that we are code-limiting engine rpm's to
about 5100 at this time.

one impression that arose in this review was how involved and complicated the details of this project are.
and how following along could be a challenge for many of the readers following these postings.
recently the focus has been on the individual blocks of the flow-diagram. and getting the code blocks to work.
now we are all moving along to the steps that follow the code being ready.

now is integration time. and its very different . a big shift in gears. like stepping out of the woods and looking
at the whole forest. i like it though. being in this place . and i'm optimistic we'll get something out
of it all that works.

bw

 

[bob weir]

this *.jpg table shows the literals in column 7 that appear in the code lines 41-85 for the range tests, posted oct 8

here's the math for the t0 line 41 code , col 7 of this table : .0300/128u = 234
the .0300 comes from : inverse ( 2000 rpm / 60 sec/min )

here's the math for col 6 of t1 : inverse ( .0273 ) * 60 = 2200 , the hi - end of the RPM range of col 2

note that all col 7 literal numbers are for the high end of each range test RPM range ex. 2200 of t1 range 2011-2200

note - line 16 of the 1st page of asembly code posted oct 8 is in error. it shows 111 for bits 2,1,0 for a timer0
prescaler rate of 1:256 ; we want 1:128 so bits 2,1,0 should be 110. this bit coding can be seen
in the PIC12F508 datasheet 4.5 OPTION Register
the correct line 16 is : movlw b'11010110'

 

[bob weir]

the code was updated , that is to say its known errors were fixed. it was tested with the MPLAB IDE simulator stopwatch and all
the numbers looked good. to affirm the code changes resulted in timing delays that were all in their expected range.

then a uC 508 was programmed. using a PicKit-3 programmer. next , on the bench, a 5% D.C. TTL pulse signal
was applied and the Rigol 1054 'scope was used to monitor this input signal and the uC 'fire' output signal.

the difference between their leading edges is the time-delay-to-fire. as per the timing-advance curve.

what we are looking for is that this time difference changes in a progressive manner as the input frequency ( RPM )
signal moves along the range of RPMs of about 1900 to 5100.

by these 3 screen shots with their cursor measurements you can see how test t1 , t6 and t11 look.
find 'BX-AX" on each scope screen shot in its upper left corner. there you will read the uS
time delay
the top foto is test t1 with a 4420 uS delay
the middle foto is test t6 with its 2320 uS tiime between the 2 pulse lead edges
the bottom foto is test t11 with a 1360 uS (1.360 ms ) measurement between the 2 cursors


in a day or two the updated code and the full table of t0 to t11 test results and the circuit of today's tests will be posted.

CH 1 , yellow , is the 5% duty cycle TTL input pulse that simulates the -71 deg signal off the engine flywheel pickup coil
CH 2 , blue , is the fire-the-plug signal the uC 508 produces some delay after receiving the -71 deg signal.

by code the fire pulse is about 200 uS in width. the bottom 2 fotos have a time base of 500uS
per vertical line. and you can easily eyeball the fire pulse width using the line
spacing as a ruler

given that the code measures the time between two -71 deg pulses you could be
wondering why 2 CH 1 pulses are not seen. and only one. think about their relative
size / spacing.
for the time-base choice to show 2 CH 1 pulses then the fire pulse at 200 uS in width is so narrow its barely a vertical line.
and easy to miss.
what i should have done for illustration is to
give it more width in code , say 1000 uS. just for the sake of seeing it better on the scope.
and the screen-shot posted here.

figured into this all is what to trigger on. if the scope is set to trigger on CH 1 then the
CH 2 pulse gets missed as it follows the 2'd -71 deg pulse. for what you see above
the trig was set for a CH 2 pulse greater than 2 uS in width. this was one of 5 choices
in the trigger menu.

 

[bob weir]

the fire pulse can be seen just to the right an 1/8" or less from the 2'd yellow pulse.
it doenst look like a pulse tho, the pulse is too narrow to even show up as a line.
all we can see for sure is its very top. , in blue. a blue dot

this scaling was referred to in the last posting. when pulses that vary widely in
spacing and width are shown at one horizontal time base

 

[bob weir]

this sketch shows the pulse generator and rigol scope connections of the
uC 12F508 uC circuit that was tested with the latest version of code. pul_2.asm

 

[bob weir]

here is a table of data from the bench test a few days ago,.

note that the signal generator is a digital one. so the HZ column is integer, and increases
in single HZ units. this made it nice to evaluate and verify the size of the RPM ranges
in an integer fashion, to the nearest whole number. that the code recognizes.

and once the HZ setting was outside this range the scope screen image would 'jump' to a new
display of the distance the fire pulse was from the 2'd -71 deg input pulse .

then the cursors would be re-positioned with the leading edges for this new BX-AX reading

 

[bob weir]

here are color scans of the 2 pages of the current version of assembly code for this CDI ignition project

as it is now the only way i know to print the *.asm code with line numbers is via MPLAB IDE with
the project open. then take those two print sheets and scan them into a *.jpg file.

the stand-alone .asm file is just a text file. and if i label each line
the MPLAB s/w will treat those numbers as code-line labels.
this messes up the true line labels.