Help caculating RPM using a PICAXE-8M

[rexlan]

picaxe rpm

Hi all:

What I want to do is use the PULSIN command on a PICAXE-8M chip to caculate the RPM of a motor. I have this idea and code so far but I am not sure how to do the math to actually get a RPM number like 2900, etc. I will use the standard 10us slice with the chip.

I am taking ten samples of the length of time between a pulse of the ignition system and averaging the sample. This is a four cylinder engine so there are (I think?) two pulses per revolution.

I thought about the count command but I don't think there is much resolution. Hippy has helped me with a variation I will use to change the value of RPM with some dil switches after I have this working.

symbol RPM= 0 ' set the name RPM to 0
low 0 ' preset I/O pin 0 to low

getpulse:
w1 = 0 ' preset word 1, the accumulator variable, to zero
for b0 = 1 to 10 'define loop for 10 times, variable b0 is the counter
pulsin 3,1,w2 ' record the length of a positive-going pulse on
I/O pin 2 into word 2
w1 = w1 + w2 ' add in the new pulse width to the total being
accumulated
next b0 ' jump back to the "for" instruction again until
loped ten times

w1 = w1 / 10 ' compute the average by dividing the accumulated
total by ten

RPM = w1 *(here is my problem)
Pause 100
if RPM > 3000 then overrpm ' jump to "overrpm" if word 2 is over
the RPM limit turn on the control
low 0 ' set I/O pin 0 to low (control off)
goto loop ' loop back to start

overrpm:
high 0 ' set I/O pin 0 to high and turn on the control
goto loop ‘ loop back to start

 

[newelltech]

picaxe counter

I think I know what you need.
First, I'm assuming that the pulse width from your ignition system is proportional to RPM. You will have to do a final calibration to compensate for the physical properties of your ignition system and sensor.
I'm assuming that the pulse width has a 25% duty cycle (for 4 cylinders it's 2 pulses per sec). It's probably somewhat less but you can trim it out.

Here's the basic math.
The number of pulsin counts that you average will determine your update rate (ie - how fast the tach needle could move).

The formula is RPM = (50,000/count)*15
Notice that I didn't combine the 50,000 and 15 because of potential register overflow. You should make the first number as large as possible without overflow for your microcontroller. Once you get the formula coded, you will need to calculate the min and max rpms and make sure there aren't any math overflows.

Let's test the formula:
Assume RPM = 60
Rev/sec = 1 rps
#Ignition pulses in 1 sec = 2
Pulse width = 25% * 500 ms = 125 ms.
Pulsin count @ 10 uSec clock = 125 ms/0.01ms = 12500
RPM = (50000/12500)*15 = 60 RPM

Let's test another point
Assume RPM = 6000
Rev/sec = 100 rps
#Ignition pulses in 1 sec = 200
Pulse width = 25% * 5 ms = 1.25 ms.
Pulsin count @ 10 uSec clock = 1.25 ms/0.01ms = 125
RPM = (50000/125)*15 = 6000 RPM

Finally check the resolution
If you took calculus you know that the slope is the first derivative of RPM wrt count
d_RPM/d_count = -750,000/count*count
Evaluating that at 6000 RPM we get a count of 125 and a slope of -48.
That means that at 6000 RPM the output will change by jumps of 48 (6048, etc).
That is if we didn't have to worry about integers. In our case we will also have a best resolution of 15 RPM at any RPM due to the interger arithmetic.

Hope this helps. If my assumptions are way off or you need better resolution, I can help you figure it out. Many years ago, I helped a friend build one of these for his Corvette. He used it to automatically turn the ignition off when the RPM exceeded a set level. We ran it at the drag strip on "grudge night". Noise was a problem so you need to use shielded cable and be careful of grounds.

 

[IanP]

picaxe frequency counter

You shouldn't measure pulses' width - you should measure number of pulses per second(s) ..
Assuming that you have only one pulse per revolutin (one cylinder) this is how I think you can realize this function:

	setint %00001000,%00001000			‘ activate interrupt when pin3 only goes high
