[72Rallye]

There are plenty of different electronic ignition systems in existence and I have no pretension of building anything better than what is already available. This was merely a personal challenge to see if the Arduino Nano can be used to build an ultra-low budget fully-programmable ignition system (I paid $2.63 for the nano including shipping).

The general architecture: the nano replaces both the mechanical centrifugal advance and the vacuum advance circuits. It uses the distributor points or an electronic points replacement, e.g.Pertronix, as a trigger. Since the points no longer switch the coil current, their lifetime and service interval are vastly improved. Using a distributor trigger eliminates the need for a Motronic-style timing wheel. However, this causes some implications for the switch-on delay of the coil current, which will be discussed later.

The points are set to trigger at a 45deg advance angle. The nano then adds a delay to fire the coil at the desired timing. There is an inherent 140us processing delay, which limits the maximum spark advance range to 0 - 40deg. The actual switching of the coil is done by the Bosch module 0 227 100 124 (e.g. Volvo 640).

If the nano doesn't receive a trigger, it switches off the coil after half a second to prevent overheating.

The manifold absolute pressure is measured with a MAP-sensor from a '98 Camry, which is then converted to a vacuum advance delay by the nano.

The nano is being programmed in C, which shouldn't cause any problems to anyone who has ever worked with programming languages. The engine speed is being calculated from the trigger to trigger period, and the centrifugal advance is taken from a look-up table, that contains values for 0-6500rpm in steps of 100rpm.

Adding a rev-limiter to the program is trivial. I am using a hard limit that cuts the ignition entirely, but if desired, it would be easy to program a soft limit that merely retards the timing.

Implementing multi-spark operation is possible, too, but with a slow TCI system there would probably only be a benefit at idle speeds. CDI is better suited for multi-spark.

Points and Pertronix systems have a constant dwell angle that causes very long coil current durations at low rpms. Therefore, these systems use an external resistor and slow-risetime coils, to avoid overheating. An electronic ignition leaves the current on only for as long as it is needed (~3ms) and can use lower resistance coils with a stronger spark.

With the distributor trigger, the nano has to predict when the next trigger will come and switch on the coil current 3ms before the expected firing time. However, when the engine is being revved-up, there is an element of surprise and the next trigger will arrive earlier than expected. The coil current needs to be switched on a bit earlier with a safety margin or the coil will not have stored enough energy by the time a surprise trigger arrives. The worst case is revving up the engine in neutral. My engine takes about 1 second to rev from idle to 6000rpm. The required safety margin for this is insignificant at the highest rpms, but requires coil current durations of up to 10ms at the lowest rpms.

Only after I had the system running did I find out, that I could have made the programming task easier by using a "smart" Bosch module. For instance, the 0 227 100 139 (Saab 900) controls the dwell angle internally and requires only a simple trigger, instead of controlling on and off times by the nano. Of course, once the program is done, it's a non-issue and then the 0 227 100 124 allows more control over what the coil is doing.
The nano was put in a box and shielded cables were used, but I didn't use any filtering or opto-isolators to protect it further. So far, so good. The box has an external toggle switch that disables centrifugal and vacuum advance and fires the coil at a fixed 45deg delay. This mode is exclusively used to set the distributor to the timing mark on the flywheel with a timing light. I find it convenient to be able to set timing at higher rpms for a brighter strobe light. Also, with mechanical advance, particularly for a recurved dizzy, I am never quite sure if the advance is truly off, which would make the setting less reliable.

As an added feature, I included a potentiometer that advances or retards timing by up to 20 degrees. It is therefore possible to change static timing on the fly from within the car. This should make it easier to find the optimum timing when building the lookup table.

I had an old distributor in poor condition, that I didn't mind sacrificing for the project. The weights and springs were removed and the cam part was welded to the shaft. The two plates that normally house the vacuum advance were also welded together. There is a caveat: because timing changes are no longer done by rotating the cam or points, but by an electronic delay, the position of the distributor rotor relative to the 4 posts in the dizzy cap changes for different delay timings. Before welding the plates together, it is therefore extremely important to put them at an angle where the rotor will face the post in the cap for the entire 0 to 40deg timing range.

I'll talk about some issues encountered when operating the system in a car in following posts.

Thomas

 

[okieopel]

very interesting.
By the way, Thank you for including the Bosch part numbers. It will make it easier to follow.

 

[rrossjr]

Wow,
Really cool. The technology is a bit over my head, but it sounds like you have
something new (novel) here and you already have proof of concept. You may want to think about
intellectual property protection if you feel there are potential commercial applications here.
Cheers,
Ron in Indy

 

[Autoholic]

Interesting project. By the way, Pertronix Ignitor II and III have adaptive dwell.

Did you consider a Hall effect trigger? That would work better than a points based trigger.

 

[72Rallye]

Thank you all for the encouraging remarks.
I don't care about IP, firstly because I don't think it is all that special. If you google "Arduino electronic ignition" there are quite a few reports, although they usually don't give much detail. Secondly, I have no interest in building systems for others. That being said, I'd gladly share what I learned, including the C-code with anyone wanting to try something similar and who doesn't have any commercial interests.
Yes, a Hall effect trigger may be better. That's what the Pertronix is, right? I had a Pertronix before I started this project, but I didn't want to tear the distributor apart in case I needed to revert back.
I bought a cheap knock-off on ebay for $26 and may install it in the future. Just type in "electronic ignition VW 009".
Since the points no longer switch the coil current, they are not that bad. There were some reports, though, that without a high current to burn off contamination they may get unreliable over time.
There is one unexpected issue with the points that I ran into, which will be the subject of a later post.

Thomas

 

[72Rallye]

False triggers

The system ran fine on the workbench using a pulse generator. However, once installed in the car it received numerous false triggers that resulted in a rough running engine. These triggers could have been addressed by additional shielding and signal filtering, but it turned out to be easier to deal with them in software.
There were two sources of false triggers. The first one was due to electrical noise when the spark plugs fired. This could simply be avoided by defining a blackout period of 500us after firing of the coil during which all triggers were ignored.
The second type of false triggers happened on the high to low transition of the points. Even though the program only responds to a rising edge trigger, there was apparently enough switch bounce to create a brief spike with a rising edge. After receiving a trigger, the program would wait 50us and then check whether the voltage level was high or low. If the level was low, the trigger was invalid and the program would ignore it.
This check was only done if the trigger arrived outside the expected trigger time window. For normal triggers the check would take too much time and reduce the maximum possible trigger advance.
One could have ignored all triggers that arrive at unexpected times, but the problem in that case is, that if the system starts out on a false trigger, it will never recover, because all valid triggers would be ignored.
With these changes the engine ran smoothly.

 

[Gary]

Great write up!
That Bosch 0 227 100 124 module is the same one that is in my '84 Senator. I've had problems with it overheating and failing and am in the process of adding a heat sink to the stock setup.
It is also used on Porsches.

 

[Manta Rallier]

Purty interesting! I've been thinking exactly about such a thing. It sounds like a simple signal conditioning circuit could be used to get rid of a lot of the false triggers. (I had an earlier career as an electronics design engineer.)

Does the code need a compiler? What is the process to compile the code and put it into the unit? Any links to sites or resources that discuss all that?

BTW, just using the MAP signal may not give the best vacuum related signal to work with. Are you connecting that to the actual intake manifold, or to a ported vacuum source? Are you using the MAP signal in a table set along with RPM?

Thanks for sharing!

 

[First opel 1981]

I wouldn't put it on a nano. I'd want to use something with a more powerful processor. Something with an ATmega2560 chip.

The hard part won't be getting the inputs together. The hard part will be writing the code.

 

[Manta Rallier]

With the distributor trigger, the nano has to predict when the next trigger will come and switch on the coil current 3ms before the expected firing time. However, when the engine is being revved-up, there is an element of surprise and the next trigger will arrive earlier than expected. The coil current needs to be switched on a bit earlier with a safety margin or the coil will not have stored enough energy by the time a surprise trigger arrives. The worst case is revving up the engine in neutral. My engine takes about 1 second to rev from idle to 6000rpm. The required safety margin for this is insignificant at the highest rpms, but requires coil current durations of up to 10ms at the lowest rpms.

This is interesting...... For the same spark energy/voltage, the coil charging time should be constant with RPM. So something else is going on IMHO. This low RPM situation may be due to a lower voltage in the system at lower RPM's as the alternator output drops. I also suspect it has a lot to do with the lower advance amount at the lower RPM's and the level of voltage needed to fire the spark later; the compression of the mixture will be higher then. FWIW, this implies that you might not have optimum spark at the higher RPM's if you are not charging the coil as much time. Low spark voltage/energy slows the initial burn and thus the overall combustion process; it might be compensated for somewhat with extra advance but may not produce the same torque/HP. Is there any other reason to limit this charging time to 3 ms? Tnx

 

