Motorcycle ignition advance, simple project?

The fuel injectors don't fire anywhere near spark time, a single Teensy 3.2 should be more than enough to handle that engine. That's a 32-bit ARM with 64K RAM, it should be overkill.

Do you have a regular Arduino now?
If you read the magnet sensor (please use a Hall switch, not a reed switch!) and generate a strobe with a led that only fires at spark time, is there somewhere on the engine you can see if it synchs steady? That would give you a measure of how well that chip can keep up... or not.

Haha, a reed switch at 12k rpm would be funny! Hall of course it is.

I am looking at making a wiring tap on the current ignition module and sending data to my regular Uno. Tap the signal coming from the sensors on the crank, and tap the signals sent to the coils. I cannot see if having any form of load adjustment, but I think it might have some basic curve in it. I would like the Arduino to tell me the rpm and the degrees of crank rotation difference between crank pulse and coil pulse. This way I can see if it has a curve, and if so what it is. And since (again) I think there is no load adjustment, I can do this revving the engine without riding the bike. Which in itself will be quite a challange, as the bike is in 34856724934762847539 pieces on the floor. But it will be a bike again within the next few decades weeks.

Hugo

When current flows it makes a field, a linear Hall sensor might pick up even weak pulses.

I like the idea of using the controller to read the operation of the bike before using it to control the operation. How well you do at the one job may tell if the other is possible.

Remember that all of these events take enough time that you can probably get that data too and not just a set of start points.

Be aware that printing to serialwill impact your sketch speed if you overfill the serial output buffer.
Best to do is use the highest baudrate you can (running 1.6.9 my serial is 250000 baud), keep the messages short and don't print lines per milli.

You might also look into using one of the analog
sensors used to pick up wheel motion on car's ABS
systems.
These are ruggedized to handle both vibration and
temperature.
You need to have something like a zero cross circuit
to read into the uP.
Dwight

The engine aleady has some sort of sensory system instead of point, so I hop to use those. That would be the easiest.

And with a bit of help I found the basic curve on the motor (without vacuum advance):
20 degrees below 1650 rpm
40 degrees above 3500 rpm
So I won't make a table for the rpm vs advance numbers, making five if-then-else rules will already make it possible to make the curve more detailed then it is now!

Cheers,

Hugo

Well, starting the count / setting the trigger signal at 180 degrees from TDC proves not to be very useful, I better start counting. With a dwell time of 4000us (micro symbol?!?) I get a negative amount of us about 6.700 rpm! Setting the trigger / starting the count at TDC leaves a bit more time. I'll see if I can post the excel I made about it.

Hugo

Spanner in the works; on a forum about the bike I am building I am advised to say away from tuning these engines. They are air cooled and prone to cracking the heads even without tuning. Adding advance ignition will increase combustion efficiency, and therefor temperature. Without controlled cooling (liquid cooling with a thermostat) it is best to stay away from tuning...

Bummer...

Hugo

Time to find an old engine to improve. Perhaps a lawnmower or chainsaw engine.
If it breaks, not a big loss and you won't be riding it.

Well, I am looking into adding oil cooling to the engine, see whether that makes a significant change to running temperatures. If I can manage the temperature, I feel comfortable adding performance.

Cheers,

Hugo

You might include temperature of the heads as one of the
parameters of timing.
Dwight

True, but it kinda voids the idea. I wanted to add 'vacuum advance' to make it run more efficient. When the engine is cold it is not running efficient because it is cold, and when it gets warm I get to cancel the added advance to avoid it running hot, cancelling the effect of making it more efficient. Hmmmm, I'd like some experience numbers on this engine when it gets to tune-ability. Back to the GSResource forum...

Cheers,

Hugo

See about water-methane injection to cool the air charge going into the cylinder, it worked on supercharged fighter engines in WWII.

Or add nitrous. No, I'd like to stick to pump gas. I have some plans but until I feel comfortable the engine is up to it, the electronics bit is in the waiting room.

Hugo

Nitrous is a whole nother thing. MW only mediates heat.
I remember seeing water-injection for my old Type-3 VW. It ran best in rain as it was.

HugoW:
Spanner in the works; on a forum about the bike I am building I am advised to say away from tuning these engines. They are air cooled and prone to cracking the heads even without tuning. Adding advance ignition will increase combustion efficiency, and therefor temperature. Without controlled cooling (liquid cooling with a thermostat) it is best to stay away from tuning...

Bummer...

Hugo

