Digital programmable CDI ignition for 2-stroke engines

[bob weir]

progress report mar 9 .
the code is ready for testing. and was loaded into a 12F508. a no-scope approach is being worked.
and once the fire-signal-out looks good the scope will be attached. as only with the scope can the actual
delays following the -71 signal be verified.
experimenting with a single pulse to the -71 pin yields a single pulse on the fire pin. or it did once. and now it wont repeat.
a single fire out pulse is expected as t_dly is preloaded prior to a -71 signal being detected. this should result in a t_dly followed by the fire pulse.
then the code is suppose to loop at the GP3 pin until the -9 signal comes along.
looping there means the single -71 pulse will result in a fire pulse on GP2 only once
in order to get this to happen though the pulser and logic probe are already connected to the uC when they all have +5 power applied. doing this step
allows transients from those 2 devices to interact with the uC pins.
and these transients could be what is causing the GP2 pin to fire
adding pull-down resistors did not remedy this matter. one idea to try is edit the
code so that pin 4 /MCLR ( the -9 input pin GP3 ) is enabled.
this will allow the uC to be reset with a switch instead of having to cycle the +5 V supply. thus there should be no pulser & probe transients on the input pins. this is what will be tried first. enabling the MCLR pin function.
and re-coding so GP4 is the -9 input pin , not GP3

oh , one thing learned along the way ... using the logic probe on all 6 i/o pins revealed that
only 4 of them would indicate a logic 0 ( the default ). at first i thot something was wrong with
this uC. then realized the 2 pins not showing a logic 0 were setup as inputs. so , of course,
they would not signal a logic level.

 

[bob weir]

mar 17 progress report . a square wave with a period the width of the time for 62 deg of rotation is being used as
a test signal. it is believed this is ok to do. and is being applied to both input pins simultaneously.
the test signal is from the TTL port of a DDS signal generator. and on p. 13 of the PIC12F508 data sheet the pins
GP4 and GP5 are shown to be of type : TTL.

it is common in this TTL family for one output to have a fanout ability to connect directly to a
handful of inputs that are TTL too at the same time.

and the first pulse
edge is treated as tho its the -71 signal from the flywheel. and the next pulse rising edge taken as the -9 deg one.
the reason the expect this to work is that the code looks at these 2 signals sequentially. and , in fact , loops to
wait when it sees a low level. then when the signal changes from low to logic high some
following code executes.

it has seemed reasonable to test the code this way. only the delay seen with the scope before the fire
pulse emerges from the uC is not what is expected. not even close. and is puzzling.

another approach is being worked. to use a test signal made up of 2 distinct pulses that simulate the -71
and -9 ones from the flywheel. the easiest way to get such a signal is to code a 2'd uC to provide them.

this code is being worked on right now. the first version will provide signals for one of the RPM ranges.
for example test no. 3 catches flywheel rpms in the range 2600 to 3000. and gives them all the same
delay until the spark plug is fired.

the main parameters in the code will be a variable that sets the time between the 2 output pulses.
and the other variable will set how long before this pair of pulses repeat.

thus it will be a snap to edit the code, re-burn the uC and test the next rpm range. and scope
to see if the 1'st uC code is outputting the fire pulse after the right amount of delay.

later today or tomorrow the new test signal code will be finished. and can then be
applied to the uC with the ignition code in it. and hopefullu the delay-to-fire times
will look better than they do now.

 

[bob weir]

the following 3 documents are a proof-of-code-idea for using a 2'd uC as
a source of signals to test the ignition code with.

first is the code. one page. to get it all to fit on a single page all the line spacings had to ..................... be removed
then are 2 scope images. they show where the coded delays occur.
and reveal how by simply editing 2 literals one can have signal code
that simulates any of the RPMs and the flywheel -71 and -9 degree signals
the ignition code will ever see.

note : the times shown are arbitrary. and no effort was made to make
them actual to the engine. that'll be the next step

 

[bob weir]

 

[bob weir]

 

[bob weir]

 

[bob weir]

see BX-AX = 1.240 ms in the text box of the upper left of the screen

lines 21 and 22 generate the 1240 uS delay seen between the trailing edge of the -71 deg pulse and the leading edge of the following -9 deg pulse.

the code has the 125uS delay code repeat 10 times.
10 x 125 = 1250 and the measured value of 1240 is good


