IHOP02: GOES Messages: 9 Entries..

Some of the high-rate 'shield-off' test files were not recorded
properly in the field so I re-ran them in the lab for
stations 3,5,9; sonic/krypton used were the same units as the
stations had at teardown.  Note station 9's uw was running at 10hz.
A generic IRT #3577-2 and trh-005 were added in addition to the baro.
Hopefully this will be sufficient to analyze the noise.

See entry #265 for file lists.

06/18/02 18:45 - 19:50 Local

Reason:	No messages coming in

Station was operational, power was ok, SDR was running, etc.
Downloaded metppf.

GOES problem:
The unit was 'dead' and eve couldn't talk to it.  The front-panel
power plug may have been 'bad'.   When measuring the power it
appeared to be low, then ok.  Perhaps it was loose but I tried
to wiggle it around quite a bit to reproduce this problem and
couldn't.
After getting power back to the transmitter, I could program
it normally.  However the output power was very low: 3W.
Replaced GOES:
Out:	015 	this one is bad!
In:	1002	this one was swapped from site 2 a few days ago
	and may be bad because that site had been dropping out
	with questionable goes rf during the middle of the day,
	however, it's forward was 15W (yeow!), ref=1W (hmm)
After that the station has been coming in.

I've attempted to do a quick look at the files I captured to evaluate the
effect of the GOES spikes.  I was trying to capture both krypton and Tsfc 
data during the period of 2 GOES transmissions -- one before shielding and
one after.  Ideally, you would see one pulse in one or both of the signals
before shielding and nothing after.


(I have copied all of these files to Boulder into 
/net/pam/projects/IHOP02/captures/ )
I wrote the code "sift.q" to plot the capture files.  Note that I have not
attempted to figure out time in these plots, though I did sprinkle a modest
amount of EVE "time" commands during the file captures so that time 
be figured out.

I didn't capture everything at some of the stations -- usually forgetting to
capture a "before shielding" data set in my rush to fix things.  Also, the
connector problem at 2,3, and 4 caused no good Tsfc data to be collected after
shielding.  Some of these tests should be repeated.

I'm attaching to this message the plots that I made.  Sorry they are all
PostScript.

[From an e-mail from Gordon:]

Steve,

You probably know most of this, but here's how to change the GOES transmission
rate:

The GOES configs are in the files called  $PAM/config/s0N_goes.dat, where N=1:9

They are on the panasonic, and on aster.

They contain this line:

# GOES:    SIO_PORT   XMIT_ID XMIT_CHAN RATE  OFFSET clock_update_rate=xx_minut
GOES: /tyCo/4  36416752  125   00:05:00  00:00:05   CLOCK_UPDATE_RATE=6 SOURCE=4 SE110


To transmit one 5 minute average every hour, change the RATE from 00:05:00 to
01:00:00.

Edit the files on the panasonic, so you can easily install them on a station.

When you're out at a station, eject the PCMCIA card, put it in the panasonic,
and do

config_to_pccard  N
   where N is the station number

Then insert it back into EVE, and do:

EVE> entersys
system> del goesid.dat
system>  reboot

Gordon

Here is my comment:

GOES data were not available for the last 24 hours until late today, and only
about a 20-hour buffer was retrievable.  Thus, we lost about 4 hours of GOES
data from about 13-17CDT yesterday (5/31).  The data from s1-3 should be on
the Panasonic by now, and we will download the /cards at s4-6 tomorrow, so
all of the data should be available by this time tomorrow.

Here is more from Gordon:

Something was wrong with the NOAA NESDIS systems, and we were
not able to fetch our data from the GOES ground systems from 14:00 CDT
May 31 up to now, the morning of June 1.

However the last fetch did finally work, and [all but 4 hours of] the missing
data should be filled in.  So, the web plots should be back in shape
by 10:00 CDT this morning.

We did a QUICK stop (1203-1205) at s5 and verified that I had left the GOES 
transmitter (SE110) off.  We left it off and did nothing else at this site.

I just looked at the variation of the jumps from the high-rate data at s1&8
on 5/23.  (The code is in ../S/jumpsort.q)  The attached plot shows that the
variations in time can be large, and that the effect on each site and each 
channel can be different.  This is going to be a problem...

GOES at 8 has been showing low modulation and fair data quality with
some periods of constantly < 3 good checksums (May 14 21:00 - May 15 02:00)

Transmitter: SE120, SN 3515.

Measured output:  12W forward, 1/2 W back.

The antenna is pointing at 146 deg azimuth, which according to John is
correct. Did not measure the elevation angle.

A one point I connected the GOES power plug to the wrong connector
on the front panel, and the transmitter wasn't reponding.  Talked
to John later - he said those other power plugs have 1 amp fuses,
and I probably blew its fuse, since GOES draws more than 1 amp during
transmissions. The GOES power connector has a hidden label, and is the 
one without a fuse.

Once it was on the right power plug it worked again.  

Result - no changes were made to GOES, and as of May 16 it is still
showing low modulation and fair data quality - but checksums look
about as good as any other site.

The satellite_angle program reports these values for the
station groups. The stations within a group are within 0.5
degrees of each other in both elevation and azimuth.

Used a GOES longitude of 75 degrees.

	GOES	GOES
Group	Azimuth Elevation
West	138	38
Central	142	39
East	143.5	40