Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
07/25/01 05:44
Read: times


 
#13480 - Newbie Project: Please suggest platform
Please help me select an appropriate microprocessor platform (8052 or other) for my project. Details are as follows:

I am a newbie, so go easy on me...this is LONG!

Application:
-Motorsports. Signal Manipulation for CDI type Ignition System.

Background:
-The current rage in 2 Cycle Racing Engines (Motorcycles, Snowmobiles, etc) is the use of 3D and 4D Ignition Control Units. Just a few years ago, these "black boxes" were available only to factory race teams. Now aftermarket units are widely available to the average guy.

Some definitions:
-2D system: A 2 Dimensional System in one where the ignition timing output (retard) from the "black box" is the function of only one input. The first, and most important input is always the current engine RPM. So a "2D" system simply varies ignition output at the funtion of RPM. The ignition curve, or map is simply z=f(x) where z is retard and x=RPM.

-3d system: A "3D" system adds another parameter. So now the ignition timing output (retard) might be a funtion of ignition and another parameter such as throttle position...z=f(x,y). Now the ignition map is a "3D" surface...hence the term 3D ignition timing control.

- 4D System: z=f(x,y,u)...you get the point.

Specific Application:

I am not interested in making my own CDI or Black Box. That has been well done by many. I am looking at tricking an existing unit in a way that will allow me to use a "3D" mapping where the rules have made that "difficult".

Specifically, the rules for my racing applicaton have been recently revised to outlaw any sensor connections to the black box other than an external spark pickup, and sensors std on the motor through the stock wiring loom. (This essentially eliminates throttle position, gear position, temperature, pressure sensors from being used to map ignition)

This essentially limits you to one feedback signal...current motor RPM (we'll call RPM "w" for angular velocity)

What I want to do is create a counter that can accurately time the period between spark onset events. This will be done for on a rolling basis, and used to calculate acceleration, or dw/dt with minimum lag. This dw/dt will be converted to a voltage output that will be fed to an existing, off the shelf "black box" ignition.

Basically I will get a "3D" Ignition system, even though I only have one signal...the spark event. I can do this by using a legal "black box" ignition, and plugging in my sensor, which is attched to the secondary high voltage spark plug lead (allowed by rules) to the throttle position sensor. But instead of throttle position, my system will be sending a voltage to the "Black box" which is a good estimation of engine load. (dw/dt is inverse of engine load) This can make for very effective ignition mapping.

Structure:

First of all, some filtering, and cleaning of the signal coming from an inductive sensor on the secondary spark plug lead will be done. Hopefully this will give a clean enough pulse (0-5V TTL, etc) that it can be fed to directly to a microprocessor for counting.

Now, lets assume we want to calculate dw/dt across 8 igition pulses (to minimize error). On a rolling basis, we will have to store perhaps 8 or nine "counts" (depending on data flow)

Minimum RPM is 500, so assuming "12 cyrstal" timing, that means that you will have (60/500)s between pulses = 110589 counter pulses. As such, at least 17 bits will be required to store the current ignition cycle "count". At max RPM = 20,000, only 2764 pulses will be counted in one ignition cycle.

After 8 ignition cycles, we can calc the acceleration. This is easy. you take the 8 "counts" and do a least squares fit (1st order) where RPM=function(time). y=ax+b. the coefficient a=dw/dt. If that chews up too much processor time, other finite difference methods could be used, but they would produce more error. Least Sq's is preferred.

The output (voltage) time lag would be 8 ignition cycles plus calc time plus D/A conversion time. Assuming calcs are FAST and D/A is fast, the lag would not be bad. at 10,000 RPM the lag would be 60/10000*8 = .048s + "overhead"

Now for the next ignition cycle, we drop the oldest count and replace it with the most recent, and do it again.

Finally, I know that the microprocessor can not cycle as fast as it can count, but it should be able to produce outputs at least every spark event. (.004s-.006s) Even changes in output state every 2 or 3 spark events would be fine.

Other Items:
- Must be compact
- Must be good for 0-65 Deg C
- Must be reliable.

PLease dont think of this as "cheating". This is the way the the big boys go faster every year despite new rules. It is part of the engineering side of racing. Any one interested in pointing me in the right direction, please help. Thanks in advance for your expertise!

- Brant Thomas

List of 5 messages in thread
TopicAuthorDate
Newbie Project: Please suggest platform            01/01/70 00:00      
RE: Newbie Project: Please suggest platform            01/01/70 00:00      
RE: Newbie Project: Please suggest platform            01/01/70 00:00      
RE: Newbie Project: Please suggest platform            01/01/70 00:00      
RE: Newbie Project: Please suggest platform            01/01/70 00:00      

Back to Subject List