CHATS: Site base Messages, 15 Entries..

Ian Faloona's formaldehyde instrument was installed in the trailer today. It
was too windy to place it on the PAM tower by base and so John and I will do 
it when the winds are becalmed. Ian will return with additional equipment that
is still being worked on so it will be some days before data is taken.

Ian is from UC Davis.

If for some unknown reason you want to see if the sodar 'ppp' link is up:

$ ifconfig

and look for something like this

ppp0      Link encap:Point-to-Point Protocol
          inet addr:192.168.13.1  P-t-P:192.168.20.20  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:11 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:815 (815.0 b)  TX bytes:133 (133.0 b)

at this time it'll be up roughly 20-min every odd hour, and is initiated
by the sodar side pc.

Also you can look in /var/log/messages to see if anything did go for
something like this:

May 18 13:04:48 aster mgetty[21177]: data dev=ttyS0, pid=21177, caller='none', conn='DIRECT', name='', cmd='/usr/sbin/pppd', u
ser='/AutoPPP/'
May 18 13:04:49 aster pppd[21177]: pppd 2.4.3 started by a_ppp, uid 0
May 18 13:04:49 aster pppd[21177]: Using interface ppp0
May 18 13:04:49 aster pppd[21177]: Connect: ppp0 <--> /dev/ttyS0
May 18 13:04:51 aster pppd[21177]: user isff_ppp logged in
May 18 13:04:51 aster pppd[21177]: PAP peer authentication succeeded for isff_ppp
May 18 13:04:51 aster pppd[21177]: local  IP address 192.168.13.1
May 18 13:04:51 aster pppd[21177]: remote IP address 192.168.20.20

Before I forget:

		Sodar		Repeater	Base
s/n		240-1951	240-1950	240-1946
mode		1=slave		4=reptr/slave	0=master
baud (ops)	115k (com1)	19.2k upper-ttyS20   115k (aster ttyS0)
baud (setup)

CallBook	0=1946		0=1946		0=1951
		1=1946via1950	1=1951		1=1951via1950
		2=1950				2=1950
	Use entry 1 for 'full-link' on either end.
	Use entry to 'repeater' to talk directly with it,
	and/or upper:/dev/ttyS20

Operational	Table=0, V1.62 (all are the same)

RadioCharacteristics (all are the same)
FreqKey		7
Maxpkt		8
Minpkt		9
xmit rate	1
data rate	3
power		9
etc.		0
etc		0
etc.		255
etc.		0

18may07

With Ian's Formaldehyde coming Monday with it's supposed 7A 1-phase load,
plus his desire for airconditioning, I decided to recheck the base power.


With A/C, battery charger, lights, Motosat and several PC's running:
Red-Leg: 16A
Blk-Leg: 18A
50A breaker in building, so we should be OK for Ian's

15may07....18may07

We've been having troubles with the pocketecs especially at hftower,
but also at west overnight.   On a regular basis we need to make
sure a file-system-check is done on these devils.

Gordon's 'copy' script (do this first)
-----------------------
   copy_usbdisk.sh

Gordon's 'checking' script: (do this second)
-----------------------
   bb_fsck.sh
	This will take several hours to do, and you should first
	clean off the media using the script above.
	It essentially does a
	fsck -c -c with both a read plus a 'read/write' diagnostic
	of bad blocks.   This should help overcome the difficulties
	with these devices if regularly performed.
	Gordon's script also creates a log of activity (see below)
	and if you 'ps -elf | grep fsck' during the operation, you'll
	get something like this.

0 S aster    15607 25915  0  79   0 -  1102 wait   09:37 pts/8    00:00:00 /bin/sh /usr/local/isff/projects/CHATS/ISFF/scripts/bb_fsck.sh
4 S root     15644 15607  0  81   0 -  1039 -      09:37 pts/8    00:00:00 fsck -c -c -p /dev/sdd1
0 S aster    15645 15607  0  79   0 -   909 pipe_w 09:37 pts/8    00:00:00 tee -a /usr/local/isff/projects/CHATS/ISFF/logs/usbdisk_ptec11_20070518_093729_fsck.log
4 S root     15646 15644  0  78   0 -  1488 -      09:37 pts/8    00:00:00 fsck.ext3 -c -c -p /dev/sdd1


To check the disk by hand:
--------------------------
1) connect on usb port, while watching tail -f /var/log/messages
   for the device to be recognized.
   NOTE: make certain the usb cable is secure, these can be loose!
2) Konquerer will come up: cancel that
3) mount
   to see whether it is mounted or not.
   should come up as /media/usbdisk
   umount if it is.
4) su root
5) run the file system check on appropriate device: fsck.ext3 /dev/sdc1
   report should look like this....
e2fsck 1.38 (30-Jun-2005)
usbdisk: recovering journal
usbdisk has been mounted 119 times without being checked, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
usbdisk: 16/7325696 files (18.8% non-contiguous), 280011/14651272 blocks

Inventory: 8 pocketecs, 2 spares here
-------------------------------------
ptec#2	15may07:OK reinstalled at west
ptec#11	15may07:OK reinstalled at hftower but subsequent errors
	18may07:...
