Model Engine Ignitions

[74Sprint]

A little more work on the calculations.
So now that I know the RPM what's next? Well I need to know how fast are the degrees flying by.

so (RPM x 360 degrees) / 60 = degrees per second.

Example: 300 x 360 = 108,000 per minute
108,000 / 60 = 1,800 degrees per second

I know that my Hall sensor is 55 degrees before top dead center, so how long do I have before the crank goes from 55 degrees to TDC?

Time to TDC is 55 / 1,800 = 0.03056 seconds or 30.56 milli-seconds.

How much time is 1 degree? I can reduce this down to 1 degree by dividing the time by 55.
0.03056 / 55 =0.000556 seconds per degree or
1 / 1,800 = 0.000556 seconds per degree or 0.556 milli-sec or 556 micro-sec

so if I wanted say to have 10 degrees advance BTDC then I would tell the MCU to wait 45 degrees before firing and since the Arduino works with either milli or micro seconds, I'll use micro seconds because I plan to go higher RPMs:
45 x 556 usec = 25,020 usec. before sending out a coil fire trigger.

The 1 thing I haven't mentioned yet is the amount of time the MCU takes to calculate the RPM, do the table lookup from the EEROM to get the amount of timing advance at the calculated RPM, and send out the fire trigger pulse. I can setup a way in the code to time all this; trigger in, calc, lookup, and trigger out. Once I have this I then need to subtract that from the 55 degrees. So if the calculations take say 1 milli-second to do then my wait time would be 25,020 - 1,000 = a wait time of 24,020 usec before the fire trigger.

All this can seem a bit mysterious I know. I've had people with a degree in computer science that can't quite understand that the MCU can not forecast the future and needs time to do the calculation and WAIT to fire the coil. I think the confusion lies in the terms used such as advance the timing by telling the MCU to wait less time. But one has to remember that if you want to use an advance of say 20 BTDC then the Hall can not be set at 20 degrees BTDC because 20-20 = 0. The MCU will not have any time to do the calculations and will fire the coil at less than 20 degrees. This is because as the MCU is doing the calculations the crank is still turning toward TDC and time is burning up and the MCU will fire after the calculations are done, so no advance. This also brings us to "is the MCU fast enough to do the calculations at the RPM I want to use?" As for the Arduino Nano I don't know yet because I haven't finished my testing. I do have MCUs that are up to 200 times faster just incase the Nano can't handle 10,000 RPM on a single cylinder but, I think it can. I know it will not do 5,000 RPM on a 18 cylinder engine. This also brings us to "is there enough time to charge the coil 2-5 msec?" Might have to use more than 1 distributor and use 2 Nanos/MCUs or 2 distributors and 1 fast MCU. Mind you one can always use 18 LS1 coils and a fast MCU.

Cheers
Ray.

 

[bluejets]

I'd do the suck it and see approach.
Jam in something close, then check with a timing light.

 

[awake]

Your reasoning all makes sense to me. The nice thing is, you don't actually have to do any particular calculations in real time. Instead, calculate the values in advance for different RPM ranges, allowing for the time needed to process the ISR including lookup, set timer, etc. You don't even need to calculate RPM on the fly (unless you want to display it, but I would do that outside of any ISRs and just let it chug along) - instead, build your lookup table with the microsecond measurement of the pulse and the corresponding microsecond timer setting for the advance. Depending on the length of the table, you may to do the lookup via an indexing scheme of some sort (let the upper 3 bits of the pulse measurement give you the lookup table index, for example - scaled as needed, of course). Alternately, you may only need, say, 8 values for 8 RPM ranges, and it may be just as simple to walk through the table for the lookup - and build the time needed to get to the right lookup value into the corresponding timer setting. I would say that with a little finesse, you could arrange things in such a way that your ISR could complete in a very few microseconds, particularly if you set the table up so that lookups involving the highest RPMs always finish the fastest.

 

[74Sprint]

