Imprecavo contro il nuovissimo ordinamento quando Nils 
<n...@cubic.org> ha detto :

> Please - give the software guys all the freedom possible. 

I'm the one who pay for the board, the one that makes all the solderings 
ant the software guy :) ... oh yes, I'm also the customer!

-- 
Nuno on zx-6r '04 & CRe 250 '99 working in progress...
La riforma della scuola è pronta
dieci casse Marshall dentro ogni aula
*** www.gladio.org ***

Imprecavo contro il nuovissimo ordinamento quando dalai lamah 
<a...@hotmail.com> ha detto :

> No. Solution 2 is sometimes the lesser evil (for example when you have 
to
> pick the RPMs directly from the spark cable) but when you have a phonic
> wheel to use, there is no reason to do that.
> 

I've got a phonic wheel but it would not be "portable" to use such 
solution. I'd use instead the signal that goes to the ECU and an hall 
sensor. In this way I'd have to move just the sensor every time I change 
engine. Re-calibration would be done via software changing the number of 
cylinders and strokes of engine. Knowing the number of teeth of every 
phonic wheel is somehow harder.

-- 
Nuno on zx-6r '04 & CRe 250 '99 working in progress...
La riforma della scuola è pronta
dieci casse Marshall dentro ogni aula
*** www.gladio.org ***

N1 wrote:
>
>> You need to check your arithmetic -- 18000 RPM is 300 Hz.
>> for a 1 pulse per revolution signal.
>>
> 
> 18000(rpm) / 60 (seconds) * 4 (number of cylinders) / 2 (revolutions for a 
> spark)
> 

Increasing the number of cylinders doesn't make the shaft turn faster or 
slower. Neither does the presence or absence of a spark.

JS

Imprecavo contro il nuovissimo ordinamento quando JSprocket 
<J...@internept.org> ha detto :

> Increasing the number of cylinders doesn't make the shaft turn faster or 
> slower. Neither does the presence or absence of a spark.
> 

As I sayd to Dalai Lamah it's easier to count the sparks than the 
revolution of the crankshaft. from the sparks you can understand how many 
rpm is doing the crankshaft

-- 
Nuno on zx-6r '04 & CRe 250 '99 working in progress...
La riforma della scuola è pronta
dieci casse Marshall dentro ogni aula
*** www.gladio.org ***

rickman wrote:
> Joerg wrote:
>> Tim Wescott wrote:
>>> N1 wrote:
>>>> I'm working on a data acquisition system for byke/car engine.
>>>> I'm trying to figure out which would be the best way to count RPM and
>>>> I've thought to two different ways:
>>>> 1- using an interrupt routine attached to a digital input to count,
>>>> say, 10 revolution and then look how much time passed between the
>>>> first and the tenth to figure out ho many would they be in a minute.
>>>> 2- using an IC to transform frequency to voltage and then read it from
>>>> an analog input.
>>>>
>>>> I think that solution 2 is better and cleaner but I'd like to keep
>>>> everything on the same board. On the other side I don't know if the
>>>> solution 1 would be accurate enough.
>>>>
>>>> Max value would be 18000rpm that is 600hz for a 4 cylinder, 4 stroke
>>>> engine...pretty low for most MCU. It'd be ok to have a resolution of
>>>> 100rpm (3HZ).
>>> If your processor has a timer capture function, run the crank sensor to
>>> the timer capture.  If your processor doesn't have a timer capture
>>> function then consider another processor, or the cost of implementing a
>>> timer capture in external logic.
>>>
>> Yes, I'd second that. But it may need a lot of averaging since the
>> trigger point will flop around a bit in the usual engine environment.
> 
> I'm not sure why people are suggesting that the period between pulses
> be measured and then perform a divide operation to calculate the RPM.
> If you only want accuracy to 100 RPM, it should be a simple matter to
> count the number of pulses that happen in 1/100th of a minute or 0.6
> seconds.  This count will be the number of RPM in hundreds.  If you
> count for 1.2 seconds you will get the measurement accurate to 50 RPM
> which is typically about the level of accuracy used in RPM readings,
> especially at the low end(750 or 1250 RPM for example).
> 
> This can even be done in a very, very simple MCU without a counter
> function.  With a max pulse rate of 300 Hz, an interrupt could be used
> or even polling!  A simple timer loop can count machine cycles to
> establish the time base and polling the pulse input in that same loop
> will give you the pulse count.  If you want to get fancy, you can even
> perform debounce or spike rejection to help exclude noise.  A hardware
> counter would have a lot more difficulty with that.
> 
> A very small and simple processor can do this job easily and
> cheaply.
> 

Now how would that timer loop count precise machine cycles?

-- 
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