loop:
	pause 2000 						‘ wait 2 seconds

' multiply b1 by 30 and this will be your RPM .. or if you wait for 1s (pause 1000)  then multiply by 60 ..

	goto loop


interrupt:
	if pin3 = 1 then interrupt 			‘ loop here until the interrupt cleared
	setint %00001000,%00001000 			‘ re-activate interrupt
	b1 = b1+1
	return 						‘ return from sub

end

Regards,
IanP

PS: Try to use the CODE option for it makes the reading more transparent ..

 

[newelltech]

picaxe speedometer

Using pulse width works with ignition systems because the signal from the rotor or electronic ignition is normally a fixed duty cycle. That means that the pulse width is proportional to RPM. If he has some other ignition signal then measuring frequency is the way to go.

Measuring pulse width has some advantages over frequency. It is a more instantaneous measurement and offers better noise immunity.

Just for the sake of discussion, let's assume that he wants to shut off the ignition immediately after the RPM exceeds 6000 and he will want to do this within say 0.1 sec.
With frequency measurement, he needs to count for 0.1 secs and will get a count of 20 representing 6000 RPM. You can see that a count of 21 would represent 6300 RPM. So the resolution at this point is 300 RPM. So the ignition will shut off somewhere between 5700 and 6300 RPM.
With pulse width measurement, each pulse will be 1.25 ms and the count will be 125 (for 10 us clock) for 6000 RPM and he can average up to 80 pulses. You can see that a count of 126 would be 5952 RPM. So the resolution at this point would be 48 RPM. So the ignition would shut off somewhere between 5952 and 6048 RPM

In addition, pulse width provides somewhat better noise immunity and a car is a very hostile electomagnetic environment. For example each 'noise spike' while counting frequency will increase the RPM by 300 RPM. In contrast the pulse width measurement is collecting multiple measurements and averaging. That means that the microcontroller can reject any pulse widths that are out of range and erroneous pulses that aren't rejected are at least averaged out. in addition, the effect of noise on the pulse edges is intrinsically averaged out. By this I mean that if there is noise on the rising edge, sometimes it will trigger early and sometimes late, but will tend to average out. With the frequency counting method, extra noise pulses are accumulative, ie - they always add.

There are techniques for rejecting noise while counting also but they are more difficult to implement and less effective.

So I think either method will work for his application, but if the input signal has a proportional pulse width, or someone needs a higher performance system, the pulse width approach will yield a more noise tolerant system.

 

[rexlan]

picaxe count command

You shouldn't measure pulses' width - you should measure number of pulses per second(s) ..
Assuming that you have only one pulse per revolutin (one cylinder) this is how I think you can realize this function:

Regards,
IanP

PS: Try to use the CODE option for it makes the reading more transparent ..

Thanks IanP. I thought about the count command but the resolution is very poor. I am working between 2800-3100 RPM and there is only a couple of counts difference so I could easily have an error of 100+ RPM. I also need to update the RPM ever 1/2 second maximum. At 140 MPH a quarter of a second is allot of road and this device has to control my intake manifold based on throttle position and RPM.

I do need the better resolution and think measuring the width of the pulse and taking an average will give me the resolution I will need.

Added after 5 hours 21 minutes:

Using pulse width works with ignition systems because the signal from the rotor or electronic ignition is normally a fixed duty cycle. That means that the pulse width is proportional to RPM. If he has some other ignition signal then measuring frequency is the way to go.

Measuring pulse width has some advantages over frequency. It is a more instantaneous measurement and offers better noise immunity.

