C2-Blueberry Data Downloads - Revision history

69.161.4.229 at 06:57, 29 November 2016

2016-11-29T06:57:57Z

69.161.4.229 at 18:00, 2 November 2016

2016-11-02T18:00:46Z

69.161.4.229 at 17:36, 2 November 2016

2016-11-02T17:36:22Z

imported>Bob at 21:11, 15 July 2016

2016-07-15T21:11:24Z

imported>Bob: /* Fall 2015 to Spring 2016 */

2016-07-15T19:59:21Z

Fall 2015 to Spring 2016

imported>Bob: /* == */

2016-07-15T19:06:02Z

137.229.92.213 at 20:06, 22 June 2016

2016-06-22T20:06:55Z

137.229.92.213 at 18:38, 22 June 2016

2016-06-22T18:38:36Z

137.229.92.213 at 23:23, 20 June 2016

2016-06-20T23:23:44Z

137.229.29.192 at 22:33, 31 May 2016

2016-05-31T22:33:16Z

@@ Line 21: / Line 21: @@
        C2_2007-07-26.dat                2007,160,1900   -   2007,207,1100  167,168,230
        C2_2008-06-13.dat                2007,207,1200   -   2008,25,2400   168,230
-       C2_2008-08-26.dat                2008,165,1500   -   2008,239,1900  179,191,237
+       C2_2008-08-26.dat                2008,165,1500   -   2008,239,1900  179,191,237 (still alpha thermistors for thermistor string)
-       c2_blueberry_2009_08_05.dat      2008,239,1900   -   2009,217,1200  179,191,237
+       c2_blueberry_2009_08_05.dat      2008,239,1900   -   2009,217,1200  179,191,237 (ysi thermistors for thermistor string)
        c2_blueberry_2009_09_27.dat      2009,217,1300   -   2009,270,1000  179,196,237
        C2_2010_06_26.dat                2009,217,1200   -   2010,177,2100  179,196,237

@@ Line 28: / Line 28: @@
        c2_blueberry_2011_08_16.dat      2010,222,2100   -   2011,228,1800  179,182,196,238
        c2_blueberry_2012_08_06.dat      2010,282,1500   -   2012,219,1700  179,182,238,196,250
-       [Find the gap between 2012,219,1700 and 2012,288,600 in the radio record]
+       c2_blueberry_2012_radio-only_gap.dat 2012,219,1800   -   2012,288,600  182,238,250
        c2_blueberry_2014_07_24.dat      2012,288,600    -   2014,205,1200  182,238,250
        c2_blueberry_2016_08_18.dat      2014,249,400    -   2016,231,1000  182,238,250

@@ Line 28: / Line 28: @@
        c2_blueberry_2011_08_16.dat      2010,222,2100   -   2011,228,1800  179,182,196,238
        c2_blueberry_2012_08_06.dat      2010,282,1500   -   2012,219,1700  179,182,238,196,250
        c2_blueberry_2014_07_24.dat      2012,288,600    -   2014,205,1200  182,238,250
+      c2_blueberry_2016_08_18.dat      2014,249,400    -   2016,231,1000  182,238,250
        SHAND RECORD    2001,365,2400   -   PRESENT

@@ Line 37: / Line 37: @@
 168 2100  to  2002  217 1800
 	97	900   to  2002	97	1500
 222 2000 (station maintenance)
 0124 0200 to  2014 0206 1200 (low battery voltage. There are a few data points in that period, but spotty)
-8/24 15:00 -- After shand.engr shut down there is some major funkyness going down with the clock I think and the data is probably garbage until data retrieval is stopped on lognet.iarc ( I think )
+8/24 15:00 -- After shand.engr shut down there is some major funkyness going down with the clock (see note below)
-                   I think this will only be resolved with a site visit.
+                                      I think this will only be resolved with a site visit.
-       Legit Gaps isn't totally updated at the moment (7/2011) I think early 2008 may be a gap but haven't verified.
 Incomplete Array ID Identification:

← Older revision		Revision as of 19:59, 15 July 2016
Line 63:		Line 63:

	===Fall 2015 to Spring 2016===		===Fall 2015 to Spring 2016===
		+	In August 2015 shand.engr.uaf.edu was shut down. Shand had been the remote data retrieval computer from 2002 to 2015. Over the fall of 2015 we had a number of issues transitioning away from shand. It quickly became obvious that LoggerNet could not consistently retrieve data from the tenuous radio links on the SP. I moved the most recent version of Loggerdata.pl to host lognet so that we could take advantage of the older, more stable data retrieval software on the new computer. However, it turns out that there is a major bug specific to CentOS, the operating system running on LogNet. The time zone of the logger specified in the configuration files used by Loggerdata.pl was ignored on centOS so August 2015 to early January 2016 there was some fighting back and forth with the two competing data retrieval programs. I inadvertently fixed this by disabling loggerdata downloads for this site in late December / early January. However, due to poor performance I re-enabled again in March to try to get the sites caught up before our April trip. Around then I figured out the timezone bug present when running things on LogNet / CentOS. So, data retrievals were moved to host Ralph which is a debian OS based computer. Downloading became more consistent at that point and I'm not sure why we haven't heard from the Council sites since early May but could be a bear again. But, in light of this there is quite a bit of data in the Blueberry hill data stream with a mix of timezone (UTC vs Ak Standard at UTC-9hrs). It is only apparent which time zone the data is in if you look at the incoming shortwave radiation data and so I thought I would create this section to delineate as best I can tell. Definitely a bit of an own goal...
		+
		+	Station origination to
		+	"2015-08-24 15:00:00" AKSTD
		+	"2015-08-24 01:00:00" UTC
		+	"2015-08-25 01:00:00" AKSTD
		+	"2015-08-25 00:00:00" From here till the next several months, a low value @ 0:00 or 1:00 = AKSTD, a high value = UTC
		+	If that makes any sense.
		+	Like this sampler:
		+	"2015-09-02 00:00:00",0.00 (AKSTD)
		+	"2015-09-02 00:00:00",0.00 (AKSTD)
		+	"2015-09-02 00:00:00",0.00 (AKSTD)
		+	"2015-09-02 01:00:00",0.00 (AKSTD)
		+	"2015-09-02 01:00:00",11.24 (AKSTD)
		+	"2015-09-02 00:00:00",126.00 (UTC)
		+	"2015-09-02 01:00:00",147.70 (UTC)
		+	"2015-09-02 01:00:00",128.10 (UTC)
		+	"2015-09-02 01:00:00",54.21 (UTC)
		+	"2015-09-02 00:00:00",9.77 (AKSTD)
		+	"2015-09-02 01:00:00",0.07 (AKSTD)
		+	"2015-12-20 00:00:00" UTC
		+	"2015-12-29 00:00:00" AKSTD
		+	"2016-03-28 18:00:00" UTC
		+	"2016-03-29 17:00:00" AKSTD
		+	"2016-03-30 00:00:00" UTC
		+	"2016-03-30 16:00:00" AKSTD

← Older revision		Revision as of 19:06, 15 July 2016
Line 60:		Line 60:
	==========================================================================		==========================================================================
	Just generally, in the fall of 2009 the Incoming shortwave radiometer wires at the radiation stand become loose. There are some garbage values interspersed that fall that I got tired of cleaning up. Primarily mid October to Mid December. Maybe all of that data should just be zeroed out.		Just generally, in the fall of 2009 the Incoming shortwave radiometer wires at the radiation stand become loose. There are some garbage values interspersed that fall that I got tired of cleaning up. Primarily mid October to Mid December. Maybe all of that data should just be zeroed out.
		+
		+
		+	===Fall 2015 to Spring 2016===

← Older revision		Revision as of 18:38, 22 June 2016
Line 56:		Line 56:
	237 - 24, Soil		237 - 24, Soil
	238 = 25, Soil		238 = 25, Soil
		+
		+	==========================================================================
		+	Just generally, in the fall of 2009 the Incoming shortwave radiometer wires at the radiation stand become loose. There are some garbage values interspersed that fall that I got tired of cleaning up. Primarily mid October to Mid December. Maybe all of that data should just be zeroed out.