rickman wrote:
> Joerg wrote:
>> Tim Wescott wrote:
>>> N1 wrote:
>>>> I'm working on a data acquisition system for byke/car engine.
>>>> I'm trying to figure out which would be the best way to count RPM and
>>>> I've thought to two different ways:
>>>> 1- using an interrupt routine attached to a digital input to count,
>>>> say, 10 revolution and then look how much time passed between the
>>>> first and the tenth to figure out ho many would they be in a minute.
>>>> 2- using an IC to transform frequency to voltage and then read it from
>>>> an analog input.
>>>>
>>>> I think that solution 2 is better and cleaner but I'd like to keep
>>>> everything on the same board. On the other side I don't know if the
>>>> solution 1 would be accurate enough.
>>>>
>>>> Max value would be 18000rpm that is 600hz for a 4 cylinder, 4 stroke
>>>> engine...pretty low for most MCU. It'd be ok to have a resolution of
>>>> 100rpm (3HZ).
>>> If your processor has a timer capture function, run the crank sensor to
>>> the timer capture.  If your processor doesn't have a timer capture
>>> function then consider another processor, or the cost of implementing a
>>> timer capture in external logic.
>>>
>> Yes, I'd second that. But it may need a lot of averaging since the
>> trigger point will flop around a bit in the usual engine environment.
> 
> I'm not sure why people are suggesting that the period between pulses
> be measured and then perform a divide operation to calculate the RPM.
> If you only want accuracy to 100 RPM, it should be a simple matter to
> count the number of pulses that happen in 1/100th of a minute or 0.6
> seconds.  This count will be the number of RPM in hundreds.  If you
> count for 1.2 seconds you will get the measurement accurate to 50 RPM
> which is typically about the level of accuracy used in RPM readings,
> especially at the low end(750 or 1250 RPM for example).
> 
> This can even be done in a very, very simple MCU without a counter
> function.  With a max pulse rate of 300 Hz, an interrupt could be used
> or even polling!  A simple timer loop can count machine cycles to
> establish the time base and polling the pulse input in that same loop
> will give you the pulse count.  If you want to get fancy, you can even
> perform debounce or spike rejection to help exclude noise.  A hardware
> counter would have a lot more difficulty with that.
> 
> A very small and simple processor can do this job easily and
> cheaply.
> 
> Rick

600ms wouldn't even be acceptable for a tachometer, it _certainly_ 
wouldn't be acceptable for a tachometer so cheesy it could only show 
increments of 100RPM, and it just plain wouldn't work at all for a 
governor application or an electronic ignition system.

Hence the suggestion that gives an answer with (hopefully) a usefully 
low delay.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" gives you just what it says.
See details at http://www.wescottdesign.com/actfes/actfes.html

N1 <i...@me.it> writes:
> JSprocket <J...@internept.org> ha detto :
> 
> > Increasing the number of cylinders doesn't make the shaft turn faster or 
> > slower. Neither does the presence or absence of a spark.
> 
> As I sayd to Dalai Lamah it's easier to count the sparks than the 
> revolution of the crankshaft. from the sparks you can understand how many 
> rpm is doing the crankshaft

You're going to couple to /all/ the spark plug wires?!?
Inductive coupling to even one is going to be tricky.

N1 wrote:
> Imprecavo contro il nuovissimo ordinamento quando Nils 
> <n...@cubic.org> ha detto :
> 
>> Please - give the software guys all the freedom possible. 
> 
> I'm the one who pay for the board, the one that makes all the solderings 
> ant the software guy :) ... oh yes, I'm also the customer!
> 

Then do yourself one favor: Get a good consultant to check things out 
before deciding on a final circuitry. Maybe you can find one locally in 
Italy. I have seen similar designs where mistakes were made and it was 
too late.

For example the signal from the sensor needs to be pre-conditioned. 
Usually it's not enough to just digitize it using a comparator. Someone 
nearby keys the microphone on his radio and ... poof, it starts reading 
ghibberish. Ideally there should be lowpass, highpass, SW-adjustable 
gain and threshold, hysteresis (preferably also under SW control) and so 
on. Plus EMI filtering which is not an easy job at all in automotive.

-- 
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

On Tue, 5 Aug 2008 09:17:59 PST, Everett M. Greene <m...@mojaveg.lsan.mdsg-pacwest.com> wrote:
>N1 <i...@me.it> writes:
>> JSprocket <J...@internept.org> ha detto :
>> 
>> > Increasing the number of cylinders doesn't make the shaft turn faster or 
>> > slower. Neither does the presence or absence of a spark.
>> 
>> As I sayd to Dalai Lamah it's easier to count the sparks than the 
>> revolution of the crankshaft. from the sparks you can understand how many 
>> rpm is doing the crankshaft

>You're going to couple to /all/ the spark plug wires?!?
>Inductive coupling to even one is going to be tricky.

Maybe the engine uses a distributor and a single coil?

N1 wrote:

> I'm working on a data acquisition system for byke/car engine.
> I'm trying to figure out which would be the best way to count RPM and
> I've thought to two different ways:
> 1- using an interrupt routine attached to a digital input to count, say,
> 10 revolution and then look how much time passed between the first and
> the tenth to figure out ho many would they be in a minute.
> 2- using an IC to transform frequency to voltage and then read it from an
> analog input.
>
> I think that solution 2 is better and cleaner but I'd like to keep
> everything on the same board. On the other side I don't know if the
> solution 1 would be accurate enough.
>
> Max value would be 18000rpm that is 600hz for a 4 cylinder, 4 stroke
> engine...pretty low for most MCU. It'd be ok to have a resolution of
> 100rpm (3HZ).

Use period to measure low speed RPM and frequency to measure
high speed RPM. That way you will get response and accuracy that
you will need.

Most of the current engine controllers now are measuring the engine
speed from the crank sensor 60 -2 or 36 -1 (60 index markers with
2 gaps for synching)

At low speeds the acceleration in an engine on firing can be impressive.

Regards,

--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com
w...@bytecraft.com