Displaying motor RPM effectively

Question

I have a softcore RISC-V CPU running on an FPGA that is controlling a DC motor very simply with a PI controller. There are 7-segment displays for the user to vary the speed setpoint and another 7-segment display to show the actual motor speed. To verify the actual motor speed that is calculated by the RISC-V, a non-contact tachometer physically measures the motor shaft RPM. It works accurately to the exact RPM according to the tachometer.

Currently the PI is updated every 1ms so a new motor speed is calculated at this rate and it is continuously written to the 7-segment display in the C main loop. But the lowest values flicker and makes the value unreadable.

So my question is, how should I process and display the actual motor speed values in software so that it is readable? I have thought about updating the display slower (say every 100ms), or taking an average over the last 10 or 50 (10ms or 50ms respectively). I assume the tachometer is doing something similar as it appears to have almost 1 second delays between refreshing the measurement.

Anyone familiar with motor drivers or have any ideas as to how this is done practically?

Answer 1

We tend to have two requirements for such a process variable display

• A stable readable low noise display
• With low latency, that is, a rapid update

Unfortunately, the two are in direct conflict. As the length of a filter increases, so does the latency, while the noise goes down.

The simplest two filters are an exponential decay, equivalent to a first order RC, and a box-car moving average filter. Both are trivial and fast to implement, requiring only two additions and a shift per output (if you implement the box-car recursively rather than directly).

Try these out first, because of the simplicity. You may find filter lengths that meet your requirements.

If you want a better noise/latency tradeoff, then avoid the temptation to cascade multiple RC filters, they will settle very slowly. Instead, use a Bessel filter. While more complicated, it is designed to have a dead-beat settling response.

Beyond a single filter, there are things you can do to improve the subjective experience of the user. If you use two filters in parallel, one fast, one slow, then you can select which to show. If the speed is changing slowly, use the low noise slow display. Monitor the difference between the two filters. If it exceeds some threshold, switch the display to the fast responding filter, until the slow one has caught up. You might even reset the slow one up to the fast filter's output value. We used precisely this technique in a power meter made for the RF market.

Weigh-scales have this speed/accuracy conundrum. Supermarket shoppers like a stable last digit in their checkout scales, if it's flicking around it does not engender confidence. There has been a lot of work done on algorithms to track a 'good' result in software, some of which should be accessible to the public.

Answer 2

When a variable is moving around, and you want to display it digitally, an update rate of ~3Hz is about optimal.

Otherwise if the display is bouncing around a bit the least-significant digit can become unreadable (or confusing with different segments appearing to be of different brightness).