the time between the 71 and 9 pulses is a matter of how fast the flywheel is spinning.
and this time is what the uC TMR0 module measures in units of 32 uS


correction - the TMR0 measures the time between the leading edges of the 71 and 9 pulses.
shown here is the time delay coded for the trailing edge of 71 to leading edge of 9 pulses

 

[bob weir]

lines 27 and 28 generate the 3120 uS delay between the trailing edge of the -9 deg pulse and the lead edge of the next -71 pulse

the code in this example has the 125uS delay code subroutinne repeat 25 times
25 x 125 = 3125 and the measured value of 3120 is good


this delay time also corresponds to RPMs. and should be in harmony with the coded
delay for the time between the 71 and 9 pulses

 

[bob weir]

the next step is to do the math and code for actual delay times that occur
in one of the RPM ranges the code is testing for. then apply these test
signals to the ignition uC and see what the scope shows is the delay
to fire time. getting that right is the whole purpose of the ignition code

 

[bob weir]

look close and see that the 2 delay subroutines are identical except for
the literal value in line 31 of .7 becomes .40 in line 39

the stopwatch tool was used to find the best choice of literal for a one loop
delay of 125 uS

the variable names and label names had to be different too or the
assembly listing would not 'build'

 

[bob weir]

a reminder ... for any comments or questions please contact me via e-mail
instead of this forum. [email protected]

messages that will add to this effort and move it along will be mentioned





note - to clear something up . the code above uses the MPASM language format
of 'GPIO,1' to refer to that no . 1 pin on the uC. my shorthand is to call it A1 instead.

the trainer board i learned with was the Microchip low-pin-count board.
and the header labels it came with were in this A2 , B3 , C6 format. to save space.

 

[bob weir]

march 23 progress report.
along the way since the last posting an idea was come across. having to do with when things are not what you were working to create. in short it means that
when the results wanted are not turning up a better way to look at the matter is needed. and when we look in a newer way
at the problem we will make better sense of things by finding more of what was missed earlier

this was applied to the approach being used in the code earlier this year. with some further math it is very evident the timing was
way off at the low rpm end. the code is undergoing revision . many more range tests are being added. the new rpm range size
is 50 +/- instead of 200 - 300. this is necessary to ensure that the slow end of the rpm range doesnt take so much delay that the -9 deg pulse signal
is missed.

the good news is as the rpms increase more timing safety margin arises due to them needing more spark advance.
and this gets us away from the -9 deg signal

also at this time it is looking like at upper rpms there possibly wont be a rpm range at all. the code will test for exact arc_62 values.
and the subtraction test used for lower rpms will no longer do. some different code is called for. the type needed here
was seen in one of those early baseline Gooligum lessons. testing two numbers for equality.

a new idea too has evolved in the effort to code a 2'd uC as a test signal source. like having the code step the
time spacing between the 71 and 9 deg pulses.
this will allow a sweep thru the range of rpms the flywheel can spin at. to test that the correct
delay to fire is happening . and with a long , 1-sec , delay so the scope can be stopped in time. and take
some measurements.

a new idea too to solve is the problem of not knowing what the TMR0 value is that's saved to arc_62 each rotation.
it would be good to have this number. as the timing delay to fire is based on it. recall that a lot of time is free for
other uses once the flywheel passes the 0 deg mark ... until it gets past 270 , 180 , 90 and finally to 71 deg again.

i.e. for only about 75 to 80 deg of each full rotation is the code doing anything useful. this leaves us 360 - 80 = 280 deg
of rotation time to code ever what we can as an aid in developing and testing the code.

that time would be available to output 2 pulses. the first would have a width equal to arc_62 . and the 2'd
would be t_dly in width. with a coded long delay there would be time to stop the scope and measure these
pulse widths. or possibly the scope could be put into 'single' mode and trigger on either of these pulses
as they would exit the uC from the same unused output pin.

remember this 1054 scope has 4 channels and we're only using 3 of them so far : the 71 & 9 test
input signals and the fire-out signal

that's all i have for now. next is to put these ideas into practice and learn how well they work.

 

[bob weir]

the coding of a 2'd uC to provide test signals is moving along well.

the foto image is of the 2 pulses coming out of a 16F506 to the 1054 scope

i had to change to this uC as it offers 8-bit ADC ability.
and is covered in lesson 10 of the Gooligum baseline series
of tutorials

