CDI schematic
CDI schematic
Hi
I was wondering if any of you have any schematics for a simple CDI for a small single cylinder engine. I don't have a specific application just yet but I have in the past and I'm sure I will in the future. Also interested in schematic for a rev limiter.
Thanks
Brian
I was wondering if any of you have any schematics for a simple CDI for a small single cylinder engine. I don't have a specific application just yet but I have in the past and I'm sure I will in the future. Also interested in schematic for a rev limiter.
Thanks
Brian
Re: CDI schematic
Hi Brian,
Not directly CDI, but here is a hall effect type that is doing well.
Hall Effect ignition
Can't help you out with a rev limiter at this time. A circuit of interest might be a frequency to voltage converter that could be used to limit or disrupt the ignition above a predetermined point on the low voltage side of the coil.
DC
Not directly CDI, but here is a hall effect type that is doing well.
Hall Effect ignition
Can't help you out with a rev limiter at this time. A circuit of interest might be a frequency to voltage converter that could be used to limit or disrupt the ignition above a predetermined point on the low voltage side of the coil.
DC
cool
exactly the type of thing I was looking for. I had scribbled up a similar design to one of those a couple of days ago but my electronic design skills are lacking a bit so I wasn't real sure it would work.
Thanks again
Brian
Thanks again
Brian
Re: cool
I have been trying to come up with a method to create an electronic advance. Most of the systems I have seen are mechanical linkage with the throttle that moves the hall effect sensor.
Below 20k rpm should not be to difficult for some of the basic microcontrollers to handle.......I think.
I prefer twin opposed cyl engines so this pushes that envelope to 40Khz minimum realistically. With a CPU clock of 3-4 times that it would seem that reaction time for any lag in response would not become an issue.
No time to play with the idea at present. Just day dreaming again! [img]/ubb/images/graemlins/blush.gif"%20alt="[/img]
DC
Below 20k rpm should not be to difficult for some of the basic microcontrollers to handle.......I think.
I prefer twin opposed cyl engines so this pushes that envelope to 40Khz minimum realistically. With a CPU clock of 3-4 times that it would seem that reaction time for any lag in response would not become an issue.
No time to play with the idea at present. Just day dreaming again! [img]/ubb/images/graemlins/blush.gif"%20alt="[/img]
DC
Re: cool
Depends on the program. Lots of the simple micros have clocks of 4 mHz (some are 20, Micrchip, for instance).
Dividing by 2 or 4 as appropriate, you get the "cycle" timing. many instructions take 3 to 4 cycles, some take longer, like interrrupts.
20k rpm gives 50 microseconds per revolution, which is maybe 15 instructions of a 1 micosecond cycle. Might be just do-able, wiith a simple program.
The faster units , with cycles of under 1 microsecond would allow much nicer programs.
Automotive processors are pretty powerful, although they admittedly have lots of sensors and cylinders to monitor. But they are getting towards the pentium power range.
Dividing by 2 or 4 as appropriate, you get the "cycle" timing. many instructions take 3 to 4 cycles, some take longer, like interrrupts.
20k rpm gives 50 microseconds per revolution, which is maybe 15 instructions of a 1 micosecond cycle. Might be just do-able, wiith a simple program.
The faster units , with cycles of under 1 microsecond would allow much nicer programs.
Automotive processors are pretty powerful, although they admittedly have lots of sensors and cylinders to monitor. But they are getting towards the pentium power range.
Re: cool
Thanks for the response JT,
That is exactly as I figured too. I had been contemplating that very issue in clock tics per instruction. Interpolate that with trend data taken by the software between pulses might set the response lag to 2 or 3 rpm? Depending on how many instruction are required to sense and make adjustments of course.
Some of the smaller PIC micro's have no interupt functions, so I would hesitate to say that would be a good choice. Precisely why these units are not well suited for encoder quadrature inputs with any reliability above 100hz too.
Wondering also if any RC circuits could handle this a lot simpler with better reaction time. Most of the ignition systems I have come across for models without mechanical advance do not seem all that complex, but all the IC component numbers are removed.
DC
That is exactly as I figured too. I had been contemplating that very issue in clock tics per instruction. Interpolate that with trend data taken by the software between pulses might set the response lag to 2 or 3 rpm? Depending on how many instruction are required to sense and make adjustments of course.
Some of the smaller PIC micro's have no interupt functions, so I would hesitate to say that would be a good choice. Precisely why these units are not well suited for encoder quadrature inputs with any reliability above 100hz too.
Wondering also if any RC circuits could handle this a lot simpler with better reaction time. Most of the ignition systems I have come across for models without mechanical advance do not seem all that complex, but all the IC component numbers are removed.
DC
Re: cool
If you could get about 50 INSTRUCTIONS per rev, you could probably get there, doing some clever assembler work. You would have to use assembler, you probably would never get close with a C compile, although they are getting better.
If all you wanted was straight ignition, you could do it with nearly anything. You would not even need a micro, just a sensor and a coil driver, like one of the old Delta (is that right?) automotive units. BTW, I do have a schemo somewhere for one of those. If wanted I could make a copy.
if you wanted an RPM related advance based on the sensor, you need a micro with some extra power, because some math or a look-up table would be required. Math would make it smoother, but a look-up is faster. You also would need an on-board timer function. You likely could not use the interrupt, but you could maybe just monitor an input for the sensor pulse.
From that you would predict the time of the next one, and fire ahead of the expected time by the advance number.
I think it would get involved, and might not be precise enough. You would need quite a few clock ticks per rev, so that your advance granularity would be acceptable, like 3 or 4 degrees per step max.
Sounds like good fun for those so inclined. Sorry to get out on a techie trip here.
If all you wanted was straight ignition, you could do it with nearly anything. You would not even need a micro, just a sensor and a coil driver, like one of the old Delta (is that right?) automotive units. BTW, I do have a schemo somewhere for one of those. If wanted I could make a copy.
if you wanted an RPM related advance based on the sensor, you need a micro with some extra power, because some math or a look-up table would be required. Math would make it smoother, but a look-up is faster. You also would need an on-board timer function. You likely could not use the interrupt, but you could maybe just monitor an input for the sensor pulse.
From that you would predict the time of the next one, and fire ahead of the expected time by the advance number.
I think it would get involved, and might not be precise enough. You would need quite a few clock ticks per rev, so that your advance granularity would be acceptable, like 3 or 4 degrees per step max.
Sounds like good fun for those so inclined. Sorry to get out on a techie trip here.
Re: cool
We like techie stuff here if'n it fills the reader with a greater understanding of what can be accomplished with the simplest of devices. I don't think the old hit-n-miss, pop'n johnny engines would have made it far for aircraft applications. So simple is relative, eh?
I have some experience with writting assembly language for the older 8 bit processors and have also worked with the Basic Stamp(BS2) units as of late. Reading what I can about these for my purposes has so far shown that these will miss input changes while executing the program step in process. In other words the inputs may never be reacted to in real time with attention to other functions as its priority.
The simple ignition system in this thread linked for Brian could be modified to use as input. The lookup table is an interesting approach in that a curve could be created and modified easily from comparison to a set time base taken from say the CPU clock speed. Definitely faster than some math calculations to determine rate of change to either inputs and outputs. Basing that resolution as you stated as granularity on degrees converted to less than microseconds between sensed pulses.
Short of putting a potentiometer on the throttle control and doing an A-D conversion. This thought kind of misses the intention of purely electronic advance.
Great stuff! [img]/ubb/images/graemlins/grin.gif"%20alt="[/img]
DC
I have some experience with writting assembly language for the older 8 bit processors and have also worked with the Basic Stamp(BS2) units as of late. Reading what I can about these for my purposes has so far shown that these will miss input changes while executing the program step in process. In other words the inputs may never be reacted to in real time with attention to other functions as its priority.
The simple ignition system in this thread linked for Brian could be modified to use as input. The lookup table is an interesting approach in that a curve could be created and modified easily from comparison to a set time base taken from say the CPU clock speed. Definitely faster than some math calculations to determine rate of change to either inputs and outputs. Basing that resolution as you stated as granularity on degrees converted to less than microseconds between sensed pulses.
Short of putting a potentiometer on the throttle control and doing an A-D conversion. This thought kind of misses the intention of purely electronic advance.
Great stuff! [img]/ubb/images/graemlins/grin.gif"%20alt="[/img]
DC
Re: cool
Otto:
It is all RPM vs clock speed. The Stamp is OK for a low-speed engine, but the discussion was for up to 20k rpm. That's darn fast, the stamp might not even respond to an input at that rate.
There are analog ways of doing an advance too, especislly if you can mechanically set the relationship of the sensor pulse to TDC at any arbitrary place.
You can put it at the advance location, and then use an analog differentiator as a speed-up device to bypass a lag circuit, for instance. There are likely better ways.
It is all RPM vs clock speed. The Stamp is OK for a low-speed engine, but the discussion was for up to 20k rpm. That's darn fast, the stamp might not even respond to an input at that rate.
There are analog ways of doing an advance too, especislly if you can mechanically set the relationship of the sensor pulse to TDC at any arbitrary place.
You can put it at the advance location, and then use an analog differentiator as a speed-up device to bypass a lag circuit, for instance. There are likely better ways.
Re: cool
Ummm... sorry, but you're way off. 20k rpm is only 333 rps which translates into 3 milliseconds (or 3000 microseconds) per revolution; 1500 microseconds per spark on a two-cylinder, two-stroke. With a 1 microsecond clock (available in the '80s when I first looked into microcontrollers) and 5 clock cycles per instruction you have 300 instructions per spark; should be plenty. If you use interrupts, you would have some longer instruction cycles but could probably use fewer instructions so I'm pretty sure it's do-able either way.
Re: cool
Well now, you do have a point there, a small matter of a factor of 60, as in seconds per minute.
that's what I get for doing math in the head.
And for having to worry about 20KHZ at work, not 20kRPM There, 60 nanoseconds is a relatively big deal in our PWM audio amplifier designs.
At 3 ms per revolution, you have a much better chance of a decent calculation! But you still don't need a computer to do the spark, or probably even an advance.
that's what I get for doing math in the head.
And for having to worry about 20KHZ at work, not 20kRPM There, 60 nanoseconds is a relatively big deal in our PWM audio amplifier designs.
At 3 ms per revolution, you have a much better chance of a decent calculation! But you still don't need a computer to do the spark, or probably even an advance.