Subject: Staff/Scientist Logs

For a long time, I've wanted to do a quantitative study of the antenna
system temperature versus frequency. Today I discovered a way to plot
all antennas on the same graph, by normalizing the data to the Tsys
value at a single frequency (1430).

The relative system temperature is
Tsys(f) / Tsys(1430 MHz)

Thanks to Aaron's work, last week we took measurements at 1.43. 3.04,
and 8.4 GHz. On a log-linear plot, the data fit a nice straight line. 
The graph below shows the individual antenna graphs for 13 antpols

Heres a review of testing comms on 4h today. We had a problem with "atalnaon" on 4h.

atalnaon 4h
LNAOn@PAXBoxServer@ant4h not responding timeout

This lead us to suspect a comm problem on that antenna. It could be the RimBox or the PAXBox, because PAX goes through Rim.

Next we did:

Very very initial data, with limited flagging of bad antennas and pols only, no RFI sweeping nor calcaling, be patient for loading...

SDO/HMI Quick-look Continuum: 2012 05 21 0130 UTC

(empty, feed came from 3h)

Feed S/N: SB-005

Feed S/N: SB-003

(had buggy feed installed in Feb 2012)

Feed S/N: SB-030

(was empty, no feed)

Feed S/N: SB-043

(was empty, no feed)

Feed S/N: SB-039

1. check basic comms 
2. check for sanity on basic settings, such as LNA biases 
3. check for sanity on basic sensor points, temps, ... 
4. check for power output via scans on GPS satellites 
   1. autocorrelations
5. finer checks on spectra returned of various satellites
   1. autocorrelations 
6. check on higher performance and integration within interferometry
   operations via scans on weaker objects, i.e. quasars
   are delays good, fine tune delays, are pols correlating well with the

March 31, 2012

On rare occasions it appears that a single BEE2 will miss taking an integration when commanded. Across that BEE2, software registers appear to retain their values rather than update. This is usually, but not always, found on the first delay cal of an observation. After analysis of the logs, I don't think this is network dropout and I doubt that it's a failure of the physical clock. My best educated guess (without any real data to back it up) is that the BEE2 is sporadically not driving the software-register data to the FPGA, or is lagging in some other way.