...
If we decide to fix these data, we will need the following coefficients:
...
Sensor ID3 I2C ADD: 12 data rate: 1 (secs) fan(0) max current: 80 (ma)\n
...
2015 04 09 15:01:26.7912 0.08542 44 \rresolution: 12 bits 1 sec MOTE: off\r\n
...
2015 04 09 15:01:26.8472 0.05602 28 calibration coefficients:\r\n
...
2015 04 09 15:01:26.8755 0.02831 21 Ta0 = -4.112729E+1\r\n
2015 04 09 15:01:26.9047 0.02921 21 Ta1 = 4.153065E-2\r\n
2015 04 09 15:01:26.9348 0.03005 21 Ta2 = -5.198994E-7\r\n
2015 04 09 15:01:26.9555 0.02074 21 Ha0 = -7.871138E+0\r\n
...
2015 04 09 15:01:26.9848 0.02932 21 Ha1 = 6.237115E-1\r\n
...
2015 04 09 15:01:27.0148 0.02994 21 Ha2 = -5.446227E-4\r\n
2015 04 09 15:01:27.0348 0.01999 21 Ha3 = 8.683383E-2\r\n
...
2015 04 09 15:01:27.0648 0.03001 21 Ha4 = 7.886339E-4\r\n
2015 04 09 15:01:27.0947 0.02994 21 Fa0 = 3.222650E-1\r\n
P.S. There now is a version of fixSHT.qq in the CABL/ISFF/R directory that implements this fix, though we now how to figure out how to apply this fix in our data flow. One possibility is to bundle it with the wind-direction computing script to write to both high-rate and 5-min NetCDF files.
Ultimately, of course, the solution is to fix the sensor/microprocessor. This is an intermittent problem that has affected at least 2 different sensors. Since it is a bit slip, it likely is an issue communicating between the PIC and the SHT. Thus, it appears that either the PIC, SHT, or the interface circuit is marginal in some aspect. Is the timing too fast? Is a pull-up resistor needed? Is some timing wait state needed?