Tuning means a lot of things to a lot of people. One of the biggest advantages of Electronic ignition and fuel injection vs Clockwork timing and "leaky bucket" fuel mixing is the drivability. Peak power might not be higher but you don't get as many flat spots or dips in the delivery.

There are a lot of dedicated RPM chips that use inductive pickups that you could use to take the load off the Arduino.

Whilst the AVRs obviously have a disadvantage when it comes to pure clock speed, MCUs like the 2560 do have a bit going for them compared to a lot of the newer ARM chips. They're 5v (Automotive sensors are traditionally almost all 5v), have a heap of built in EEPROM and a stack of timers available.

If you are going down this path, it's the timers that make the whole thing possible on an AVR. There is definitely enough accuracy and speed to do it on these chips, but if you try to force it all in the main program loop then you're going to have a bad time.

With you're triggering, if you want proper advance control, you're going to need more resolution than 1 pulse per RPM. The bare minimum I'd recommend for ignition control is 4 per RPM, but more is better. Wheels like the 36-1 are common as they give you both the crank position and the RPM with good resolution.

One thing you might want to plot out before doing much more.
Plot out the time delay for the different advances.
You might be surprised at how flat the time delay was.
Dwight

Well, I've done some math (actually Excel did...). I do'n't quite know how to put it in words decenlty, but I hope you'll understand. Working with only a TDC sensor will not work at all:

Maximum accelleration:
12000 revs per minute per second =>
200 revs per second per second =>
0,000200 revs per second per µs

At 1k rpm one rotation takes 60.000 µs, so with 0,00002 revs per µs, maximum of 12 revs is added in the estimated revolution following the one at 12k rpm.
At 12k rpm one rotation takes 5000 µs, so with 0,00002 revs per µs, maximum of 1 rev is added in the estimated revolution following the one at 12k rpm.

So a decent 64-1 wheel is certainly required, maybe 32-1, and the thing will need to do the math VERY quickly.

Hugo

HugoW:
12000 revs per minute per second

That is an acceleration term with mixed time units

200 revs per second per second =>
0,000200 revs per second per µs

Is the max acceleration at 12K rpm 200 revs/sec/sec?

At 1k rpm one rotation takes 60.000 µs, so with 0,00002 revs per µs, maximum of 12 revs is added in the estimated revolution following the one at 12k rpm.
At 12k rpm one rotation takes 5000 µs, so with 0,00002 revs per µs, maximum of 1 rev is added in the estimated revolution following the one at 12k rpm.

Except that acceleration compounds the speed. The increase will be moar.

What's the difference between spark advance at 12000 rpm and 12001 rpm and why does that need special handling?

Fast calculations? You don't need to calculate at run-time what you can pre-calculate and table in flash and look up in a few cycles at run-time.

I've fiddled all night with Excel and the lot becomes more and more complex. And I seem to forget that the object of the excersize is to control the ignition timing, not necessarely make a very complex Arduino project. So, time to change the direction of thought.

Basic timing would be very simple:
If the starter button is activated, ignition should be at TDC.
Running rpm below 1650 rpm there is 20 degree static advance.
Running rpm between 1650 to 3500 rpm, static advance should increase from 20 to 40 degrees, linear with the rpm increase.
Above 3500 it should stay at 40 degree.
In addition, I want to advance extra due to part load, manifold pressure measured with a 555 sensor. Say 0V gives 0 advance, 5V gives 20 degrees advance.
So measuring rpm and pressure sensor value gives me an advance number.
Dwell time is 4ms.
All in all, not a lot of variables.

So what makes it difficult? Well, the accelleration does. And the high number of pulses to get an accurate rpm variance reading. Measuring only at TDC to estimate what to do in the next revolution is not enough. Measuring 32 times per revolution at 12k RPM gives a very small time between pulses to calculate anything.

But there are cars from way before the age of digital electronics with decent advance curves, arranged mechanically. But those curves are difficult to change / tune.

So, if I put a disc on the engine's crank with only one tooth and a sensor at TDC, I can register RPM. If I fit a second sensor on a (RC car) servo, which triggers the spark, I have a system which I can change.

What's the problem? Well, very little, as far as I can tell now. The only thing would be dwell time, as I should actually start charging the coil 4ms before sparking. This could be recalculated into the equasion, as 4ms at 1000rpm is 24 degrees, at 12k 4ms is 288 degrees. And that is linear through the rev range.

Mechanically I can fit the sensors, wheel and servo fairly easely. The system could be fairly simple and wouldn't require a lot of programming, I think.

Feel free to shoot at the idea.

Cheers,

Hugo