-
Categories
-
Platforms
-
Content
Digital programmable CDI ignition for 2-stroke engines
- Thread starter dR.eXntriK
- Start date
hello great bob weir sir, i came across this site while searching on google while i was searching for digital programmable CDI, i read few posts here not all yet and i came to know that bob sir and all other here want more ppl to join here in this thread. Sir i am very very happy and thankful to you for helping so great on this thread, i am also working on the same project for my company, i have to make many programmable cdi's for my company and i am working on my first CDI yet, and apart from it, it is my first major project of my life.... so i will love to share my experiments and work i will do in my company, and hopefully will get guidance and support for you all for the same...
.. i will hopefully start posting from tomorrow here in this thread... Hope to make the projects complete and make this thread usefull for learners..
.. i will hopefully start posting from tomorrow here in this thread... Hope to make the projects complete and make this thread usefull for learners..shanky ,
thank you for the respect. i'm not so great. just a guy trying to understand how to do something new. that will end up with my motorcycle back on the road. and you dont have to call me sir either.
it is good you found this site. its lots more than i had back when i was in your shoes. my goal is to provide a working example for others who are faced with the need to have a DIY digital cdi ignition for a gas engine.
you are going to be challenged over and over to learn and do a project of this size.
i've been at it part time for over 2 years now. and once i realized this was taking lots longer than i thought it would bought a good used 100cc dirtbike off a craiglist ad.
and yes , i am interested in what you do. your experiments , your cdi circuit design . how you code it and lessons learned. however i do ask that you start
your own thread. and please give it a slightly different title. post a link to it here.
for you there will be an enormous amount of information and material involved . and if you start to post
any of it here the result will be lots of clutter on this posting site. not so good. newcomers and other interested parties would just be distracted
in different directions than the path my project is taking. i've seen this happen at another cdi forum. total dis-organization.
and the newcomer is overloaded with page after page of postings to sort out. and no clear path to follow.
ideally replies to this thread are following closely with my work. and their focus is on understanding it. think of it as riding a horse in the direction it is already going.
regards,
bob
ps - what country is your message flag icon ?
thank you for the respect. i'm not so great. just a guy trying to understand how to do something new. that will end up with my motorcycle back on the road. and you dont have to call me sir either.
it is good you found this site. its lots more than i had back when i was in your shoes. my goal is to provide a working example for others who are faced with the need to have a DIY digital cdi ignition for a gas engine.
you are going to be challenged over and over to learn and do a project of this size.
i've been at it part time for over 2 years now. and once i realized this was taking lots longer than i thought it would bought a good used 100cc dirtbike off a craiglist ad.
and yes , i am interested in what you do. your experiments , your cdi circuit design . how you code it and lessons learned. however i do ask that you start
your own thread. and please give it a slightly different title. post a link to it here.
for you there will be an enormous amount of information and material involved . and if you start to post
any of it here the result will be lots of clutter on this posting site. not so good. newcomers and other interested parties would just be distracted
in different directions than the path my project is taking. i've seen this happen at another cdi forum. total dis-organization.
and the newcomer is overloaded with page after page of postings to sort out. and no clear path to follow.
ideally replies to this thread are following closely with my work. and their focus is on understanding it. think of it as riding a horse in the direction it is already going.
regards,
bob
ps - what country is your message flag icon ?
Last edited:
dear reader - there is some circuitry not yet covered. instead of that today we are moving along to the code. we'll get back to the circuit later.
getting a CDI circuit design , built and tested is one of the major tasks for this project. and a person can find many CDI circuits online.
the other big task is writing some code that makes the CDI circuit fire the spark plug at the proper time. this code exists online too.
for one example see my june 21 , 2015 post
what will make mine different is having the detailed background story on why the code works the way its suppose to. and emphasis on
using the least powerful uC to do the job. this way we learn the minimum uC and memory size that works.
this way distractions and confusion are kept to a minimum. also the code is written in assembly language, not C.
along the way we will use the software tools for simulation and timing analysis.
v. 8.92 of MPASM is the software.
see my sept 25 , 2014 posting for a link to get this s/w
pseudo code for the assembly language software that runs my digital CDI circuit. the CDI code is for
a 1-cylinder 4-cycle gas engine of 225cc size. the engine goes to a Yamaha XT225 enduro motorcycle.
factors :
a flywheel magnet and coil magnet sensor provides 2 timing signals each rev
the first timing signal occurs at about -70 deg BTDC
this signal will be used by the microcontroller and its s/w ( code )
the second signal is at -10 deg BTDC and is used at low RPMs
both timing signals need to be converted to pulse/digital form
before the microcontroller can make use of them
the engine mfg. provides a timing chart of RPM vs deg. of timing advance
the software ( code ) needs to measure the time of one revolution of
the flywheel.
whatever the amount of time is it corresponds to an RPM value.
the code deals in time for one revolution. and not RPMs per se
the time for one revolution can be called a period
a period divided into 1 then multiplied by 60 gives you RPMs
every period/RPM is associated on the timing graph to some value
of degrees of timing advance.
for periods/RPMs below 2000 the code defers to the 2'd timing signal
for ignition timing and firing of the spark
for periods/RPM's above 2000 the code determines the period/RPMs and then delays
some time appropriate to agree with the mfg' timing chart
after this delay a pulse signal is sent from the uC to the CDI circuit
that causes the sparkplug to fire
` simultaneous with these steps to figure period/RPM , delay and fire the plug
the time/period of the next revolution is being measured
the code repeats these steps for every revolution of the flywheel
and fires the plug every rev too. thus this code could be used for a 2-cycle engine
a following post will show the code in block diagram form. with subsequent diagrams
having more detail. then finally the code itself. and along the way you will see a table
of RPMs , periods, counts of the number of pre-scalar numbers. this will show you the basis
for the decision to get the most counts out of an 8-bit period number. an example of how
the delay is calculated is called for too.
getting a CDI circuit design , built and tested is one of the major tasks for this project. and a person can find many CDI circuits online.
the other big task is writing some code that makes the CDI circuit fire the spark plug at the proper time. this code exists online too.
for one example see my june 21 , 2015 post
what will make mine different is having the detailed background story on why the code works the way its suppose to. and emphasis on
using the least powerful uC to do the job. this way we learn the minimum uC and memory size that works.
this way distractions and confusion are kept to a minimum. also the code is written in assembly language, not C.
along the way we will use the software tools for simulation and timing analysis.
v. 8.92 of MPASM is the software.
see my sept 25 , 2014 posting for a link to get this s/w
pseudo code for the assembly language software that runs my digital CDI circuit. the CDI code is for
a 1-cylinder 4-cycle gas engine of 225cc size. the engine goes to a Yamaha XT225 enduro motorcycle.
factors :
a flywheel magnet and coil magnet sensor provides 2 timing signals each rev
the first timing signal occurs at about -70 deg BTDC
this signal will be used by the microcontroller and its s/w ( code )
the second signal is at -10 deg BTDC and is used at low RPMs
both timing signals need to be converted to pulse/digital form
before the microcontroller can make use of them
the engine mfg. provides a timing chart of RPM vs deg. of timing advance
the software ( code ) needs to measure the time of one revolution of
the flywheel.
whatever the amount of time is it corresponds to an RPM value.
the code deals in time for one revolution. and not RPMs per se
the time for one revolution can be called a period
a period divided into 1 then multiplied by 60 gives you RPMs
every period/RPM is associated on the timing graph to some value
of degrees of timing advance.
for periods/RPMs below 2000 the code defers to the 2'd timing signal
for ignition timing and firing of the spark
for periods/RPM's above 2000 the code determines the period/RPMs and then delays
some time appropriate to agree with the mfg' timing chart
after this delay a pulse signal is sent from the uC to the CDI circuit
that causes the sparkplug to fire
` simultaneous with these steps to figure period/RPM , delay and fire the plug
the time/period of the next revolution is being measured
the code repeats these steps for every revolution of the flywheel
and fires the plug every rev too. thus this code could be used for a 2-cycle engine
a following post will show the code in block diagram form. with subsequent diagrams
having more detail. then finally the code itself. and along the way you will see a table
of RPMs , periods, counts of the number of pre-scalar numbers. this will show you the basis
for the decision to get the most counts out of an 8-bit period number. an example of how
the delay is calculated is called for too.
Last edited:
hi guys ,
on re-reading the most recent posting some clarification is called for:
1. the first timing signal is in the -70 to -60 deg BTDC area , exactly where is not known yet. but it will
................. worked out later , so dont sweat it if we dont know it yet. for now i think -70 will
.................... be the starting value. at this point it is not known if even holds at a steady deg value
...................... over the engines operating range. the scope will tell us that later on
2. by 'pseudo code' is meant just saying what the code is suppose to do in plain english. this idea is one
................ the Gooligum assembly language author uses. you'll see it used in his training lessons
3. oops, the uC does not use the -10 deg pulse, just the -60/-70 deg one . oh , the code could.
.................... if you wanted to get a period from -10 deg to the next -10 deg point you could. for that matter we dont
................ really need to use a whole period. another option is to measure the spin time from -10 to -60/-70.
............ this is saying that partial revolution times also can be correlated linearly with RPMs for
................ the sake of finding the deg of advance on the RPM-deg chart. deciding how to go at it
................. is something that unfolds with experience and understanding and the uC's abilities.
.................... what is important is to pick one way and work it until you have reason to change anything.
4. the mfg timing chart of deg vs RPM's and the common usage or RPMs as an engine spec are 2 good reasons
.................. to continue to use term RPM here. recognize that the code deals in periods only. there is no reason
............... for the ignition code to deal in RPMs. ok, an exception is to use the period value on purpose to convert
................ it to RPMs so it can be sent to a dashboard LCD and show you what the RPMs are. but this is an
................... add-on for later. and it can be done easily with a picaxe-18 chip using Pic Basic not assembly.
5. that line with 'simultaneous' in it reflects one of the valuable feaures of the uC timer . namely how it can work
................. in the background while other tasks, like determining where the period is on the timing graph
..................... happens in the foreground. you'll learn about this all in the Gooligum Baseline lesson 5 : Timer0
...................... a timer is the first of many so-called modules included in the PIC series of uC's. and by sticking with
................ the baseline uC's to start with we dont bump into them needlessly. for instance if there were an ADC
...................... modulel with the 12F508 we'd have to figure out how to be sure the pins on the chip that are ADC
.................capable are turned off. not having them there to begin with just makes it easier for beginners.
bw
on re-reading the most recent posting some clarification is called for:
1. the first timing signal is in the -70 to -60 deg BTDC area , exactly where is not known yet. but it will
................. worked out later , so dont sweat it if we dont know it yet. for now i think -70 will
.................... be the starting value. at this point it is not known if even holds at a steady deg value
...................... over the engines operating range. the scope will tell us that later on
2. by 'pseudo code' is meant just saying what the code is suppose to do in plain english. this idea is one
................ the Gooligum assembly language author uses. you'll see it used in his training lessons
3. oops, the uC does not use the -10 deg pulse, just the -60/-70 deg one . oh , the code could.
.................... if you wanted to get a period from -10 deg to the next -10 deg point you could. for that matter we dont
................ really need to use a whole period. another option is to measure the spin time from -10 to -60/-70.
............ this is saying that partial revolution times also can be correlated linearly with RPMs for
................ the sake of finding the deg of advance on the RPM-deg chart. deciding how to go at it
................. is something that unfolds with experience and understanding and the uC's abilities.
.................... what is important is to pick one way and work it until you have reason to change anything.
4. the mfg timing chart of deg vs RPM's and the common usage or RPMs as an engine spec are 2 good reasons
.................. to continue to use term RPM here. recognize that the code deals in periods only. there is no reason
............... for the ignition code to deal in RPMs. ok, an exception is to use the period value on purpose to convert
................ it to RPMs so it can be sent to a dashboard LCD and show you what the RPMs are. but this is an
................... add-on for later. and it can be done easily with a picaxe-18 chip using Pic Basic not assembly.
5. that line with 'simultaneous' in it reflects one of the valuable feaures of the uC timer . namely how it can work
................. in the background while other tasks, like determining where the period is on the timing graph
..................... happens in the foreground. you'll learn about this all in the Gooligum Baseline lesson 5 : Timer0
...................... a timer is the first of many so-called modules included in the PIC series of uC's. and by sticking with
................ the baseline uC's to start with we dont bump into them needlessly. for instance if there were an ADC
...................... modulel with the 12F508 we'd have to figure out how to be sure the pins on the chip that are ADC
.................capable are turned off. not having them there to begin with just makes it easier for beginners.
bw
Last edited:
here is flow diagram for the uC code that makes the CDI fire and run the engine.
right now what is being looked at is to just
provide code for each block of the diagram . or to do a follow-up flow diagram with more detail. what i'm stumbling over is
the setup block referring to instruction code in later blocks. what the detailed setup block needs to say is what all of the uC needs set up. also i think a circuit diagram is called for. so you can see the uC pins in use.
this will make the code easier to follow when actual pin port numbers are referenced.
the uC is declared to be the 12F508. this could change later to the 12F509 . the only difference
between them is the 509 having twice the memory locations for the code.
ok , the circuit diagram will be worked on and posted next. and allow for the code vs detailed flow diagram decision to sort itself out along the way
right now what is being looked at is to just
provide code for each block of the diagram . or to do a follow-up flow diagram with more detail. what i'm stumbling over is
the setup block referring to instruction code in later blocks. what the detailed setup block needs to say is what all of the uC needs set up. also i think a circuit diagram is called for. so you can see the uC pins in use.
this will make the code easier to follow when actual pin port numbers are referenced.
the uC is declared to be the 12F508. this could change later to the 12F509 . the only difference
between them is the 509 having twice the memory locations for the code.
ok , the circuit diagram will be worked on and posted next. and allow for the code vs detailed flow diagram decision to sort itself out along the way
Last edited:
for every shaft revolution the TMR0 code places a period value in a UDATA variable. this period is a RPM representation. and it somewhere along the r/min graph line.next the code will do some range-test code then know better where on the graph the period goes.
the size of these ranges is about 500 RPMs. so the code will find for us ex. the period is in a range
of RPMs from 2000 to 2500, or 4500 to 5000.
Last edited:
aug 11 2015 details of block of ignition code flow diagram for 12F508
this is the 2'd block posted earlier, 7-25 i think it was ...
...its the block after the start oval that cites detecting -60/-70 pulses
steps : 1. detect a -60/-70 deg input pulse 0 --> 1 logic level change
2. clear theTMR0 register i.e. set its value to zero
3. re-code the OPTION register for psa = 128 ... see p. 38 uC data
for where it says the psa register gets 0'd each TMR0 write
4. delay some time , tbd, so the 1'st pulse '1' level is not
re-read as the 2'd pulse. note - the 508 is not able to
detect pulse edges on its input GPIO pins. only logic levels
5. detect the next -60/-70 input pulse ( 0-->1 logic level change)
6. read the TMR0 register and store this number in the W-reg'
7. then move/store the W- register value to a UDATA register
8. re-code the OPTION reg' for psa = 128
note : the stored 8-bit TMR0 value is the period/RPM of the most recent
engine rotation. this period/RPM is a point somewhere on the
"ignition timing vs. engine speed" chart. now that we have this
RPM /period / engine speed point in the form of a period - value the
next step is to find what RPM - range this value is in. this is the job
of the next block in the flow diagram. and will be the subject of
the following posting.
this is the 2'd block posted earlier, 7-25 i think it was ...
...its the block after the start oval that cites detecting -60/-70 pulses
steps : 1. detect a -60/-70 deg input pulse 0 --> 1 logic level change
2. clear theTMR0 register i.e. set its value to zero
3. re-code the OPTION register for psa = 128 ... see p. 38 uC data
for where it says the psa register gets 0'd each TMR0 write
4. delay some time , tbd, so the 1'st pulse '1' level is not
re-read as the 2'd pulse. note - the 508 is not able to
detect pulse edges on its input GPIO pins. only logic levels
5. detect the next -60/-70 input pulse ( 0-->1 logic level change)
6. read the TMR0 register and store this number in the W-reg'
7. then move/store the W- register value to a UDATA register
8. re-code the OPTION reg' for psa = 128
note : the stored 8-bit TMR0 value is the period/RPM of the most recent
engine rotation. this period/RPM is a point somewhere on the
"ignition timing vs. engine speed" chart. now that we have this
RPM /period / engine speed point in the form of a period - value the
next step is to find what RPM - range this value is in. this is the job
of the next block in the flow diagram. and will be the subject of
the following posting.
this graphic includes the red rectangles to illustrate the 'RPM-range' idea introduced earlier.
this PIC12F508 uC works with integer numbers only. and these 8-bit numbers are all in the
range 0 to 255 , so we are further restricted.
if this PIC12F508 uC were math-enabled and could handle
real numbers then we would use the algebraic straight line formula : y = mx + b
and figure out the 'y' ( deg advance ) with it. with 'x' being our nmbr value
the next block of code on the flow diagram takes the nmbr value and figures what
red rectangle in belongs in. there will be 10 rectangles coded to begin with. this number
is likely to change later on with engine run experience and availability of more uC memory.
Last edited:
for the next code block, the one that does the range-test for RPM's this message purpose is to
propose that you now take a look at the simulator tool that comes with MPLAB IDE. the reason is
that the code is tricky to follow.
oh, the idea is simple enough, compare 2 numbers and decide
which is bigger ... and the simulator will let you follow the action one line at a time. and see the
changes to the registers and flags and program counter. this is the path i took to learn this
block of code well. and to better understand what it is doing.
as an aid i went to U-Tube and watched videos of this simulator tool. here is one link.
as you find others take care to focus on PIC12 uC's and assembly not 'C' language.
my approach was to just fool with and play with the simulator software. trial and error.
until i finally figured out how to work it. this took weeks of part time effort. and when there
was a gap of time on returning it'd be necessary to go thru it all again , stepping along one
line at a time, seeing the changes. and re-working out the range-test boundary values .
the next post will be a detailed description of what the range-test code is doing . it is likely to
consist of several postings. and could be several weeks to complete. this range-test code has
been the toughest part of the whole program to work out.
one idea i have to assist you learning this is to post a stand-alone piece of code that does
a range-test with a fixed value for 'nmbr'. then when you run the simulator you can edit the
value for 'nmbr' , re-build the code and run the simulator again.
later on , once all these flow diagram blocks are posted with their detailed descriptions
the plan is to then post the whole ignition CDI program
propose that you now take a look at the simulator tool that comes with MPLAB IDE. the reason is
that the code is tricky to follow.
oh, the idea is simple enough, compare 2 numbers and decide
which is bigger ... and the simulator will let you follow the action one line at a time. and see the
changes to the registers and flags and program counter. this is the path i took to learn this
block of code well. and to better understand what it is doing.
as an aid i went to U-Tube and watched videos of this simulator tool. here is one link.
as you find others take care to focus on PIC12 uC's and assembly not 'C' language.
my approach was to just fool with and play with the simulator software. trial and error.
until i finally figured out how to work it. this took weeks of part time effort. and when there
was a gap of time on returning it'd be necessary to go thru it all again , stepping along one
line at a time, seeing the changes. and re-working out the range-test boundary values .
the next post will be a detailed description of what the range-test code is doing . it is likely to
consist of several postings. and could be several weeks to complete. this range-test code has
been the toughest part of the whole program to work out.
one idea i have to assist you learning this is to post a stand-alone piece of code that does
a range-test with a fixed value for 'nmbr'. then when you run the simulator you can edit the
value for 'nmbr' , re-build the code and run the simulator again.
later on , once all these flow diagram blocks are posted with their detailed descriptions
the plan is to then post the whole ignition CDI program
Last edited:
hey troops , here is a piece of sample code that does the range test.it takes the TMR0 value for one period then finds which RPM range box it goes in. see the previous
posting for the image of red RPM range boxes overlaid on the deg-adv. vs rev/min image.
here is the same range test code that can be moved to MPLAB IDE s/w and made into a project.
once that is done ( for help see lesson 1 of the Gooligum baseline lessons ) you can open the
simulator tool and run the code one line at a time. doing this allows viewing the windows containing
the nmbr variable and the flag registers. thus the logic-decision of the subwf instruction and the
status of the C flag is monitored. repeat run the simulator changing line 14 with a different value .
then see which axxxx you end up at. doing this enough times and you will catch on how it all works.
once that is done ( for help see lesson 1 of the Gooligum baseline lessons ) you can open the
simulator tool and run the code one line at a time. doing this allows viewing the windows containing
the nmbr variable and the flag registers. thus the logic-decision of the subwf instruction and the
status of the C flag is monitored. repeat run the simulator changing line 14 with a different value .
then see which axxxx you end up at. doing this enough times and you will catch on how it all works.
dear reader ... for this code business a helpful link is the one posted last sept 25 , 2014 with the
URL for Gooligum. the person behind that site wrote a series of lessons for a beginner to learn
MPLAB assembly language. and in his baseline series lesson 5 for TMR0 on p. 5 / 17 is some
discussion of the subwf instruction used in the sample code posted here yesterday.
how this instruction works is a bit tricky to understand due to how the C flag is used.
for the case here where 2 numbers are arranged for a subtraction step . the C-flag is set to 1
when there is no borrow for the result
URL for Gooligum. the person behind that site wrote a series of lessons for a beginner to learn
MPLAB assembly language. and in his baseline series lesson 5 for TMR0 on p. 5 / 17 is some
discussion of the subwf instruction used in the sample code posted here yesterday.
how this instruction works is a bit tricky to understand due to how the C flag is used.
for the case here where 2 numbers are arranged for a subtraction step . the C-flag is set to 1
when there is no borrow for the result
Last edited:
this post will look closer at the range test code posted on aug 18. a week ago.
one matter to make light of is the test code using the variable 'nmbr' and fixed
values .195 , .117 ... etc. in each test. all of them are analogs of the period of
the flywheel rotation.
nmbr is the actual period as measured by TMR0. and is
the no. of times the prescalar incremented from 0 to a final value in one revolution.
ex. line 14 , 15 set 'nmbr' to .116 or 116 decimal. this is saying one rev took
116 x (128uS). this equals .0148 sec and 1/.0148 = 67.34 Hz and
60 x 67.34 Hz = 4040 RPM.
line 14 , 15 are simulating a TMR0 value for the
sake of running this code through the MPLAB IDE simulator tool.
as the 'nmbr' values decrease the RPM increases. the series of tests t1 - t8
are in decreasing period size and increasing RPMs. the first test t1 wants to know
if nmbr = 116 = 4040 RPM is in the range 255-195 / 1838-2403 RPMs ?
there are 2 ways for the program flow to exit t1. the first is if nmbr is in
the 255-195 range. then the flow is governed via line 20 'goto a2250'
the 2'd exit path is if nmbr is not in that range. then the flow is to the next
test t2. where we'll learn if nmbr = 116=4040 RPM is in the range 2416-4006 RPMs.
see the 12F508 doc' for the subwf instruction and the STATUS register.
there you will read that subwf compares 2 values and decides which is larger
by subtracting them and noting if a borrow is needed. when 'nmbr' is smaller than
W a borrow is needed and the C flag is made to be 0. a 0 is the same as clear
in the btfsc instruction line 19. the clear means line 20 gets skipped.
for t1 with nmbr = 116 and W = 195 we can see that 116 is smaller.
so of course the next range test is called for. to learn if 116 is in the range
117-194. it wont be so test 2 ends with the code flow to test 3 , t3.
test 3 will result in the C flag being 1. thus line 30 executes and the
code flow jumps to line 61. right now there is a do-nothing 'nop' there.
but later on the code will arrange for a certain delay. this delay will meet
the ignition advance requirement. more on this later .
again . this code is an executable example for the simulator tool in MPLAB.
by running it in single-step mode and watching the W, nmbr and STATUS
registers you will see the subtraction and branching steps. the subwf and btfss
instructions working together amount to an IF-THEN-ELSE structure.
and give us the ability to branch based on decisions the code makes.
all the code did was compare 2 values to see which was bigger based
on subtracting them and seeing what the C-flag bit of the STATUS reg' is
then going to either 1 of 2 places.
one matter to make light of is the test code using the variable 'nmbr' and fixed
values .195 , .117 ... etc. in each test. all of them are analogs of the period of
the flywheel rotation.
nmbr is the actual period as measured by TMR0. and is
the no. of times the prescalar incremented from 0 to a final value in one revolution.
ex. line 14 , 15 set 'nmbr' to .116 or 116 decimal. this is saying one rev took
116 x (128uS). this equals .0148 sec and 1/.0148 = 67.34 Hz and
60 x 67.34 Hz = 4040 RPM.
line 14 , 15 are simulating a TMR0 value for the
sake of running this code through the MPLAB IDE simulator tool.
as the 'nmbr' values decrease the RPM increases. the series of tests t1 - t8
are in decreasing period size and increasing RPMs. the first test t1 wants to know
if nmbr = 116 = 4040 RPM is in the range 255-195 / 1838-2403 RPMs ?
there are 2 ways for the program flow to exit t1. the first is if nmbr is in
the 255-195 range. then the flow is governed via line 20 'goto a2250'
the 2'd exit path is if nmbr is not in that range. then the flow is to the next
test t2. where we'll learn if nmbr = 116=4040 RPM is in the range 2416-4006 RPMs.
see the 12F508 doc' for the subwf instruction and the STATUS register.
there you will read that subwf compares 2 values and decides which is larger
by subtracting them and noting if a borrow is needed. when 'nmbr' is smaller than
W a borrow is needed and the C flag is made to be 0. a 0 is the same as clear
in the btfsc instruction line 19. the clear means line 20 gets skipped.
for t1 with nmbr = 116 and W = 195 we can see that 116 is smaller.
so of course the next range test is called for. to learn if 116 is in the range
117-194. it wont be so test 2 ends with the code flow to test 3 , t3.
test 3 will result in the C flag being 1. thus line 30 executes and the
code flow jumps to line 61. right now there is a do-nothing 'nop' there.
but later on the code will arrange for a certain delay. this delay will meet
the ignition advance requirement. more on this later .
again . this code is an executable example for the simulator tool in MPLAB.
by running it in single-step mode and watching the W, nmbr and STATUS
registers you will see the subtraction and branching steps. the subwf and btfss
instructions working together amount to an IF-THEN-ELSE structure.
and give us the ability to branch based on decisions the code makes.
all the code did was compare 2 values to see which was bigger based
on subtracting them and seeing what the C-flag bit of the STATUS reg' is
then going to either 1 of 2 places.
one thing that influences the code doing its job is the speed of the uC.
the 12F508 is using its built-in 4mhz oscillator. and the instruction cycle
is 1 uS. most instructions take one microsecond to execute.
this graph shows the amount of time there is for the ignition code
to do its calculations. it has from the first flywheel pulse at about
-60 deg BTDC to the worst-case timing advance of about -30 deg.
you can see that the time for the flywheel to rotate from -60 to
-30 shrinks as the RPMs increase. this -30 deg occurs at 5000 RPMs.
now if you've noticed the tachometer while driving a car you've seen
how the rpms are mostly in the 1500-2500 rpm range. and seldom if
ever at 5000. so with careful shifting of the motorcycle and minding
the rpms you can keep it in its safe operating range . in terms of
what the code can keep up with
remember the goal is to get the code to work in this minimal 12F508 uC.
later on faster ones with more memory and other features can be used.
Last edited:
dear reader ,
this post was going to be on the topic from the flow diagram. the one posted on july 25. its the box
that begins "delay the amount of time ...". well , i was poised to post a table of time delays for each
of the RPM ranges. the starting point was going to be the -60/-70 deg pulse off the flywheel.
the exact starting angle is not known any better at this time. somewhere along the flow of this
past week an idea came to me. that the angle could be pinned down now. better than this 10 deg
size range. the uncertainty is based on the unknown nature of the
magnetic field and when its field strength interacts with the pickup coil enough to generate
the half-sine wave.
if you look back to the june 12 2015 posting of a screen shot from the Rigol 'scope. it shows
the actual signals from the pickup signal during engine cranking. channel 1 , yellow trace, is
the only channel being used. anyway this was the picture i thought of that could answer the
BTDC question angle for the first half sine. is it -60 or -70 or some other angle ?
from the first + half sine to the next one is 360 deg of revolution. and the scope
has features that let one measure the time between these half sines very accurately.
the 2'd half sine of the pair is presumed to occur at -9 deg, according to the chart
posted on aug 11 2015 of BTDC vs RPM (-9 deg at 1400 RPM). so long as the rpms
are at or close to the idle speed of 1400 rpm. the graph being flat at idle rpms.
recall that no uC code is needed for the engine to run at idle. given that , then
all that needs doing is to add some gas to the tank and oil to the engine and with
the CDI circuit board attached spin it up until it starts. then looking at the scope adjust the idle screw for a
time between the upper pulses of 1400/60 = 23.33 hz and 1/23.33 = .0429 sec. = the period .
once the idle is steady then enable the scope to do digital recording. then measure
the time between the 2 upper half sine signals and also the time between the
first and 2'd half sine. the ratio of those 2 measurements times 360 is the degrees
between the half sine pair. and this value ssubtracted from the -9 deg is the -60 or -70 deg
position of the first half sine.
with that we will then have a better starting point
with which to calculate how long the code needs to wait until its time for the
code to send the fire signal to the plug.
a note about using the scope. the june 25 screen shot is saved in my PC.
and i dont know if its possible to reload it back into the scope. if i could then the measuring could
be done with it. except that if you look close at the 2 pairs of signals the space
between them, appears to shrink. this means the rpms are increasing and
the period is not a constant. we need a steady-rpm set of signals.
by the next posting it is hoped to have some time delay values. following that will
be the code that is called as a subroutine by each range test. this code will be based
on the 10 mS delay code seen in one of the early Gooligum baseline lessons.
this post was going to be on the topic from the flow diagram. the one posted on july 25. its the box
that begins "delay the amount of time ...". well , i was poised to post a table of time delays for each
of the RPM ranges. the starting point was going to be the -60/-70 deg pulse off the flywheel.
the exact starting angle is not known any better at this time. somewhere along the flow of this
past week an idea came to me. that the angle could be pinned down now. better than this 10 deg
size range. the uncertainty is based on the unknown nature of the
magnetic field and when its field strength interacts with the pickup coil enough to generate
the half-sine wave.
if you look back to the june 12 2015 posting of a screen shot from the Rigol 'scope. it shows
the actual signals from the pickup signal during engine cranking. channel 1 , yellow trace, is
the only channel being used. anyway this was the picture i thought of that could answer the
BTDC question angle for the first half sine. is it -60 or -70 or some other angle ?
from the first + half sine to the next one is 360 deg of revolution. and the scope
has features that let one measure the time between these half sines very accurately.
the 2'd half sine of the pair is presumed to occur at -9 deg, according to the chart
posted on aug 11 2015 of BTDC vs RPM (-9 deg at 1400 RPM). so long as the rpms
are at or close to the idle speed of 1400 rpm. the graph being flat at idle rpms.
recall that no uC code is needed for the engine to run at idle. given that , then
all that needs doing is to add some gas to the tank and oil to the engine and with
the CDI circuit board attached spin it up until it starts. then looking at the scope adjust the idle screw for a
time between the upper pulses of 1400/60 = 23.33 hz and 1/23.33 = .0429 sec. = the period .
once the idle is steady then enable the scope to do digital recording. then measure
the time between the 2 upper half sine signals and also the time between the
first and 2'd half sine. the ratio of those 2 measurements times 360 is the degrees
between the half sine pair. and this value ssubtracted from the -9 deg is the -60 or -70 deg
position of the first half sine.
with that we will then have a better starting point
with which to calculate how long the code needs to wait until its time for the
code to send the fire signal to the plug.
a note about using the scope. the june 25 screen shot is saved in my PC.
and i dont know if its possible to reload it back into the scope. if i could then the measuring could
be done with it. except that if you look close at the 2 pairs of signals the space
between them, appears to shrink. this means the rpms are increasing and
the period is not a constant. we need a steady-rpm set of signals.
by the next posting it is hoped to have some time delay values. following that will
be the code that is called as a subroutine by each range test. this code will be based
on the 10 mS delay code seen in one of the early Gooligum baseline lessons.
Last edited:
this scene shows the Rigol 1054 scope recording the timing signal
that comes off the flywheel magnet during the spin via the starter motor. with the spark plug removed good signals were obtained. by 'good' is meant the time between the 2 + half-sine waves was within
1% of the time between the 2 - half sine wave signals.
that is the flywheel was turning smooth and evenly one rev to the next. recognize that being a
4-stroke engine one rev is the exhaust cycle and the next is a compression cycle. so we can expect
the flywheel to slow down a bit on this comp stroke. this effect is reduced by removing the
spark plug
Last edited:
the cursors show 123.2 ms between the + half-sine signals.then the right cursor was moved to the left - half-sine and a 3-signal average of 21.0 ms was
mesured. the 3 -signal avg for the period was 122.0
understand that from the first + half wave to the 2'd + one is one rev of the flywheel.
this is the same as saying it turned 360 degrees.
what we want to know is the degrees between the first + half-sine and the next - half sine.
here's the math : 21.0 / 122 * 360 = 61.96 or 62 deg.
see the foto of the flywheel & magnet posted on june 21
now we know that the electrical arc length of the magnet is very close to 62 deg.
and given that the one end is known to be at about -9 deg then the other end is 62 deg earlier.
9 and 62 = 71. so the first + half-sine wave happens at -71 deg BTDC.
the until-now uncertainty of it being in the -60/-70 deg range is now updated with this new data.
and -71 deg will be the reference point from which the delay - to - fire is measured
the july 25 post showing a flow diagram that includes a block 'delay the amount of time ...'
is where in the code this -71 deg BTDC is used.
if you go back and look at this same picture on the june 12 post you can see the uneven
spacing between the + and - half-sine. my guess is the first pair was the comp stroke and
the next one was the exhaust. this guess is based on the narrowness of the 2'd pair
being due to the flywheel speeding up a bit on the exhaust stroke. then the air is simply
being pushed out the open exhaust valve.
another factor is the june 12 signal was captured in 'single' mode , instead of 'run/stop' mode.
thus the very first flywheel-magnet signal triggered the screen shot. instead of letting it run a
few seconds and getting to a stable speed.
Last edited:
Similar threads