Your reasoning all makes sense to me. The nice thing is, you don't actually have to do any particular calculations in real time. Instead, calculate the values in advance for different RPM ranges, allowing for the time needed to process the ISR including lookup, set timer, etc. You don't even need to calculate RPM on the fly (unless you want to display it, but I would do that outside of any ISRs and just let it chug along) - instead, build your lookup table with the microsecond measurement of the pulse and the corresponding microsecond timer setting for the advance. Depending on the length of the table, you may to do the lookup via an indexing scheme of some sort (let the upper 3 bits of the pulse measurement give you the lookup table index, for example - scaled as needed, of course). Alternately, you may only need, say, 8 values for 8 RPM ranges, and it may be just as simple to walk through the table for the lookup - and build the time needed to get to the right lookup value into the corresponding timer setting. I would say that with a little finesse, you could arrange things in such a way that your ISR could complete in a very few microseconds, particularly if you set the table up so that lookups involving the highest RPMs always finish the fastest.

Holly crap! how did you manage to read my code? I'm not sure from what you're saying would give me 1 degree precision. I'm willing to try it if you can expand on your thinking. Actually using an index is how I get the EEPROM memory location to read. This is a lot faster than calculating the RPM and then either using a nested 'IF' statement. I also try to stay away from using division since computers can only ADD and division has multiple steps, it's the slowest of all the basic math operations. But when you have to, you have to. I also don't like to use interpolation because I think that is just a waste of time.

So indexing aka placing or looking up a value in an array by converting the range number into an index just as 1, 2, 3 etc. Let's say that I have a range for the advance values that goes up by 1,000 RPM, 0, 1,000, 2,000, 3,000 etc.
so:

(1/Time) x 60 = RPM between pulses or ((1/(T*0.327))/60)/100 = RPM pulse width

let's say RPM =4,655. Then 4655 should be in the 4,000-4,999 memory location. So a standard nested 'IF' statement would look like this.
IF RPM <1,000 then
Look in memory location 1
else
if RPM >= 1,000 and <2,000 then
Look in memory location 2
else
if RPM >= 2,000 and < 3,000 then
look in memory location3
else
if RPM >=3,000 and <4,000 then
Look in memory location 4
and so on....... end IF

Problem is that the MCU will read the whole condition.

A select statement would be faster because it just goes down the list until it finds a match, does what it is told and exits the select statement list.
Select RPM
RPM <1,000
look in memory location 1
RPM <2,000
look in memory location 2
RPM <3,000
mem_loc = 3
RPM default
mem_loc = 1
and so on..... end SELECT

I could also just get the first digit '4' but, if the RPM is 415 then the code will look in location 4 which is no good. I could also make my range step be 500 RPM which, would handle this but not 4,500. Even if I took the first 2 digits it wouldn't work because 04 = 4. There is also a other things I could do like checking the length of the RPM number and so on.

I could also do this:
Select RPM
RPM <1,000
IF RPM <1,000 and >500 then
mem_loc = 2
else
mem_loc = 1
end IF
RPM <2,000
mem_loc = 3

I have found with testing that looking up the value with the above code is in the nano-second range but, transferring that value to a variable is slow, it's in the micro-sec range or higher. Which is still plenty fast enough for my little 1 banger.

What is the fastest code? Well it is to make my range steps go up by 100 and just use the first 2 digits of the RPM.
So:
00, 01 to 09 converts to location 0, 1 to 9 and then 10 to 99 allows for up to 100 memory locations. The Nano EEPROM has 1024 locations. There is a problem with the ATmega328P MCU in that it needs time to transfer the lookup value from memory into a variable. This can be as much as 20 milli-seconds, way to long. I have had to use 20 msec only about 3 times to get stability. To do away with the wait(delay) it helps to store the values in Hexadecimal but, then you have to convert that value into decimal when reading the location value, no biggy. Doing this brings you back to nano-second times. As for a 100 RPM range I think that is to small unless one is using a hit-n-miss engine. I'm most likely going to use the code just like above with 500 RPM range steps.
So:
Select RPM
RPM <500
IF RPM <100 and >50 then // Note engine is cranking, retard timing
mem_loc = 1
else
mem_loc = 2 // Note engine is idling
end IF
RPM <1,000
mem_loc = 3
RPM <1,500
mem_loc = 4
etc.....
RPM default
no_spark //Note engine must be stopped
end SELECT
And so on something like this.....

