Need math help with tachometer that calculates rpm w/1 cycle.

I get the impression that you did not understand input capture.

What’s the TOP value of your counter? Where does it reside?

Where do you reset the counter for the next reading?
(Hint: counter is not “period”)

Use volatile multibyte variables with atomic read.

If you reveal what you expect to get, and how you believe that you can get it, we can start learning basic timer operations.

This is a project that I want to share with a large number of
watercraft enthusiasts from a blog post. There is a large number
of people around the world that are still riding 2-stroke Kawasaki
Jet Ski's, Yamaha Wave Runner's, and Sea Doo's, and I want to
help them prevent engine failures.

A tachometer is a good indicator that the jet pump and engine
is set up to work together. For reliability, it is important to know
where the engine makes peak horsepower (HP) and that the jet pump
is properly set-up to allow the engine to rev a few hundred rpms
beyond peak HP.

For example, if your stock engine with an after market exhaust makes
peak HP @ 6,500 rpm, the pump's impeller will load down the engine
at some point and act like a rev limiter. There were many impellers
sold that will load an engine down hard and prevent the engine from
exceeding 5500rpm, and that is the beginning of an engine that may
fail on a wide open throttle run.

But lets assume you have the correct impeller and the engine will rev
to 6600rpm, and you decide to have the engine modified to make more
HP at a higher rpm. Often cylinder porting will change where the engine
makes peak HP to either 6800rpm or 7200rpm.

Each set-up will increase the HP, but the 7200rpm engine will require a
smaller impeller so the engine will rev beyond 7200 by at least one or
two hundred rpm.

Again a tachometer is the first step to a reliable engine.

Most tachometers that are commonly available have a refresh rate that
is too slow. Good tachometers can cost \$200.

I want to share a blog post on a PWC site that explains how to make a
decent tach, from common parts. Possibly built around a Nano Every.

DrDiettrich:
I get the impression that you did not understand input capture.

I have consumed many data sheets, app-notes, tutorials, forum content,
and video's, but I am beginning to wonder about my comprehension.

DrDiettrich:
What's the TOP value of your counter? Where does it reside?

The TCNTx register is first copied to a low byte, and then a high byte.
If I was programming in assembly, I would need to deal with these
separately. But according to the data sheets, GCC reads these 16 bit
registers, so I do not need to handle them as a high and low byte.

DrDiettrich:
Where do you reset the counter for the next reading?
(Hint: counter is not "period")

TCNTx = 0. Even though this is an example in AVR-130: Set-up and
use of AVR timers, I would have thought it was reset when the interrupt
flag is cleared?

DrDiettrich:
Use volatile multibyte variables with atomic read.

I use global variables and I use volatile to define variables changed by
the interrupt.

than atomic functions

Thanks

Bill M.

I don't know where to start fixing your wrong opinions

The counter is cleared only explicitly or when TOP is reached, depending on the timer mode.

In loop(), all you do is print 'period'. You do this without an atomic read, because an interrupt can occur mid way through the 16 bit access to 'period'. You have to turn interrupts off, make a copy, and turn them on again. It's sort of okay for a test program if you realize this and expect some anomalies, but it won't do for the final code.

aarg:
In loop(), all you do is print 'period'. You do this without an atomic read, because an interrupt can occur mid way through the 16 bit access to 'period'. You have to turn interrupts off, make a copy, and turn them on again. It's sort of okay for a test program if you realize this and expect some anomalies, but it won't do for the final code.

I thought if i had roughly ~26ms before the next interrupt, that there was more than
enough time to output input capture data through the serial connection.

But ever since I divided the program into two separate parts, data collection, and display
data using cli() and sli(), I have started to see improvement in the input capture data.

Bill M.

What update rate and what accuracy do you want? And is the accuracy only necessary at high revs eg 6000+

Snarky wasn't my first thought.

Display accuracy goal is up to 1/10th, no ones column to keep output readable.
But accuracy is something that is easy to talk about, but I believe will take much
more testing to achieve.

Yes accuracy is important at higher rpm ~5000 to 8000.

The desired update rate is in the title. Keep in mind that Hour meter/Tachometers
and most tachometer code is too slow to provide usable data.

Most Arduino code and hour meters are fine for sitting at your desk or inside your
car, but imagine you are riding a motocross bike and you need a tach that provides
useful information in a split second.

Basically I am trying to start small and just write code that: Retrieve input capture
data, calc rpm, display, repeat.

Eventually I would like to Retrieve multiple input capture data, average the ICP data,
calc rpm , display, repeat.

Then add features to the basic program.

Bill M.

JCA34F, DrDiettrich, aarg, blh64 Thank you for your math and programming help!

How do you want to display at high update rate? Quickly jumping digital digits are not readable, also analog bars or needles flicker. That's why an update per rev is nonsense at 6000 rpm (100 Hz), better is an average over e.g. 1/2 second.

DrDiettrich:
better is an average over e.g. 1/2 second.

That would be OK. But I suspect that when it is finished, depending
on what display is used, the refresh rate will be close to 1/2 second.
The goal is for anyone to assemble the tach with parts available on
ebay (it's possible some of these parts may slow down the tach).

One of the reasons I chose the Nano Every is its memory should support
most tft, glcd displays and of course HD44780, and 7 segment displays.
I expect some of these displays to affect the refresh rate.

Another possible benefit from the ATMega4809 is the combination logic
may eliminate a chip and capacitors from a hardware solution to mask coil
ringing.

DrDiettrich:
How do you want to display at high update rate? Quickly jumping digital digits are not readable

I am fortunate to be able to benefit from the experience of others that
is not updating the ones column by leaving as a '0' 6550, 6560, 6570, etc.

The only time the tachometer is useful is at wide open throttle (wot), and
because the jet pump loads down the engine, and acts like a rev limiter
(similar to a propeller on an outboard), the engine rpm at wot tends
to stabilize. So only the one hundreds column and tens column will be
active. Example 7xx0 rpm.

But believe me, looking down and staring at a tachometer @wot doing
50 mph isn't much fun.

There are many other hurdles, that I have possible answers for. For example,
as mentioned in a previous tachometer thread: (1) coil ringing is a problem
when a capacitive pick-up is attached to a spark plug wire. (2) Some aftermarket
ignitions supply a tach wire with a 12v signal, and 2 or 3 signals per revolution.
(3) Many 2-stroke engine run a wasted spark ignition, so a capacitive pick-up
attached to a plug wire may need to measure 1 or 2 sparks.

Other problems that I don't have answers for are water proof buttons, potting,
an enclosure, waterproofing the area around the display, and which displays
will work best in direct sunlight, etc. Perhaps a filter based on the average over
time.

Bill M.

Another problem is recording peak rpm and displaying it after the test ride.
The problem with this feature is that a tach will often record a high rpm caused
by the pump ingesting air (because the ski bounced out of the water), and for
a split second the engine can rev very high. Some sort of limit or software filter
will be required.

.