RPM display logic check

[Newz2000]

Would someone please check my logic? Any suggestions are also appreciated.<p>My little 16f877a computer will be (among other things) displaying a bargraph of engine RPMs on an LCD display.<p>The processor is running at 20MHz. That means 5,000,000 instructions per second. The LCD will be updated every 200ms.<p>The car is a '67 VW Beetle with 1500cc 4cy engine (slightly modified). The engine's coil creates two sparks for every engine rotation. The engine's valid RPM range for this project is 600 - 6000 RPMs, which equals 20 - 200 sparks per second, or 4 - 40 sparks between LCD updates.<p>A spark from the coil will increment timer 1. The resolution will be 150 RPMs because 1 spark every 200ms = 2.5 engine rotations per second = 150 RPMs. The timer will be reset every 200ms when its value is read and the LCD is updated.<p>Based on earlier suggestions, I'm going to set a timer to trigger an interrupt every 25uSec. That gives me 125 instructions from one interrupt to the next, or 400,000 per second, which matches the speed of the i2c bus I'm using.<p>I figure that the worst case scenario will take 100ms to update the screen (my brother ordered a 4x20). So if 100ms before the screen is due for an update, I grab the counter value, reset it to 0 and then begin the process of updating the display, there will be a maximum lag between the engine's true state and what is displayed on the LCD of 300ms (100ms + 200ms). I'm really curious to know if that will feel "laggy" when you step on the gas. (Of course, it is a VW...) If so I'll have to do 6 updates per second which makes my resolution higher than 150. I thought the engine would do 4 sparks per rotation, since it was a 4cy engine, but we checked it. The rotor turns half way for each engine rotation.<p>For testing purposes, I've created an astable 555 timer circuit with a trimmer that adjust the pulse rate from ~10 Hz to some higher number. It would be interesting if there was some way to make the timer pulse change automaticaly from 10 - 20 - 40 ... 100 Hz and then back down. <p>In addition to the engine RPMs we're also measuring oil temperature and hopefully compression. We'll see how that goes.<p>Thoughts or suggestions are welcome. I'm learning as I go, so if anyone can provide some insight that will help me avoid a snag, go for it. I'm still wating for the LCD and 20MHz crystal to come in the mail so I'm stuck in the "thinking about it" stage for now.

[Gorgon]

Hi Matt,
First of all, you don't need to update the whole display each time, for the speed just write the 5 digits needed. You can update the whole display every 2 to 5 seconds.<p>When measuring the speed, what if you measured the time between 2 or more cycles instead and then compute the speed. This would reduce the lag of the update, and you only need to update the value if it is different from the one last written. If you update with 300ms lag, the meter will 'hang' when you lift the accelerator pedal.<p>When I do LCD screen updates I normally use a master copy in ram that I write to the LCD from. This makes it easy to update the whole LCD once in a while. When updating 'high speed' values I just write the characters in question. You only need to write 1 extra byte to move the cursor to the correct position.<p>And last, don't fall in the trap to erase the LCD before writing the whole screen. It takes time and you will see it blinking.<p>TOK

[rstofer]

My guess is that the RPM reading will be VERY sluggish. One of the ways to improve this is to sample 10 times as often and keep a 10 entry moving average. Throw out the oldest reading and keep the latest 9 plus the new reading. Unfortunately, you just don't get enough counts to make any difference.<p>So, come up with a way to increase the counts. Put a slotted disk on the crankshaft pulley and use a slotted optical sensor. Try to get 10, 20 or more counts per revolution.<p>The other thing to consider: oil temperature doesn't change very often, why update the display if the number isn't different. Focus on updating that portion of the display that is changing quickly.<p>And, LCDs don't change quickly anyway...

[Gorgon]

<blockquote><font size="1" face="Verdana, Helvetica, sans-serif">quote:</font><hr>Originally posted by rstofer:

So, come up with a way to increase the counts. Put a slotted disk on the crankshaft pulley and use a slotted optical sensor. Try to get 10, 20 or more counts per revolution.
<hr></blockquote><p>Oops. <p>If you use the 25us timebase to measure time between pulses you have plenty of timer ticks at 6000 RPM you'll have 200 each revolution.<p>TOK <p>[ August 12, 2005: Message edited by: Gorgon ]</p>

[rstofer]

Actually, this is a very nice solution. Then RPM = 1,200,000 / counts between pulses. But it does take a division.<p>Measuring frequency doesn't require a division but it does need pulse rate to get any kind of resolution.

[rshayes]

