Into the CDI-sheet is a 56usec delay to trigger the thyristor.
Into the TCI-sheet there is a 45/55% delay.
If you have 60usec delay for your TCI, I think you don't use the right code....
The code calculate within 360 - 40 = 320 degrees the ignitiontime, not into the 40 degrees.
I know wat the problem can be, it's the magnet and the hallsensor.
You can't set a exact time with a magnet and hallsensor becourse the magneticfeeld is not defined.
If your flywheel spin harder, the magneticfeeld change and also the triggertime of your hallsensor.
I use for research a IR-optocoupler (TCST2000) and a very near gap (>=1mm), no magnets and hallsensors.

I believe the 56us delay you are mentioning is the off-time of the output until it goes high again = the time it is open for the spark to burn.
What I'm referring to is the time between the trigger of the hall sensor until the output goes low. This is the delay that regulates the ignition angle.
However, even if the ignition angle is set to maximum (all variables in the lookup table are 0) there is still a processing delay of 60us.

I have now done another test, and put all the numbers in the lookup table to the value 2. This made the delay time to approx 260us. By this I conclude that the resolution of the ignition timing is 100us, what I mean is if you change the value in the lookup table by 1, there is 100us more delay between the input and output.
So, it seems it's not possible to compensate for 60us in the lookup table, since subtracting 1would then be over compensating by 40us, so the ignition would actually be advancing slightly with RPM. (providing the trigger has the margin)
The only way to make it exact is to change the code to either increase the resolution or add another 40us delay and then compensate by -1 in the lookup table.. Maybe adding a 40us timer would not be so hard.. maybe I will try that..

I'm comparing the signal on pin 6 and 7 which only gives the delay in the processor, everything else is excluded. The internal delay in the processor seems to be abt 60us even if it is set to 0 in the lookup table, so this is the minimum delay in the processor. Have you tried to measure it in this way?

This is normal with a processor as far as I know, you will always have some delay, since it has to do a number of loops before the signal is processed and output is activated. In this case the processing time seems to be approx 60us.
This means a 7,2deg delay of the spark @ 20k rpm. The other 3deg I'm seeing could be from the hall sensor etc. Or it could also be that the delay in the processor is actually a little bit more than 60us since my oscilloscope is old, and not calibrated in any way..

Actually, maybe over-compensating by subtracting 1 from the values in the lookup table would give a nice result anyway, to compensate for small delays in the hall sensor too.

More experiments later..

I think you are on the right track Rallyfinnen.. Our airplane engines do operate in the 7-10,000 rpm range mostly. There are some of us going higher with special engines etc.
The delay is the factor you are working on. This is where the code numbers have to be adjusted due to lag in the hall and processor as rpm's increase.. Good work on the theory by the way! You are definitly on the right track. Since you are able to test the rpm and lag differences with your scope, you have a better idea what's happening than those of us without testing equipment.

When you get the numbers correct and can post a downloadable hex file for the 16f628, please do so.

Alot of us, myself included have a hard time compiling the code to hex. There is a how-to on the website for those that understand the principles..I haven't the time to learn at the moment.
Nice work on the results! We need input like this for sure on the forum.. Thanks in advance for your time and efforts!

John

Rob.. how are connecting the IR optocoupler to the timer for testing? I have a similar part with a slotted gap for a rotating metal plate with a Motorola device. Maybe use that to replace the hall and magnet for higher speeds and less lag? I'll upload the spec sheet for it shortly.. I get them locally for 20 cents each! It has total of 5 pins..2 for the IR led, and 3 for the reciever. Also very small size.
Is this optocoupler replacing the optocoupler on the timer board?

John

Yeah, thinking about it a bit more, I realize that the 100us resolution gives a resoluton of approx 5deg @10k rpm, and 10deg @ 20k rpm
I will se if I can get somebody change the code to improve the resolution of the timing.. it seems the timer used is now running at 1/16 clock frequency, and if that is increased, the resolution should be better..but at this level I'm lost.. A c-hacker is needed!

@Sam, download the 16F628 sheet and find the prescalervalues.
You can change the values, but you hav change them both (now into the exelsheet 128 and 16)

@John, cut the middle wire of the opto, this is the basic of the opto transistor.
See the picture I draw how to connect to the timerboard.
If you want to use the opto to you board, there must be into the transistorlead a resistor (1 - 10 kOhm) to plus of the batterie.

Rob, Our devices are similar.. Mine has a 3 lead on one side for the reciever..the third lead is for the base of the transitor internally.. could be eliminated like we did with the optocoupler I think.. I'll try the resistor you mentioned tonight.. We think alike!

John

Hmm, that's beyond my limitations I think.. I would not know what I'm doing. Will see if I can get some support from a skilled programmer to realize my ideas..

@Sam, the values I mark you can change, but allways both.
If you change 128 into 256, you have to change 16 into 8.
You don't have to much changes to make, I beleve there where only 3 or 4 changes who make sense.
BUT, if you can find us a real programmer we all to appreciate it !!

Now I have discussed this with a friend who has done a lot of programming.

This is what I will try:
T2CON = 0x05; //start TMR2 counter 1:4
T2CON = 0x04; //start TMR2 counter 1:1

This should improve the resolution of the ignition timing.
It will require rescaling of the 'ignition map' (tspark[]) depending on what frequency I use (1:1 or 1:4), so that means the excel file needs to be modified accordingly.

Is the reason to change both clocks to avoid rescaling of tspark? I believe rescaling is needed to adapt the 8-bit range to higher revs. (don't want to be working with 1-digit values in that rev-range) Is there a function for this in the excel sheet as well?

This might not be recommended on low-rev engines, since it will limit the timing adjustment range on low revs. For car engines the clutch engages at 6-8k rpm, +15k is concidered top range Pipe is normally tuned to somewhere between 10-15k.

I will let you know how it works out!

Hi John.....i mucked around with the RC circuit last night in your power board and found that it needs to be fine tuned depending of what turns you have on
the bobbin/ferrit as it seems to make more difference in the recover time not just the oscillation time, as i already had 375 / 8 / 16 turns pre done

John remember the PDF i got Rob to post it has the opto triger you are talking about in it

http://www.modelbouw.gompy.net/cdi/P...ion-System.zip

Sam is it not as easy to increase the clock rate of the pic as it is set to 4Mhz to decrease the delay if that helped ......spose more code would be needed after that change Uh

brett

It should just be a frequency divider for the timer, meaning it counts quicker, with closer steps, that should result in better resolution, but aslo limits the maximum delay time, since it's only a 8-bit counter. It will reach 255 pretty quick..
Well, I'm no expert, so I'll just try it and see what happens

All hobby cdi's I know can handle untill 10,000 rpm.
More professional cdi's have also more pickups, so they can calulate within a short time.
From start, we can't down with the low rpm, 1800 was the end.
Maybe if we use two sensors, the low rpm and real timing can be better.
I'm not a programmer, I understand wat the means, but I can't (re)write the program.
I know wat I / we want, I know how the CDI / TCI must behave and I know how the hardware must be.
A other problem is the language, I can't express me like a want todo to be clear to others.....it takes to many time and misunderstanding.
Into the Nertherlands there are also not many people who use this kind of engines.
The country is to small, we don't have big green feelds or big water where it's permit to use pertol engines.

The 16F628 also has a 16 bit timer(timer 1) 0 to 65534. that should give a little more time.

I can not get the direct hall working, it is quite fine adjustment between self runing and not at all with R2 and C3

any ideas cheers

Brett.. to use the direct hall input, I originally had set R-2 to a value of 680 ohms. I'm not sure what notes Rob put on that schematic since I didn't really look at it much since it was posted.. Give the 680 a try first before playing around with other values. Mine triggers nicely with 680 ohms. Remember though that no timer board was used with that setup so there would be no test functions available.. Mine originally had no timer board and was a stand alone ignition board. You have to trigger it with a magnet at the hall.

John

John i do not need a timer board.....it goes off and triggers it self haha........i have tried both ways hi and low for R1, one way self runs other wont triger

spark is ok but i cant control it, im using a 2sc4138 20 amp device from a TV, my turns are alittle different than yours but thought it was close

i have gone back to my triger board as i know it works to 13k rpm but on that old power board from 1975

it has two large 2n3055 and i was tring to make a small power board, Do you think that two transistor circuit is more stable ???

that is what my bobbin was wound for


brett

Brett.. If your old board was more stable with the windings you have, I'd use it.. My circuit was designed around the toroid and specific windings I used. If assembled with those specs it's stable also. I have 14 of them sitting on my work bench and all operate exactly the same. Switching back and forth between the 680 ohm to positive for direct hall input and then back to the 150 ohm for the timer board presented no bad habits on any of them.

John

I'm now runnng the timer2 at 1:4, and that gives better resolution, but less delay time (abt 1ms I think) and this makes the retard angle quite low on low rpm's. It would be better to use timer1 I think..

I'm now running the trigger at abt 48degrees to give some time for the processor on high revs. I have changed the excel-sheet a bit for this, to compensate for the 1:4 timer frequency and pre-trigger. Again, this could be improved with a 16bit timer..

I also added a delay-compensation into the excel sheet. This allows me to enter the total delay time (of the processor, hall sensor etc), and that is then compensated in the actual values written in tspark.

Since the timer is now the limiting factor, I see values above 255 and sometimes below 0 in tspark. As it is now, I have to manually correct them so they stay between 0 and 255. It would be nice to incorporate this in the code, too much work to do it manually..
 I also tried adding a calculation so the actual angle shown in the graph is based on the corrected tspark value.

I'm not sure if I should continue with this concept, or hope that my friend can solve it using the 16bit timer1.
 
Practical tests:

The delay of the processor does not seem to be affected from changing the timer frequency, It's still around 60us.

When I set the delay compensation to 100us and a constant ignition angle, I get the same behaviour with the ignition timing lamp (strobe) as running without the cotroller board.
The behaviour is that I see a slight retard of the ignition angle at high revs (a few degrees) with and without the controller board. The tricky part is that I don't know if this is actual delay, or just due to a delay in the timing lamp..?
There must be some microsecond delay in the timing lamp too, but I'm not sure how much, and I can't think of any way to measure it.. Suggestions?

Charlie, Digikey has toroids that should work..their part number is 495-3852-ND.
$.45 each if you buy one.. $.33 if you buy 10 at a time.

John

Old C-code will give you back. No test. Minimum RPM 917(OPTION_REG 0x07). No bugs(<span class="short_text" id="result_box"><span title="optimaliz&aacute;l" style="background-color: rgb(255, 255, 255);">optimization</span></span><span id="result_box" class="short_text"><span style="background-color: rgb(255, 255, 255);" title="javitva">)</span></span>. Sorry web translate.<span id="result_box" class="short_text"><span style="background-color: rgb(255, 255, 255);" title="&uuml;dv&ouml;zlettel"> Link:</span></span><font size="2" color="#000000">http://www.elektroworld.info/ftp/index.php?action=downloadfile&amp;filename=cdinobu g.zip</font><span id="result_box" class="short_text"><span style="background-color: rgb(255, 255, 255);" title="&uuml;dv&ouml;zlettel"> Regards nyemi.
</span></span>

Sam by lamp do you mean led bulb.....if you looked up the frequency (data sheet) it was able to flash at that might help choose one that could keep
up to the rpm/flash rate so there was no delay at the point etc

good work so far thanks

brett

Hello guys!

I have now ventured into the programming world.. and I have no ideaf if I'm lost or not

Below is the code where I tried to make some changes (bold text) to use the 16bit timer1, what do you think?

void main() {
//
const unsigned int tspark[]={ 0, 0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 5, 6, 6, 7, 8, 8, 9, 9, 10, 10, 11, 11, 12, 12, 13, 13, 14, 14, 15, 16, 16, 17, 17, 18, 18, 19, 19, 20, 20, 21, 21, 22, 22, 23, 24, 25, 25, 25, 26, 26, 27, 26, 27, 27, 26, 27, 27, 26, 26, 26, 27, 26, 26, 27, 27, 27, 25, 25, 26, 26, 26, 24, 24, 24, 25, 25, 25, 22, 22, 23, 23, 23, 23, 24, 22, 22, 23, 23, 23, 24, 24, 24, 22, 22, 23, 23, 23, 23, 24, 24, 24, 24, 25, 23, 23, 23, 23, 24, 24, 24, 24, 24, 25, 25, 25, 25, 23, 23, 23, 24, 24, 24, 24, 24, 25, 25, 25, 25, 25, 26, 26, 26, 23, 23, 24, 24,
24, 24, 24, 24, 25, 25, 25, 25, 25, 25, 26, 26, 26, 26, 26, 27, 27, 27, 27, 24, 24, 24, 24, 24, 25, 25, 25, 25, 25, 25, 25, 26, 26, 26, 26, 26, 26, 27, 27, 27, 27, 27, 27, 28, 28, 28, 28, 28, 28, 28, 25, 25, 25, 25, 25, 25, 25, 25, 26, 26, 26, 26, 26, 26, 26, 26, 27, 27, 27, 27, 27, 27, 27, 27, 28, 28, 28, 28, 28, 28, 28, 29, 29, 29, 29, 29, 29, 29, 30, 30, 30, 30, 30, 30, 30, 30, 31, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 27, 27, 27, 27, 27, 27, 27, 27, 28, 28, 28, 28};
// Data type changed to int for 16bit timer values

short int spark=0;
unsigned int tspk, t0,t1,low;
unsigned int ofc; //Holds number of overflows
const unsigned int LowDelay=25; //Delay &lt;1832 RPM, in degrees
const unsigned int ld=360/LowDelay; //Dont change this
TRISB = 0x0E; // set RB1,2,3 for input, all others for output RB0=SCR RB4=Strobe
PORTB = 0x11; // set gate to SCR high i.e pin 6 of PIC +strobe
OPTION_REG = 0x06; // tmr0 SOURCE INT CLOCK, 1:128 PRESCALER
INTCON = 0x00; //Disable interrupts +Resets interrupt flags
TMR1 = 0; // Reset timer1
TMR0 = 0; // Reset timer0
PR2 = 255; // This is how far timer2 counts before overflow
T1CON = 0x05; // start TMR1 counter 1:1 using internal clock ??TMR1ON 0x04 or 0x05??
while(1){ //Loop forever
ofc=0; // Reset overflow teller
INTCON = 0x00; // Disable interrupts + Resets interrupt flags
while(PORTB &amp; 0x02){ //Wait for low pulse on Hall switch
if (INTCON&amp;4) { // Overflow
ofc++; //Increase overflow counter
INTCON = 0x00; // Resets interrupt flags
} // End IF
spark = 1;
} //North pole of magnet has passed
if(spark){
t0 = TMR0;
TMR0 = 0; //Start new rev count
if(ofc &gt; 0) { //Overflow timer0, we have &lt; 1832 RPM
if ( ofc &gt;= 36) ofc=36; //Min RPM 50 to avoid big calculations
low=ofc*ld; //Simplified calculation, gives about 25 degrees
delay_cyc (low); //extra delay based on overflow counter
delay_cyc (low);
delay_cyc (low);
delay_cyc (low);
delay_cyc (low); //Repeat 16 times - prescaler
delay_cyc (low);
delay_cyc (low);
delay_cyc (low);
delay_cyc (low);
delay_cyc (low);
delay_cyc (low);
delay_cyc (low);
delay_cyc (low);
delay_cyc (low);
delay_cyc (low);
delay_cyc (low);
} // max 255 -&gt; 2550 cycles
tspk = tspark[t0]; //use table lookup for spark delay
T1CON = 0x05 // start TMR1 counter 1:1 using internal clock ??TMR1ON 0x04 or 0x05??
TMR1= 0; // clear spark timer
while(TMR1 &lt; tspk); // loop until timeout to send spark
PORTB &amp;= 0xee; //sends a ground to the SCR gate
Delay_us(1650); // Calculated delay
PORTB |= 0x11; //ground off the SCR
spark = 0;
} // end if(spark)
} // end while(1)
} // end main

No, I'm actually using a strobe light for car ignition timing. I have an idea to scope the delay between the output of the processor, and the output of the ignition coil.
If i can add up all the delays for the compensation, it should very accurate, no matter what the delay in the strobe is.
In the data sheet of the hall sensor it says that the delay is typically 0,2us, and maximum 2us., so if I approximate 1us for the hall it should be more than good enough.

Sam i just read the data sheet and i see the 1.5us delay on the hall BUT it does not say at what resolution that is at .....

like what Hz will it work to ??? Do you know

brett