RPM Resolution verified to ±1RPM 🎯

I’m happy to report that nanoEFI’s RPM resolution is ±1RPM! Verified via oscilloscope.

Here’s what that looks like on the bench tach:

IMG_0913

The readout above is updated at the maximum refresh rate of the OLED display, not slowed or averaged. So what you’re seeing can be taken as a good real-time measurement of engine speed by the ECU while being fed a simulated 3600RPM trigger signal. Nice and stable.

"What is that ~16667 number at the top of the display… and why is it above the RPM count…?"

It’s almost as if that number were actually more important than RPM. Hmm… :face_with_monocle:

Well… that’s because it is more important!

That 16667 at the top line indicates the number of microseconds (μs, millionths of a second) that pass between each complete 360° revolution of the crankshaft at a given engine speed.

The ECU doesn’t actually think in terms of “RPM”. Instead, calculates and schedules injection/spark events based counting the number of microseconds (μs) over the course of each combustion cycle. In this example 3600RPM equals 16667μsPR (microseconds per revolution).

Ultimately, “RPM” is really just the human readable format you see on your display representing engine speed, but isn’t actually used for calculating much of anything internally.

Taking this a step further… even thinking in terms of μs per revolution is its own layer of abstraction. It’s the unit I decided to make standard across all functions in the coding, so it’s easier for me to work on the system. However, the true measurement of time and engine speed is of course, in processor clocks.

In our 328p processor running at 20mhz, one μs equals ~20 CPU clocks. the If the number 16,667μs wasn’t already large enough, multiply that by 20 and you’ll finally be thinking of engine speed on the processor’s terms. So next time your screaming along all-out at WOT and pegging the governor, remember the ECU is quickly counting up to well over 300,000 in the time your relatively slow crankshaft is able to spin just once. :upside_down_face:

Accuracy and Linearity
Accuracy is different than resolution (or precision), as the ECU could be calculating 3601RPM when the engine is actually spinning at 3620. So far, the decoder has been tested accurate to ±1RPM as well, via oscilloscope.

I should note that there is currently some non-linearity at specific and repeatable RPM points with the V-Twin decoder pattern. This doesn’t affect the single-pulse pattern. As additional patterns are added, I’ll post up a chart of what to expect from each.

Challenge
Who wants to figure out the refresh rate of the tachometer OLED screen judging by ONLY the animation below? The video capture was taken on an iPhone 8+ with default video settings. First person to get it right will get rights to flex their own unique forum title “Pixel Perfect:muscle:

Alright, that’s enough hints. Don’t cheat and look it up. Show how you arrived at the answer :wink:

Larger original GIF [here]

2 Likes

29/30 visible scans in 15 seconds, so roughly 2 per second.
I had to look up default video settings on an iphone though. Looks like the 8 and 8+ default to 30 fps.
I have to think this makes a 32 fps display, with the forward roll, but that seems like a weird frame rate for an oled panel, to me.
Alternative is that the iphone is really only doing 28 fps, but that seems like something apple would get some hate over.

So, 32fps, final answer, even though that seems illogical from a device perspective.

1 Like

Alright :+1: Yep, one roll takes exactly 15 frames and each frame of the GIF is 0.04 seconds.

Got it :+1: Shot in 30fps.

Not quite!!

The screen itself actually has no fixed refresh rate. It updates when sent new information from the microcontroller. Totally arbitrary!

:grin:

Are you saying it was a trick question? :upside_down_face:
Or is there something fundamental about the question I failed to grasp? :confounded:

It’s a bit tricky, but not a trick question. I can think of two answers that would be safe to assume without making a test rig to get a definite answer.

Try using a GIF splitter online to see the animation as picture stills frame-by-frame. :shushing_face:

And keep in mind that the roll rate is relative to the FPS of the camera (not the animation). :no_mouth: