Rpm measurement

[ginantonik]

am at a dangerous stage of picaxe'ing - some knowledge but not enough....

How do i go about counting a pulse and relating it to time (then showing on an LCD/OEL screen) - i.e. 1000 pulses/min - for example

I thought i can use the 'count'statment somehow - but i cannot acheive a fast enough update on an LCD screen - it updates at the 'sampling period'.

Any advise please, before it drives me mad..?

 

[nick12ab]

but i cannot acheive a fast enough update on an LCD screen - it updates at the 'sampling period'.

What's the maximum number of pulses you will expect to receive in the "sampling period", whatever that is?

What is the duty cycle of these pulses?

Currently without having enough information, I will recommend that you look at this thread: PICAXE Computer Fan Controller with speed and temperature measurement. The PICAXE Computer Fan Controller has successfully measured a 5500 RPM fan and it could even go higher - I didn't have a faster fan to test with.

EDIT: In the PICAXE Computer Fan Controller, the Winstar HD44780-compatible OLED was driven using the parallel interface. This is probably important for this application.

 

[geoff07]

You might want to distinguish between the rotational measurement and the display interval. It is not easy to read a display that is updating very quickly. One approach would be to have a main program that updates the display every so often to suit the observer, limited by the data rate and volume of data you want to transfer - and an interrupt routine that detects the pulses and increases a counter, for example.

A lot depends on your required accuracy, rotational speed and method of detection. 1000 rpm is ~17 pps, easily counted by an interrupt that increases the count by one each time and resets each second, with the display updated say once per second. Or you could do a rolling average over several seconds.

As an example of a similar apllication, my garage door controller has a stall detector using a watchdog timer that counts down to zero, unless it is reset by a pulse from the motor (received by interrupt). That works at about 10pps and has plenty of time for other processing, running at 32MHz, so 17pps should be no problem, and you could always use a chip at 64MHz if what you were doing was too challenging for 32MHz.

 

[hippy]

I thought i can use the 'count' statment somehow - but i cannot acheive a fast enough update on an LCD screen - it updates at the 'sampling period'.

It could be possible to reduce the sampling period for COUNT and then determine the actual RPM by simple multiplication.

Another trick is to measure the time per revolution ( or part revolution ) with PULSIN and calculate RPM from that though the maths can be more complicated.

More advanced and also with more complicated maths, you could count the number of reference clock ticks per revolution ( or part revolution ) and again calculate from that.

What range of RPM's you are looking at and with what accuracy you need to display at will give an idea of which is the best mechanism to use.

 

[ginantonik]

5000 - 10000 rpm - i will have a look at this thread - thanks

 

[ginantonik]

display interval is the problem i guess - its for a vehicle rev-counter - so the rpm can change quickly all the time, a 1 sec update may be too slow - but this is the bit i am struggling with.
rpm range will be 500 - 10,000 rpm
accuracy +/-50 rpm or some such.

 

[ginantonik]

If i reduce COUNT for 1 sec then *60 to counts/min - i can get it to work but 1 sec update is too slow.
Will try COUNT for 0.1 sec then *600 and see how it looks - this seems to be easiest (just need to fiddle with my 'pulse generator' to give higher pps)

Will also have a play with second idea.

You have lost me with third option.........

 

[ginantonik]

had a look at the 'input' by deconstructing the code and it seems that it is similar to my 1st attempt using COUNT function - i will have a play and reduce sample period and see if this will do what i want.

Thanking eveyone for suggestions......

 

[AllyCat]

Hi,

Perhaps it's better to consider those values in revs per second, i.e. about 8 - 160 revs/sec and +/- less than 1 rev/sec. Thus you can't count the revs for much less than a second (but using two ignition pulses per rev. could help).

An alternative method discussed many times on this forum is to measure the time (period) between pulses (e.g. using PULSIN) and let the PICaxe calculate the frequency (rpm) by division. Certainly better below about 1,000 rpm and should be possible up to 10,000 rpm.

Cheers, Alan.

 

[hippy]

If you measure T as time of a revolution in microseconds -

