2017 September

From EOVSA Wiki
Revision as of 11:29, 28 September 2017 by Dgary (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Back to Observing Log

Sep 01

13:10 UT Overnight I took another X-Y delay phase calibration on 2253+161. Comparison with the one from Aug. 10 shows that it is identical, so I will not update the calibration--mainly because the results on Ant 11 and 13 are much better on Aug. 10. Ant 11 was clearly not pointing well last night. Ant 13 may have the same issue. Additionally, using the low-frequency receiver showed that the X-Y delay for Ant 14, for that receiver, badly needed updating. So I ran delay_widget.py on it and adjusted the LoRX delay by -6 ns. This is the same amount needed for the HiRX, so probably I should simply adjust the LoRX and HiRX values at the same time, when analyzing the high-frequency receiver data. I should also say that we were able to correct the data instability late yesterday by running the ACC LabVIEW code from memory rather than booting from the ACC. This demonstrates that we know what the problem is, although we still do not have a permanent solution. Gelu will investigate further today.

Sep 14

03:41 UT We did some testing of the fast correlator (running at 300 MHz), and Jack says the earlier problem is gone! So I have set up the system to run in 300 MHz mode pretty-much all night on 2253+161, although the wind is up and many scans will be no good. It will try new scans every 20 min. I hope to get one or more good scans, with which to set the delays, and possibly run on the Sun in this mode tomorrow. Looks the like the first scan, at 03:45 UT, will be missed due to wind...

12:52 UT The scans overnight went okay, but we lacked coherence on 6 of the antennas. This corresponds to three of the ROACHes, so it may be a non-issue in the sense that it could be related to dodgy timing (Jack said the timing score was quite bad for the design). I captured some packets and wrote up an analysis for Jack. I did note a few anomalies, including a pattern of missing and/or zeroed content packets. I have gone back to the old correlator, and am now attempting to grab some 3C84 data for determining the delays, prior to starting observations for the day.

Sep 25

04:40 UT I tried a new 300 MHz correlator design of Jack's, but it had serious problems--namely, the M count was all over the place, with huge numbers, and the correlated data packets were not coming out. So I went immediately back to the 200 MHz design, and took data for updating the delays. One iteration is all it took, and the delays seem fine now.