[First opel 1981]

Another limitation of the arduino is that it operates in miiseconds.
At 6000 rpm the engine is spinning 100 times per second. That only allows 10 units per engine revolution.
If being used for fuel injection that translates to incremental adjustments on the injectors at 10% steps.

 

[72Rallye]

Great write up!
That Bosch 0 227 100 124 module is the same one that is in my '84 Senator. I've had problems with it overheating and failing and am in the process of adding a heat sink to the stock setup.
It is also used on Porsches.

Hi Gary,
That's interesting! My '82 Monza 3.0E has a 1 227 022 008, but it also runs well with a 0 227 100 139. Both are "smart" (dwell-adjusting) modules. So, in later years they reverted back to a "dumb" module?
My '86 928 has two 124s, mounted on a large aluminum plate. That's how I first became acquainted with that module.
Thomas

 

[72Rallye]

Purty interesting! I've been thinking exactly about such a thing. It sounds like a simple signal conditioning circuit could be used to get rid of a lot of the false triggers. (I had an earlier career as an electronics design engineer.)

Does the code need a compiler? What is the process to compile the code and put it into the unit? Any links to sites or resources that discuss all that?

BTW, just using the MAP signal may not give the best vacuum related signal to work with. Are you connecting that to the actual intake manifold, or to a ported vacuum source? Are you using the MAP signal in a table set along with RPM?

Thanks for sharing!

Before using the Arduino one needs to download a free IDE or web editor as they call it from arduino.cc. It has an editor and a compiler built in. There is also also an online syntax reference manual for their flavor of C, for people like myself who don't speak C fluently.
To upload the program, one connects the nano to the laptop via a USB cable, sets a few parameters like the port number (e.g. COM4) and clicks "upload". That's all.
At this point I'd like to credit Nick Webb for having introduced me to the Arduino world, and for a hint to use interrupts.
Thomas

 

[72Rallye]

Another limitation of the arduino is that it operates in miiseconds.
At 6000 rpm the engine is spinning 100 times per second. That only allows 10 units per engine revolution.
If being used for fuel injection that translates to incremental adjustments on the injectors at 10% steps.

The Arduino Nano ATmega328 may be approaching its limitations, but it is clearly up to the job. Clock speed is 16MHz and instructions take a few microseconds. The limiting factor in precision is jitter in the output stage. I see full-range jitter of 120us, which at 6000rpm causes a timing error of +/- 2 degrees of crankshaft angle. The error at lower rpms is proportionally smaller. 2 degrees is good enough for me.
And while the processor is waiting for the next trigger it has plenty of time to do some other calculations as you will see.
Thomas

 

[72Rallye]

This is interesting...... For the same spark energy/voltage, the coil charging time should be constant with RPM. So something else is going on IMHO. This low RPM situation may be due to a lower voltage in the system at lower RPM's as the alternator output drops. I also suspect it has a lot to do with the lower advance amount at the lower RPM's and the level of voltage needed to fire the spark later; the compression of the mixture will be higher then. FWIW, this implies that you might not have optimum spark at the higher RPM's if you are not charging the coil as much time. Low spark voltage/energy slows the initial burn and thus the overall combustion process; it might be compensated for somewhat with extra advance but may not produce the same torque/HP. Is there any other reason to limit this charging time to 3 ms? Tnx

It has nothing to do with the spark being weaker at low rpms. It is all about timing.
At 6000rpm the trigger pulses arrive with a 5ms spacing. That leaves about 3ms for the coil to charge. You need to give the coil some time to recover. If 3ms is good enough at 6000rpm, then it is good enough at all rpms. At least, if the engine were running at a constant speed and constant advance setting.
For 1000rpm the pulse spacing is 30ms. Now imagine we are revving up the engine and the next trigger arrives at 1100rpm or 27ms. The trigger arrives 3ms earlier than expected. Had we switched on the coil just 3ms before the expected 1000rpm trigger, then there wouldn't be any stored energy in the coil for a sudden 1100rpm trigger. That's why I have to switch on the coil a few ms earlier to be on the safe side.
The same discussion goes for sudden vacuum advance changes that also shift the timing of the next trigger.
At higher rpms the surprise factor becomes less of an issue, because the coil current is on with a much larger duty cycle and because the rpms cannot change as quickly (stored rotational energy in the crank and flywheel goes with the square of the rpms).

