value of CPM in sleep mode...

[thinrope]

I have been testing (my) latest patches in devel and I am getting a bit of strange results in sleep mode. Basically the logged CPM from the original firmware and the CPM I calculate based on no integration window (or actually maximal integration window if that is easy to grasp)... There is a visible difference that I plotted in gnuplot:

set datafile separator ","; set key autotitle columnhead
set xdata time; set timefmt "%Y-%m-%dT%H:%M:%SZ"; set format x "%Y-%m-%d\n%H:%M";
plot "b" u 1:2:($3/$4*60) w filledcurves above title "over-reported", "" u 1:2:($3/$4*60) w filledcurves below title "under-reported", "" u 1:($3/$4*60) w p title "measured CPM", "" u 1:2 w p title "reported CPM"

Here is part of the data:

timestamp,cpm,counts,interval
2013-04-29T10:14:07Z,350,451,82
2013-04-29T10:15:08Z,358,348,61
2013-04-29T10:16:09Z,314,335,61
2013-04-29T10:17:10Z,346,367,61
2013-04-29T10:18:41Z,356,182,30
2013-04-29T10:19:42Z,356,185,30
2013-04-29T10:20:43Z,294,154,30
2013-04-29T10:21:44Z,330,168,30
2013-04-29T10:22:45Z,318,160,30
2013-04-29T10:23:46Z,324,169,30
2013-04-29T10:24:47Z,390,197,30
2013-04-29T10:25:48Z,334,171,30
2013-04-29T10:26:49Z,326,165,30
2013-04-29T10:27:50Z,354,183,30

2013-04-30T11:16:49Z,302,154,30
2013-04-30T11:26:50Z,356,183,30
2013-04-30T11:36:51Z,366,185,30
2013-04-30T11:46:52Z,346,176,30
2013-04-30T11:56:53Z,306,159,30
2013-04-30T12:06:54Z,360,184,30
2013-04-30T12:16:55Z,328,168,30
2013-04-30T12:26:56Z,290,152,30
2013-04-30T12:36:57Z,382,192,30
2013-04-30T12:46:58Z,324,167,30
2013-04-30T12:56:59Z,362,185,30
2013-04-30T13:07:00Z,352,182,30
2013-04-30T13:17:01Z,352,180,30
2013-04-30T13:27:02Z,324,166,30
2013-04-30T13:37:03Z,326,168,30
2013-04-30T13:47:04Z,392,200,30
2013-04-30T13:57:05Z,342,176,30
2013-04-30T14:07:06Z,324,169,30
2013-04-30T14:17:07Z,328,165,30
2013-04-30T14:27:08Z,330,166,30
2013-04-30T14:37:09Z,300,153,30
2013-04-30T14:47:10Z,338,171,30
2013-04-30T14:57:11Z,394,199,30

And the image showing always underreporting as opposed to taking all counts in an interval and dividing by the interval.

Any ideas?

[new299]

I'm not sure I fully understand what the maximal integration window is. I was assuming it was intended to be a calculation from all pulses between the "log interval"s. So if the log interval was set to 10mins it would be based on 10mins of pulses, is this correct?

If that's correct then it wont work because the Geiger counter HV board (and CPU) is only "on" for 30seconds during that 10min period. But I may well have misunderstood.

[thinrope]

Well, when the board sleeps, my patch doesn't run, so what happens is that it runs only in the last 30s and it logs 30s as interval (last column) and number of counts in that interval. Dividing those two numbers (*60) is almost always more than the calculated CPM from the original firmware (column 2). This is represented by the green between the points. I expect there is either something funny going on while the HVPS is "booting" or the "integration window" is doing some magic (I still cannot fully understand how it works).

If used in the normal mode (not shown on the graph) there is also over-reporting, so statistically those probably cancel out and problem is only in sleep mode log.

I am now testing in background level, then will put a more active source and see if it makes a difference (does the offset depend on CPM).

[new299]

There are a couple of issues that could effect this I think. Firstly I think you're using the interval start time as logged by the controller in m_interval_start? That value in set in the Controller constructor which is called in main after initialising the Geiger counter, and after a 10000us delay. So the geiger total_count will actually be for >10000us more that m_interval_stored-current_time. That shouldn't be a huge issue though...

is_cpm30_valid() also requires valid windows covering 30.5s this shouldn't cause an issue but might be a bug related to that which is effecting things.