This step is just to figure out how many clicks are measured in some amount of time, to get a rate from which I can extrapolate and calculate the time. For best results, I assembled the project on a random piece of plastic sheet, and hung it on the wall in the corner of my shop, where it is unlikely to be bumped or otherwise disturbed.

The count part is easy, it's part of the ISR I set up inside the Pi Pico. An int64_t is incremented by +1 each time the ISR fires.

The "some amount of time" part is a little harder. At this point, I had only wired up an LCD display, and a couple of buttons for the user to press. For this first calibration, you just push one button to start the count, and another to stop it. But, how to do this accurately over the course of several days or weeks? I wanted this to span maybe a month, but be accurate down to the second. Should you trust your PC's clock for this? How about your phone's stopwatch? It's probably good enough for whatever I'm trying to do, but I was setting up my shortwave radio stuff again anyways, so I strung up an antenna and tuned my tube radio to 10000 Khz, which is WWV. Now there's a clock that you can be sure is as correct as you're going to get.

Throughout 2023, I noticed that whenever I tuned in, the nixie clock I had in the room was always correct and in lock step with the radio. The nixie clock updates itself every 10 minutes with the system clock of my local server. This is excellent news; it means I can probably rely on the server to receive data from the experiment and have correct timestamps.

The manual start/stop without logging ended up being a much bigger problem, because of power fluctuations my area experiences. 2023 was a particularly bad year for this. The power would usually be out for less than a second, but this was easily long enough to reset the Pi Pico, losing the current count. This was partially mitigated by publishing the current status on MQTT once per minute, but mostly resolved once I added a surplus 120V UPS, even though the power supply on the clock is just a 1A 5V wall adapter. I do have a 12V UPS which runs off a small lead-acid battery, which should last a lot longer, but again, installing it requires me to reset the experiment. The 120V UPS turned out to not be quite enough either, as the unit would sometimes lock up as the UPS's relay switched from wall power to the internal inverter. I added a soda-can-sized low voltage capacitor from an old linear power supply I happened to have to the 5V rail, which solved the issue. The only downside is that if power is completely lost, the now incredibly slow rise time of the 5V rail will not properly reset the Pi Pico, and it will never start properly. I have to manually reset the Pi Pico via shorting the reset pin to GND when this happens.

Regardless, I collected two "full" data sets while the experiment was still in the manual start-stop configuration. These are:

Calibration Run #1
Start: 2023-08-28 15:50:00
End:   2023-10-04 23:05:00 (3222900 seconds)
diode count: 109455847 (33.961912 s^-1)
noise count:   6136367 ( 1.903989 s^-1)
tube  count: 237784358 (73.779626 s^-1)

Calibration Run #2
Start: 2023-10-02 23:14:00    +1 hour daylight savings
End:   2023-11-19 10:11:00 (4103820 seconds)
diode count: 133363720 (32.497458 s^-1) -4.31% change from #1
noise count:   7521785 ( 1.832874 s^-1) -3.73%
tube  count: 290043498 (70.676466 s^-1) -4.20%

Uh oh, run #2's count rate was about 4% lower for some reason. Maybe this idea isn't going to work after all. What sort of errors might we expect in this setup? Not much is going to change the actual rate of decay, but maybe temperature or pressure might affect things. If it affects the detectors themselves, I'd probably have expected a different change in the tube and diode counters, but they are both around 4.2%. The temperature and pressure does change the density of the air though, and the PVC tube is not airtight. Could this have had an effect on the count from the tubes? Maybe, but I also might have just written the number for the time down wrong somehow. The only evidence for these runs are scribbled on a sticky note. Maybe we should have listened to Charles "I wish to God these calculations had been executed by steam" Babbage after all.

We won't have to wait long, because after cal run 2 I improved the Pi Pico firmware to send and receive MQTT messages over WiFi. Now, to start a new run, I can just send an MQTT message with the current time, and the system will automatically reset all the counters and start over. Periodically (once/minute) the Pico also sends out a status report, containing the current count of both detectors, as well as what it thinks the current time should be based on the counts. All of which gets logged by my server PC, and some of which I also publish live on my website so that those of you playing at home can watch, too. I can also send in new calibration data via MQTT; if I decide to adjust it later, I won't have to update the firmware.

I also added some new hardware. There is a BME280 temperature/pressure/humidity sensor so the room's environment could be measured. Perhaps a corelation with one of them will be apparent. I also added a DS3232M RTC chip. This is just in case I lose trust in the timestamp the listener computer adds to the report when it comes in; the report will always contain a timestamp from the RTC, which is spec'd to be good to +/- 5PPM. The RTC also has another temperature sensor.

Once this was done, I was ready for another run, which was done in the early months of 2024. I accidentally let this one run for 2 months instead of just 1, but this is the sort of project where it's better to forget about it for weeks at a time.

Calibration Run #3
duration   : 5529557 seconds diode count: 187643047 (33.934553 s^-1) -0.08% change from #1
tube  count: 408074272 (73.798727 s^-1) +0.03% 

Now, I'm more willing to believe that run #2 was a fluke. There's a less than 0.1% change from run #1, which seems pretty good (but is probably horrible accuracy for actual clock makers). Whatever, it was now time to do a much longer run.