Model engine CDI easy and cheap

[74Sprint]

Awake your right we are getting far too advanced for what is needed here so I'll restrict that stuff to PM's. The Arduino UNO is perfect for what is needed here I think. It has enough speed and resources for Eccentric to complete his task.

I come from a RADAR tech back ground working on the secrete stuff down to the component level. Because all my computer skills were limited to mostly the binary level I had to learn how to program in binary. No languages just streams of 1's & 0's. It would take an hour of programming with 16 switches (no keyboards) just to have the computer say "Hello World" on a green screen. Working on my own I started using Commodore computers and CBM basic. I advanced my skills in time to what was my favorite 'Microchip' and using C & C++.

Lloyd-ss and Vietti, when I started to use Arduino I had a hard time not because it was hard but, because it was too easy to use. I kept saying to myself it can't be this easy I must be missing something. But if anyone asked me what is the easiest way to get into micro-controller or micro-processor programming then it is definitely Arduino. As Awake pointed out the starter kit is the best way to go and the people on the Arduino forum are very helpful and patient, well at least most of them. They won't write your code but, will give lots of examples. Nice thing about Arduino is that it can take the "C" language along with it's complexities when your ready such as programming internal resources. The Arduino IDE comes with a serial monitor so you can do serial writes to the screen and see what your code is doing for debugging. The Arduino IDE also when setup will write the code for you to get started, "fluff". The biggest thing I find with people starting out and writing functions is to put those functions in the right order. I even have to draw things out sometimes to make heads or tails of it.

Enjoy
Ray

 

[Lloyd-ss]

Lloyd-ss and Vietti, when I started to use Arduino I had a hard time not because it was hard but, because it was too easy to use. I kept saying to myself it can't be this easy I must be missing something. But if anyone asked me what is the easiest way to get into micro-controller or micro-processor programming then it is definitely Arduino.

Ok gents, it got complicated right away, LOL.
There are so many choices of the Arduino platform, with the Nano, Uno, UnoR3, Mega, etc. And the price differential isn't that much, when you consider the total cost of a project. When I used the stamp years ago, I started with a low end one, thinking it would be adequate. But as the project grew, I ran out of I/O, and would have loved to had some built in A-D convertors, etc, etc. I ended up switching to the version with the max I/O, and that took care of most of the issues.
So, which one do I choose? I don't anticipate needing any wifi, but who knows? and the idea of being able to integrate lots of sensors sounds like a ton of fun. The IDE sounds very good and I think I'd like to go that route for programming. I don't mind the Arduino having more capability than I need, but I want to stay in the hobbyist realm because I am not going to be doing anything super sophisticated. And I don't want any model that will soon be superseded. Once I get over this hump, I can be on my way.
Which model(s) do you think? Thanks! Lloyd

 

[willray]

Ok gents, it got complicated right away, LOL.
There are so many choices of the Arduino platform...
So, which one do I choose? I don't anticipate needing any wifi, but who knows? and the idea of being able to integrate lots of sensors sounds like a ton of fun.

Buy absolutely anything - a crap Nano for $6 will get you started:

Aliexpress Nano

Make its LED blink, experiment with the language, figure out how to make its I/O read input and talk to the world, then worry about which one is right for whatever project you want to work on. At the prices of Arduinos, you'll spend more on coffee while trying to figure out the "right one", than you will on just buying a board and doing it.

For your purpose, the only real differences between Arduino(compatible) platforms, are the processor speed, available memory, and available I/O pins and functionality.

Practically anything else the might be included on some Arduino variant, can be added to any other variant by wiring up a secondary board with the peripheral (pretty much all of the "added features" that are available on-board some Arduino variants, are integrated identically to if they were an external board wired in to, for example, the SPI bus).

The IDE sounds very good and I think I'd like to go that route for programming.

Frankly, the IDE is awful. It's somewhat less featureful than IDEs for "real" programming languages from the early 1980s. Think of it as a primitive text-editor with a button to compile the contents. It does, in general, get the job done, and it's better than the alternative.