ptec#6  15may07:OK but subsequent errors until 'bb_fsck'
	17may07:OK
ptec#7	The 'good unit' used for many days in array
	and put into hftower on 5/17
ptec#1	

13may07 18:00pdt

Stopped dsm, etc.
Moved power strip with 'aster latitude, isff2, AP24, D-link'
from raw power plug to UPS plug.
Last night we saw data outage at roughly 2-3am local due
to a power hit.   The AP24, etc died and r.t. data was
halted.   The aster latitude stayed up due to internal
batt. but the dlink, etc was out.   The adams appeared
to stay up based on file create dates but may have had
some loss based on raw file sizes....not yet fully
investigated.
today had 'poor' wind dir. so we decided to do this now.

Sodar connection remains down as signal is insufficient. Additional tests will
be done during unsatisfactory winds during ops.

File 15 is not good data; it was used for demo by Ned

I used Gordon's instructions, logbook entry 59, to start new config for
the horizontal array at 2.5 m.  Will rerun covars.

3/30: I forgot to edit Vazimuth.q as described in logbook #54

Gordon's instructions for chaningin the config, e.g. when changing the 
heights of the horizontal array:

cd config

create the new xml, for example:

cp ops1.xml ops2.xml

edit ops2.xml, changing the heights of the sensors for
  There are a bunch of them.

Also change the heights in the section
.  There are
a bazillion of them (pays to have quick vi hands, or
you can do global changes with this vi command:

1116,1348s/9.6m/4.9m/g

where you figure out the line number range by looking at
the info line in vi.

Then you're done editing, check for syntax errors:

ck_xml ops2.xml

It will either report an error, or a long list of sensors and variables
names if things are OK.

edit configs.xml. Add an entry for the new config.  Here are the
entries for ops1 and ops2. The times are in UTC. Note
that the times cannot overlap.  Update the end
time of the previous ops.

  
    

  
  

To check the configs:

proj_configs -l configs.xml

Assuming the new operations period has started (the begin
time has passed) then shut down dsm_server:

ps -ef | fgrep dsm_server
kill -HUP pid

Then edit $ISFF/scripts/run_server.sh
to change the xml file (when I get the
time I can make that step unnecessary).

Then run it

$ISFF/scripts/run_server.sh

Then run statsproc:

$ISFF/scripts/run_statsproc.sh

Also edit Vazimuth.q as described in Entry #54.

Gordon wrote:

Doing dpar(robust=T) gets around the problem
of dat("w'h2o'"). Is that good enough for gov't work?

It is failing in dat.Scorr (which is a complicated
mess), trying to conform dat("heights.sonic") to
w'h2o'.  Not sure why...

Fixed logbook problem:

Gordon wrote:

Converting the logbook to html is failing here, complaining
about an entry that doesn't have a date.

Could you exit logbook and re-enter?

If you get an error then you may have to fix

$ISFF/projects/CHATS/ISFFlogbook/tklog.log by hand editing.

(Make a backup of it first).

I see this empty entry at the end. Perhaps it is causing the
problem:

50
{author {}} {type {}} {site {}} {title {}} {graphics {}} {text {
}}

I'd nuke that entry if restarting doesn't fix it.  Make sure
you keep the "end" record.

In order to recalculate covars:

Edit covar_redo.sh in CHATS/scripts to specify desired start and stop times.
Run it in batch mode:

>batch
at> ./covar_redo.sh
at> D

See if running:
>at -l
should print single line about batch job running

data_dump -d (dsm) -s (sampid + 1 for calibrated data) -p sock:localhost

8mar07

Motosat working
	Established networking so Gordon can 'get in'

	Login to Motosat for adjustments:
	web browser to 192.168.1.1
	admin and pwd is .... (on aster pc there's a 'save' on it so
	you can get in, but otherwise we'll need to reset this)

	iss notes on this gizmo (some addressing is different)
	www.eol.ucar.edu/iss/SatelliteInternet

	Addresses:
	192.168.0.1	modem
	192.168.1.1	router lan
	192.168.0.2	router wan
	192.168.1.2	ASTER's eth2 interface that the motosat will
			fwd ssh's to.
			if you change this, use fedora-admin-network
			tool and restart the interface.

	
	
Initial 'wireless' working
	Still no power to array but a 'battery test' demo'd that the
	comms from base to array/tower is working a nominal.

	AP24 internal is on tripod next to base pointing under the
	trees to eant-A roughly 75' north of the array.  NOTE: this
	uses a 10m 'serial' cable extension (ie extra capacitance bad)
	to a ~40' cat5e cable.

	AP24 external antenna is on top of 5section pam mast roughly
	pointing to tall tower (180deg antenna)


Ping tests
	using
	ping -s 1048 -i .25 east
	ping -s 1048 -i .25 upper
	i saw over 15min. 0% loss with avg ~9mS per packet

	see: /etc/hosts on aster for ip addresses and for naming to
	ssh/ping such as:
	ping