Just for the sake of discussion, let's assume that he wants to shut off the ignition immediately after the RPM exceeds 6000 and he will want to do this within say 0.1 sec.
With frequency measurement, he needs to count for 0.1 secs and will get a count of 20 representing 6000 RPM. You can see that a count of 21 would represent 6300 RPM. So the resolution at this point is 300 RPM. So the ignition will shut off somewhere between 5700 and 6300 RPM.
With pulse width measurement, each pulse will be 1.25 ms and the count will be 125 (for 10 us clock) for 6000 RPM and he can average up to 80 pulses. You can see that a count of 126 would be 5952 RPM. So the resolution at this point would be 48 RPM. So the ignition would shut off somewhere between 5952 and 6048 RPM

In addition, pulse width provides somewhat better noise immunity and a car is a very hostile electomagnetic environment. For example each 'noise spike' while counting frequency will increase the RPM by 300 RPM. In contrast the pulse width measurement is collecting multiple measurements and averaging. That means that the microcontroller can reject any pulse widths that are out of range and erroneous pulses that aren't rejected are at least averaged out. in addition, the effect of noise on the pulse edges is intrinsically averaged out. By this I mean that if there is noise on the rising edge, sometimes it will trigger early and sometimes late, but will tend to average out. With the frequency counting method, extra noise pulses are accumulative, ie - they always add.

There are techniques for rejecting noise while counting also but they are more difficult to implement and less effective.

So I think either method will work for his application, but if the input signal has a proportional pulse width, or someone needs a higher performance system, the pulse width approach will yield a more noise tolerant system.

Yep ... this is the way I think we need to go as well. Here is what I am stumped on at the moment though. Actually, I have a very clean signal from the EDIS module in the system and it is conditioned for a tach drive already.

This was exactly what I was looking for and your answer got me to thinking. I think the formula is wrong because you used a duty cycle of 25% Or, I don't understand where the 50,000*15 came from.

Here is what I found today and I crudely looked at it on the scope in the car where I have a digital tach now.

At 3000 RPM I saw the leading edge of a pulse every 10 ms or 1000 us. Using the PULSIN command would have returned the number 1000.

There are 2 pulses per revolution of my 4 cylinder engine in my case with the electronic ignition.

Constant per revolution = 3,000,000

3,000,000 divided by PULSIN = RPM

Now the obvious problem is that this chip cannot do this math which creates another problem I think!

Is there a workaround?

 

[rexlan]

picaxe rpm sensor

Have I been abandoned????

Here are a few real numbers I measured with my scope and monitored with a digital tach in the car. The count is with the 10 us clock.

I looked and see that the duty cycle is 50% and there are two pulses per revolution of the engine.

I put some pictures up here.
**broken link removed**

RPM = 2030
Time = 15ms
Count = 1500



RPM = 3010
Time = 9.9ms
Count = 990



RPM = 3590
Time = ~8ms (hard to see)
Count = ~800



RPM = 4000
Time = 7.5ms
Count = 750

 

[newelltech]

negative side of ignition coil picaxe

Cool car. Data looks good too.
You are indeed correct that the numerator should be 3,000,000 not 750,000. I was using the signal to a cylinder not the ignition so it should be multiplied by 4 for 4 cylinders. From your link it looks like you have have figured out how to do the math with 16 bits with the help of your two 'advisors'. If you need anything else, let me know.

 

[rexlan]

picaxe math

Cool car. Data looks good too.
You are indeed correct that the numerator should be 3,000,000 not 750,000. I was using the signal to a cylinder not the ignition so it should be multiplied by 4 for 4 cylinders. From your link it looks like you have have figured out how to do the math with 16 bits with the help of your two 'advisors'. If you need anything else, let me know.

Well .... I'm not there yet! The problem is still this math limitation. Hippy did a subtract routine that has perfect resolution; however, it takes about 6 seconds to do each RPM calculation ..... no good for this.

I am still having trouble with another method because of multiple statements in a single line.

So the original question remains. An elegant way to solve this 3000000/count=RPM. Resolution to 10 RPM is also acceptable.

I will put all of this up on the webpage when it is done so others can uses it if they want to.

Thanks for the interest and assistance .... I NEED both

 

[VSMVDD]

picaxe modulus math

use an external counter ic using edge trigger clock
and a flip flop to get one pulse per rotation clocking in

then decoding and working out the rpm is much easier
from just 8 or 16 bit input to the pic

something like a /10 counter to prescale it
basicaly its a frequency counter

so look around for sources like that

use an output from the pic to refresh the counter {gate it}

 

[newelltech]

bike speedo picaxe

Ok, well here are some approaches.

1. Buy the floating point chip for the pixaxe - it's $15. This will solve all your problems - it's fast and accurate. You'll have to deal with floating point numbers, but that's easy.

2. Use the distributed method. Instead of 3,000,000 / count use this:
Step 1: Calculate r1 = 60,000/count (a 16 bit integer is 65536 so no overflow)
Step 2: Calculate RPM = r1 * 50
The downside to this is that your resolution is +/- 50 RPM
Keep in mind, I'm not familiar with the PICAXE, but I'm assuming it has 16 bit arithmetic. If not let me know.

3. Use asm and write your own 24 bit divide routine. This may sound daunting but in a quick search, I found a lot of sample code for 24 bit (which is all you need) and 32 bit (you could use this as is too) divide routines for PICs. This would also be a great learning experience.

4. Other tricks with BASIC - I have some ideas that would be fast enough (in BASIC) but don't have time right now to go through the math. I'm assuming that the divide routine you mentioned was an interative subtraction done in BASIC and that's why it's too slow.


Dennis

Added after 55 minutes:

More -

Out of curiosity, I looked up the picaxe BASIC instructions and discovered that it supports the modulo operator. So I think this will solve your problem in BASIC.

Here's what you do:
Calculate the RPM as before
RPM = (60000/count)*50

Then calculate the TrimRPM that you will add to the RPM above, as follows
Step 1: Calculate the Remainder = 60000 % count (this is the modulo operator)
Step 2: Calculate r2 = Remainder * 50 (you'll have to add some code to make sure this doesn't overflow)
Step 3: Calculate TrimRPM = r2/count (this should give you a trim of 0 to 50)
Step 4: Calculate Final RPM = RPM + TrimRPM

I think this will get you within 1 RPM at all RPM's and should be very fast

I'm making the assumption that the BASIC divide command does not round which is a good assumption I think.
You will need to go through each calculation and add checks/or verify that there is no overflow.
You will need to make sure it works - this is just off the top of my head and I haven't done any checking so I could have screwed up something (like before :|) but in theory it should work.

Post your code and I'll check it out.

Dennis

Added after 16 minutes:

use an external counter ic using edge trigger clock
and a flip flop to get one pulse per rotation clocking in

then decoding and working out the rpm is much easier
from just 8 or 16 bit input to the pic

something like a /10 counter to prescale it
basicaly its a frequency counter

so look around for sources like that

use an output from the pic to refresh the counter {gate it}

Here's the problem with using a frequency counter:
He needs an update every 1/2 sec. So adding a flip-flop would give 1 pulse per rev. So at 3600 RPM there would be 60 pulses per sec. Gating for 1/2 sec yields 30 counts to represent 3600 RPM so his resolution would be +/- 120 RPM.
Adding a prescaler would make it 10 times worse and it would be unusable.
He's looking for a resolution of 10 RPM, preferably 1 RPM.

 

[rexlan]

picaxe tacho

Ok, well here are some approaches.


Dennis

Added after 55 minutes:

More -

Out of curiosity, I looked up the picaxe BASIC instructions and discovered that it supports the modulo operator. So I think this will solve your problem in BASIC.

Here's what you do:
Calculate the RPM as before
RPM = (60000/count)*50

Then calculate the TrimRPM that you will add to the RPM above, as follows
Step 1: Calculate the Remainder = 60000 % count (this is the modulo operator)
Step 2: Calculate r2 = Remainder * 50 (you'll have to add some code to make sure this doesn't overflow)
Step 3: Calculate TrimRPM = r2/count (this should give you a trim of 0 to 50)
Step 4: Calculate Final RPM = RPM + TrimRPM