here the scope horiz. time base is set at 100us per division.

and it can be seen that the pulses are 200us wide each, as coded.

the spacing between the pulses is a measure of the input signal
from that blue Bourns 10-turn pot.

the 6 leds allow one to know the value from the ADC conversion
step that is stored in register ADRES.
my guess is that ADRES stands for 'analog to digital conversion result'

only 6 leds are in use. and the number for all 6 lit is 3F in hex.
soon i will be trying to get the last 2 leds of ADRES coded to pins.

this ADRES number is used for some time code that calls a subroutine
and has it loop this many times for an overall delay.

by using a pot like this one can change a variable easily over the
0-255 range of a byte. and with the leds have immediate feedback what the number is.

the 6 leds were easy to code as the C port is 6 pins C0 to C5.
and all can be configured as digital outputs

this number from the pot/ADC/ADRES code will be used to vary the time between
what we simulate to be the 71 and 9 degree pulses the 2'd uC receives from the flywheel

this way we know exactly what to expect in the way of delay-to-fire
signal out of the 2'd uC. the 12F508 we've seen posted here already.

the reason we know what to expect is the 508 code main purpose is to
measure the time between the 71 and 9 pulses. then determine the
correct amount of delay time until the spark plug is to be fired. next is to output a
pulse to the CDI circuit . the correct delay time is applied once the next 71 pulse
comes along. i.e. the delay-to-fire is referenced to when the 71 pulse arrives

this will all become more clear with some circuit sketches of this 16F506
circuit - under - test and then both uC's wired together

 

[bob weir]

the coding is tricky to get those last 2 MSB of ADRES to the B4 and B5 pins.

the instructions RRF and RLF do not connect directly to any of the port B pins.



a note too about this uC having ADC and comparator modules. neither one
calls for any new instructions. there are still just 33 of those. what is new
is a handful of new registers. one you've seen here already , ADRES. and the
ADC and comparator both have control registers. those are needed so you can
set these 2 new modules up the way you want them to run.

as you read this post and the tutorial lesson 10 and the uC data sheet and try things
out you will get it all to work. and along the way have
the momentary awareness experience of having learned something.

 

[bob weir]

as indicated on the last posting code to light up the bit 6 and bit 7 of ADRES was being worked on.
its done . and now all 8 bits of the ADC result in register ADRES are visible via external leds on
the 16F506.
so why is this a big deal ?
1. first it shows how an internal register or file contents can be known at once.
.....................as you rotate the 10-T pot the leds turn on or off accordingly
2. these 8 bits span two of the ports. as neither B or C is 8-bits wide
3. when testing the 2'd uC , the one with the ignition timing code, we will
....... now know exactly the timing between the incoming 71 , 9 pulses
4. the code did not need the instructions RRF or RLF. but uses BTFSC instead.
(we will be seeing those two rotate/shift instructions later on . we can do the same thing
............. moving ADRES to external leds using only 2 or 3 pins , not 8.)

the result is significant in itself. for its usefulness in other programs you may write.
and it is but a part of the overall test signal code. what is left to do
is use this ADRES value with a delay 32uS subroutine . so that for every ADRES number
the delay between the -71 and -9 deg BTDC pulses is (ADRES) * (32uS) .
this delay is something we will have to verify with the scope

below is the code and a sketch of the circuit.
a note fyi ... the 16F506 is in the 'baseline' family of uC's
it was chosen as it is a 14-DIP and 11 of its pins are available for digital output
vs 5 of the pins on the 12F508. plus the fact it contains an ADC module

so far we are using 9 of its pins : 1 for analog V in and 8 digital out for the leds
we will use 2 more of the PORTB pins for the 71 and 9 output pulses

 

[bob weir]

the 2 scans of code pages put here on monday are not here today ... ???

so they are being re-uploaded

 

[bob weir]

today code is being worked on to complete the test-signal uC effort. you saw a preview of this with the above
mar 28 scope foto. that delay code was jury-rigged to make a 200uS delay between the 71 and 9 pulses.

the actual test signal code will use a subroutine that takes 32uS to run once. and multiply this delay by the
number in the ADRES register. thus the delay between 71 and 9 pulses is (ADRES) * (32uS)

