Hi, I have a v2.61 sensor and I have noticed that when it is run for an extended amount of time without a power cycle that the graphing data starts showing up erratically. My sensor is 19311, you can see from the graph where one reading will be high (in the .27 range) and the next is low (.07 range) and is probably a valid reading. You can also see where I power cycled the sensor and it returned to providing normal graph points. Looking over the work unit the first line shows a long runtime with a high cpm and uSv/h while the remaining readings in the file show typical numbers.

2451586879,1747845,2016-12-9 0:8:1,f,40859.8 minutes,42.8 cpm,0.25 uSv/h
2451826071,1747922,2016-12-9 0:12:1,n,4.0 minutes,19.3 cpm,0.11 uSv/h
2452066277,1747977,2016-12-9 0:16:1,n,4.0 minutes,13.7 cpm,0.08 uSv/h
2452306480,1748047,2016-12-9 0:20:1,n,4.0 minutes,17.5 cpm,0.10 uSv/h
2452546685,1748098,2016-12-9 0:24:1,n,4.0 minutes,12.7 cpm,0.07 uSv/h
2452786885,1748170,2016-12-9 0:28:1,n,4.0 minutes,18.0 cpm,0.11 uSv/h
2453027090,1748235,2016-12-9 0:32:2,n,4.0 minutes,16.2 cpm,0.09 uSv/h

It looks to me like what is happening is that the sensor maintains a running count of minutes running and recorded clicks and at some point the runtime (65535 min?) overflows and returns to zero but the total clicks continues where it was. I do not have workunits available far enough back to see if this is the case. I don't see anywhere where the source code is available to review to see if this may be the case.

It would appear that the incremental data returned by the sensor is still accurate and valid and that only the first line from each workunit contains the suspect data.

I have also noticed that at this time sensors 16366 and 17070 are showing evidence of this same behavior and when reviewing their work units I see they are also v2.61 sensors.

Has anyone else observed this in the past? Would it be possible to obtain a copy of the source code for review? Does anyone else have thought or know the cause of this behavior?