rexlan
Junior Member level 3
- Joined
- Aug 20, 2006
- Messages
- 31
- Helped
- 0
- Reputation
- 0
- Reaction score
- 0
- Trophy points
- 1,286
- Location
- USA -- Florida
- Activity points
- 1,547
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
IanP said: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 ..
newelltech said: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.
newelltech said: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.
Here's the problem with using a frequency counter:VSMVDD said: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 said: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
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
"You will need to go through each calculation and add checks/or verify that there is no overflow. "
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
Well .... it turns out Dennis that you are probably correct as usual!newelltech said: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?
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.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?