With a timing wheel there would be less of a surprise, because the processor gets constant information about the speed of the engine, and not just twice per revolution. This also puts a higher workload on the processor and adds complexity and cost.

I forgot to mention in an earlier post that the vacuum is measured at the manifold and not ported vacuum, because that's the only way it makes sense to me from a physics standpoint.

Thomas

 

[72Rallye]

Cylinder timing errors

I ran into one unexpected issue with the distributor trigger.
The upper graph in the attached picture shows the engine speed as a function of time. Well, actually it only shows the apparent engine speed calculated from the trigger spacing of the distributor points. The rpms slowly increase, because the car is accelerating.
There is a distinctive pattern on the data that repeats every 4 pulses. What is happening here is that the triggers for the 4 cylinders do not all happen at the same crankshaft angle. Some arrive earlier, some later.
I could see that the point’s gap is different for each cylinder and varies between 0.3mm and 0.4mm. I don't know what is normal; hardly anyone ever looks at this. Maybe my distributor was too worn and the cam was croocked when I welded it onto the shaft. A Pertronix would be less sensitive to gap variations, but at least in theory it could have timing problems of its own. The 4 magnets in the rotor might not be spaced by exactly 90 degree angles, or the magnetic field strength of the magnets might not be exactly equal. Both effects would cause timing errors for each cylinder.
Does it matter? The variations measured in the run would amount to a timing error of +/-5 degrees. That is starting to become significant and means that not all cylinders get the optimum advance angle for maximum power. I'd be surprised if it amounts to more than 1-2hp, though.
It also means that different cylinders use different entries in the advance vs rpm lookup table.
Finally, the variations would cause some cylinders to trip the rev-limiter 200-300rpm earlier than others. This may not be a bad thing, since it creates kind of a soft rev-limiter. However, I'd rather define my own soft limiter than rely on defects in the distributor.
Overall, I expect that having the engine running at different rpms and advance settings simultaneously makes it more difficult to optimize the lookup table.

It would be very difficult to mechanically correct the trigger variations. They also seem to have weak resonances and get stronger at certain rpms. Fortunately, the pattern is stable over many cycles (1 cycle = 2 crank revolutions) and therefore the program can learn the pattern and correct for it by firing individual cylinders earlier or later. For this to work, it is not even necessary that the program knows which trigger refers to which cylinder or what the firing pattern (1342) is.
Initially, I wanted to average the pattern over many cycles to make it more stable. However, it turned out, that better results were achieved if the correction was based only on the immediately preceding cycle. This makes the program easier and leads to faster recovery should the program ever skip one cylinder trigger.
The lower graph shows the apparent engine speed derived from the signal on the coil. As can be seen the correction by the program removed the 4-pulse pattern and only uncorrectable jitter remains. The engine is thus firing in a much more consistent way.
Without pattern correction by the program, the variation from the distributor would have been copied 1:1 to the coil.

Thomas

 

[Manta Rallier]

It has nothing to do with the spark being weaker at low rpms. It is all about timing.
At 6000rpm the trigger pulses arrive with a 5ms spacing. That leaves about 3ms for the coil to charge. You need to give the coil some time to recover. If 3ms is good enough at 6000rpm, then it is good enough at all rpms. At least, if the engine were running at a constant speed and constant advance setting.
For 1000rpm the pulse spacing is 30ms. Now imagine we are revving up the engine and the next trigger arrives at 1100rpm or 27ms. The trigger arrives 3ms earlier than expected. Had we switched on the coil just 3ms before the expected 1000rpm trigger, then there wouldn't be any stored energy in the coil for a sudden 1100rpm trigger. That's why I have to switch on the coil a few ms earlier to be on the safe side.
The same discussion goes for sudden vacuum advance changes that also shift the timing of the next trigger.
At higher rpms the surprise factor becomes less of an issue, because the coil current is on with a much larger duty cycle and because the rpms cannot change as quickly (stored rotational energy in the crank and flywheel goes with the square of the rpms).

With a timing wheel there would be less of a surprise, because the processor gets constant information about the speed of the engine, and not just twice per revolution. This also puts a higher workload on the processor and adds complexity and cost.

I forgot to mention in an earlier post that the vacuum is measured at the manifold and not ported vacuum, because that's the only way it makes sense to me from a physics standpoint.

Thomas

