Page History

...

I also note the METCRAX-II logbook comment: "TRH.40m.rim restarted" where we found that the (bad) data are correctable.  My (manual) code to implement this for METCRAXII is at $ISFF/projects/METCRAXII/ISFF/R/fixSHT.qq.  It isn't clear that it is worth the effort to implement this fix for the 15 hours of data that are missing during this educational deployment...

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?