The same problem occurs in frequency counters. At frequencies of a few hundred hertz or lower, 4 digit accuracy requires a gate time of 100 seconds or more. The solution is to measure the period between two adjacent pulses and then calculate the frequency from the measured period. Some of the Hewlett-Packard counters did this internally years ago.<p>I would consider measuring the period of four pulses. This would cover one complete revolution of the camshaft. It is possible that the four ignition pulses are not equally spaced, due to mechanical tolerances. That engine is old enough to use mechanical breaker points, and the four lobes on the distributor may not be exactly the same, expecially after nearly 40 years of wear. Counting all the way around to the same cylinder will mean that all of the measurement is done with the same mechanical signal.<p>At 600 RPM, you will get 20 pulses per second. Counting four pulses would allow updating every 200 milliseconds. You will probably see some flicker in the display at minimum RPM.<p>Running four overlapping counts would allow updating every 50 milliseconds. This would reduce the flicker considerably. Remember that movies run at 24 frames per second and usually do not show objectional flicker.<p>At 6000 RPM, each revolution takes 10 milliseconds. Counting two revolutions (4 pulses) will take 20 milliseconds. Resolving 1 RPM will require a clock rate of 300 kilohertz. You may want to change your processsor clock to 18 megahertz rather than 20. This will give you 15 machine instructions between each sample point.<p>I suspect that you will have to write the code in assembly language in order to control the timing. That is going to be a busy processor by the time you interleave a software divide routine with four counting routines.<p>Use a fair amount of filtering followed by a schmidt trigger to get a sharp edge again. The points WILL bounce when opening and closing.

[rshayes]

A 300 kHz clock counted for 1/5 second will give a maximum of 60,000 counts. Two bytes can store 4 BCD digits. A look up table in a PROM would take 120,000 bytes, so a 128K x 8 PROM would be adequate. This would avoid the need for a software divide routine. I would use a computer program to generate the table. Possibly BASIC running under DOS (from the Windows 95 CD) or one of the various forms of C if you have it.

[Newz2000]

Excellent ideas, thanks. I'll try counting the time for four sparks, Stephen, that sounds like a reasonable way to be accurate and at the same time refresh the display as quickly as possible.<p>Regarding the display, I didn't clearly communicate that the display will be a 2 line by 20 character wide bargraph with the RPMs being shown as a number in the top left 4 characters. I'll try to demonstrate with ASCII art:
<blockquote><font size="1" face="Verdana, Helvetica, sans-serif">code:</font><hr><pre>
6000 RPMS ...:::||
....-----:::::||||||
</pre><hr></blockquote>
I have no idea how that would turn out (it would be nice if code tags used a fixed-width font) But we figured that since we cannot fix the display in the instrument panel it needs to be visible at a glance and a bar-graph is easier to glance at than small numbers.<p>That will take longer to update than just numbers. It will be interesting to see how quickly the display can be updated. I'll be using 8 bit mode connected to an i2c shift register, so I should get reasonably fast updates.

[rstofer]

I had read the bargraph thing earlier. It would seem that this simplifies the computation in the following way: There are only 20 possible readings between 0 and 6000 RPM or 300 RPM per bar. It should be possible to calculate the time counts that represent the center of each bar and just do a lookup in a small table. In fact, you could do an IF-THEN-ELSE type of binary search with only 5 tests. That might be faster than a table lookup with a 16 bit argument.<p>It may not be the center value that causes a bar to get turned on, it may be the minimum value. Mess around with a spreadsheet until you get what you want.

[Gorgon]

Hi Matt,
Regarding the bar graph resolution. All LCD display modules based on the HD44780 controller can have up to 8 programmable characters. If you use 5(or6) of them to make partial bargraph characters, you will have 6*20 or 120 steps in the graph or one step for each 50 RPM.<p>Programming your own characters makes it possible to format the look of the bargraph for your own taste. <p>If you have room for this in the PIC controller, it only takes 120 16bits values in a table to find the correct offset for the bargraph. With a binary search you only need 6 or 7 tests to find the value.<p>Stephen:
Running four overlapping counts would allow updating every 50 milliseconds. This would reduce the flicker considerably. Remember that movies run at 24 frames per second and usually do not show objectional flicker.<p>The reason for this is that each frame is shown 2 times, making an effective rate of 48 frames per second.<p>The LCD is a slow device and the image is slowly changing and looking stable. You may see some flicker when you write to it, but normally only when seen from the side, at the limits of the viewing area. There is always a tradeoff between the update frequency/ change of content and the viewing comfort / need for information. <p>
TOK <p>[ August 13, 2005: Message edited by: Gorgon ]</p>