I'm trying to develop some code to run a shift light for use in a race car. Once completed this code will be incorporated into a multi-function lap timer etc
The car is 4 cylinder 4 stroke, and I have an RPM interface that outputs a nice clean square wave. Using an oscilloscope I can measure a complete cyle (spark and inter-spark pause) at 3000 rpm of 9.71 ms which by my maths is 3089 rpm so I am happy with the output.
When I capture the same using inputcaptureex (register.timer1=2) at approx 3000 rpm i get a table of values like this :-
5752,13244,5861,13341,5869,13418,5984,13261,5732,13222,5846,13273
the 5nnn figure i think is the move from high to low to trigger the spark and the longer number the pause between sparks although this is a bit of guesswork as you would expect the spark duration to be fairly constant at any rpm but it doesn't appear to be the case.
If I use the 13nnn figure and convert it from ticks to m/s I get 8.9m/s which equates to an rpm of 3340 which is about 10% too high. I realise by doing this i am ignoring the spark portion , but if i add this on i get an rpm of 2304 which is too low.
if anyone has any advice or has done this before I'd appreciate a poiinter as to where i might be going wrong
thanks
Capturing RPM data
Re: Capturing RPM data
Using the average of the data for the six spark cycles shown I compute 2890 RPM.FFMan wrote:f i add this on i get an rpm of 2304 which is too low.
- Don Kinzer
There are 19133 ticks per spark cycle.FFMan wrote:I get an average of all 6 cycles of 19133
Each tick represents 8 CPU cycles or 8/14.7MHz = 542nS.
Therefore, each spark cycle is 19133*542nS = 10.4mS.
Given a 4 cylinder/4 stroke engine, each revolution of the crankshaft comprises 2 spark cycles.
Therefore, 1 revolution is 2 * 10.4mS = 20.8mS --> 2885 RPM
- Don Kinzer
That is the correct value of a tick if you were using Register.TimerSpeed1=1 since the main frequency is 14.7456MHz. However, I believe that you said you were using Register.TimerSpeed1=2 which selects a divide-by-8 prescaler. Consequently, you need to incorporate an 8X factor into your calculations at some point.FFMan wrote:i think i was in error by using the 67.8n/s per tick
- Don Kinzer