I think this will get you within 1 RPM at all RPM's and should be very fast

I'm making the assumption that the BASIC divide command does not round which is a good assumption I think.
You will need to go through each calculation and add checks/or verify that there is no overflow.
You will need to make sure it works - this is just off the top of my head and I haven't done any checking so I could have screwed up something (like before :|) but in theory it should work.

Post your code and I'll check it out.

Dennis

Dennis that is pretty brilliant I'd say. I will work with that tomorrow and try to get something up. I worked on Jeremy's earlier and it is very close indeed. Bigg3st problem is that I don't understand the math. You obviously do so bear with me a bit.

I will also try to send you a PM tomorrow.

Rex

 

[rexlan]

picaxe 8m

Mornin:

I set this up with some crude variables and a loop to see it run on the simulator. What I found is that the Balance variable will overflow with several mid range caculations. If the count is 1630 for instance. Not sure how to address or fix this. Here is the code so far.

I do have another routine that works; however, it is not returning quite the accuracy I am lookg for. This one of yours Dennis appears to be spot on.

Symbol StartRpm = W1
Symbol Counter = W2
Symbol Balance = W3
Symbol Trim = W4
Symbol TrimRpm = B10
Symbol RPM = W6

GetCount:
     for W0 = 400 to 6500 step 30
	W2 = 0
    for B11 = 0 to 9
  W2 = W2 + W0
	Next B11
W2 = W2 / 10

Goto Calc

Calc:

StartRPM = 60000 / Counter * 50
Balance = 60000 % Counter
Trim = Balance * 50
TrimRpm = Trim / Counter
RPM = TrimRpm + StartRpm

Next W0

 

[newelltech]

picaxe rev limiter

So you didn't believe me when I said

"You will need to go through each calculation and add checks/or verify that there is no overflow. "

I think you'll find that Balance doesn't overflow - it is always less than 60000. But the next calc for Trim is the culprit. This is easy to fix and can be done with a simple change that gives you 10 RPM resolution or a little more complicated one that keeps 1-2 RPM resolution. I'll give you the more accurate one:
************************************
StartRPM = 60000 / Counter * 50
Balance = 60000 % Counter

;Select range
if Counter < 1000 then Range1000
if Counter < 5000 then Range5000
if Counter < 10000 then Range10000
if Counter < 50000 then Range50000
;if you get here you have low rpm and you need to add code for what you want it to do. The next line is just an example
RPM = 0;
goto End:

Range1000:
Trim = Balance*50
TrimRPM=Trim/Counter
goto CalcRPM

Range5000:
Trim = Balance*10
TrimRPM=Trim/(Counter/5)
goto CalcRPM

Range10000:
Trim = Balance*5
TrimRPM=Trim/(Counter/10)
goto CalcRPM

range50000:
Trim = Balance
TrimRPM=Trim/(Counter/50)
goto CalcRPM


CalcRPM:
RPM = TrimRpm + StartRpm

End:
; do your controls here

*****************************************
I think this will work ok, but you'll need to test it out.
Be careful with the TrimRPM calc - you want to make sure that the Counter gets divided first. I don't know if your BASIC supports the parentheses I've shown. If not you'll have to do the calc first - Counter = Counter/10 for example
Also there is still more work to do that I'll leave to you.
You need to handle the end points. For example at a count of 50000 the RPM is 60. The ranges only go up to 50000 so you need to do something like force to count to 49999 if it goes over or force the RPM to 0:
But you must fix this before testing it.
It looks like you're almost there!
Regards,
Dennis

 

[rexlan]

picaxe pulse rate

Thanks Dennis ..... I'll work more on that and post back.

I have another "item" we can work on too. With this I was thinking about using the larger chip and putting a speedometer in it as well. I’ve use about 40% of the space in this little 8 pin version.

I am wondering if we can use the same RPM information in this specific application to calculate the Speed. I have the final drive ratios for this car and all 850 of them are identical ... "spec" class.

I sent a PM ... ??

 

[rexlan]

picaxe rpm counter

OK ... I seem to have this worked out and it "appears" to be working. The next issue is to clean it up so I can reclaim my symbols. I have used them all but I can get one back without the test loop. Here is the code so far and it is working well. Turns on the LED and writes the info to the LCD.

Next issue is to caculate the Speed in MPH from the RPM. I have the final gear ratios so I will work on that.

Symbol RPM_Total = W0
Symbol New_Count = W1
Symbol Counter = W2
Symbol Balance = W3
Symbol Trim = W4
Symbol TrimRpm = B10
Symbol RPM = W6
Output 1

	;Itnt:

Pause 1000
serout 4, N2400, (254,1)
pause 200
serout 4, N2400,(254,1,"   Engine RPM")

	Main:

   for W2 = 301 to 6500 step 50
        for B11 = 0 to 4
        ;PULSIN 2 ,1 , W2
  
	CalcRPM:

RPM = 60000 / Counter * 50
Balance = 60000 // Counter
if Balance = 0 then Quick
  


   ;Select range 
if Counter < 1000 then Range1000 
if Counter < 5000 then Range5000 
if Counter < 10000 then Range10000 
if Counter < 50000 then Range50000 

 Range1000: 
Trim = Balance*50 
TrimRPM=Trim / Counter
RPM = TrimRpm + Rpm
  goto Accumulate 

 Range5000: 
Trim = Balance*10 
New_Count = Counter / 5
TrimRPM=Trim / New_Count 
RPM = TrimRpm + Rpm
  goto Accumulate 

 Range10000: 
Trim = Balance*5
New_count = Counter / 10
TrimRPM=Trim / New_Count  
RPM = TrimRpm + Rpm
  goto Accumulate 

 Range50000: 
Trim = Balance
New_Count = Counter / 50 
TrimRPM=Trim / New_Count
RPM = TrimRpm + Rpm
  goto Accumulate 
  
  
	Quick:

RPM = Rpm

	Accumulate:

RPM_Total = RPM_Total + RPM


	Next B11

GetAverage:

RPM = RPM_Total / 5

	;Turn on Contrtoller:

IF RPM > 2990 then Control_ON
IF RPM < 3050 then Control_OFF


	Display:

;serout 4, N2400, (254,1)
;pause 10
;serout 4, N2400,(254,1,"   Engine RPM")
pause 100
serout 4, N2400,(254,198,#W6,"   ")
pause 100

RPM_Total = 0
Pause 100



   Next W2

   GOTO Main


	Control_ON:
High 1
GOTO Display


	Control_OFF:
Low 1
GOTO Display

 

[rexlan]

edis8 rpm module

Update:

Interesting find yesterday. I built a proto unit with the diode interface and it works perfectly.

PROBLEM however is that it is off by a factor of two!! This unit reads 2x the RPM so this "probably" means that my formula (RPM=3,000,000/Count) is wrong.

This also means that Dennis has now made a significant mistake. That being that he thought he had originally made one when in fact he had not!

Dennis can you explain this pulse thing to me AGAIN? You can see the scope pictures that I have. What I am not understanding is if the pulses are ignition firing (I assume they are) then should we have divided them by 2 since there are two firings per revolution (being only one firing per cylinder every two revolutions).

Confusing

 

[newelltech]

plot + picaxe

I'm not conceding a mistake. Not yet. Still possible bug just a 'cautionary flag' at this point.

So distributor firing is 2 pulses per sec. and ignition firing would be 1 pulse every other sec (1/4) or 0.5 pulses per sec. but it would have the same pulse width (I think - depends on your ignition system) or a 50% duty cycle. So if you were connected to an ignition wire, it would show either the same or 4x RPM.

I think something else is going on.
Is it possible that your uC clock is 2x?
Are the scope pics on your website taken with the prototype connected? If not, can you re-take them?
Can you hook up a pulse generator to test the prototype?

 

[rexlan]

calculate the rpm of the car with a waveform

I'm not conceding a mistake. Not yet. Still possible bug just a 'cautionary flag' at this point.

So distributor firing is 2 pulses per sec. and ignition firing would be 1 pulse every other sec (1/4) or 0.5 pulses per sec. but it would have the same pulse width (I think - depends on your ignition system) or a 50% duty cycle. So if you were connected to an ignition wire, it would show either the same or 4x RPM.

I think something else is going on.
Is it possible that your uC clock is 2x?
Are the scope pics on your website taken with the prototype connected? If not, can you re-take them?
Can you hook up a pulse generator to test the prototype?

Well .... it turns out Dennis that you are probably correct as usual!

Here is what I have found now. If I connect to the nasty tach line it is correct. If I connect to the nice PIP line (those are the scope pictures) it is wrong by a factor of 2.

It looks like the pulse is on and off equally so 50% duty cycle. However, I am not thinking that this pulse is for every ignition firing so it needs to be divided by two.

This Ford EDIS (Electronic Discharge Ignition System) has one coil for two cylinders and uses what is called wasted spark. There are no points and no distributor. The same coil is fired for two cylinders that are 180 degrees apart so I "think" there would actually be one ignition event per revolution instead of one event for every two revolutions (in this system).

I talked to Perry Edwards who is one of the leading authorities on this system. This is why I was tricked I think:

For an EDIS-8 module, there will be four complete cycles of the PIP waveform for every 360 degrees crankshaft, or thirty-five VR signal cycles (not 36 because of the missing tooth). An EDIS-6 will yield three PIP cycles per every 360-degrees crank, and an EDIS-4 gives two.

Do you agree?

Here is a technical link to the system.
https://www.megamanual.com/ms2/EDIS.htm

 

[newelltech]

exemple programme basic picaxe

Yep, the EDIS fires the plug 2x per cycle. The firing at TDC has no effect - hence wasted spark. Standard ignitions fire once per cycle. So the PIP and SAW signals will both have 2x the pulses which will shorten the pulse width by 1/2 and result in an RPM reading of 2x.
I still don't understand where you were getting the 'nasty tach' signal?
Just for testing, I would add this line at the beginning.
Counter = Counter * 2
Then you don't have to make any other code changes.
You will see a worsening of resolution by a factor of 2 since you have only 1/2 as many counts.

Just an aside:
I don't really get the wasted spark concept. The Squirt box has some kind of processing inside to advance and retard the spark so why can't it remove the wasted spark. Then it could lengthen the real spark to get more firing power.
I can't believe the cost would be increased by much. What do they sell for anyway?
Let's get together an build a better one!

 

[rexlan]

picaxe count examples

The plot thickens:

OK ... this rascal is not working. I put some info and pics up on a page here:
**broken link removed**

I also mention that the digital tach in the car reads accurately on either connection line.

With Dennis's code I get this result with this board:

PULSIN = 0 or 1 ..... means that the time is calculated between the rising or falling edge of the pulses. 1 is rising, 0 is falling:

Input connected to the tack line of EDIS:
If PULSIN = 0 then unit reads 1/2 of actual RPM
If PULSIN = 1 then unit reads 2x of actual RPM

If unit connected to PIP line on the EDIS:
Unit reads accurately.


Now with 32 bit math routine:
Does not matter if PULSIN is 1 or 0

If connected to tach line unit reads OK
If unit connected to PIP line unit reads 2x of actual RPM

This makes absolutely no sense to me but I have verified this 20 times!

Dennis please figure this out!.
BTW: I ran out of room with your math (it is more accurate too) in this chip but will use it when I get the 18X parts and add the other features. I only have about 15 bytes left in this one and I need to add some switches and a table.