I just pushed a new firmware version 1.1 (source + compiled binary) to the repo.  It has new features and bug fixes that I found when I finally got around to testing the code with a function generator standing in for the geiger tube so I could generate very high count rates.

New Features

The Counts Per Second (CPS) and average-based Counts Per Minute (CPM) are logged to the USB serial interface every second in an easy-to-parse format.

I (15388) cnt_task: CPS = 2, CPM = 24
I (16388) cnt_task: CPS = 3, CPM = 84
I (17388) cnt_task: CPS = 3, CPM = 100
I (18388) cnt_task: CPS = 2, CPM = 103

The idea is that software running on an external computer could get access to the raw data from the Geiger Counter for use logging or posting to the server.

I used LVGL to animate the movement of the gauge needle between updates for a much nicer GUI experience.  Now it looks a little more like a real analog meter.

Finally, I also added a software click output on spare GPIO 2 because I figured not everyone would like to build the 555-based clicker hardware.  GPIO2 could be connected directly to a device like a piezo buzzer or it could drive a simple 2N2222A type speaker driver as shown below.  The pulse is 2.5 mSec long (changeable in config.h) with a 2.5 mSec off period after to ensure the speaker is never left in a 100% on state.

Bug Fixes

The GUI task computes versions of the raw CPS and CPM that are supposed to account for the tube's 90 µSec dead time.  However the calculation for the CPM was off by a factor of 60 which broke calculations of dose and automatic range switching for the gauge.  So that got fixed as did deciding which value to use in switching ranges on the gauge so another bug where the gauge needle would go off the far end because it was trying to display something like 1099 CPS on a range of 0 - 1000 CPS.

Finally I completely rewrote the dynamic averaging algorithm used to compute the average CPM values.  Normally it's easiest to just store 60 individual CPS values in an array and average that for CPM.  However during conditions where the rate of pulses/sec is changing quickly, such as moving close to or away from a radiation source, then the CPM value is very very slow to change because it's being averaged over 60 seconds.  So my code looks at two averages, one over the entire array (up to 60 seconds of data) and one over the last 5 seconds of data.  If the short average is significantly different than the long average then the short average is used and the long average reset to restart with only 5 seconds of data in it.  A special case is implemented for very low counts (e.g. background radiation) where it's not uncommon for 2 or 3 CPS values to be 0.  In this case the average is completely started over so it grows one entry per second starting with the very low rates.