Blog

tower base

39.100585N

105.105618W

S.W. anchors

39.100595N

105.105905W

39.100578N

105.105776W

S.E. anchors 

39.100432N

105.105384W

39.100316N

105.105247W

N. anchors

39.100678N

105.105425W

39.100806N

105.105431W

Found these photos of the damage to the tower. The tower was fixed on Nov 6, 2009, https://wiki.ucar.edu/x/DhAFAw

Photos of Tower damage

August 17, 2013

All remaining brackets, booms and deer stands have been removed from Turb Towers.  What remains is a beacon, two levels of lightning protection.

The following plots were made with our Splus function, plot.tilt, that does a linear least squares fit to find the plane of mean flow, and plots the wind vector elevation angle vs azimuth. The planar fit becomes a sine curve on the tilt plot.

See EOL sonic tilt documentation.

From a long term plot of the sonic "diag" value, I chose two periods where the the values were consistently very small. plot.tilt discards 5 minute wind averages when "diag" is above 0.01, or more than 1% of the data has a non-zero CSAT3 diagnostic value.

For the upper sonics at 16, 30 and 43 meters, the minimum wind speed used for the fit was 1.0 m/s. For the lower sonics at 2 and 7 meters, the minimum wind speed was set to 0.5 m/s. This didn't have much effect on the fit, however.

Feb 21 to April 4, 2011

Aug 5 to Aug 17, 2011

Tom says that typical droop of sonic booms results in 1 to 2 degree tilts. The sonic booms point up-slope from the tower, so the approximate 5 degree tilts seen here are a combination of the boom "droop" and the slope of the terrain.

They generally agree on an approximate 5 degree tilt of the sonics relative to the mean flow, except the 9.9 degree tilt for the 7m sonic in Aug 2011.

There appears to be some local "disturbance in the force", causing a pinched effect at 2 meters, and to a lesser extent at 7 meters, so that winds straight into the sonic have an additional downward inclination.

There seems to be good agreement at 16 meters and above between the two fits. I suggest using the average of the two values for those levels. Perhaps we need to look at more data for 2 and 7 meters.

dpar(start="2011 2 21 00:25",end="2011 4 4 07:26",coords="instrument")
dpar(hts=2)
plot.tilt(flag="diag",ellim=10,spdmin=0.5)

As a test of whether a 3G cellular modem could replace the WIFI network connection at Manitou Forest Observatory, I've setup a titan DSM in my office, with a Cradlepoint CTR350 router and a Verizon USB720 modem. The modem uses an external antenna (6" dipole) in the window of my office.

The modem's signal strength can be viewed from the Modem->Info page of the router's WWW interface. It is currently showing a 92% signal strength at -79 dBm:

Name	Value
Manufacturer: 	Novatel Wireless Inc.
Model Info: 	MC760 VERIZON
Modem Firmware Version: 	Q6085BDRAGONFLY_V139 [Jul 02 2009 18:00:00]
Carrier Status: 	UP
ESN/IMEI: 	5B4F86F2
Mobile Directory Number: 	7204707887
Connection Type: 	CDMA
PRL Version: 	53013
Signal Strength (%): 	92
Signal Strength (dBm): 	-79
PhysicalPort	USB1
Connection Status: 	Connected

CTR350 serial number: MM090168701586
CTR350 MAC: 00 30 44 06 bc 0f

Crontab entries check the status of the ethernet and Verizon link, and can power cycle the router if necessary:

# Only run router_check.sh if net_check.sh succeeds to avoid power cycling modem if the problem is with t
he ethernet connection
1,31 * * * * net_check.sh eth0 192.168.0 192.168.0.1 && router_check.sh 8 www.eol.ucar.edu www.google.com
# Every 4 hours, run router_check.sh by itself, in case the router needs
# power cycling to get the ethernet working
10 */4 * * * router_check.sh 8 www.eol.ucar.edu www.google.com

Rsync transfers from the Titan to FLAB are running at about 61 KB/sec. This was a transfer with compression enabled, of binary files (shareable libraries):

sent 294 bytes  received 5998216 bytes  61523.18 bytes/sec
total size is 16029060  speedup is 2.67

Transfers the other way are about 85 KB/sec:

sent 5998221 bytes  received 214 bytes  85084.18 bytes/sec
total size is 16029060  speedup is 2.67

Remote Admin

Remote admin is enabled on port 30080 from all hosts with 128.117 IP addresses. However I have not been able to successfully get past the login screen. After entering the password, nothing more appears. Firefox status bar says "Transfering...". tcpdump shows packets arriving from port 80 of isfs4.dyndns.org, but nothing is rendered. Cradlepoint tech help says it is because the signal strength of -80 dBm is too low, that it needs to be up around -65 to -70. He says he did get past the login screen, but I have never been able to. I'm dubious. Maybe its a Firefox thing? Steve Oncley just tried Chrome and Safari. No luck.

With the system outside, the signal strength showed as 96%, -77 dBm, but still remote admin would not work.

Power Supply

The power supply consists of the following in a cooler box:

• Power-One HB12 supply, 12V, 1.7A
• Morningstar Sunguard charge controller
• Panasonic lead-acid, 12V, 7.2 Ah battery

On Mar 12, started testing the whole system, modem, router, DSM and power supply in the back lot of FL1 near the yard maintenance shed. Will watch the voltages to see that the HP12, controller and battery can keep up.

Kurt felt the values on 3/13 were too low to maintain a healthy battery, so he turned a pot on the charger to increase the voltage. The values for 3/14 are much better.

Installed

On March 21, at 11:55 MDT, John Ortega installed the system at Manitou. It came up and is online, and has registered with DynDNS as mfogw.dyndns.org. It is mounted on the scaffolding tower, next to the Skybeam WIFI. A little 6" dipole antenna is connected to the Verizon modem. He attached a grounding strap from the gray DSM box to the tower. There is an ethernet surge protector inside the box to provide protection on the ethernet cable coming up the tower, once it is connected. A GPS is on port 3 and NTP looks good.

Here is the current network configuration. Note that it is not connected to the rest of the MFO network at this time.

The RAL server at 192.168.0.5 is configured as the DMZ host - the Cradlepoint should pass all traffic, except those ports otherwise forwarded, to the RAL server.

September 28, 2012

Chris and Lisa

All equipment has been removed from the Turbulence Tower.  Three sonics, two Licors, five TRHs, barometer, 4-comp, dsm, ALL cables (except eth), batteries, charger.

Things that we kept there were all TRH booms, barometer boom, three sonics booms, CSAT electronic plates (3), 4-comp boom WITH mounting plate and deer stand.

Gear that is in EOL:  Five TRHs, two sonic booms, three CSAT electronic plates, 4-comp, barometer, three batteries, power cable and splitters.

Most gear was sent to SCP due to lightening strike on September 27th.  At this point I will go through cables and repair as much as I can with what supplies we have in the lab.  Most cables need repair.

September 25, 2012

Afternoon

Chris and Lisa

Replaced barometer with another barometer.  Do not know serial number on new unit.  It is coming in but not parsed the same.

Removed sonic at 8m and 30m.

From my reading of the logbook, the licors were at these heights, starting at the given dates:

Failures:

Summer 2009: SN 0813, 1166 fixed at Licor after lightning damage prior to being deployed at Manitou.

Oct 2, 2011: 16m, SN1163, https://wiki.ucar.edu/x/cKmrB
Nov 6, 2011: 16m, SN1167, https://wiki.ucar.edu/x/jofpB
Aug 23, 2012: 16m, SN1164, https://wiki.ucar.edu/x/boHCBg

According to https://wiki.ucar.edu/x/HwClBg, the 16m licor is SN1164.

http://www.eol.ucar.edu/isf/projects/BEACHON_SRM/isfs/qcdata/plots/2012/08/23/licor_20120823.png

On Aug 23 18:48:30, the diag initially dropped from a good value of 249 to 118-121.

2012 08 23 18:48:30.5894  0.1001      49 249\t0.07072\t12.6021\t0.05373\t415.742\t19.45\t76.2\t\n
2012 08 23 18:48:30.6894     0.1      49 249\t0.07068\t12.6090\t0.05378\t416.812\t19.45\t76.2\t\n
2012 08 23 18:48:30.7894     0.1      49 121\t0.07176\t12.6058\t0.00112\t418.920\t19.45\t76.2\t\n
2012 08 23 18:48:30.8893 0.09994      49 119\t0.06758\t12.5810\t0.00463\t435.376\t19.45\t76.2\t\n
2012 08 23 18:48:30.9893 0.09998      48 118\t0.06661\t12.4256\t0.01945\t-6.373\t19.43\t76.2\t\n
2012 08 23 18:48:31.0896  0.1003      48 118\t0.06405\t11.7233\t0.03659\t56.809\t19.45\t76.2\t\n
2012 08 23 18:48:31.1894 0.09977      49 118\t0.06470\t11.6094\t0.04970\t170.629\t19.45\t76.2\t\n
2012 08 23 18:48:31.2893 0.09994      49 118\t0.06822\t11.0511\t0.06201\t287.164\t19.43\t76.2\t\n

After the number of bytes (49 or 48) is the licor data record. The data fields (diag,co2raw,co2,h2oraw,h2o,Tcell,Pcell) are separated by tabs (\t)

A diag of decimal 118 is binary 01110110,  where bits 0,3 and 7 are 0.

bits 0-3 are the AGC, automatic gain control.  The critical diag bits are 4-7.

See: ftp://ftp.licor.com/perm/env/LI-7500/Manual/LI-7500Manual_V4.pdf, page 3-36.

Bit 4 is Sync:

Sync Flag - If not OK, indicates that the LI-7500 embedded software and the digital signal
processor (DSP) receiving the signal from the chopper motor in the sensor head are out of
sync. Check cabling.

Bit 5 is the PLL:

PLL - Phase Lock Loop offset, indicates the status of the chopper motor. If not OK, there
may be a problem with the chopper motor in the sensor head.