Once I have the degrees of advance I just need to find the time per degree to get my holdoff time.

Now to make some code for testing.

Cheers
Ray

 

[Steamchick]

Fascinating discussion about coding/ programming. But way over my head.
But I did see a comment about the spark plug cleaner tphat sand-blasted the plugs. Post #200. My experience: I used one for my pocket full of plugs for my motorcycles in the 1960s.... I changed plugs every time I thought they were not running right.... fouled, mis-firing or just losing power. Curiously, the sand-blasted plugs seemed to foul and lose power relatively quickly... A week, or tank of fuel, etc. (as opposed to just washed with petrol and something - twig or cocktail stick - poked down the side on the insulator to clean...).
In a later life I worked with the Champion engineer selecting and testing appropriate plugs for the engines in our factory. He advised that the gloss finish of the plugs allows for the retention of less contaminant than the sand-blasted rougher finish I had experienced. What was happening to me was that the sand-blasted finish collected carbon in the pores/scratches, leading to flash-over down the insulator, especially during cold starting. This meant poor and delayed ignition, even mis-firing.
So I would not use plugs cleaned that way nowadays.
K2

 

[DKGrimm]

Slightly off topic. But can an ignition circuit be judged by the ability of a spark to jump a certain gap in air. So for example if a spark jumps 10mm in air is it likely to be OK under compression say 6 or 7 to 1

Here's a couple pages from a white paper I wrote (to myself) a while back. It seems to give reliable results for inductive ignition systems and magnetos, although I have no idea how to use it with CDI. This comes from a stash of similar working papers I have posted on www.dkgsite.com.

 

[DKGrimm]

Fascinating discussion about coding/ programming. But way over my head.
But I did see a comment about the spark plug cleaner tphat sand-blasted the plugs. Post #200. My experience: I used one for my pocket full of plugs for my motorcycles in the 1960s.... I changed plugs every time I thought they were not running right.... fouled, mis-firing or just losing power. Curiously, the sand-blasted plugs seemed to foul and lose power relatively quickly... A week, or tank of fuel, etc. (as opposed to just washed with petrol and something - twig or cocktail stick - poked down the side on the insulator to clean...).
In a later life I worked with the Champion engineer selecting and testing appropriate plugs for the engines in our factory. He advised that the gloss finish of the plugs allows for the retention of less contaminant than the sand-blasted rougher finish I had experienced. What was happening to me was that the sand-blasted finish collected carbon in the pores/scratches, leading to flash-over down the insulator, especially during cold starting. This meant poor and delayed ignition, even mis-firing.
So I would not use plugs cleaned that way nowadays.
K2

Same as my experience with sandblasted plugs in my dad's garage when I worked there.

 

[Steamchick]

Hi Mr. Grimm. I also remember a spark plug tester for ignitions. The tester was a glass tube with a scale in 1/8" marks and the sharp-pointed earth contact could be moved away from the HV terminal (connected to the HT lead) to measure "sparking performance Voltage". The gap - around 1/2inch? - was deemed an "OK" ignition. But if if could not jump 1/4" then it was no good. (Not sure of the exact measurements, but there was a table of gap dimensions versus kV of the ignition! - 2kV being the "OK" point as I remember?).
There was also a hand-wound magneto for testing the 18mm dismantlable-type spark plugs (Cleaning those was my job!).
I believe both testers were "Lodge Spark Plug" company tools! - a Company absorbed by Champion in more recent years - (?). Ignition Technology has advanced a long way since then! Now I simply change plugs at 36,000miles, because it says so in the book, and I never worry about the car not starting for "dirty plugs", etc. The Champion rep advised that from the testing we conducted in the late 1980s/early 90s that the earliest failures would occur around double that mileage, just in case of a "missed" service. The Warranty was for 60,000 miles, so plugs needed to have sufficient platinum on the electrodes to withstand that mileage with fewer than 6 failures per million plugs). But AFTER MARKET plugs would only be good for 40,000 miles for 6ppm failure rate! - Less Platinum on the after-market electrode tips (Which should never have any abrasive cleaning applied - the platinum is only microns thick!). - Don't quote me on that as aftermarket parts were not my remit, and my memory isn't perfect! That was the "Engineering" of lifetime of the serviceable parts!
As I recall... the "fouling degradation" of the surface of the insulator was expected around the 70,000 miles (or more), providing "Good" clean fuel (Western economy countries) has been used. This is worse if the fuel is not "regular high quality lead free" (Some 3rd world nations). I also heard that NGK had the "best" clay in the world for this insulator application, which is one reason why they claim to be the "best" plugs...
Probably of no interest for models with home made plugs and ignitions and different performance parameters and fuels!
Enjoy,
K2.

 

