It's a opensource project.
If you want a commercial project, go to the shop and buy one.

Rob,

in this schematic http://www.rcuniverse.com/forum/m_43...38/key_/tm.htm

Why not have the pic increase or decrease the pulse to drive the mosfets according to engine RPM. That way at low rpm the unit is consuming very little current.

are you thinking of a push pull system with the mosfets? one is on and one is off and then they just alternate?

My ASCII- artwork isn't nice.
Wat I mean is, pause, high, pause, low, pause, high, pause, low,.....
This we have to make on both channels from the pic.
If transistor1 is high, transistor2 must be low and between switching (!) there must be a break/pause.
The transformer in the new schematic is a normal transformer and didn't work as a flybacktransformer.
This transformer need AC and the problem is, we don't have AC so we have to make it.
But AC have a smooth sinus wave and we don't have.
The Voltage will go from high within 0 usec to low......and thats not good.
Transformers don't like the squerpuls we put into the transformer.
But1 transformers act analogous, so inside the transformer the squerpuls will be reformed to a sinuswave.
But2 we have to given the transformer some time to do this and this is the break/pause between the high and low switching.

Dead time injection is not needed when a push-pull system inimplemented using a transformer with a center tap, only when half orfull bridges are used, to prevent a shoot-trough.

The square wave voltage isn't really a problem, because transformersare inductive, and therefore the current can't follow the square wavepattern; instead, the current will be more like a triangle shape.Ofcourse, driving the transformer with sine waves is more efficient. Itis possible to generate a sine wave using PWM hardware, but then thefrequency would be much lower, and thus a larger and heaviertransformer would be needed. This is ofcourse not what we want. A verysmall, light transformer needs a very high frequency input.

The problem with the current designs, is that the software has toconstantly check the sensor input for the pulse. This means the timingis rather inaccurate; at, say, 10krpm, the input needs to be checked at120kHz to achieve 1 degrees accuracy.

With the input capture hardware, an accuracy of 3.75 thousands of adegree is possible, and far less CPU intensive. Also, measuring theinterval between the pulses, which is needed to determine the speed, isfar easier.

I'll look into the schematics to find out if it is possible to use theexisting board with a few minor patches. If not, a different, lessaccurate and less flexible implementation of the software would beneeded to use the board.

The placement of the sensor (or, more accurately, the place of therising edge of the sensor respective to the TDC position) is a somewhatcomplicated matter. If the input capture function cannot be used, itwould be easier if the rising edge is outside the range where theignition should take place. On the other hand, if the rising edgeoccures at the exact moment the ignition should fire at low speed,starting will be easier. This is for a capacitive ignition system, foran inductive ignition, it is again different.

How do you start the engine? Do you rotate it by hand, do you use astarting cord, or something like a power drill? Would it be a problemif the engine would need to be rotated a few times (about 5 turns) at aconstant speed before the ignition start firing? This would be neededto get a reasonably accurate speed measurement.

On the matter of capacitive vs. inductive ignition systems: I'm notsure if the coil for an inductive system needs to be bigger and heavierthan for an capacitive system. With the inductive kind, the capacitorand transformer are not needed. Also, an inductive system is basicallya current source; the voltage on the secondairy side will rise untilthe current can flow, either through the spark plug, or through thesemiconductors on the primairy side (which is very bad). A capacitivesystem, om the other hand, is a voltage source; the secondairy side ofthe coil will deliver a voltage, which may or may not be sufficient tojump the spark gap.


EDIT:by the way, the transformer setup that i've seen in the designs, is not a flyback, it's just a blindly driven push-pull circuit. To get optimal efficiency. it needs to be carefully tuned.

What kind of electronic equipment do you have?Ithink Ican't assume all of you to have oscilloscopes and compilers and programmers for the microcontroller. How do you expect to build and test these things? Do you expect pre-programmed controllers from fellow builders? I'm thinking about using a bootloader, so that the software can be updated without a special programmer, using a serial port.


EDIT2: I do not mean to offend the previous programmer, but the existing code is, in my opinion, broken beyond repair. I won't be using that code, but write the new code from scratch.

I write in C, so learning PICBasic will not really help you understanding my code, or enable you to make educated changes. PICBasic is not portable and, in my opinion, very inflexible, and unsuitable for any kind of serious development.

I'm not quite sure about the ignition advance option; we could use tables, and either choose the closest entry, or interpolate between the entries, or use a formula with some variables that can be adjusted. Any thoughts?

Sparky GSX

We typically start our aircraft engines by hand. The procedure is to close the choke and then flip the propellor until it "pops" - usually 3 to 5 flips. Then open the choke and flip the propellor until it starts - usually 1 to 3 flips. Smaller engines - 26cc and smaller can be started with small high torque hand held electric starters. I don't think you can assume constant speed for 5 revs for starting.

One other consideration I didn't mention in my previous post is that radio frequency interference is a consideration when designing a CDI for model aircraft. We typically solve this problem by shielding the spark plug wire and cap. Also maintaining as much distance as possible between the ignition and the receiver-servo group.

Speaking for the RC aircraft guys, we are hoping that you electronic & software wizards could develop a simple, reliable and inexpensive ignition that we could build. Once the software was debugged we would download and burn our chips.