Bit 6 is the detector:

Detector - If not OK, indicates the detector cooler is not maintaining the proper temperature:
this will happen at temperatures above 50 °C. Note that this does not always indicate a
serious problem; the cooler may simply have not yet reached the target temperature during
instrument startup, or it may be out of range due to external environmental conditions.
Readings may still be OK. Check cables and wiring.

Bit 7 is the chopper:

Chopper - If not OK, indicates the chopper temperature controller is out of range, hot or cold.
As with the Detector indicator above, this may or may not indicate a serious problem. The
chopper should be able to temperature control when ambient is between +50 and -25 °C.

Since Aug 23, the diagnostic value has been all over the map, with bits 5,6,7 changing over the day.
Here's a snippet of data from Aug 30. Diag=159, binary 10011111, bits 5 and 6 are 0 (not OK), bits 4 and 7 are OK.

159\t0.84090\tOverflow\t0.85015\tOverflow\t30.04\t76.3\t\n
159\t0.14794\tOverflow\t-0.15488\tOverflow\t30.04\t76.3\t\n
159\t0.74279\t1034826496\t0.88954\tOverflow\t30.06\t76.3\t\n

I think Tcell and Pcell have always looked OK.

August 17, 2012

10:00am - 1:30pm MDT

Three batteries installed at Turbulence Tower.  Four component was installed and working.  New TRH 2m top plate.  New 2m sonic (CSAT0536) was installed to replace odd sonic.

August 15, 2012

10:30am - 3:00pm

Putting freshly calibrated sonics (CSATs) on turbulence tower with Licors, TRHs and barometer.  The four-component radiation did not get mounted due to a mount missing.  System was check with just a charger powering instruments but then shut off due to missing batteries.  Everything looks good but the 2m sonic.

Guy tensions were checked.

Remember:  Batteries, radiation mounting plate, radiation instrument, boom and electronics box.

45m:  CSAT0537, Licor 1166

30m:  CSAT0853

15m:  CSAT0539, Licor 1164

7m:  CSAT0800

2m:  CSAT0855, Licor 0813

Aug 23, 11:30 am

Installed a new kernel with one small difference in the PC104 interrupt handling. If the PC104 interrupt hander is called, and it sees no bits set in the pending value, then it goes ahead and call handlers for all unmasked PC104 interrupts (which in manitou's case is just one, IRQ 3).

This logic was also in the patched 2.6.16 kernel. It counted these "spurious" interrupts and from time to time, complained about them. The new code doesn't log any complaints. The intcount script could be used to see if it is happening frequently.

Since re-installing the data system last week, with the new kernel, I've seen a few timeouts where all data from the emerald cards cease. This patch may help that.

The data system was re-installed on Aug 15. It is the same hardware (CPU, serial cards, usb disk, enclosure and interface panels) as before.

The Linux kernel has been upgraded, from 2.6.16 to 2.6.35. This kernel has PPS support, so an extra patch was not needed to get the PPS from the GPS. It also does not have the bug where executables could not be run from compact flash. Therefore they are not copied to ram disk at bootup.

This kernel also sets the PC104 CPLD to do the default linux-style interrupt handling, where AUTO_CLR and RETRIG are not enabled as before. The GPIO interrupt that serves the PC104 is now an edge detect interrupt. It has a patched handler for the edge detected interrupts.

The Licors are also modified with a fix that was found when testing at FLAB. Because the CTS line into the DSM was allowed to float,then it generated interrupts over a long cable. They occur when the TX line from the Licor is active, so it must be some sort of cross talk. It is not simple to disable CTS interrupts in the kernel. Instead, the CTS to the DSM was looped back to RTS from the DSM in the Licor box and not allowed to float. The Licor CTS was already looped back to its RTS in the box, so this is a symmetrical loopback.

We shouldn't see any of the "spurious interrupt" messages, primarily because the kernel now doesn't complain about them, but also since we are not getting the storm of CTS interrupts, then things should be much more predictable.

Just flipping through the data, have noticed what appears to be a nice sweep event (upper air intrusion into the canopy) at about 2011 Oct 5 23:30*.*

June 26, 2012

11:00am - 2:05pm MDT

Removal of all sensors on the Turbulence Tower today.  Sonics, Licors, TRHs, pressure, four-component, batteries and dsm.  Cables have remained on tower.  Kept beacon on also.

Since we left cables on tower we had to mark cables on the dsm side so we know what instrument it was and which port.  This was our organization codes using colored paper clips, zip ties and electrical tape.  All levels have a sonic, TRH and Licor which are bundled together.  This is the code for the bundle.

CSAT marked with zip tie

TRH marked with tape

Licor marked with nothing.

Heights are marked with paper clip colors.

45m - Green

30m - Pink

15m - Blue

8m - Yellow

2m - White

Additional random cables.

Ethernet - 1 SMALL zip tie, no clip

Rad22m - 2 SMALL zip ties, no clip

Pressure - 3 SMALL zip ties, no clip

dsm was taken down at 11:35am.

WE NEED PRESSURE TUBING!