Code update 2.31 and 2.41

I published a code update for the old displays (legacy) 2.31 and the new TM1637 displays v2.41.  Going forward, the old displays will retain the v2.3X series. If I eventually make the switch to TFT or OLED, that will get an entirely new version prefix v3 series. 

This latest code improvement was made to the "error handling" and "smoothing" sections of the RPM calculation. In an effort to deliver the most-precision possible, I ran into a serious issue with the "neopixel" library for the WS2812B LEDs. The issue is directly related to how the library turns off all hardware interrupts to deliver the precise data timing needed to drive these LEDs. The problem is, I'm relying on the internal timers (directly related to the interrupts).  So basically, each time the LEDs were updated the clock stopped - so to speak. 

So, when you're trying to measure a frequency using very careful timing, and your stopwatch is broken, it makes things pretty difficult to say the least.  This would result in a "jumpy" gauge reading at certain RPMs.  Oddly, specific RPMs (frequency)  were more susceptible than others. 

Rather than ditching the Adafruit Neopixel library or rewriting it (which I did try for a few days), I decided to live with the erroneous results and handle them in software. Basically, it detects an erroneous result by comparing the previous RPM reading to the current RPM reading. If the RPM increases by 20%, it throws away that reading the instead relies on the previous reading. Remember: these readings occur at extremely high speeds that even the most fast-revving engines cannot touch. So I feel safe doing this.

---

  if (((rpm > (rpm_last +(rpm_last*.2))) || (rpm < (rpm_last - (rpm_last*.2)))) && (rpm_last > 0) && (justfixed < 3)){
        rpm = rpm_last;
        justfixed++;
        if(DEBUG){Serial.print("FIXED!  ");}
        if(DEBUG){Serial.println(rpm_last);}         
      
  } else {
    rpm_last = rpm;
    justfixed--;
    if (justfixed <= 0){justfixed = 0;}
  }

---

The software also counts the number of fixes that are applied simultaneously - to make sure we're not over-correcting while the engine RPM is changing. 

This new error handling is enabled all the time regardless of SENS option.  The "COnd" Smoothing feature still works to remedy any remaining noise you may experience associated with your specific installation by maintaining a rolling average of multiple RPM readings. 

Let me know what you think in the forums or comment below.

​Stay Tuned!