[awake]

Ray, I am working up a rough sketch of what I was thinking, but in the process, I noticed what I think is problem with the units in your formula.

According to your earlier post, ((1/(T*0.327))/60)/100 = RPM where T = the pulse width from the hall-effect sensor, in microseconds. Unfortunately, this yields results that do not sound right: plug in RPM = 500 and it gives T = .0036670. If T is in microseconds, .003667 is a 3.667 nanosecond pulse! And its going to get even shorter at higher RPM!

I'm thinking T is actually in seconds in this formula. That would give a pulse width of 3.667 milliseconds. I checked that by calculating a single complete revolution at 500 RPM = 500 revolutions / 1 min = 8.333 revolutions / 1 second. Divide top and bottom by .8333 to get 1 revolution / .120000 seconds. So a single total revolution at 500 RPM takes 120 ms; a pulse-width of 3.667 ms would suggest that the hall-effect sensor pulses for about 11 degrees out of 360. That sounds about right to me.

Simplifying the formula (multiplying and dividing the constants) and solving for T gives me this formula: T = 1 / (RPM * .545). If you get a chance, see if that looks right to you.

Meanwhile, I will work up the sketch and will post it later today ...

 

[awake]

Okay, attached are two documents that try to sketch out what I had in mind. I started to put it all into a post, and it was going to be way too long, so I turned it into a .pdf file that describes the logic, and a spreadsheet that illustrates the calculations. Hopefully together these make sense, but if not, don't hesitate to ask. And on the flip side, hopefully this is not tediously telling you things you already know!

 

[bluejets]

Fascinating discussion about coding/ programming. But way over my head.
But I did see a comment about the spark plug cleaner tphat sand-blasted the plugs. Post #200. My experience: I used one for my pocket full of plugs for my motorcycles in the 1960s.... I changed plugs every time I thought they were not running right.... fouled, mis-firing or just losing power. Curiously, the sand-blasted plugs seemed to foul and lose power relatively quickly... A week, or tank of fuel, etc. (as opposed to just washed with petrol and something - twig or cocktail stick - poked down the side on the insulator to clean...).
In a later life I worked with the Champion engineer selecting and testing appropriate plugs for the engines in our factory. He advised that the gloss finish of the plugs allows for the retention of less contaminant than the sand-blasted rougher finish I had experienced. What was happening to me was that the sand-blasted finish collected carbon in the pores/scratches, leading to flash-over down the insulator, especially during cold starting. This meant poor and delayed ignition, even mis-firing.
So I would not use plugs cleaned that way nowadays.
K2

Well, that was in the days of 36hp Holdens and the like, not exactly "race cars".
Why does everything with you blokes have to be performance related to the Nth degree, they are model engines for crying out loud.
Most are happy just at the fact that they will actually run.

Point was as the pressure increased the spark deteriorates.

 

[Steamchick]