Thanks for your interest.

AlZ

Ok, so the starting phase requires some more thought. If the ideal point for the ignition when starting is not the same as either of the edges from the sensor, a reasonably accurate speed measurement is needed to determine the delay for the spark. The easiest, en probably most reliable thing to do, would be to align the rising edge of the sensor with the desired point for the ignition when starting, and to use an accurate solution in hardware and software for the spark timing when the engine is running.

How does this work with the current software? Is it possible to start the engine that way? On motorcycles, this usually isn't a problem, because the sensor is aligned with the ignition point when starting.

Some further comments on timing.

Almost all are using a Hall effect sensor for a pulse. Timing will vary depending on the engine manufacture but is typically 28 to 30 degrees before Top Dead Center. We attach the propellor to the shaft in such a manner that when we "flip" the propellor, the magnet passes by the Hall sensor and fires the plug. You can see the magnet and Hall sensor clearly in the attached photo.

Ok, so when flipping, we do get a pulse from the hall sensor, but what is the offset between the rising edge of the sensor and the desired time for the ignition? If there is no offset, and you use a capacitive system, starting the engine should be easy (from a CDI point of view). If there is an offset, or if you're using an inductive system, it's a bit more difficult. The problem with inductive systems is that you can't run a continuous current through the coil, waiting for the edge from the sensor to generate the spark. If you just keep the transistor on, and thus have a continuous current through the coil, it could overheat and fail.

Nice to see that you are working on new code for this!
I hope it's something I can adapt to my version too

I have now done the first dyno runs with the ignition, and have just started learning how it reacts. Not exacly according to the two stroke tuning books I have read it seems..

For those of you interested in the result, you can find a short summary with pictures here:
http://www.hpibajaforum.com/forum/sh...78#post1066878

<br type="_moz"/>

Hi SparkyGSX,

What version of C do you use? CCS ?

Most if not all model aircraft engines produce a spark when a logic 0 is seen at the ignition board. So I think the best thing to do is have your code look for a low going pulse and then start the timer or what ever. So I guess I am saying as soon as the magnet reaches the hall the signal goes low. This is where the spark needs to occur.

I usually use AVR microcontrollers for such projects, so I use AVR studio with WinAVR. I currently don't have tools for the PIC microcontrollers, but that doesn't have to be a problem. Which compiler I use also isn't really relevant, since porting between compilers is generally fairly easy. Only the syntax for interrupt handlers and tables in flash memory is different, but that is very easy to fix. It's not something I worry about at this stage.

But the conclusion is that when starting, we don't need any complicated spark timing; just generate the spark as soon as the sensor input goes low. When the engine is running, it is fairy easy to get accurate speed measurements, and get the timing right.

As was stated before there does need to be a delay at starting to prevent kick back. The inital timing is set at 28 to 30 degrees Before Top dead center. There needs to be about 5ms delay.That would retard the timing to around 5 degrees or so.That would make starting easier with no kickback.

The delay, in milliseconds, depends on the rotational speed of theengine. A fixed delay of 5ms is easy to implement, but would that besufficient? Wouldn't it be easier to adjust the sensor so that thisdelay isn't needed, and only advance the ignition in software once theengine has started?

What I would like to change about the existing design, is to connect the hall sensor to pin 9 instead of pin 7, the SCR to pin 2 instead of pin 6, and move the jumpers on pins 7 and 8 to two other pins, probably 17 and 18, to be able to use the UART for communication with a PC or laptop for configuration and debugging.

While I´m not thrilled about the design, in particular, the (in my opinion) unnecessary optocoupler, the rather fragile flyback converter, and the use of a 7805 voltage regulator instead of a low-drop regulator or shunt regulator.

But by far the worst part is the rather poor choice of the I/O pins of the microcontroller, which makes it impossible to use any of the specialized peripherals.

I don't mean to offend anyone by saying this, but I feel it needs to be said to be able to explain what I would like to change, and why. <br type="_moz"/>

Hi SparkyGSX,

I don't know how you would advance the timing if the inital timing is set at say 5 degrees BTC. this is just my idea, feel free to do it any way you want. set the inital timing to 30 degrees. have a delay so the engine wont kick at startup. Then as the rpm increase, decrease the delay thus advancing the timing. Some want the curve to be opposite. full advance at startup and retard the timing as the rpms increase. As far as using other pins use what you need to so it will work the way you want.

Yes the delay does depend on engine rpm. I just used this example to show what is needed at startup.

once the engine is running, I really don't care where the sensor is.

The idea is that you measure and filter the interval between the pulses, and constantly estimate the rotor position, based on this interval measurement. Every time a pulse is received, you calculate the difference between the estimated and measured position of the crankshaft, and adjust the estimated position by a fraction of the difference. That way, you always have a fairly high-resolution live estimation of the crankshaft position, which is constantly adjusted but small amounts, and keeps tracking the actual position.

This way, it doesn't matter exactly where the sensor is, because the switching events are related to the estimated crankshaft position, and not directly to the sensor input.

Hi SparkyGSX,

