CDI gr8flyer55
09-17-2012 | 01:18 PM
#326
Joined: Mar 2009
Posts: 293
Likes: 0
Received 0 Likes
on
0 Posts
From: xnot applicable, AUSTRALIA
RE: CDI gr8flyer55
Jake,
If the circuit is a stable version, I can probably help with the pc board drawing. Not familiar with Eagle but downloaded a version yesterday to take a look at it.
Still need to know answer to my previous question in #317.
If the circuit is a stable version, I can probably help with the pc board drawing. Not familiar with Eagle but downloaded a version yesterday to take a look at it.
Still need to know answer to my previous question in #317.
09-17-2012 | 01:54 PM
#327
Senior Member
RE: CDI gr8flyer55
Hi Guys,
I tried John's curve and for me the timing curve is right where it needs to be at startup through WOT.
Jake,
I have a question though in the curve John is using
1) above table the first value is 1448075. how is that usable? Its bigger then the biggest number that timer1 can hold and there other values similar.
2) the table has a 2 as the second number it seems that the numbers should go in some kind of order.
3) the first row it seems that the numbers are all over the place (example)
108,100,91,83,74,65,57,48,39,39,41,44,47,
49,52,55,57,60,62,89,117,145,173
Now I am guessing that at lower rpm the pic is using the numbers at the end of the table and as the rpm increases the pic uses the values closer to the beginning? is this right?
as I mentioned on my engine sim using a timing light the curve is where it should be.(IMO)
Thanks.
I tried John's curve and for me the timing curve is right where it needs to be at startup through WOT.
Jake,
Code:
1448075,2,44,86,128,170,212,254,296,338,380,422,464,506,548,160,152,143,134,126,117,108,100,91,83,74,65,57,48,39,39,41,44,47, 49,52,55,57,60,62,89,117,145,173,200,228,256,286,328,370,412,454,496,538,580,622,664,706,748,790,832,874,916,958,1000,1042,1084, 1126,1168,1210,1252,1294,1336,1378,1420,1462,1504,1546,1588,1630,1672,1714,1756,1798,1840,1882,1924,1966,2008,2050,2092,2134,2176, 2218,2260,2302,2344,2386,2428,2470,2512,2554,2596,2638,2680,2722,2764,2806,2848,2890,2932,2974,3016,3058,3100,3142,3184,3226,3270, 3315,3360,3405,3450,3494,3539,3584,3629,3674,3718,3763,3808,3853,3898,3943,3987,4032,4077,4122,4167,4211,4256,4301,4346,4391,4435, 4480,4525,4570,4615,4660,4704,4749,4794,4839,4884,4928,4973,5018,5063,5108,5152,5197,5242,5287,5332,5377,5421,5466,5511,5556,5601, 5645,5690,5735,5780,5825,5869,5914,5959,6004,6049,6094,6138,6183,6228,6273,6318,6362,6407,6452,6497,6542,6586,6631,6676,6721,6766, 6811,6855,6900,6945,6990,7035,7079,7124,7169,7214,7259,7303,7348,7393,7438,7483,7528,7572,7617,7662,7707,7752,7796,7841,7886,7931, 7976,8020,8065,8110,8155,8200,8245,8289,8334,8379,8424,8469,1329068,1334735,1340402,1346069,1351736,1357403,1363070,1368737,1374404, 1380071,1385738,1391405,1397072,1402739,1408406,1414073,1419740,1425407,1431074,1436741,1442408
I have a question though in the curve John is using
1) above table the first value is 1448075. how is that usable? Its bigger then the biggest number that timer1 can hold and there other values similar.
2) the table has a 2 as the second number it seems that the numbers should go in some kind of order.
3) the first row it seems that the numbers are all over the place (example)
108,100,91,83,74,65,57,48,39,39,41,44,47,
49,52,55,57,60,62,89,117,145,173
Now I am guessing that at lower rpm the pic is using the numbers at the end of the table and as the rpm increases the pic uses the values closer to the beginning? is this right?
as I mentioned on my engine sim using a timing light the curve is where it should be.(IMO)
Thanks.
09-17-2012 | 02:07 PM
#328
My Feedback: (11)
RE: CDI gr8flyer55
If curve is linear like belownumbers shouldbe in order. 3 things thatI think can give you the numbers in different order .
1 data colection to the Copy/Paste Cell
2 calculation
3 curve .
One of them it my have couple bugs.
Curve can influence the numbers. If you taper down at HI RPMS then your numbers are going to change,If you use a curve similar of
ROB posted here.
If you use something like I just test here then they should be in order.I just used 12F683_CDI_v0.9b3 excel file.
LOW RPM= Hi number
Hi RPM= Lo number
So... in order to make sure "numbers are right" make a linear curve , spread the numbers as equal possible over the RPM range.
Look in to the table data and you should all numbers in order.
After that go ahead and create your desired curve.
In this particular example that first number is an issue....can be a data colection,calculation .
Take a picture of the curve and posted here. My be able to pinpoint better.
Like I saidcan be one of the 3 or all 3 of them with the new version of the file.
Thanks
Adrian
.
1 data colection to the Copy/Paste Cell
2 calculation
3 curve .
One of them it my have couple bugs.
Curve can influence the numbers. If you taper down at HI RPMS then your numbers are going to change,If you use a curve similar of
ROB posted here.
If you use something like I just test here then they should be in order.I just used 12F683_CDI_v0.9b3 excel file.
LOW RPM= Hi number
Hi RPM= Lo number
So... in order to make sure "numbers are right" make a linear curve , spread the numbers as equal possible over the RPM range.
Look in to the table data and you should all numbers in order.
After that go ahead and create your desired curve.
In this particular example that first number is an issue....can be a data colection,calculation .
Take a picture of the curve and posted here. My be able to pinpoint better.
Like I saidcan be one of the 3 or all 3 of them with the new version of the file.
Thanks
Adrian
.
09-17-2012 | 10:28 PM
#330
Senior Member
Joined: Feb 2010
Posts: 133
Likes: 0
Received 0 Likes
on
0 Posts
From: szarvas, HUNGARY
RE: CDI gr8flyer55
Hi Jake
<span lang="en" id="result_box"><span class="hps">In the</span> <span class="hps">code</span><span>, you can also</span> <span class="hps">wait</span> <span class="hps">for the Hall</span> <span class="hps atn">input (</span><span>GP2</span><span>)</span> <span class="hps">signal</span>
<span class="hps">when there</span> <span class="hps">is</span> <span class="hps alt-edited">ignition timing</span> <span class="hps">delay</span> <span class="hps">is not ready</span><span>?(<span lang="en" class="short_text" id="result_box"><span class="hps">Look at the picture</span><span>.)</span></span></span></span><span lang="en" id="result_box">
<span class="hps">It's okay</span><span>?</span>
<span class="hps">Not</span> <span class="hps">Cultivate</span> <span class="hps">the consequences</span><span>?</span>
<span class="hps atn">Spark-</span><span>ignition</span> <span class="hps">failure</span><span>?</span></span>
<span lang="en" id="result_box" class="short_text"><span class="hps">Solution:</span></span>
<span lang="en" id="result_box"><span class="hps">Disable</span> <span class="hps">external</span> <span class="hps">interrupt</span> <span class="hps">input</span><span>, ignition</span> timing <span class="hps">delay</span> <span class="hps">time?</span></span>
<span lang="en" id="result_box" class="short_text"><span class="hps">What do you think</span> <span class="hps">about this?</span></span>
<span lang="en" id="result_box"><span class="hps">In the</span> <span class="hps">code</span><span>, you can also</span> <span class="hps">wait</span> <span class="hps">for the Hall</span> <span class="hps atn">input (</span><span>GP2</span><span>)</span> <span class="hps">signal</span>
<span class="hps">when there</span> <span class="hps">is</span> <span class="hps alt-edited">ignition timing</span> <span class="hps">delay</span> <span class="hps">is not ready</span><span>?(<span lang="en" class="short_text" id="result_box"><span class="hps">Look at the picture</span><span>.)</span></span></span></span><span lang="en" id="result_box">
<span class="hps">It's okay</span><span>?</span>
<span class="hps">Not</span> <span class="hps">Cultivate</span> <span class="hps">the consequences</span><span>?</span>
<span class="hps atn">Spark-</span><span>ignition</span> <span class="hps">failure</span><span>?</span></span>
<span lang="en" id="result_box" class="short_text"><span class="hps">Solution:</span></span>
<span lang="en" id="result_box"><span class="hps">Disable</span> <span class="hps">external</span> <span class="hps">interrupt</span> <span class="hps">input</span><span>, ignition</span> timing <span class="hps">delay</span> <span class="hps">time?</span></span>
<span lang="en" id="result_box" class="short_text"><span class="hps">What do you think</span> <span class="hps">about this?</span></span>
09-18-2012 | 07:52 AM
#334
Senior Member
Joined: Aug 2011
Posts: 144
Likes: 0
Received 0 Likes
on
0 Posts
From: Moscow,
ID
RE: CDI gr8flyer55
Charlie, I don't know how you are getting that table. Maybe your hall sensor degree setting is wrong? When I set all the advance curve to 0 I get the following table...
5333,0,0,0,0,0,0,0,0,0,0,0,0,0,0,272,293,314,335,3 56,377,398,419,440,461,482,503,524,
[...]
4997,5018,5039,5060,5081,5102,5123,5144,5165,5186, 5207,5228,5249,5270,5291,5312
These should be the max values for waiting all the way to TDC with 30 degree hall sensor placement.
Nyemi said:
> But RC Ignition uses a Hall input rising edge.
The hall sensor is active low, like in your picture. So the falling edge comes right as the magnet is hitting the sensor. That's why I figured on using the falling edge. If I used the rising edge I would be getting the interrupt right as the magnet leaves the sensor.
> In the code, you can also wait for the Hall input (GP2) signal when there is ignition timing delay is not ready?
The interrupt only triggers on the falling edge. So it will only produce one interrupt per rev. The rising edge will not trigger the interrupt, so we don't have to worry about it.
> above table the first value is 1448075. how is that usable?
It's not. You must have an error in the spreadsheet. Everyone should check their numbers. There should be nothing larger than 5333 in the table if you hall is at 30 deg. If you hall is at 40 deg. then you should have nothing above 7125.
> In this particular example that first number is an issue....
I should have mentioned this. The first number is actually table value 256.
I'm using an 8-bit variable for CurrentRev. In order to get double the resolution (128 instead of 256 uS) I'm using the low 8-bits of Timer1 to round up or down. So we can get 255 for CurrentRev, but then if it gets rounded up it will go to 256, which rolls over to 0 since we're using an 8-bit variable. So a CurrentRev of 256 will end up being 0.
I figured this was a pretty slick way to do things. A real CurrentRev of 0 can never happen, unless you were running at infinity RPMs. So I use table value 0 to get an extra table value out of the same space, and it accounts for the chance of the max value of 255 getting rounded up to 256 and rolled over to 0.
> If you look at the table I posted you will see that there are values bigger then what timer1 can hold.
If you email me the spreadsheet I'll take a look at it to see what's going on. It's easy to accidentally change a wrong cell in Excel and have it screw up the whole sheet.
I'm working on the spreadsheet and should have a new version today or tomorrow with the features people have asked for. People also kindly sent me some example spreadsheets that show a slick way to make a button generate the code. Keep the examples coming! It really helps me to learn the spreadsheet tricks.
In the future, the spreadsheet will generate all the code, or at least the whole "User Settings" section. I'll also write some documentation to help people figure things out, and hopefully I can figure out how to protect all the cells that shouldn't be changed.
On the website I'm also going to start putting up new versions each time instead of replacing the old ones. And I'm putting up a "Dev release" download section that will link to the files I'm currently working on at the moment.
If you want to help work on the spreadsheet use the dev version to add changes, and email it to me as soon as you can so that we don't get out of sync. I added another sheet for the new curve that adds more control points (every 500 RPM instead of every 1K). It isn't linked to the table values yet.
http://www.electrofunnel.com/CDI-2012/index.htm
-Jake
5333,0,0,0,0,0,0,0,0,0,0,0,0,0,0,272,293,314,335,3 56,377,398,419,440,461,482,503,524,
[...]
4997,5018,5039,5060,5081,5102,5123,5144,5165,5186, 5207,5228,5249,5270,5291,5312
These should be the max values for waiting all the way to TDC with 30 degree hall sensor placement.
Nyemi said:
> But RC Ignition uses a Hall input rising edge.
The hall sensor is active low, like in your picture. So the falling edge comes right as the magnet is hitting the sensor. That's why I figured on using the falling edge. If I used the rising edge I would be getting the interrupt right as the magnet leaves the sensor.
> In the code, you can also wait for the Hall input (GP2) signal when there is ignition timing delay is not ready?
The interrupt only triggers on the falling edge. So it will only produce one interrupt per rev. The rising edge will not trigger the interrupt, so we don't have to worry about it.
> above table the first value is 1448075. how is that usable?
It's not. You must have an error in the spreadsheet. Everyone should check their numbers. There should be nothing larger than 5333 in the table if you hall is at 30 deg. If you hall is at 40 deg. then you should have nothing above 7125.
> In this particular example that first number is an issue....
I should have mentioned this. The first number is actually table value 256.
I'm using an 8-bit variable for CurrentRev. In order to get double the resolution (128 instead of 256 uS) I'm using the low 8-bits of Timer1 to round up or down. So we can get 255 for CurrentRev, but then if it gets rounded up it will go to 256, which rolls over to 0 since we're using an 8-bit variable. So a CurrentRev of 256 will end up being 0.
I figured this was a pretty slick way to do things. A real CurrentRev of 0 can never happen, unless you were running at infinity RPMs. So I use table value 0 to get an extra table value out of the same space, and it accounts for the chance of the max value of 255 getting rounded up to 256 and rolled over to 0.
> If you look at the table I posted you will see that there are values bigger then what timer1 can hold.
If you email me the spreadsheet I'll take a look at it to see what's going on. It's easy to accidentally change a wrong cell in Excel and have it screw up the whole sheet.
I'm working on the spreadsheet and should have a new version today or tomorrow with the features people have asked for. People also kindly sent me some example spreadsheets that show a slick way to make a button generate the code. Keep the examples coming! It really helps me to learn the spreadsheet tricks.
In the future, the spreadsheet will generate all the code, or at least the whole "User Settings" section. I'll also write some documentation to help people figure things out, and hopefully I can figure out how to protect all the cells that shouldn't be changed.
On the website I'm also going to start putting up new versions each time instead of replacing the old ones. And I'm putting up a "Dev release" download section that will link to the files I'm currently working on at the moment.
If you want to help work on the spreadsheet use the dev version to add changes, and email it to me as soon as you can so that we don't get out of sync. I added another sheet for the new curve that adds more control points (every 500 RPM instead of every 1K). It isn't linked to the table values yet.
http://www.electrofunnel.com/CDI-2012/index.htm
-Jake
09-18-2012 | 07:54 AM
#335
My Feedback: (11)
RE: CDI gr8flyer55
Jack,
Ilook at the excel file , Last Rev3 ,I had a bit time today and in the Table value on the D3 for copy paste I look at the statement and reason for starting with the high number and then small is
that it gets first cell G262 and then G7,G8....etc.
I change the beginning and the end of the statement and then all comes in order. Un less you need the G262 for some reason to be first. .
G262= 916RPM
As far as calculation all seams to be OK, I test it with a linear curve like in the last posting and all comes in order .
If you make a wave curve then numbers are up and down to reflect that.
Before:
=TEXT(G262,0)&","&TEXT(G7,0)&","&T EXT(G8,0)&","&TEXT(G9,0)&",........... ....,"&TEXT('Table Values'!G261,0)
After:
=TEXT(G7,0)&","&TEXT(G8,0)&","&TEX T(G9,0)&",..........,"TEXT(G261,0)&","& ;TEXT('Table Values'!G262,0)
Thanks
Adrian
Ilook at the excel file , Last Rev3 ,I had a bit time today and in the Table value on the D3 for copy paste I look at the statement and reason for starting with the high number and then small is
that it gets first cell G262 and then G7,G8....etc.
I change the beginning and the end of the statement and then all comes in order. Un less you need the G262 for some reason to be first. .
G262= 916RPM
As far as calculation all seams to be OK, I test it with a linear curve like in the last posting and all comes in order .
If you make a wave curve then numbers are up and down to reflect that.
Before:
=TEXT(G262,0)&","&TEXT(G7,0)&","&T EXT(G8,0)&","&TEXT(G9,0)&",........... ....,"&TEXT('Table Values'!G261,0)
After:
=TEXT(G7,0)&","&TEXT(G8,0)&","&TEX T(G9,0)&",..........,"TEXT(G261,0)&","& ;TEXT('Table Values'!G262,0)
Thanks
Adrian
09-18-2012 | 09:44 AM
#336
Senior Member
Joined: Feb 2010
Posts: 133
Likes: 0
Received 0 Likes
on
0 Posts
From: szarvas, HUNGARY
RE: CDI gr8flyer55
Hi Jake
<the hall="" sensor="" is="" active="" like="" in="" your="" picture.="" so="" the="" falling="" edge="" comes="" right="" as="" magnet="" hitting="" sensor.="" why="" i="" figured="" on="" using="" edge.="" if="" used="" rising="" would="" be="" getting="" interrupt="" leaves="">
<span lang="en" class="short_text" id="result_box"><span class="hps">The</span> <span class="hps">user</span> <span class="hps">should be seen</span> <span class="hps">as</span> <span class="hps">good.</span>
<span class="hps">Not</span> <span class="hps">the code</span><span>.
</span></span><span lang="en" class="short_text" id="result_box"><span class="hps">Watch</span> <span class="hps">video:www.youtube.com/watch</span></span>
<the interrupt="" only="" triggers="" on="" the="" falling="" edge.="" so="" it="" will="" produce="" one="" per="" rev.="" rising="" edge="" not="" trigger="" we="" have="" to="" worry="" about="" it.="">
<span lang="en" class="short_text" id="result_box"><span class="hps"><span lang="en" id="result_box"><span class="hps">This is a</span> <span class="hps">practical problem</span><span>.</span>
<span class="hps alt-edited">High</span> <span class="hps">electronic</span> <span class="hps">smog in the</span> <span class="hps">PIC</span><span>.</span>
<span class="hps">My</span> <span class="hps">engine</span> <span class="hps">is working</span><span>.</span> <span class="hps">Your</span> <span class="hps">ignition</span> <span class="hps">code.</span>
<span class="hps">PIC</span> <span class="hps">is working</span> <span class="hps">badly.</span>
<span class="hps">Believe</span> <span class="hps">me.</span>
<span class="hps">I can only</span> <span class="hps">help you</span><span>.</span>
<span class="hps">To</span> <span class="hps">be perfect</span> <span class="hps">in your</span> <span class="hps">code.
</span></span></span><span>
</span></span>
</the></the>
<the hall="" sensor="" is="" active="" like="" in="" your="" picture.="" so="" the="" falling="" edge="" comes="" right="" as="" magnet="" hitting="" sensor.="" why="" i="" figured="" on="" using="" edge.="" if="" used="" rising="" would="" be="" getting="" interrupt="" leaves="">
</the><the hall="" sensor="" is="" active="" like="" in="" your="" picture.="" so="" the="" falling="" edge="" comes="" right="" as="" magnet="" hitting="" sensor.="" why="" i="" figured="" on="" using="" edge.="" if="" used="" rising="" would="" be="" getting="" interrupt="" leaves="">The hall sensor is active low, like in your picture. So the falling edge comes right as the magnet is hitting the sensor. That's why I figured on using the falling edge. If I used the rising edge I would be getting the interrupt right as the magnet leaves the sensor.
<span class="hps">Not</span> <span class="hps">the code</span><span>.
</span></span><span lang="en" class="short_text" id="result_box"><span class="hps">Watch</span> <span class="hps">video:www.youtube.com/watch</span></span>
The interrupt only triggers on the falling edge. So it will only produce one interrupt per rev. The rising edge will not trigger the interrupt, so we don't have to worry about it.</the><the hall="" sensor="" is="" active="" like="" in="" your="" picture.="" so="" the="" falling="" edge="" comes="" right="" as="" magnet="" hitting="" sensor.="" why="" i="" figured="" on="" using="" edge.="" if="" used="" rising="" would="" be="" getting="" interrupt="" leaves="">
<span lang="en" class="short_text" id="result_box"><span class="hps"><span lang="en" id="result_box"><span class="hps">This is a</span> <span class="hps">practical problem</span><span>.</span>
<span class="hps alt-edited">High</span> <span class="hps">electronic</span> <span class="hps">smog in the</span> <span class="hps">PIC</span><span>.</span>
<span class="hps">My</span> <span class="hps">engine</span> <span class="hps">is working</span><span>.</span> <span class="hps">Your</span> <span class="hps">ignition</span> <span class="hps">code.</span>
<span class="hps">PIC</span> <span class="hps">is working</span> <span class="hps">badly.</span>
<span class="hps">Believe</span> <span class="hps">me.</span>
<span class="hps">I can only</span> <span class="hps">help you</span><span>.</span>
<span class="hps">To</span> <span class="hps">be perfect</span> <span class="hps">in your</span> <span class="hps">code.
</span></span></span><span></span></span>
</the></the>
09-18-2012 | 12:12 PM
#337
Senior Member
Joined: Aug 2011
Posts: 144
Likes: 0
Received 0 Likes
on
0 Posts
From: Moscow,
ID
RE: CDI gr8flyer55
> I change the beginning and the end of the statement and then all comes in order. Un less you need the G262 for some reason to be first.
The last table value DOES need to be first. CurrentRev can be 255 and get rounded up to 256. Since it's an 8-bit variable setting it to 256 rolls it over to zero. That's why the last value ends up in the first slot in the array.
Zero is not a valid revolution time, so I'm just making use of the zero slot in the array to handle the case where the highest value gets rounded up.
-Jake
The last table value DOES need to be first. CurrentRev can be 255 and get rounded up to 256. Since it's an 8-bit variable setting it to 256 rolls it over to zero. That's why the last value ends up in the first slot in the array.
Zero is not a valid revolution time, so I'm just making use of the zero slot in the array to handle the case where the highest value gets rounded up.
-Jake
09-19-2012 | 06:03 AM
#339
Senior Member
Joined: Jul 2010
Posts: 404
Likes: 0
Received 0 Likes
on
0 Posts
From: Alkmaar, NETHERLANDS
RE: CDI gr8flyer55
Table valuas from John (website Jake) without any changes, just open Exel-file and copy / past from cel D3 tab tablevalue
9272,2,44,86,128,170,212,254,296,338,380,422,464,5 06,548,168,174,167,160,152,145,138,131,124,116,109 ,102,83,63,43,39,41,44,47,49,52,55,57,60,62,89,117 ,145,173,200,228,256,290,368,445,522,599,676,753,8 31,908,985,1062,
1139,1209,1270,1330,1390,1451,1511,1571,1631,1692, 1752,1812,1873,1933,1993,2053,2114,2174,2234,2295, 2355,2397,2436,2475,2514,2553,2593,2632,2671,2710, 2749,2789,2828,2867,2906,2945,2984,3024,3063,3102, 3141,3180
,3220,3259,3298,3337,3376,3416,3455,3494,3533,3572 ,3611,3651,3690,3729,3768,3807,3847,3886,3925,3964 ,4003,4043,4082,4121,4160,4199,4238,4278,4317,4356 ,4395,4434,4474,4513,4552,4591,4630,4670,4709,4748 ,4787,482
6,4865,4905,4944,4983,5022,5061,5101,5140,5179,521 8,5257,5297,5336,5375,5414,5453,5492,5532,5571,561 0,5649,5688,5728,5767,5806,5845,5884,5924,5963,600 2,6041,6080,6119,6159,6198,6237,6276,6315,6355,639 4,6433,64
72,6511,6551,6590,6629,6668,6707,6746,6786,6825,68 64,6903,6942,6982,7021,7060,7099,7138,7178,7217,72 56,7295,7334,7373,7413,7452,7491,7530,7569,7609,76 48,7687,7726,7765,7805,7844,7883,7922,7961,8000,80 40,8079,8
118,8157,8196,8236,8275,8314,8353,8392,8432,8471,8 508,8545,8581,8617,8654,8690,8726,8763,8799,8836,8 872,8908,8945,8981,9017,9054,9090,9127,9163,9199,9 236
9272,2,44,86,128,170,212,254,296,338,380,422,464,5 06,548,168,174,167,160,152,145,138,131,124,116,109 ,102,83,63,43,39,41,44,47,49,52,55,57,60,62,89,117 ,145,173,200,228,256,290,368,445,522,599,676,753,8 31,908,985,1062,
1139,1209,1270,1330,1390,1451,1511,1571,1631,1692, 1752,1812,1873,1933,1993,2053,2114,2174,2234,2295, 2355,2397,2436,2475,2514,2553,2593,2632,2671,2710, 2749,2789,2828,2867,2906,2945,2984,3024,3063,3102, 3141,3180
,3220,3259,3298,3337,3376,3416,3455,3494,3533,3572 ,3611,3651,3690,3729,3768,3807,3847,3886,3925,3964 ,4003,4043,4082,4121,4160,4199,4238,4278,4317,4356 ,4395,4434,4474,4513,4552,4591,4630,4670,4709,4748 ,4787,482
6,4865,4905,4944,4983,5022,5061,5101,5140,5179,521 8,5257,5297,5336,5375,5414,5453,5492,5532,5571,561 0,5649,5688,5728,5767,5806,5845,5884,5924,5963,600 2,6041,6080,6119,6159,6198,6237,6276,6315,6355,639 4,6433,64
72,6511,6551,6590,6629,6668,6707,6746,6786,6825,68 64,6903,6942,6982,7021,7060,7099,7138,7178,7217,72 56,7295,7334,7373,7413,7452,7491,7530,7569,7609,76 48,7687,7726,7765,7805,7844,7883,7922,7961,8000,80 40,8079,8
118,8157,8196,8236,8275,8314,8353,8392,8432,8471,8 508,8545,8581,8617,8654,8690,8726,8763,8799,8836,8 872,8908,8945,8981,9017,9054,9090,9127,9163,9199,9 236
09-19-2012 | 08:34 AM
#341
Senior Member
Joined: Aug 2011
Posts: 144
Likes: 0
Received 0 Likes
on
0 Posts
From: Moscow,
ID
RE: CDI gr8flyer55
Hang tight. I'm working on a major rework of the spreadsheet.
Safety Note: I've noticed the CDI can sometimes fire a random spark here and there. Sometimes a bit after you power it up, sometimes after you remove the power. I think this is probably a hardware issue due to the way the circuit is constructed, I don't think anything can be done about it in software. So be careful! You should power up the CDI before you start messing with the engine and stay clear even after you shut it down.
One feature I'm working on is a software kill switch. I'll probably have the unit fire a few sparks right after the engine stops just to make sure the cylinder can't accidentally fire from a random spark. This probably won't be 100% either as gas could vaporize over time and create fresh fumes in the cylinder.
Safety Note: I've noticed the CDI can sometimes fire a random spark here and there. Sometimes a bit after you power it up, sometimes after you remove the power. I think this is probably a hardware issue due to the way the circuit is constructed, I don't think anything can be done about it in software. So be careful! You should power up the CDI before you start messing with the engine and stay clear even after you shut it down.
One feature I'm working on is a software kill switch. I'll probably have the unit fire a few sparks right after the engine stops just to make sure the cylinder can't accidentally fire from a random spark. This probably won't be 100% either as gas could vaporize over time and create fresh fumes in the cylinder.
09-19-2012 | 02:19 PM
#343
Joined: Mar 2009
Posts: 293
Likes: 0
Received 0 Likes
on
0 Posts
From: xnot applicable, AUSTRALIA
RE: CDI gr8flyer55
Unit firing at power up due to the way 150R (R7) is connected to positive rail and transistor collector (Q2) must pull down to turn off.
Same as with Gompy's old 16f628A ignition that had switching for either a CDI or TCI system. In John's CDI power board he shows an alternative connection for R7 depending on whether you use points, hall effect directly or input from a certain pic micro circuit.
If the circuit was changed so that 150R (R7) was connected to ground and the transistor collector (Q2)connected to the positve rail, then this would not happen. It probably requires software change on GP1 though.
Same as with Gompy's old 16f628A ignition that had switching for either a CDI or TCI system. In John's CDI power board he shows an alternative connection for R7 depending on whether you use points, hall effect directly or input from a certain pic micro circuit.
If the circuit was changed so that 150R (R7) was connected to ground and the transistor collector (Q2)connected to the positve rail, then this would not happen. It probably requires software change on GP1 though.
09-19-2012 | 07:56 PM
#346
Senior Member
Joined: Feb 2010
Posts: 133
Likes: 0
Received 0 Likes
on
0 Posts
From: szarvas, HUNGARY
RE: CDI gr8flyer55
Hi jake
<span lang="en" id="result_box"><span class="hps">I</span> <span class="hps">think</span> <span class="hps">a software</span> <span class="hps">error</span><span>.</span>
<span class="hps">As is</span> <span class="hps">described above.</span>
<span class="hps">Solution.</span>
<span class="hps">The Hall</span> <span class="hps">signal,</span> <span class="hps">not the</span> <span class="hps">interrupt handler</span><span>.</span>
<span class="hps">But it's</span> <span class="hps">easy to</span> <span class="hps">find out</span><span>.</span>
<span class="hps">I</span> <span class="hps">RCexl</span> <span class="hps">code.docs.google.com/file/d/0BxQHqG9HPIj3LU1CaUliTi1xa1U/edit</span>
<span class="hps">The hardware</span> <span class="hps">is working</span> <span class="hps">well</span><span>.</span>
<span class="hps">You have a 100</span><span>%</span> <span class="hps">software problem</span><span>.</span></span>
<span lang="en" id="result_box"><span class="hps">I</span> <span class="hps">think</span> <span class="hps">a software</span> <span class="hps">error</span><span>.</span>
<span class="hps">As is</span> <span class="hps">described above.</span>
<span class="hps">Solution.</span>
<span class="hps">The Hall</span> <span class="hps">signal,</span> <span class="hps">not the</span> <span class="hps">interrupt handler</span><span>.</span>
<span class="hps">But it's</span> <span class="hps">easy to</span> <span class="hps">find out</span><span>.</span>
<span class="hps">I</span> <span class="hps">RCexl</span> <span class="hps">code.docs.google.com/file/d/0BxQHqG9HPIj3LU1CaUliTi1xa1U/edit</span>
<span class="hps">The hardware</span> <span class="hps">is working</span> <span class="hps">well</span><span>.</span>
<span class="hps">You have a 100</span><span>%</span> <span class="hps">software problem</span><span>.</span></span>
09-19-2012 | 09:26 PM
#347
Senior Member
Joined: Aug 2011
Posts: 144
Likes: 0
Received 0 Likes
on
0 Posts
From: Moscow,
ID
RE: CDI gr8flyer55
I think you may have a good idea there. I will add a check in the ISR to see if the signal is still driven low. That way the falling edge will cause a check 4-8 uS later. That should filter out any high frequency noise or transient signals.
-Jake
-Jake
09-19-2012 | 10:03 PM
#348
Senior Member
Joined: Feb 2010
Posts: 133
Likes: 0
Received 0 Likes
on
0 Posts
From: szarvas, HUNGARY
RE: CDI gr8flyer55
Hi Jake
<span lang="en" id="result_box" class="short_text"><span class="hps">I</span> <span class="hps">assembler</span><span>:</span> <span class="hps">routine</span> <span class="hps">handles</span> <span class="hps">the</span> <span class="hps">Hall</span> <span class="hps">inputs.</span></span>
<span lang="en" id="result_box" class="short_text"><span class="hps">This</span> <span class="hps">bounce-free</span> <span class="hps">input.</span></span>
Label_0003 BTFSC GPIO ,GP2 ;BTFSC = wait for high pulse on Hall switch (-_+).
GOTO Label_0002 ;BTFSS = wait for low pulse on Hall switch (+_-) Alterable!!
MOVLW 0x01 ;Hall input configuration (GP2)
MOVWF 0x24 ;<span id="result_box" class="short_text"><span style="background-color: rgb(255, 255, 255);" title="Segéd regiszter.">Auxiliary registers=0x24</span></span>
GOTO Label_0003
Label_0002 MOVF 0x24 , F
BTFSC STATUS , Z
GOTO Label_0003
CLRF 0x24
<span lang="en" id="result_box" class="short_text"><span class="hps">Continue</span> <span class="hps">program execution</span><span>.</span></span>
<span lang="en" id="result_box" class="short_text"><span class="hps">I</span> <span class="hps">assembler</span><span>:</span> <span class="hps">routine</span> <span class="hps">handles</span> <span class="hps">the</span> <span class="hps">Hall</span> <span class="hps">inputs.</span></span>
<span lang="en" id="result_box" class="short_text"><span class="hps">This</span> <span class="hps">bounce-free</span> <span class="hps">input.</span></span>
Label_0003 BTFSC GPIO ,GP2 ;BTFSC = wait for high pulse on Hall switch (-_+).
GOTO Label_0002 ;BTFSS = wait for low pulse on Hall switch (+_-) Alterable!!
MOVLW 0x01 ;Hall input configuration (GP2)
MOVWF 0x24 ;<span id="result_box" class="short_text"><span style="background-color: rgb(255, 255, 255);" title="Segéd regiszter.">Auxiliary registers=0x24</span></span>
GOTO Label_0003
Label_0002 MOVF 0x24 , F
BTFSC STATUS , Z
GOTO Label_0003
CLRF 0x24
<span lang="en" id="result_box" class="short_text"><span class="hps">Continue</span> <span class="hps">program execution</span><span>.</span></span>
09-20-2012 | 06:01 PM
#349
Senior Member
Joined: Nov 2005
Posts: 805
Likes: 0
Received 0 Likes
on
0 Posts
From: Hamburg,
PA
RE: CDI gr8flyer55
Nyemi,
So we just have to convert this assembler routine into a "C" routine and the input routine should then function correctly.
I think I may have saved some of the old routines from the old project we can try.
Jake, would it help to have the old excel file that we had used to generate the c code after making the curve from the previous project, or have you already obtained a copy? It would probably have to be edited since the c code is using the data collected in a slightly different sequence but may be helpful. Nyemi had suggested the original routine when we had the problem before.
As for the numbers in the curve looking odd and being too large, the spreadsheet generated numbers do come out right if I do a flat curve. I didn't edit anything else that I can remember, just the curve. I started at 0 rpm and 0 degrees of advance if that is of importance. Just trying the curve in a compiled hex file showed no bad reactions during the running of the engine, so it must not be affecting the timer output to the ignition. Either way, it was a test run which gave us an idea of how it worked so far. A little tweaking here and there should have the code working as expected. It's come a long way in a very short time, there are bound to be some setbacks to overcome.
John
So we just have to convert this assembler routine into a "C" routine and the input routine should then function correctly.
I think I may have saved some of the old routines from the old project we can try.
Jake, would it help to have the old excel file that we had used to generate the c code after making the curve from the previous project, or have you already obtained a copy? It would probably have to be edited since the c code is using the data collected in a slightly different sequence but may be helpful. Nyemi had suggested the original routine when we had the problem before.
As for the numbers in the curve looking odd and being too large, the spreadsheet generated numbers do come out right if I do a flat curve. I didn't edit anything else that I can remember, just the curve. I started at 0 rpm and 0 degrees of advance if that is of importance. Just trying the curve in a compiled hex file showed no bad reactions during the running of the engine, so it must not be affecting the timer output to the ignition. Either way, it was a test run which gave us an idea of how it worked so far. A little tweaking here and there should have the code working as expected. It's come a long way in a very short time, there are bound to be some setbacks to overcome.
John
09-21-2012 | 02:16 PM
#350
Senior Member
Joined: Aug 2011
Posts: 144
Likes: 0
Received 0 Likes
on
0 Posts
From: Moscow,
ID
RE: CDI gr8flyer55
It's easy enough to include inline assembly in your C code. Advanced programmers often check the assembly that is generated from the C code and redo any parts they don't like with an inline assembly routine.
But the main issue is that Nyemi's code uses polling while mine uses interrupts. Polling repeatedly checks the pin to see if it's changed. With the interrupt it calls the interrupt service code when the hardware finds a falling edge. So I only get one interrupt.
I added an if statement to check if GP2 is low when the interrupt is called. It seems to work fine in the simulator until 81 Hz (about 4800 RPM). I'm not sure what's going on here and will have to do some real world testing. I have no idea if this is just a simulator artifact or if it is a real world problem.
-
I did some more testing with a real spark plug and the CDI seems able to spark continuously at 63 uS between sparks. I used a trigger pulse of 3 uS, then a delay of 63 uS for each spark. That was the fastest it could spark reliably. So about 66 uS between sparks.
So the unit can spark every 5 deg. up to 12,300 RPM!!!
Or every degree up to 2,500 RPM!
This is without the added resistance of cylinder compression, but it bodes well for the multispark idea!
-Jake
But the main issue is that Nyemi's code uses polling while mine uses interrupts. Polling repeatedly checks the pin to see if it's changed. With the interrupt it calls the interrupt service code when the hardware finds a falling edge. So I only get one interrupt.
I added an if statement to check if GP2 is low when the interrupt is called. It seems to work fine in the simulator until 81 Hz (about 4800 RPM). I'm not sure what's going on here and will have to do some real world testing. I have no idea if this is just a simulator artifact or if it is a real world problem.
-
I did some more testing with a real spark plug and the CDI seems able to spark continuously at 63 uS between sparks. I used a trigger pulse of 3 uS, then a delay of 63 uS for each spark. That was the fastest it could spark reliably. So about 66 uS between sparks.
So the unit can spark every 5 deg. up to 12,300 RPM!!!
Or every degree up to 2,500 RPM!
This is without the added resistance of cylinder compression, but it bodes well for the multispark idea!
-Jake