RPM = 60 000 000 / T

If you measure P as the length of a PULSIN in 10us units -

RPM = 6 000 000 / P

Calculating '6 000 000 / P' is not trivial on a PICAXE but '60 000 / P' is and then you can multiply (divide?) by 100 and the result may be good enough. If not you just have to put a bit of effort in to do the calculation properly and there are examples for doing 32-bit maths on the forum.

As you are measuring a single revolution you can notionally update your display every revolution. You will be more limited to the time it takes to process the reading and get it to the display.

 

[ginantonik]

Hmmmm - thanks Allycat & hippy + the rest of you.

Fog is starting to clear - latest attempt (using COUNT) with 'system' on my lap (while typing) shows some promise - need to get to school and make a better test rig to produce the pulses...

Now got a better understanding of using PULSIN - will have a go at that as well.
One big advantage of electronics is that once the mechanical side is sorted - only a case of sitting in the warm and playing with computor......

 

[inglewoodpete]

Just a thought but there is little point in updating the display more than 3 times a second: you can't read the changing speed with a faster update rate. My experience was with digital tachometer I built for my car in my youth, using discrete chips.

 

[RexLan]

IMO I believe the only way it will work is with the use of PULSIN. Count at higher RPM will have teriffic errors.

IMO you will also need to use a rolling average or your data will be all over the chart.

IMO if you update a display more than once every second it will be unreadable and look like flickering hash.

IMO you will also need a very good circuit to give a precisely defined trigger edge and this will become more important at higher RPM. A perfect SW pulse generator is not the same as you will receive from the vehicle.

And finally, IMO trying for 10,000 RPM will be difficult ... you will run out of time I believe to capture it but it will be close.

 

[hippy]

And finally, IMO trying for 10,000 RPM will be difficult ... you will run out of time I believe to capture it but it will be close.

Not sure that's always true. RPM is rather deceptive, feels fast and difficult to deal with, but 10,000 RPM is only 167 RPS, so about 6ms per revolution, which is quite pedestrian even for a PICAXE.

In some respects it's lower RPM which cause problems. 100 RPM is just 1.7 RPS, 590ms per revolution and you are then limited to a display update of the same rate.

 

[RexLan]

I'm not that good on the math but we had some difficulty with overflow at the lower RPMs and 366 was pushing it for our routine. We (Jeremy) also had to break the code initially to decide if it was a "fast" sample or "slow" sample and then apply the appropriate instructions. The problem is that one sample will produce random garbage so you will need, IMO, at least 4-6 samples to get an accurate output. Using a rolling average, however, you only need one sample to refresh the average and it is quite accurate.

Using the fresh average as a rev-limiter is OK, but not to update a display. Once/sec is about max if you want to actually read it. Once/2-3 seconds is better.

 

[hippy]

We (Jeremy) also had to break the code initially to decide if it was a "fast" sample or "slow" sample and then apply the appropriate instructions.

That makes sense. At fast RPM one can COUNT in a fairly short period and multiply up where at low RPM you would need a long COUNT period. At slow RPM a single PULSIN will be accurate for a single pulse but at faster RPM the pulses become shorter and PULSIN results may be get less accurate.

 

[Goeytex]

IMO I believe the only way it will work is with the use of PULSIN. Count at higher RPM will have teriffic errors.

I have had good success with Pulsin for both a rev limiter and an ignition system.

IMO you will also need to use a rolling average or your data will be all over the chart.

I have not found averaging to be necessary when using pulsin with a good Honeywell Hall sensor. I get consistent readings without having to do any averaging. RPM can be computed and action taken once per revolution.

IMO if you update a display more than once every second it will be unreadable and look like flickering hash.

That depends upon the particular display and the link speed between the microcontroller and the display. With a cheap budget display, I agree. However a better display can be refreshed much faster. I have had good success with 4D systems displays. But faster than 1 update per second is probably not necessary anyway.

IMO you will also need a very good circuit to give a precisely defined trigger edge and this will become more important at higher RPM. A perfect SW pulse generator is not the same as you will receive from the vehicle.