Hi Bluejets: fair comment... However, this website has some contributors who are experts in their field, and some who just want to learn what makes "the best" into "the best". Whether it is machining precision, or engineering "best practice" - or anything else.
I am happy with a 50% success rate on "runners", but still aim for "the best" - where I can learn and improve. (Murphy's 47th law: Aiming for the Bull's-eye means you'll have a better chance of hitting something! - or was it "Aiming for the Bull is good, speaking a load of Bull is not!").
Incidentally, I am curious just watching the discussion on something like this, as I am NOT making an ignition system, nor do I understand the computer coding discussion, etc., but within the discussion there are a few morsels of information that teach me something about bits I have fitted to cars - and not really understood what they do...
I would buy an ignition system and simply use it "from the box" - but that doesn't make this thread less interesting - to me at any rate.
On the technical side, I am curious to learn about ignition voltage and current and thought the success of ignition was down to "spark energy" - which is usually monitored by "open circuit voltage" of the HT side, as it is difficult to monitor the arc current (without high tech oscilloscopes, etc.). Hence, the input energy has a significant effect, which is part of the discussion above (points "dwell" on those old Holdens?).
Aside: For 4 years I was an engineer designing HV switchgear - but never understood the stuff the HV Electrical engineer did to determine how to quench arcs of many hundreds of Amps at 500kV! - I just designed the equipment that managed to break the arcs, because I met his criteria for contact separation speed.... (distance and time = start-to-stop in 9 inches, in 0.05 seconds.). - Nothing at all like an ignition system...
Long live the freedom of speech where we are all equal, yet can maintain our different viewpoints without censure. (Except that my wife is always right!).
K2

 

[bluejets]

Except that my wife is always right!

That is the statment of the day and most important.

 

[awake]

Incidentally, I am curious just watching the discussion on something like this, as I am NOT making an ignition system, nor do I understand the computer coding discussion, etc., but within the discussion there are a few morsels of information that teach me something about bits I have fitted to cars - and not really understood what they do...

Part of the reason I put the details into attachments rather than in a long post was to make it easier for folks to choose whether or not to dig into the messy bits!

 

[DKGrimm]

On the technical side, I am curious to learn about ignition voltage and current and thought the success of ignition was down to "spark energy" - which is usually monitored by "open circuit voltage" of the HT side, as it is difficult to monitor the arc current (without high tech oscilloscopes, etc.). Hence, the input energy has a significant effect, which is part of the discussion above (points "dwell" on those old Holdens?).

I also have a EE background with a couple career years dealing with industrial electric power. After retirement I spent more than ten years trying to teach myself about the energy, voltage, and current stuff you mention in ignitions systems. I've collaborated with John Vietti to make some small magnetos that seem to work, including a construction series in "Model Engine Builder" for a magneto-igniter combination for a Red Wing (still running, BTW). If you care to see some of my untutored musings on the subject, I posted working papers on www.dkgsite.com. These have a bunch of math and engineering jargon, but some of that is necessary to really understand the innate complexity of ignition systems. Albert Einstein is quoted as having said, "Everything should be as simple as possible, but not simpler".

 

[74Sprint]

Ray, I am working up a rough sketch of what I was thinking, but in the process, I noticed what I think is problem with the units in your formula.

According to your earlier post, ((1/(T*0.327))/60)/100 = RPM where T = the pulse width from the hall-effect sensor, in microseconds. Unfortunately, this yields results that do not sound right: plug in RPM = 500 and it gives T = .0036670. If T is in microseconds, .003667 is a 3.667 nanosecond pulse! And its going to get even shorter at higher RPM!

I'm thinking T is actually in seconds in this formula. That would give a pulse width of 3.667 milliseconds. I checked that by calculating a single complete revolution at 500 RPM = 500 revolutions / 1 min = 8.333 revolutions / 1 second. Divide top and bottom by .8333 to get 1 revolution / .120000 seconds. So a single total revolution at 500 RPM takes 120 ms; a pulse-width of 3.667 ms would suggest that the hall-effect sensor pulses for about 11 degrees out of 360. That sounds about right to me.

Simplifying the formula (multiplying and dividing the constants) and solving for T gives me this formula: T = 1 / (RPM * .545). If you get a chance, see if that looks right to you.

Meanwhile, I will work up the sketch and will post it later today ...

You know I found that mistake yesterday morning and in the correct version time is in msec, also my correction factor changed to 0.325, (1/(Tmsec*0.325))*600 = RPM. How correct and accurate will be determined once it's all put together.
My table looks like this:

Hz	Pulse Width	RPM	Time msec	RPM per	Calculated RPM from PW	Degrees	55 degree Hall Time to
1 Magnet	msec measured	from Hz	Between Pulses measured	1 second	(1/(Tm*0.325)*600) = RPM	per Second	TDC in seconds
2.5	14.000000	150		0.23333333​	131.8681	791.208791​	0.069513889​
5	6.000000	300	176.000000	0.10000000​	307.6923	1846.153846​	0.029791667​
10	3.000000	600	90.400000	0.05000000​	615.3846	3692.307692​	0.014895833​
15	2.000000	900	62.800000	0.03333333​	923.0769	5538.461538​	0.009930556​
20	1.500000	1200	56.800000	0.02500000​	1230.7692	7384.615385​	0.007447917​
25	1.200000	1500	37.400000	0.02000000​	1538.4615	9230.769231​	0.005958333​
30	1.000000	1800	30.800000	0.01666667​	1846.1538	11076.923077​	0.004965278​
35	0.880000	2100	27.000000	0.01466667​	2097.9021	12587.412587​	0.004369444​
40	0.760000	2400	23.440000	0.01266667​	2429.1498	14574.898785​	0.003773611​
45	0.680000	2700	20.760000	0.01133333​	2714.9321	16289.592760​	0.003376389​
50	0.600000	3000	18.760000	0.01000000​	3076.9231	18461.538462​	0.002979167​
55	0.560000	3300	17.160000	0.00933333​	3296.7033	19780.219780​	0.002780556​
60	0.515000	3600	15.640000	0.00858333​	3584.7647	21508.588499​	0.002557118​
65	0.475000	3900	14.440000	0.00791667​	3886.6397	23319.838057​	0.002358507​
70	0.440000	4200	13.400000	0.00733333​	4195.8042	25174.825175​	0.002184722​
75	0.400000	4500	12.520000	0.00666667​	4615.3846	27692.307692​	0.001986111​
80	0.385000	4800	11.800000	0.00641667​	4795.2048	28771.228771​	0.001911632​
85	0.360000	5100	11.000000	0.00600000​	5128.2051	30769.230769​	0.001787500​
90	0.340000	5400	10.480000	0.00566667​	5429.8643	32579.185520​	0.001688194​
95	0.325000	5700	9.920000	0.00541667​	5680.4734	34082.840237​	0.001613715​
100	0.305000	6000	9.420000	0.00508333​	6052.9634	36317.780580​	0.001514410​
150	0.205000	9000	6.220000	0.00341667​	9005.6285	54033.771107​	0.001017882​

It is hard to get accurate measurements with my sh*t DC motor controller, I'm more than likely am going to be tweaking the calcs. Your calculation T = 1 / (RPM * .545) pretty much jives with mine and looks good. Your hold-off time is also close to mine. I did more research into whether I should use an interrupt or just the Arduino pulseln (pulse length). If I use the pulseln then I can have it measure the pulse width in either milli or micro seconds using almost any pin I want without using up an interrupt. I can still call up an ISR to do my calculations without linking the ISR to anything and keep my speed up. Also the pulseln has a default timeout of 1 second if it sees no pulse. This would work good for me because I could take this as a stalled engine or one that has not started yet. Your theory discussed in your PDF would lean more toward time between pulses setup which, I may still have to do if PW doesn't work out. In my testing I first got the Hz of the rotating magnets, divided that by 2 and then converted that into RPM. But because the Nano won't know the RPM I used the PW to calculate the RPM and compared that to the measured RPM. Since I decided to use a SELECT function to get the memory location (0, 1, 2, etc) based on 100 RPM increments my PC computer program will use a 2D table that is seeded with some values already for the 100 location. What I want to do is allow a person to select a range and then enter the advance value just once and do this for each selected range. Most controllers use this setup today. There will also be 10 locations for the temperature timing adjust if required. If you look at the values below you'll see that 20 executions' is still less than 1ms. I don't think the calculations and lookup will be more than the 20 executions'. Note: serial communications are very slow and should be kept to a minimum and outside of ISRs.

I also did some timing of code and got this:
164681 cycles read all of EEPROM and transfer into RAM
RAM cycles per byte: 11.22
EEPROM cycles per byte: 40.23

clock cycle = 0.0625 micro-seconds at 16mhz
0.010293 seconds or 10.293 milli-sec to read all of EEPROM locations
RAM time per byte = 0.00000070125 seconds or 701.25 nano-sec
EEPROM time per byte = 0.00000251438 seconds or 2.51438 micro-sec

time to init board bare minimum = 8 micros
time to count to 10 and serial print each value = 884 micros

dwell time minimum = 2 milli-sec
This dwell time presents a problem with the Hall set at 55 degrees before TDC because I need 2 milli-seconds to charge the coil. With 2 msec. that means RPM is limited to <4,800 RPM unless I move the Hall to 90 degrees BTDC.

Well that was yesterday besides getting a heart monitor yesterday afternoon.

Cheers
Ray

 

[awake]

I've not used the pulseln function - I'll have to look into that one. Yes, absolutely agree on keeping serial communication out of ISRs, and if the main loop handles any sort of timing, out of that as well. I don't recall what sort of hardware serial buffering the Arduino / AVR may or may not have; if it does not have any significant buffering, I wouldn't want to use serial in the main loop even if the ISRs are handing timing in the background. As you say, serial is too busy and too slow, and yet can itself be time-dependent. Very convenient for reporting what is going on, also a great way to shoot yourself in the foot ... !

clock cycle = 0.0625 nano-seconds at 16mhz

Just to be pendantic ... a 16MHz clock gives a .0625 millisecond cycle, which is to say, a 62.5 nanosecond cycle, or a .0000625 second cycle.

 

[74Sprint]

Well, that was in the days of 36hp Holdens and the like, not exactly "race cars".
Why does everything with you blokes have to be performance related to the Nth degree, they are model engines for crying out loud.
Most are happy just at the fact that they will actually run.

Point was as the pressure increased the spark deteriorates.

Let's see I've worked on tractors, trucks, cars, and airplane engines from the 1930's and cars from the 1920's. I still like working on them when I get a chance and yes it is nice to see them just run. I really like going to the steam days where they have all the old stuff steam and petrol in working condition. But as for the Nth degree I am not sure, as for my race car I'd say it's more like 10th degree LOL. I love acceleration and with drag racing my reaction time and my tuning skills have to be near prefect to win. We're talking about races that I have won by 0.002 of a second combined. As for my other 2 cars I want to get the best gas mileage I can. As for my model engines, I want them to run and run reliably on 2 stroke fuel, nitro engine fuel is getting very expensive. As for this project it is a springboard to bigger things.

Cheers
Ray

 

[74Sprint]

I've not used the pulseln function - I'll have to look into that one. Yes, absolutely agree on keeping serial communication out of ISRs, and if the main loop handles any sort of timing, out of that as well. I don't recall what sort of hardware serial buffering the Arduino / AVR may or may not have; if it does not have any significant buffering, I wouldn't want to use serial in the main loop even if the ISRs are handing timing in the background. As you say, serial is too busy and too slow, and yet can itself be time-dependent. Very convenient for reporting what is going on, also a great way to shoot yourself in the foot ... !



Just to be pendantic ... a 16MHz clock gives a .0625 millisecond cycle, which is to say, a 62.5 nanosecond cycle, or a .0000625 second cycle.

Right, I did it again typed it out wrong Thanks again. There is pulseIn() and pulseInLong(). I believe the serial buffering is up to 2 bytes so not very good, it depends on how it is used, serial com or SPI. I have to rewrite some code for my coil winder because the serial com is not working out too well which, reminds me I have to call and find out where the hell my parts are at (lead screws).

Ray

 

[74Sprint]

I also have a EE background with a couple career years dealing with industrial electric power. After retirement I spent more than ten years trying to teach myself about the energy, voltage, and current stuff you mention in ignitions systems. I've collaborated with John Vietti to make some small magnetos that seem to work, including a construction series in "Model Engine Builder" for a magneto-igniter combination for a Red Wing (still running, BTW). If you care to see some of my untutored musings on the subject, I posted working papers on www.dkgsite.com. These have a bunch of math and engineering jargon, but some of that is necessary to really understand the innate complexity of ignition systems. Albert Einstein is quoted as having said, "Everything should be as simple as possible, but not simpler".

I've been to your website and I like it for the tid-bits and info. I worked for the railroad for 10 years and I still can remember seeing the flames come out of those arc-chutes on the switch gear and the bang that sounded like a gun going off in the cab. LOL

Ray