the 2'd uC , the ignition-coded one , will have a 8-led display coming off of it too. it will show us
the count from the timer TMR0 between the 71 leading edge and the 9 pulse leading edge.
the count will be in multiples of 32uS. so this number should agree with the 8-led display of the
test-signal uC.

or they could differ by one , given the 1% accuracy of both uC's using their internal 4 mhz RC oscillators

since they will both be in hex, we will have to convert to decimal. this will ensure
we are in the 64 - 161 decimal range . ( see 3-31-16 data table )

the other key thing to be looking for , the delay-to-fire following the 71 pulse , will require the
scope to verify.

when those 2 data are the right numbers and the fire-the-cdi pulse follows every 71 pulse
with the coded amount of delay we are good.
and the code will then be tested with the 225cc motorcycle engine itself.

subject to new errors of coding/thinking coming to light along the way

 

[bob weir]

on re-reading the above post one more problem was found.

those of you following this development closely have caught it too.

i'll write of it soon. here's a clue ... above is written the two 8-led hex numbers may agree or differ by one.
there's something else could have them differ ...

and that's not all. we could also get a mismatch that you would only think about if
you'd been coding time delay subroutines in the sub-100uS area.
one uC is trying to get 32uS steps with code. and the 2'd uC is using the
TMR0 module with a prescalar of 32uS.
the coded 32uS is an ideal goal. and in practice as you ask it to be a multiple over
the 1-255 range the result may not be an exact multiple. its to be determined
how close the code can come & how much of a difference this will make if its not

 

[bob weir]

hi guys , some good news to report. the 71 and 10 pulses that exit the '506 now do so with
a variable time between them. rotating the pot changes this time.
the 2 fotos show a 3F ADRES and FF ADRES time setting. the time delay subroutine is between
3 and 4 uS per unit of ADRES for now. and will be edited next to get it up to 32uS. then this '506 uC coding will be done
with as a test-signal source. and we can move on to testing it with the ignition code 508 uC.

getting the 32uS delay subroutine exact over its simulation range of 46 to 161 is more
trouble than i want to bother with. the new plan is to get it close. and make a table of what
the '506 leds say vs. what the scope says the actual delay is. so when the ignition code leds give us their
number we can do some on-the-spot math and see how close we are. plus as we sweep
the test signal we will log all the data and table and/or graph it. this will be another way to verify that
it all looks good before trying the ignition code uC out on the engine

a fyi ... in both fotos both pulse widths are the same , about 130uS

and not shown is how this pulse pair repeats every 10mS

lastly ... an error source referred to recently is that the 508 uC ignition code measures time
between leading edges of the incoming 71 and 10 pulses. and the code for the fotos
shown today are coded for a delay between the TE of 71 and the LE of 10.
thus the TMR0 in the 508 uC will have a larger count by 130/32 = 4

this is ok so long as we remember to account for it come test time

a fyi for newcomers to this post ... the 16F506 uC holds code that simulates
the 2 signals that come from the yamaha 225 flywheel. a coil of wire is swept
every revolution by a magnet fastened to the surface of the flywheel.
and a half-sine wave appears at -71 deg BTDC and another at -10 deg BTDC.

with a few parts these half-sine waves are made into digital pulses.

we want these signals to test a 2'd uC with, a 12F508 that holds the ignition code.
the purpose of the 508 is to measure the time between the 2 incoming pulses and figure
RPM's and then delay some time and emit a pulse to the CDI circuit that has
the spark plug fire. over the entire RPM range of the engine the plug fires between
-31 deg and -10 deg BTDC.

the original ignition system on my yamaha is analog. and quit working.
that was the incentive to upgrade it to a new digital one. oh ,sure , the yamaha
people would of sold me a replacement ignition system. for 500 dollars +/- .
and as its electronic there was no guarantee that it was any good. no returns
either for the same reason.

AND , as always ... should you wish to message me please use my e-mail
address instead of this forum. its [email protected]

all material that moves this project along will be considered for posting here.

my attitude of trying to keep this post as 'clean' as possible comes from observing
a similar ignition effort over at RCGroups.com . its a mess. with little to no effort
to clarify what is or has been happening. its an example of what doesnt work

 

[bob weir]

here the leds show 3F and with the timebase at 50uS you can see about 200uS between
the TE of CH 1 and LE of CH 2 pulses. 3F is 63 decimal and 200/63 is 3+ uS per ADRES unit