What it boils down to is your are doing this. Do it which ever way you think is best.Thanks for taking the time to do this for us.

I was going to build a prototype this week using the attached circuit. With the changes coming, I will defer until we have a proven software package.

On thing I would like to see incorporated is the use of a commercially available transformer such as a CTX210655-R. We can either buy new or salvage from a laptop or LCD monitor.

Winding these on a toroid is an art form. I'm not so sure my arthritic fingers are up to the task. Too many propellor strikes!

AlZ

The idea is that you measure and filter the interval between the pulses, and constantly estimate the rotor position, based on this interval measurement. Every time a pulse is received, you calculate the difference between the estimated and measured position of the crankshaft, and adjust the estimated position by a fraction of the difference. That way, you always have a fairly high-resolution live estimation of the crankshaft position, which is constantly adjusted but small amounts, and keeps tracking the actual position.

This way, it doesn't matter exactly where the sensor is, because the switching events are related to the estimated crankshaft position, and not directly to the sensor input.


I'm having some thoghts about this, would this mean you have to use an old rpm value to base your delay on (two revs back in time?) I know this can cause problems in engines with quick throttle response, that the ignition is 'lagging' when the rpm rises quickly. Not sure it's an issue though, just a thought.
I guess the optimum would be to use a multitooth trigger wheel, but it's not really an option here

Let's think about this for a minute. As an example, let's use an extreme situation where I'm hovering an aircraft with the engine turning around 5000 RPM. When I advance the throttle to pull out of the hover I surely don't want the engine to stumble or quit. Now let's assume that the software requires 2 revolutions to correctly measure the engine RPM in order for the ignition timing to follow accordingly. At 5000 RPM this requires 24 milliseconds. Even digital servos will not respond that fast, plus you have to factor in the time lag for the fuel/air mixture to adjust.

If I understand the proposed algorithm correctly, sensor position only matters for ease of starting the engine. Thereafter the software will determine the instantaneous RPM (dR/dt)every revolution based on the interval between pulses and adjust the timing accordingly. This is why we use a micro-processor in this application.

IF this is the case then I don't see the need to program in any delays when starting the engine. We simply position the sensor to fire the plug at 28-30 degrees BTC. This is a good start position to eliminate kick=back but not the best position for optimum RPM. As we advance the throttle and increase RPM's the microprocessor will automatically advance the timing based on the table of values (curve) programmed in. Prior to starting, the processor calculates an RPM of zero. Once the engine fires the RPM will increase and timing will adjust each revolution. You can hold the timing at the start position until the processor sees a minimum RPM value (e.g. 500). Sparky you may need software filters as well as hardware to filter the measured interval. Noise will be a killer! You may also have to integrate the RPM calculation over an interval to come up with an average value to alleviate the noise issue.

I think SparkyGSX is on the right track here and the programming does not have to be overly complicated- but then again I may be mis-understanding his proposed algorithm entirely!

AlZ

You always have to use "old" information, because you have to measurethe speed. The filtering may or may not be needed (I intent to makethis configurable) because of some jitter (variation) in the hallsensor edges.

It would ofcourse be possible to improve the acceleration behaviour (ina future version) by either using a different position sensor, like amissing tooth sprocket, by calculating and correcting for acceleration,or by using extra sensors, like an throttle position or intake manifoldpressure sensor.

I wouldn't know where to get affordable, small and lightweight pressuresensors, but a throttle position sensor should be very difficult. Itwould also be possible to measure the signal to the throttle servo, anduse that for ignition advance.

All this is, ofcourse, for future versions, first we'll have to build a system that works, and works better than the existing software.


@Azalner:Ithink you understand the proposed algorithm perfectly. It would be easy if the sensor can be adjusted to generate an edge at ~30 BDC for starting, and you did understand correctly that the position of the sensor doesn't matter afterwards, as long as the actual position in input correctly in the software. It isn't quite clear to me if this is always possible, or if there are engines where it is very difficult or possible to adjust the sensor or magnet.

Ihave already implemented a FIR(finite impulse respons)filter for the intervals, and therefore for the crankshaft speed. I'm not worried about spurious pulses on the input, if you use a sufficiently low resistance pull-up or pull-down resistor, any noise will be suppressed. A couple of clamping diodes and maybe a small capacitor to either power supply rail would also be a good idea.

Al..
This motor wouldn't fire and run set at 28 degrees of advance..so there has to be a great amount of retard in timing from around 0 to 300 rpm's for hand starting of twins and other slow turning motors.. it's a twin Echo weedeater conversion that does run on glow quite well, but ignition will have to wait till we get a functioning timer board with software.

John

John

Twins are a different animal. I have absolutely no experience with them except when I was on a consulting job in Texas. I ran into an old timer who had a Mac Minarelli on a giant scale PT-17 and he told me that he had to retard the spark to 40 deg. BTDC in order to start it. I didn't see him set the timing so this is hearsay. There may be other factors as well that I am not aware of.

Here is an excellent link to a Zenoah G-38 conversion to CDI ignition. [link]http://tech.flygsw.org/g38ignition.htm

It answers a lot of questions about timing and sensor placement for single cylinder engines.

AlZ