Database file from long run with memory() enabled

[Ted Sled]

Here's the logdb file from a multi day run using the Formula device and with the memory() variable enabled.

A couple of notes:
There is a spike in CPM in the middle of the db. That's me checking the beta detection with the beta shield open, not a sudden spike in background.

This was done using the AudioDevice and the AN/PDR27S. At the very end of the file the CPM slowly drops. That corresponds with the batteries finally dying. That GC ran for 43 straight days continuously on a single set of D batteries. Wow. Just wow. I also discovered that the noise levels dropped as the batteries died. The GC was still registering counts occasionally, but not at the "normal" rate.

Sorry for the 7zip format. It was the only way to get the file size small enough to avoid issues with file size limitations on SourceForge. I tried several other algorithms but only 7zip using its ultra compression ratio reduced the file size enough.

The geigerlog.proglog.zip file is over 60MB. If it is of use, I can use 7zip to break it into smaller parts that I can upload. Let me know.

This was done using 1.5pre30. When I tried to exit GeigerLog, it failed to close. After waiting a while I had to use Ctrl-C to kill it. May not be an issue in the latest pre-release.

[ullix]

The battery story is really strange. A comparison Alkali-Carbon is shown in this German Wiki (missing elsewhere) which surely explains a 2.3 fold difference, but you seem to be seeing a much higher one. Out of curiosity I would get some carbon-zinc batts and repeat the experiment?

The energy of a batt is largely determined by the amount of Zinc filled into it. Some companies under-fill, and sell as cheap batts. What is the make of your super-batts, are they perhaps over-filling? I just measured the weight of my "super alkaline D" batts as 148g.

800 000 records is a nice set to play with ;-). First pic shows the full CPM data. The yellow line is a "LinFit" (see green circled check box). A falling trend is clearly visible. The right edge shows a sharp drop, where, as you said, the batt voltage dropped sharply. My interpretation: the batt voltage drops slowly over the full 10 days, and with it the anode voltage also drops. It is a well known effect that the count rate drops when the voltage drops. Although the tube operates on the so called "plateau" of the Geiger tube, this isn't really a plateau, but a slope! !

A Poisson test can give good results when the data are steady, but here they are changing, and this should leave its traces. Unfortunately, that spike will result in even more distortion, so I have first manually removed the spike (using DB Browser for SQLite) and clipped the edges. As the Poisson Test picture shows, it is still a very decent fit, but the little lack of data at the top is the expected effect of shifting the distribution over time, therefore resulting in a broadening and an apparent lack in the center. The Poisson test is quite sensitive!

Moving to the memory swing data, shown under GeigerLog variable Temperature. Only the last 30 sec or so data are shown in the next pic. The memory use by GeigerLog goes up from about 400MB to about 1600MB over about 10 sec, and then sets back within under 1 sec. The intervals are not exactly a fixed time like 10 sec, but I have seen variation from 8 sec to 11 sec.

Still, overall at a very consistent frequency. If so, shouldn't that be visible in a FFT analysis? And it is, as seen in next pic.

Upper left shows how the memory swing increases with increasing time, equal to increasing data base size and memory need. (Bottom left is of no interest here). Upper right shows FFT Amplitude vs. Time period, and bottom right vs. frequency. I circled the maxima of a period of 0.15min, and frequency of 6.74/min, resp.. That is they represent an average period of 9.0 sec, and 8.9 sec over over the whole 850000 records!

One can also see the harmonics of this saw-tooth frequency, marked in green dots, tiny on top, big on bottom. Who said the FFT isn't useful :-)

Last dataset, recorded under GeigerLog variable Pressure, are synthetic data created with the GeigerLog formula interpreter. Here using formula EXPONENTIAL(100), which creates the distribution for the time differences in ms for two consecutive counts at an average count rate CPS=100.

The Poisson test can be 'misused' here to show the histogram of the distribution of those time gaps, and is shown in last pic. Of course, at CPS=100 the average duration is 10 ms, but much larger values are possible. In this dataset the maximum was 158.05 ms.

[Ted Sled]

The batteries are made by RayOVac. They expired in 2018. They are otherwise unused.

According to the manual printed in 1980, a set of batteries should last 60 hours. I got 43 days. Keep in mind this was made for the US Navy and in my experience, the military is always most conservative in their estimates and that 60 hours probably represents a "worst case" scenario. Still, that's a heck of a difference!!

The AN/PDR27S I have had to be made sometime after 1969 as the LM108H op amp in it wasn't introduced until that year.

The RayOVac batteries weigh in at 139 grams each and all were within one gram of each other. I also have a pair of Duracell Procell (red and black) that weigh 135 and 136 grams each; several regular Duracell (copper tops) that weigh 144 each; and a pair of Duracell Procell Constant (all black) that weigh 139 and 140 each.

One day when I'm bored beyond all imagination, I may try testing each in the GC. However, the Duracell Procell Constant (all black) are brand new and all the others have expired long ago. The Copper Tops expired in 2014, the RayOVacs expired in 2018 and the Duracell Procells (red and black) expired in March of 2020. I would hope the new batteries would outlast the aged ones.