Could you please describe the fix "(Minor) The CR1000X Datalogger PulseCount() no longer generates the occasional skipped scan." more detailed.
The problem this bug addressed occurred when the pulsecount values were read from the external hardware that actually performs the pulsecounting into the main processor. When the signal to start the scan is generated, the pulsecounting hardware latches the current count and the the main processor reads the latched values within the interrupt that starts the measurement scan. We found that we needed a small delay (~13 microseconds) to allow the auxiliary processors enough time to latch, then read the counts. There was a problem implementing the timeout where rarely, the timeout to hold off the read, was too long and the scan was missed.
The data read from the pulsecounters was not in error, but the delay was long enough that there was a potential to skip scans. All data recorded was correct, The max delay that could possibly occur was ~44 milliseconds. So the running scan had to be around 20Hz or faster, or using all of the available measurment time or this issue would not have caused any problems. The case that uncovered it was running a 20Hz scan and making many measurements (i.e. most of the available measurement time was consumed).
thanks DAM