Just rebooted marigold (twice) to load configs which put Li7500 on channel 215,
since 212's Emerald port was stolen by 200, etc.

A power glitch today caused the data systems to reboot.

Here are the messages in /usr/lib/powerchute/powerchute.log:

200000 09/25/04 12:06:31 UPS on battery
100300 09/25/04 12:06:31 Normal power restored: UPS on line
200003 09/25/04 12:46:13 UPS on battery: Blackout 051.3 V
100300 09/25/04 12:46:17 Normal power restored: UPS on line

Finally, a data-system at the aspen site!
This is a new prometheus:  SN# #237296
Emerald#0:  W241864
Emerald#1:  W242889
Lab testing of emerald W241864 indicated that port 0 (/dev/ttyS4, which
is normally channel 200) does not receive characters.

Also emerald W242889, port 2 (/dev/ttyS14, normally channel
210) did not receive characters.

To work around these bad ports, I changed connections at the
patch panel.  The sensors are still connected to the same
ports on the break-out boxes, but inside the data-system box,
channel 200 is connected to port 4 on emerald#1 (/dev/ttyS16)
and channel 210 is connected to port 5 on emerald#1 (/dev/ttyS17).

Here is channel.txt:
200     /dev/ttyS16
201     /dev/ttyS5
202     /dev/ttyS6
203     /dev/ttyS7
204     /dev/ttyS8
205     /dev/ttyS9
206     /dev/ttyS10
207     /dev/ttyS11
208     /dev/ttyS12
209     /dev/ttyS13
210     /dev/ttyS17
211     /dev/ttyS15
216     /dev/ttyS0
217     /dev/ttyS2
218     /dev/ttyS3

- added a 4ch serial cable to bring up chans 212-215
- apparently the water killed channel 208.  The 17m sonic is now working in
  ch 213
- aircoa2 (destined for aspen) temporarily hooked up to ch 212 for comparison
- 214 will be for the 2-D gill (now mounted and hopefully to be connected soon)

- cycled power on the 6251 which brought it back alive
- aircoa1 still doesn't work on network.

several reboots yesterday (and maybe this morning) were due to power going down
due to electric weather after people left the site at 3pm.

despite removing the ch 214-215 jumper, I couldn't get the new ndaq to drive
the opto22.  I didn't have the tools to check if an output message was being
sent.  Thus, I went back to old mode control in a test pattern of s1/c1/c2/c3/c4
for 3min each starting 1243.  I have just now changed to the "real" operations
mode.  Note that the hydra tubes are still not connected to hydra, the li7000
is only connected to a dummy inlet at ~2m, and the cal gas bottles are not 
opened.  Thus, the hydra signal is just from one level or stale air.

Also note that I didn't reinstall the jumper, so the hydra control is not being
monitored.  I don't think this is a problem given that it is still in a test
mode.

I'll check with Gordon about getting his code to work.

While trying to get the opto22 stuff running, I rebooted daisy several times at
about 16:30 local.

Steve, Brian, and I hung TRHs at 1,2,6,and 10m today, along with the 
corresponding sonic booms.  Daisy came up just fine.

We selected the ground just below the sonics as the "reference zero height".
The lowest level came out at 1.4m.

PS we had the TRHs on the wrong channels.  Fixed at 17:20.

Kurt cycled power on cosmos, which brought it back up.  However, it went into a continous reboot cycle because I had left a definition for ch164 in channel_config.  Now that this is removed, cosmos appears to be stable.

However, the csat.17m now appears to be bad.

P.S. Following the aster configuration quick reference got the csat restarted.
I don't know if it will come up after another power cycle.

at 03:31 GMT last night, channels 200-207 all died.  I also couldn't login to reboot.  Someone may have to hit the power.

Power was recycled at willow. This took place around 3:15 pm.

On aster or on a prometheus, the ndaqstatus command gives a bunch 
of status information from a prometheus data box. The output is wide
so expand the window to at least 90 characters.

To run it:

ndaqstatus cosmos
The critical stuff is at the top.  Here is an examble from
cosmos, on 6/15, showing a system with network problems:

*** System Status *********************************************************
                       Socket  Socket    Max    Min
  Time  Sample    Lost  Write    Temp Socket Socket Socket Buffered   Total
  Diff    Rate Samples Errors Unavail  Write  Write   Rate  Samples Samples
  msec     #/s       #      #       #  bytes  bytes byte/s        #       #
     5   13.11  133068      0    1944  14480      0    422      861    1029
***************************************************************************
Time Diff is the difference in milliseconds between the system 
clock on the localhost (where you're running ndaqstatus) and the 
clock on the prometheus.  It should be small - hopefully under 
100 msec or so. If you run ndaqstatus on the prometheus, then
Time Diff is not a useful time difference.

"Socket Temp Unavail" is a count of the number of times since
bootup that the network was temporarily unavailable.  Ideally
it should be 0. If it is growing, then the network is choked.

"Lost Samples" is the number of samples that are discarded because
of network problems.  It also should be 0, though if it grows
by something less than 100 or so a day no scientist will notice
the lost data.

.
Data system at willow is up and running as of 5:00 pm this afternoon.
2 TRH's and one barometer are running.
To be done: 

  move data system and transformer away from tower

  ground data system box

  move TRHs 1/2 meter up