Ah I gotcha.... the possible proportional period change is a lot greater at the lower RPM's... makes good sense. Tnx. IMHO good observations on the process load versus trigger source rate.

FWIW, ported vacuum seems to me to be a better (simpler?) load sensing signal than straight manifold vacuum. Manifold vacuum can hit the same at value various combinations of throttle opening versus RPM, so is more ambiguous as to load at part throttle; ported vacuum seems to me to be less ambiguous for vacuum advance purposes. MAP sensors inputs in FI system are conditioned with other inputs to get around this ambiguity.

 

[Manta Rallier]

I ran into one unexpected issue with the distributor trigger.
The upper graph in the attached picture shows the engine speed as a function of time. Well, actually it only shows the apparent engine speed calculated from the trigger spacing of the distributor points. The rpms slowly increase, because the car is accelerating.
There is a distinctive pattern on the data that repeats every 4 pulses. What is happening here is that the triggers for the 4 cylinders do not all happen at the same crankshaft angle. Some arrive earlier, some later.
I could see that the point’s gap is different for each cylinder and varies between 0.3mm and 0.4mm. I don't know what is normal; hardly anyone ever looks at this. Maybe my distributor was too worn and the cam was croocked when I welded it onto the shaft. A Pertronix would be less sensitive to gap variations, but at least in theory it could have timing problems of its own. The 4 magnets in the rotor might not be spaced by exactly 90 degree angles, or the magnetic field strength of the magnets might not be exactly equal. Both effects would cause timing errors for each cylinder.
Does it matter? The variations measured in the run would amount to a timing error of +/-5 degrees. That is starting to become significant and means that not all cylinders get the optimum advance angle for maximum power. I'd be surprised if it amounts to more than 1-2hp, though.
It also means that different cylinders use different entries in the advance vs rpm lookup table.
Finally, the variations would cause some cylinders to trip the rev-limiter 200-300rpm earlier than others. This may not be a bad thing, since it creates kind of a soft rev-limiter. However, I'd rather define my own soft limiter than rely on defects in the distributor.
Overall, I expect that having the engine running at different rpms and advance settings simultaneously makes it more difficult to optimize the lookup table.

It would be very difficult to mechanically correct the trigger variations. They also seem to have weak resonances and get stronger at certain rpms. Fortunately, the pattern is stable over many cycles (1 cycle = 2 crank revolutions) and therefore the program can learn the pattern and correct for it by firing individual cylinders earlier or later. For this to work, it is not even necessary that the program knows which trigger refers to which cylinder or what the firing pattern (1342) is.
Initially, I wanted to average the pattern over many cycles to make it more stable. However, it turned out, that better results were achieved if the correction was based only on the immediately preceding cycle. This makes the program easier and leads to faster recovery should the program ever skip one cylinder trigger.
The lower graph shows the apparent engine speed derived from the signal on the coil. As can be seen the correction by the program removed the 4-pulse pattern and only uncorrectable jitter remains. The engine is thus firing in a much more consistent way.
Without pattern correction by the program, the variation from the distributor would have been copied 1:1 to the coil.

Thomas