The output of the hall sensor is very clean with well defined edges and works fine up to and beyond 10,000 rpm . The rise & fall times can be improved by conditioning the pulse with something like a 74hC14 Schmitt Inverter. Also the Picaxe input can be configured as a Schmitt input. However, I have not found either absolutely necessary for accurate and repeatable results.

And finally, IMO trying for 10,000 RPM will be difficult ... you will run out of time I believe to capture it but it will be close.

10,000 RPM can easily be read. It depends upon the upon the amount of time the signal or signals are active during a single revolution. In a rev limiter application I did for a 2 cylinder racing engine, a magnet passes the sensor once per revolution. The magnet takes up approximately 36 degrees on the flywheel. At 10,000 rpm ONE revolution takes 6ms. The sensor generates a pulse of about 600 microseconds. With the Picaxe operating at 8 Mhz Pulsin will read a value of ~120. At 16 MHz pulsin reads reads ~240. At 32 Mhz, it will be 480. The problem with Pulsin is that when optimized for high RPM, it will time out at lower RPM.

 

[ginantonik]

This is all very interesting and confirms my original problems - particularly at low rpms.........(I'm pleased to discover that i am not as thick as i thought!)

Regarding signal conditioning this is something that i expect problems with as an o/scope test a few months ago indicated serious 'ringing' of the trigger pulse or a wire wrapped around the HT lead.
Currently i am using a simple 08 circuit as a 'pulse generator' so i can easily play around with pulse speed and duration, without getting into any mechanics (though i intend to test the system using a CDi system in a lathe).

The display traditionally would be a meter/needle type (which usefully would give some averaging and damping) however my test work today has used an LCD display - which really needs less than 1 second update to be any use when checking a varying engine speed on the DYNO.

Eventually i will use a circular/linear LED display when actually racing - I have wondered if a multi LED display is used would this make things easier?

 

[Goeytex]

Regarding signal conditioning this is something that i expect problems with as an o/scope test a few months ago indicated serious 'ringing' of the trigger pulse or a wire wrapped around the HT lead.

Getting a signal from a wire wrapped around a HT wire tends to be problematic. Even after necessary conditioning, the width of signal pulse will not be proportional to engine RPM, but instead represents the spark duration. This means that in a wasted spark ignition system there will be two pulses per revolution and if using Pulsin the time between pulses must be measured. This means higher Pulsin values and pulsin time outs at a higher RPM threshold. A Hall or optical sensor would be a much better choice IMO.

 

[bluejets]

You could use a 555 to clean up your wire wrap signal quite easily. Just a thought.

 

[ginantonik]

Bluejets - that was the plan.

The trigger pulse to the cdi/coil is only ~1-2volt so this can also be used - again cleaned up, although i understand a currect limiting resistor and <5V vener-diode can be used.

Using the HT or Cdi/Coil pulse means that i to have use some method of "counting during a time period" (COUNT) as opposed to "measuring time for sensor to be open/closed" (PULSIN).

Decided LED output instead of LCD is best way to go - lighting at various 'trigger points' may solve display update problem - will get one of my students to have a go, using the 08M as my 'pulse generator' coupled to a spare 20M2 to light some LEDs and see what happens .... the maths look too easy using COUNT ?

 

[bluejets]

Well, as far as that goes, the 555 could do most of the operations such as cleaning up the input, giving an average ramp output then you could use the micro to drive the LCD.
Just that sometimes the micro is not the be-all-end-all.

 

[ginantonik]

Yes i know - there are various frequency/current converter circuits out there often using the LM2917 after a 555 - but to be honest i have never been able to get one to work with any degree of reliability or accuracy - hencing going digital.

ironically my last test using an 18M2 to switch LED's on at a given input COUNT - is basically a 'digital' LM2917 - so i do seem to be going backwards to an Analogue system.

This project started as something for a student, modified by me for a permanent simulation/display - which i now want to use in a practical manner on my Enduro m/c's.
Anyway - back to test work and will report any positive results.......