I don't mind the Arduino having more capability than I need, but I want to stay in the hobbyist realm because I am not going to be doing anything super sophisticated. And I don't want any model that will soon be superseded.

Unless you work at it, it's unlikely you'll escape the hobbyist realm with the Arduino. There are "aimed at industrial deployment" Arduino platforms out there, but, you have to work rather hard to find them.

And I'm not aware of any Arduino platform that has been deprecated at this point.

Superseded - happens every day. As an open platform, people are creating new versions with some new gee-gaw onboard weekly. Many of them are gone again next week, but if you stick to anything that is an Arduino <X>, rather than "Bob's Arduino-compatible Chicken-Waterer", you'll still be able to buy a replacement next year, probably next decade. And even if you do buy Bob's Arduino-compatible Chicken Waterer, even if Bob gives up on supporting the chicken-watering function, it's /still/ an Arduino-compatible board, and will continue to be an Arduino just like every other Arduino, so unless you buy into some specialty chicken-watering functionality, you're at no risk of being trapped down an implementation dead-end.

 

[74Sprint]

Ok gents, it got complicated right away, LOL.
There are so many choices of the Arduino platform, with the Nano, Uno, UnoR3, Mega, etc. And the price differential isn't that much, when you consider the total cost of a project. When I used the stamp years ago, I started with a low end one, thinking it would be adequate. But as the project grew, I ran out of I/O, and would have loved to had some built in A-D convertors, etc, etc. I ended up switching to the version with the max I/O, and that took care of most of the issues.
So, which one do I choose? I don't anticipate needing any wifi, but who knows? and the idea of being able to integrate lots of sensors sounds like a ton of fun. The IDE sounds very good and I think I'd like to go that route for programming. I don't mind the Arduino having more capability than I need, but I want to stay in the hobbyist realm because I am not going to be doing anything super sophisticated. And I don't want any model that will soon be superseded. Once I get over this hump, I can be on my way.
Which model(s) do you think? Thanks! Lloyd

IMHO, For the first part, Parallax is still being made but, I have never gotten into them and don't know much about them. On the hobbyist side of things I would still go with Arduino because it was meant for the beginner/hobbyist in mind and it's about as close to the stamp as you can get, I think. It is very popular for that reason besides, it's a lot cheaper than Parallax. Next you have to be honest with yourself and get something with just a little bit more than you need for resources.

As for which Arduino I would go with the UNO-R3 because it is more breadboard friendly. The Nano has just about the same number of I/O's and functionality. They both have A/D converters, programmable I/O's, 2/3 interrupts, and PWM also they are 5V tolerant and they have built-in voltage regulators. The Arduino world has exploded and is fast becoming an acceptable to industrial stuff. Parallax use to be the defacto uC around here but, schools have switched over to Arduino. Oh stay away from the Mega unless you need a ton of I/O's.

Yes the IDE is somewhat basic but, that's for taking care of the beginner/hobbyist. Like just about any tech stuff you need to crawl before you run and there is nothing that says you can't do more with the IDE. For example, I can use the Atmega programming sheets to do more advanced programming if I have too, the IDE can handle it. It's not as advanced as say TI's, Microchip, or STmicro's IDE's but, if you don't need those right now then the Arduino IDE is a good way to learn "C" & "C++" so you can move on. Would I use it for ASIC development 'no' but, I do use it for 'proof of concept' and port the code to say something like an ARM, TI, or Microchip processor. Also Atmega is owned by Microchip and Microchip's IDE can be used for both uC's if you need something more advanced.

Cheers
Ray

 

[awake]

Frankly, the IDE is awful. It's somewhat less featureful than IDEs for "real" programming languages from the early 1980s. Think of it as a primitive text-editor with a button to compile the contents. It does, in general, get the job done, and it's better than the alternative.

On the IDE, I agree that the editing, debugging, etc. are very basic at best (though the new IDE 2.0, now in "release candidate" stage, is supposed to have some better features - ? I haven't experimented iwth it). What really makes the IDE super-useful, especially for the beginner, is the ease of adding in libraries. I would also add that, when you start, you will likely use the provided library functions that make it super-easy, e.g.,

digitalWrite(13,HIGH); // set pin 13 high, turning on the on-board LED

If / as you gain more expertise, you may decide to speed things up by skipping these routines in favor of directly writing to the data port:

PORTB = PORTB | B00100000; // set pin 13 high, turning on the on-board LED

And if you want to go even further, you can include inline assembly code (note that I haven't done this in a while, so no guarantees that I have the correct syntax!):

asm ( "sbi PORTB, 5 \n" ); // set pin 13 high, turning on the on-board LED

All of this without leaving the basic Arduino IDE. Limited to hobbyists? Yes, probably ... but then, that's what I am, and yet as a hobbyist, I can make some pretty darn sophisticated embedded projects.

 

[awake]

Ok gents, it got complicated right away, LOL.
There are so many choices of the Arduino platform, with the Nano, Uno, UnoR3, Mega, etc. And the price differential isn't that much, when you consider the total cost of a project. When I used the stamp years ago, I started with a low end one, thinking it would be adequate. But as the project grew, I ran out of I/O, and would have loved to had some built in A-D convertors, etc, etc. I ended up switching to the version with the max I/O, and that took care of most of the issues.
So, which one do I choose? I don't anticipate needing any wifi, but who knows? and the idea of being able to integrate lots of sensors sounds like a ton of fun. The IDE sounds very good and I think I'd like to go that route for programming. I don't mind the Arduino having more capability than I need, but I want to stay in the hobbyist realm because I am not going to be doing anything super sophisticated. And I don't want any model that will soon be superseded. Once I get over this hump, I can be on my way.
Which model(s) do you think? Thanks! Lloyd

IMHO, For the first part, Parallax is still being made but, I have never gotten into them and don't know much about them. On the hobbyist side of things I would still go with Arduino because it was meant for the beginner/hobbyist in mind and it's about as close to the stamp as you can get, I think. It is very popular for that reason besides, it's a lot cheaper than Parallax. Next you have to be honest with yourself and get something with just a little bit more than you need for resources.

As for which Arduino I would go with the UNO-R3 because it is more breadboard friendly. The Nano has just about the same number of I/O's and functionality. They both have A/D converters, programmable I/O's, 2/3 interrupts, and PWM also they are 5V tolerant and they have built-in voltage regulators. The Arduino world has exploded and is fast becoming an acceptable to industrial stuff. Parallax use to be the defacto uC around here but, schools have switched over to Arduino. Oh stay away from the Mega unless you need a ton of I/O's.

Yes the IDE is somewhat basic but, that's for taking care of the beginner/hobbyist. Like just about any tech stuff you need to crawl before you run and there is nothing that says you can't do more with the IDE. For example, I can use the Atmega programming sheets to do more advanced programming if I have too, the IDE can handle it. It's not as advanced as say TI's, Microchip, or STmicro's IDE's but, if you don't need those right now then the Arduino IDE is a good way to learn "C" & "C++" so you can move on. Would I use it for ASIC development 'no' but, I do use it for 'proof of concept' and port the code to say something like an ARM, TI, or Microchip processor. Also Atmega is owned by Microchip and Microchip's IDE can be used for both uC's if you need something more advanced.

Cheers
Ray

To add a couple of things to Ray's excellent post ... I've attached the first page of an Atmel datasheet that covers the ATmega328 chips used on the Uno and Nano. As I recall, the Uno and Nano have 2K of RAM, 32K of program flash memory, and 1K of EEPROM for non-volatile storage. As usual, the various peripheral features shown on the datasheet are generally overlapping - in other words, you have up to 23 digital i/o pins, but 2 of those are used for the serial interface to the USB port, 2 are used for a clock crystal / oscillator (these two are not exposed on the Arduinos), 1 doubles as the RESET pin, 6 can be used either as digital i/o or as analog inputs, and so on. I've attached a pinout diagram that shows all of the pins made available on a Nano, with all of the different functions that each pin can perform. Note that the UNO has essentially all of the same pins EXCEPT for A6 and A7.

Ray mentioned 2/3 interrupts ... it is actually a bit more than that. There are quite a few internal interrupts generated from a variety of the peripherals; for example, you can generate an interrupt when a timer overflows or counts down to zero. Meanwhile, 2 of the digital i/o pins can be designated as external interrupt pins (INT0 and INT1). But there is also another very interesting capability: all 23 of the digital i/o pins can also be set to generate "pin change interrupts," allowing you to generate an interrupt when the pin goes high, low, or toggles. In a sense, then, you actually can have up to 23 external interrupts; however, unlike INT0 and INT1, which each send the program to its own unique interrupt vector, the pin-change interrupts send the program to a shared vector. Your ISR has to check to see which pin generated the interrupt.

What if you need more i/o pins or more RAM and program space? The next step up is the ATmega2560 (Arduino Mega 2560). This chip / board has more than double the i/o pins, with correspondingly more analog channels, timers, etc. It also has 256K of program space, 8K of ram, and 4K of EEPROM. Note that it is not any faster, and does not provide any different features than the 328-based Uno / Nano ... just more of the same capabilities.

All of the above are 8-bit boards, typically running at 16MHz. They will not set the world on fire as far as speed ... and yet they are surprisingly capable little controllers, and can do far more than many people think they can (especially when you move beyond the "easy mode," digitalWrite type of approach that i described in the previous post). But if you need more horsepower, you can step up to 32-bit based boards, both those from Arduino itself (or based on their design), or others such as the STM32 or ESP32 boards. These have Arduino board definitions and libraries available that let you program them just like the old 8-bit versions, though of course each board will have differing capabilities. Some will include Bluetooth and / or wifi. And most are made to accept or plug into add-on boards that provide various sensors, actuators, and so on.

Like Ray suggests, I would start with either a Uno or Nano (and being cheap, I'd probably get a clone - which I think is what is included in the starter kit that we discussed above). Again, surprisingly capable of a wide variety of tasks, up to and including 3-axis CNC. With some mastery of one of these, you will be well positioned to move up to something bigger / faster as needed.

 

[Lloyd-ss]

This has all been a tremendous help. Looking at the pin outs in the 2 attachments, I had no idea how much the capabilities have increased. I am looking forward to this.

 

[74Sprint]

Just to add a bit, there are actually 3 sort of hard external interrupts, pins (2, 3, and 8). ISR INT0, INT1, and ICP1. ICP1 Pin 8 is different, it is a (Timer/Counter1 Input Capture Input) but, it is similar to the other programmable I/O's because pin 8 can also be programed as PCINT0 (Pin Change Interrupt 0). If set as ICP1 you could use it to count inputs or as a timer to count clock ticks up or down. This is good if you want to say calculate RPM or do as Eccentric wants to do and say set the count to 6 and then have the code do any average of 6 RPM's. When pin 8 times out or captures an input it will trigger an interrupt, if it is programmed to do that.

For my programmable ignition I haven't decided yet if I'm going to use ICP1 or one of the other interrupts. We used a counter on the PIC12LF1840 between 2 trigger pulses to get the RPM but, I changed that to a timer measuring the pulse width, only used 1 trigger pulse. I did this so flipping a propeller was easier for starting. mind you there was a bit more calculations doing it my way, timer overflows mainly. I will be using 2 interrupts, 1 for the crank trigger and 1 for the cam trigger and I could use ICP1 for the RPM calculations. There are a bunch of options I could use.

I also want to use a temperature sensor to adjust timing, cold engines suck. I will also be using a 4 line 20 character LCD display to tell me what is going on, RPM, temperature, timing degrees, and errors. For the temp sensor I will be using the Dallas DS18B20 because it does a self check to tell me if it has a problem and it is smallish and I can glue it to the engine somewhere. How's that for a $6 Nano!

Oh before I forget, the clone Arduino's usually use the older bootloader but, they can be flashed to the newer one using the 6 pin connector, I never seen much difference between the 2 and don't both with the update. I also want to say that Awake did an excellent job describing what a UNO or Nano can do.

Cheers
Ray

 

[74Sprint]

Just some FYI.
Here is some code that I use to calculate the RPM using the Nano.

void getRPM()
{
long count;
unsigned long currentTime = 0;
unsigned long startTime = millis();
attachInterrupt(0,isr,RISING); //assign INT0, when pulse is rising

pulsewidth = pulseIn (2, HIGH); //use pin 2, count ONLY while pin is high
Serial.print("pulsewidth = "); // print to the serial monitor
Serial.println(pulsewidth);

while (currentTime <= sampleTime)
{
currentTime = millis() - startTime;
}

detachInterrupt(0); //detaches the interrupt while calculating

count = (long(rev) * 60);
rpm = int(count/NumPulse);
if(rpm >= 9999)
{
rpm = 9999;
}
rev=0;
return;
}

 

[Lloyd-ss]

Just some FYI.
Here is some code that I use to calculate the RPM using the Nano.

void getRPM()
{
long count;
unsigned long currentTime = 0;
unsigned long startTime = millis();
attachInterrupt(0,isr,RISING); //assign INT0, when pulse is rising

pulsewidth = pulseIn (2, HIGH); //use pin 2, count ONLY while pin is high
Serial.print("pulsewidth = "); // print to the serial monitor
Serial.println(pulsewidth);

while (currentTime <= sampleTime)
{
currentTime = millis() - startTime;
}

detachInterrupt(0); //detaches the interrupt while calculating

count = (long(rev) * 60);
rpm = int(count/NumPulse);
if(rpm >= 9999)
{
rpm = 9999;
}
rev=0;
return;
}

Thanks Ray, for this example. Even though I couldn't write it (yet), I can pretty much follow it. That is encouraging.
Lloyd

 

[74Sprint]

Just so I don't confuse to many people, this isn't all the code necessary to make the ignition work. This shows a bit more of what is needed though and is only meant as an illustration.
Anything following the // is a comment.
The code below is setup for wasted spark or a 2 stroke engine and has not been optimized yet, so there is some redundant code. Also for the loop I took out stuff for the LCD, timing degrees lookup, and the serial-print to serial monitor.

//Declarations:

int NumPulse = 0;
int RPMin = 2; // RPM interrupt signal in (pin 2)

// RPM stuff
const byte ledPin = 13; // shows the trigger in using the onboard LED
const byte interruptPin2 = 2; // make sure pin 2 is set to interrupt INT0.
volatile byte state = LOW;
float value=0;
int rev=0;
int rpm;
int oldtime=0;
int time;
float pulsewidth = 0; // value of the pulse width (time not clocks)
const unsigned long sampleTime = 999; // the amount of time I allow for sampling.

void isr() //interrupt service routine
{
rev++; // increment the RPM count by 1.
state = !state;
digitalWrite(ledPin, state); // this will change the state of the LED. If it's on then turn off, if off then turn on.
}

void setup()
{
// put your setup code here, to run once:
pinMode(RPMin, INPUT); // sets the digital pin 2 as input

// RPM stuff
pinMode(ledPin, OUTPUT); // use the LED pin 13 as an output.
pinMode(interruptPin2, INPUT); //rpm pulse in
attachInterrupt(digitalPinToInterrupt(interruptPin2), blink, RISING); // enables the interrupt.
}

void loop()
{
// put your main code here, to run repeatedly:
getRPM(); // shown in previous post.
}

This is just an insight to what is possible and needed, it is not the only way to calculate RPM but this is good to 9,999 RPM, maybe more. I still have to straighten out the Arduino code and make a program (in C#) for the PC to modify the EEPROM stored values for timing lookup. I'll most likely only use a 2D graph or table as there is no MAP or Throttle position sensor being used. My code will only replicate a mechanical advance.

Cheers
Ray

 

[Lloyd-ss]

but if you stick to anything that is an Arduino <X>, rather than "Bob's Arduino-compatible Chicken-Waterer", you'll still be able to buy a replacement next year,

Come on now, don't go talking bad about my chicken projects. It was something far more sophisticated than a simple "Chicken Waterer". It was a "Solar Synchronized Chicken Coop Door Opener". It had to be sophisticated to make up for the deficiencies in the tiny chicken brains. The door had to be coordinated with the seasonal variations in solar sunrise and sunset. The clocks in chickens are embedded, and cannot be re-programmed. Dusk to dawn timers won't work either, and the chickens will either get trapped inside or outside, and always on the wrong side. And several safety interlocks are necessary so that no chickens get mashed in the operating door. In the end, I don't think the chickens cared one way or the other.

 

[Lloyd-ss]

ust so I don't confuse to many people, this isn't all the code necessary to make the ignition work. This shows a bit more of what is needed though and is only meant as an illustration.
Anything following the // is a comment.

Yup, Understood. And, ample comments are a very good thing.

 

[willray]

...We used a counter on the PIC12LF1840 between 2 trigger pulses to get the RPM but, I changed that to a timer measuring the pulse width, only used 1 trigger pulse...

I'm curious -- how wide (crank degrees) is your pulse? I would have thought that you'd need a pulse that subtends quite a large fraction of one rotation to push the inevitable vibration-induced jitter down into the single-degrees-of-rotation range?

 

[willray]

Come on now, don't go talking bad about my chicken projects. It was something far more sophisticated than a simple "Chicken Waterer". It was a "Solar Synchronized Chicken Coop Door Opener"...

The private joke there, was that we're also headed towards trying to appropriately instrument and automate our chicken coop, so an Arduino with appropriate chicken-specific functionality would be pretty cool from my point of view. I've thought about trying to RFID them so that the coop can keep track of who's in and who's out, but I haven't yet come up with any failsafe scheme that's less error-prone than sending the teenager up the hill to check the coop, so for the time being, he's the automation system.

 

[Lloyd-ss]

There is a ton of smart phone compatible cheap home automation stuff available. Our chickens are pretty reliable about going in at night. I found a couple of regular wall switches that are a variation on a timer controlled wall switch. The switch is programmable, and you set the latitude and date and time, and from there it knows the sunrise and sunset time throughout the year. Pretty slick, really, and it takes care of a lot of the work. Then all you have to do is put in a plus or minus time offset for the morning and evening and hook up a lead screw with some limit switches to it. The switch I chose is powered by the AC going to it, and the memory for the time and programming is non-volatile, so power outages are not an issue. There are also battery powered versions that would be compatible with a 12 vdc remote system. I found them on Amazon several years ago and its still working.

 

[74Sprint]

I'm curious -- how wide (crank degrees) is your pulse? I would have thought that you'd need a pulse that subtends quite a large fraction of one rotation to push the inevitable vibration-induced jitter down into the single-degrees-of-rotation range?

The width of the pulse varies with speed which, is why one has to do a calibration first. When one compares the timing of events of electronics and with mechanical events the mechanical is very, very slow. The pulse width also varies with the magnet's strength, the sensitivity of the Hall-Effect, and the distance between them. The timing position of the leading edge never changes, just the trailing edge changes with speed, hence pulse width. With testing we had pulse widths down to 0.01 degree at 500 RPM and 0.1 at 10,000 RPM.

To be honest we never really cared much about jitter because it was down to like 0.001 of a degree. Sure if your Hall-Effect is wobbling around enough that you could see it moving then things of course would be much different. Like I said mechanically the engine is actually quite slow in movements. A good example of this is the engine management computer on todays engines which can detect a single miss-fire at 7,000 RPM or more on a narrow band O2 sensor. Going back to 2012 I can't remember exact numbers for the pulse width but, I know it was from about 250 usec. to 1 msec. depending on the setup and RPM.

One way to get around starting is to measure the speed of the crank and use a locked in advance until around 200 RPM. Car manufacturers use between 200 and 450 RPM, some go higher. I can measure the speed of the crank using either 1 or 2 pulses, use/convert that to time, and divide 360 degrees by the time, and I will know approximately how much hold off time I need for ignition timing. I hope that makes sense. It is easier to use the time between 2 leading edges than pulse width. It is also easier to adjust the pickup to get the correct timing than having to do the math especially if your using a starter motor. Most of todays engines will not put out a spark or inject fuel until it sees both a crank and cam trigger. On some racing EMS systems like Fueltech's, it stops looking for the cam sensor once it gets both triggers timed. Which makes sense because once you know where number one is you don't need a cam trigger any more, this saves computer power at higher RPMs.

I think I did some babbling, sorry.
Ray

 

[74Sprint]

There is a ton of smart phone compatible cheap home automation stuff available. Our chickens are pretty reliable about going in at night. I found a couple of regular wall switches that are a variation on a timer controlled wall switch. The switch is programmable, and you set the latitude and date and time, and from there it knows the sunrise and sunset time throughout the year. Pretty slick, really, and it takes care of a lot of the work. Then all you have to do is put in a plus or minus time offset for the morning and evening and hook up a lead screw with some limit switches to it. The switch I chose is powered by the AC going to it, and the memory for the time and programming is non-volatile, so power outages are not an issue. There are also battery powered versions that would be compatible with a 12 vdc remote system. I found them on Amazon several years ago and its still working.

Hey Lloyd how about using a IR sensor so you don't barn door slam a chicken.

Ray

 

[willray]

The width of the pulse varies with speed which, is why one has to do a calibration first. When one compares the timing of events of electronics and with mechanical events the mechanical is very, very slow. The pulse width also varies with the magnet's strength, the sensitivity of the Hall-Effect, and the distance between them. The timing position of the leading edge never changes, just the trailing edge changes with speed, hence pulse width. With testing we had pulse widths down to 0.01 degree at 500 RPM and 0.1 at 10,000 RPM.

To be honest we never really cared much about jitter because it was down to like 0.001 of a degree. Sure if your Hall-Effect is wobbling around enough that you could see it moving then things of course would be much different. Like I said mechanically the engine is actually quite slow in movements.

I remain surprised that works. Of course, the processor is much faster than the mechanical bits, but even at 0.001 degree jitter (which astonishes me that you can get it that small - I'd have expected just simple slop in the crank bearings to contribute more variability than that!), that's still 10% of your (500RPM) pulse width. It doesn't matter how fast the processor can calculate/time things, if the RPM estimate is wrong, it seems like that'd play havoc with calculating the right value for the delay between seeing the pulse and firing the plug.

Unless I'm completely misthinking something, a 10% error in the pulse width produces a 10% error in the RPM estimate. And a 10% error in the RPM estimate should produce a 10% error in your delay-until-firing calculation. That could be 36 degrees...

Ah, but wait wait wait -- you're not predicting a delay for an almost complete revolution, your pulse occurs somewhere "close to but before" the earliest possible firing advance, so somewhere maybe 45deg BTDC? 10% error in that's 4.5 degrees, but maybe that's not critical?

 

[Lloyd-ss]

Ah, but wait wait wait -- you're not predicting a delay for an almost complete revolution, your pulse occurs somewhere "close to but before" the earliest possible firing advance, so somewhere maybe 45deg BTDC? 10% error in that's 4.5 degrees, but maybe that's not critical?

Very interesting thought. Those changes within the program, even if you are doing some sort of reliable forward-predicting, can be a real bug-a-boo to solve. But as you say, how critical is it?
I remember as a teen ager watching the timing mark on the car flywheel bouncing all around under the timing light, as the advance weights twisted everything around. But the relative BTDC at various rpms was repeatable enough that I never had to spring for a big dollar distributor. There is a big distance between "it works", and "it works perfectly," and somewhere in there, the pragmatist has to say, "it works well enough." It goes along with the old saying, "It's time to shoot the engineers and get on with production." But I totally understand the obsession. It is our nature/curse.
Lloyd