Algorithm for numeric display of base-10 - minimum changes per update

Short description:

I am looking for an algorithm to display a four-digit speed signal in such a way that the minimum number of (decimal) digits changes every time the display is refreshed.

For instance:

Filtered
 Signal      Display
--------------------
  0000        0000
  2345        2000
  2345        2300
  2345        2340
  0190        0340
  0190        0190
  0190        0190

      


Details:

I am working on a project where I need to display a speed signal (0 to 3000 RPM) on a four digit LCD. An ideal display solution would be an analog gauge, but I got stuck on a digital display. The display would be considered a machine operator and I would like it to be as enjoyable to read as possible.

The operator doesn't really care about the exact meaning of the signal. He will want to know what the value is (to the nearest 10 rpm) and he will want to see him going up and down in response to changes in the machine. He doesn't want to see him jumping all over the place.

Here's what I've done so far:

  • round the number to the nearest 10 RPM so that the last digit always reads 0
  • Filter the signal so that electrical noise and normal sensor vibrations do not cause the reading to jump more than 10 RPM at a time.
  • Added hysteresis +/- 10 RPM to avoid cases where it will fluctuate around the same value (e.g. 990-1000)

This cleared up well the situation where the signal is stable (about 75% of the time), but I still see a lot of unnecessary changes in the signal as it transitions from one stationary state to another . As the signal changes from 100 rpm to 1000 rpm (for example), it goes through many numbers along the way. Since it takes a while to actually read and understand the number, there seems to be little point in hitting all of these intermediate states. I tried to simply decrease the refresh rate of the display, but it didn’t bring satisfactory results. This made the display "sensuous" sluggish and jittery, all at the same time. There would be a noticeable delay before the numbers changed and then they would move in large jumps (100, 340, 620, 980, 1000).


Sentence:

I would like the display to work as shown in the example:

  • The display is refreshed twice a second
  • The transition from one stationary state to another should not take more than 2 seconds.
  • If the input signal is higher than the current displayed value, the displayed signal should increase, but it should never exceed the value of the input signal.
  • If the input signal is below the currently displayed value, the displayed signal should decrease, but it should never fall below the input signal value.
  • The minimum number of digits must be changed per update (preferably only one digit)
  • The higher order numbers must be changed first to reduce the difference between the display signal and the input signal as quickly as possible.

Can you think of an algorithm that will output the "correct" 4-digit decimal number according to the rules above?

The function prototype in pseudocode will look something like this:

int GetDisplayValue(int currentDisplayValue, int inputSignal)
{
    //..
}

      

Sorry for the wall of text. I wanted to document my progress to date so that anyone who answered this question would avoid covering the ground that I had already walked through.

+1


a source to share


4 answers


If you don't need 4th digit data and it is strictly tied to a 4 digit display, have you considered using a 4th digit as an increment / decrement indicator? Flush a portion of the top or bottom zero at 2 Hz * to indicate that the next sensor change will increase or decrease.

I think you can also make a good model of your device's response, whatever it is, to the settings and use that model to extrapolate the target number based on the first half second of the two second stabilization process.



* this assumes you have the two updates per second you specified. Most 4-bit displays are multiplexed, so you could possibly mask them at a much higher frequency with a little driver tweak.

+1


a source


I think your suggestion to change one digit at a time is weird because it actually gives the user misinformation ... what I would think would be to actually add a lot more state changes and implement it in a way that everyone times when the signal changes, they are calibrated by moving to the new value in one step. This would provide analog calibration as an experience and "animation" of the change; the operator very soon learns subconsciously that the numbers rotating in the sequence 0,1,2 ... indicate an increase in speed and 9,8,7, ... decrease in speed.

eg:.



Filtered signal      Display
0000                 0000
2345                 0001
                     0002
                     ...
                     2345

      

The hysteresis you have implemented is of course very good for steady state.

0


a source


This is a sensitive question and my answer does not cover the algorithmic aspect.

I believe the behavior you present in the table at the start of your post is a very bad idea. Lines 2 and 5 show the data points that were and were not in the data, i.e. Invalid data, for the convenience of the user. This can be a poor choice in terms of machine operation.

The lower update rate may "feel sluggish" but is well defined (only "real" data and no more than a hundred milliseconds). A faster update rate displays many intermediate values, but the most significant numbers should not change quickly. Both tests are easier to test than generate fairly spurious values.

0


a source


This will include more or less slowly the sensor value in the displayed value:

display = ( K * sensor + (256 - K) * display ) >> 8

      

Choose K between 0 (display never refreshes) and 256 (display always equals gauge).

0


a source







All Articles