Again, good observations! I am appreciative of the detail put into the measurements. 0.3 mm (around .012") is significantly smaller than a normal points setting. .017-.019" would be normal. And that is for a points system directly driving a coil and the gap has to be kept to a smaller level to preserve dwell. So you could open the gap if that helped.

As for wear, certainly the nubs can be worn on the point's cam, or, just as likely, the bushings can be worn or shaft bent. Until that is all investigated, you can't really know the cause.

I don't quite understand why you did not do an average.....

 

[72Rallye]

Poor man's dyno

Ok, now the engine runs reasonably well with an ignition map based on a 2.0E. However, the whole point of the project was to optimize the ignition for a modified engine, and not just use factory settings. The best way to tune the ignition map is on a dyno, but that is expensive. This was supposed to be a low-budget project.
Fortunately, there is another way. For this, we accelerate in a fixed gear from just above idle to redline and record the engine rpms as a function of time. The rate of rise of the engine speed at any given rpm will give us an indication of the strength of the engine at that speed. We can then try different static advance angles and see what works best.
Before we get to that let's do a side step. While recording rpms may be enough to optimize the ignition, it is fun to massage the data a bit further to get actual horsepower values.
It is essential to get quality data. The first thing needed is a straight section of road, about half a mile long, with no elevation changes and no wind, little traffic and no cops. That's a tall order in San Diego, but I have my secret testing location.
Furthermore, we need a way to accurately record the engine rpms versus time. Watching the tach with a stopwatch in hand won't do. This will probably be the most difficult task for the typical hobby mechanic. I am fortunate to have available a mobile oscilloscope connected to a laptop to record the voltage on the coil, and thus the rpms. When laptops still had a printer port, I used the printer port to record rpms. One could even configure an Arduino for data acquisition. So, there are low-cost solutions, but they require a bit of programming.
Back to the test run. Running in 4th gear is out of the question, since the speeds near redline would put me in jail. In 2nd gear everything happens to quickly and the measurements would be tainted by transient effects. After flooring the gas pedal, the carburetor needs some time to recover, and by the time stable operation is reached we are way beyond 3000rpm. Third gear is just right. Running from 1500rpm to 6000rpm in 3rd in my car takes about 20 seconds. The maximum speed reached is 90mph.
A typical run looks like the graph in the first attached picture. The rpms steadily rose until I aborted the run at 6300rpm. The oscilloscope also records the signal from an O2 sensor and the manifold pressure. The O2 sensor is fairly old and may not give accurate absolute values. I use it mostly to make sure that the float bowl doesn't run low during the test, which would result in an extreme lean condition. The manifold pressure drops to 96% of atmospheric pressure at the highest rpms. I guess that's ok.
The first step is to convert rpms to real vehicle speed.
Vehicle speed v = rpm / 60 * tire circumference / RAR / 3rdGear
tire circumference = 1.744m measured for my 205/60R13s
rear axle ratio RAR = 3.44
3rd gear = 1.336
The formula gives the speed in meters per second. If you want mph multiply by 2.24.
The acceleration a is given by the derivative or slope of the speed vs time curve. To calculate, we divide the increase in speed over two successive data points by the elapsed time.
a = (v1-v0)/(t1-t0) The speed needs to be in units of meters per second
There is a problem here. If there is any noise on the rpm data, and there always is, the derivative will be all over the place and even go negative. This won't work. Therefore, I am fitting the rpm data with a 5th order polynomial and use the fit for all further calculations. Excel does a great job in fitting curves (trendline).
Once we have the acceleration a versus rpm, we get the rear wheel horsepower values for each rpm as
hp = a * mass * v * 0.00137
mass is the weight of the car including driver in kilograms
The factor 0.00137 is used to convert Watts to horsepower.

The resulting horsepower versus rpm graph will look very disappointing. This is because the acceleration method only calculates the fraction of engine power used to accelerate the car. Another large fraction of engine power is used to overcome aerodynamic drag. The true rear wheel horsepower is the sum of both of those parts.
Aero drag scales with the third order of vehicle speed, but we need a scale factor. The Manta A was sold in the European market with a number of engines ranging from 60hp to 105hp. The published top speeds for those engines can be used to fit a third order curve. The resulting formula for required horsepower to overcome aero drag is:
hp = 6.7E-5 * v^3 The vehicle speed is in mph
For instance, a speed of 90mph requires 49 rwhp. The required power for a GT would be about 15% lower than for a Manta.
When we add the aero drag correction to the acceleration horsepower values the results look a lot friendlier. Both curves are shown in the graph in the second attached picture. The calculated peak horsepower and rpm position are surprisingly close to a real dyno test. I had my car dynoed at 113rwhp @ 5200rpm and the poor-man's dyno shows 112rwhp @ 5250rpm! Some of it is luck and I would have been happy even if they only agreed within 10%. Btw, the engine is a 2.2 liter with a 38DGES and an Isky combination cam.
To get an estimate of horsepower at the crank we divide the values by 0.85 for a 15% loss in the drive train.
Finally, the engine torque in ft-lbs is obtained via the formula:
torque [ft-lbs] = hp * 5252rpm / engine speed [rpm].
Both the crank horsepower and torque are also plotted in the graph.
Now we have all the tools together to actually optimize the ignition map.

Thomas

 

[Manta Rallier]

Great stuff, including the computations of wind drag and so on. Very well done! I'm impressed.

BTW 96% atmospheric is about 1.2" drop through the carb or TB/air-cleaner (at standard pressure). For American carbs, flow rating is measured at 1.5" drop for 4 BBL carbs, and for 1 BBL (and for 2 BBL's also, IIRC), flow is measured at 3" drop. Not sure what carb or TB you have to be able to relate that 1.2" drop to how close you are getting to max rated flow, but that is 1 reference for you.