[evlatests] evlatests Digest, Vol 25, Issue 33
Bob Stupak
rstupak at nrao.edu
Wed Jun 27 12:15:23 EDT 2007
Ooops, I didn't think to put antennas 19 and 21 into the array, while
I was operating....
Bob.
evlatests-request at donar.cv.nrao.edu wrote:
> Send evlatests mailing list submissions to
> evlatests at listmgr.cv.nrao.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://listmgr.cv.nrao.edu/mailman/listinfo/evlatests
> or, via email, send a message with subject or body 'help' to
> evlatests-request at listmgr.cv.nrao.edu
>
> You can reach the person managing the list at
> evlatests-owner at listmgr.cv.nrao.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of evlatests digest..."
>
>
> Today's Topics:
>
> 1. X-Band status, Modcomp-free, 26 June (Rick Perley)
> 2. Re: Ant 13 (Doug Gerrard)
> 3. Re: X-Band status, Modcomp-free, 26 June (Jim Jackson)
> 4. L-band (Rick Perley)
> 5. More on Modcomp-free flagging (Rick Perley)
> 6. "pulsing" explanation (Ken Sowinski)
> 7. Re: "pulsing" explanation (Ken Sowinski)
> 8. modcomp-free tests (Gustaaf van Moorsel)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 26 Jun 2007 15:18:10 -0600
> From: Rick Perley <rperley at nrao.edu>
> Subject: [evlatests] X-Band status, Modcomp-free, 26 June
> To: evlatests at aoc.nrao.edu
> Message-ID: <46818292.9070404 at aoc.nrao.edu>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> After appropriate flagging was (manually) done on the observations
> referred to in the prior note, I find:
>
> 1) Antennas 14, 19, and 21 are dead at all IFs. It is noteworthy
> that none of these were flagged by the system.
>
> 2) Antenna 13A and 13B are very weak. Antenna 13D is dead. The
> amplitudes of all three 'working' channels are not behaving normally,
> with oscillations and 'clunks' occurring on many timescales.
>
> 3) Antenna 16C has three different levels, at 0.0, -1.6, and -3.8 dB
> in power. There is a fairly clear periodicity in the pattern of drops
> -- 1.2 second period. The 'zero' level defined above is itself below
> what would be considered normal, by about -3 dB.
>
> 4) Antenna 18A is fixed at a high (erroneous) level, with exactly
> 180 degrees of phase on all baselines.
>
> 5) Antenna 16B has extremely unstable gains, varying by ~50% or
> more. These are clearly related to large claimed changes in Tsys,
> seen in the tables.
>
> 6) Antenna 26 has three small 'short shallow drops' on IFs A and C
> only.
>
> Overall, phases look pretty good, other than steady winds likely
> related to large baseline errors. There are a multiplicity of small
> clunks and slopes, which I have come to understand are due to the VLA's
> phase and delay compensation system. All of these are of 5 degree
> amplitude or less.
> Some VLA antennas have steady phase winds. For this observation,
> nearly all of these are on the west arm (6, 8, 4, 5, and 22). The rate
> increases more or less with baseline length. It is curious to me that
> this is not seen on the east arm, except for antenna 15. In particular,
> antennas 3 and 20 (at E64 and E48, respectively) have nice steady
> phases. It is possible we hit the stationary point (which happens once
> per day) by accident in this observation, but what's the probability ?
> Either that, or a fortuitous atmospheric wedge positioned itself just
> right ... Similarly, all north arm phases are flat, except for minor
> slopes for antennas 7 and 26 (which are of opposite sign).
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 26 Jun 2007 15:20:38 -0600
> From: Doug Gerrard <dgerrard at nrao.edu>
> Subject: Re: [evlatests] Ant 13
> To: evlatests at aoc.nrao.edu
> Message-ID: <46818326.6030806 at aoc.nrao.edu>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>
> We swapped out he EDFA's for Antenna 13 and 14 with spares and will
> continue to monitor. We verified the EDFA's were not being commanded
> off as originally thought.
>
> Doug
>
> Rob Long wrote:
>> It seems as if Ant 13 has decided to follow suit with Ant 14 and is also
>> dropping it's EDFA. Both antennas are on the 2nd EDFA chassis (along
>> with ant 19). I have not seen Ant 19 drop out, but I will keep an eye
>> out for this. Doug Gerrard is talking with Hichem about the controlling
>> software.
>>
>> Rob
>>
>> _______________________________________________
>> evlatests mailing list
>> evlatests at listmgr.cv.nrao.edu
>> http://listmgr.cv.nrao.edu/mailman/listinfo/evlatests
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 26 Jun 2007 16:02:13 -0600
> From: Jim Jackson <jjackson at nrao.edu>
> Subject: Re: [evlatests] X-Band status, Modcomp-free, 26 June
> To: Rick Perley <rperley at nrao.edu>, evlatests at aoc.nrao.edu
> Message-ID: <200706262202.l5QM2EYo008862 at revere.aoc.nrao.edu>
> Content-Type: text/plain; charset="us-ascii"; format=flowed
>
> I just checked while the system was in X-band (about 3:45PM MDT).
>
> I see nothing in the hardware to explain why Antennas 19 & 21 did not work.
>
> Antennas 13 and 14 have been having EDFA problems. These have just
> been swapped to spare EDFA's. I wouldn't trust anything before about
> 3:30PM MDT today. We also had extra problems bringing 13D up and
> some monitor points in the D351-d are not behaving - there does
> appear to be good RMS, TP and SD values. We believe the IF-D signal
> should be good but won't know for sure until we power cycle and check
> the module tomorrow.
>
> Antenna 18 IF-A is dead due to a bad D351 deformatter - it will
> likely be changed tomorrow, Thursday at the latest. We don't
> currently have spares - Kerry just completed final assembly on a few
> more and is testing them overnight.
>
> The drops on 26AC sound like synthesizer lock issues we see
> occasionally - we are looking into those in the L302 design and calibration.
>
> Antenna 16 will need some more looking into.
>
> Jim
>
>
> At 03:18 PM 6/26/2007, Rick Perley wrote:
>> After appropriate flagging was (manually) done on the observations
>> referred to in the prior note, I find:
>>
>> 1) Antennas 14, 19, and 21 are dead at all IFs. It is noteworthy
>> that none of these were flagged by the system.
>>
>> 2) Antenna 13A and 13B are very weak. Antenna 13D is dead. The
>> amplitudes of all three 'working' channels are not behaving normally,
>> with oscillations and 'clunks' occurring on many timescales.
>>
>> 3) Antenna 16C has three different levels, at 0.0, -1.6, and -3.8 dB
>> in power. There is a fairly clear periodicity in the pattern of drops
>> -- 1.2 second period. The 'zero' level defined above is itself below
>> what would be considered normal, by about -3 dB.
>>
>> 4) Antenna 18A is fixed at a high (erroneous) level, with exactly
>> 180 degrees of phase on all baselines.
>>
>> 5) Antenna 16B has extremely unstable gains, varying by ~50% or
>> more. These are clearly related to large claimed changes in Tsys,
>> seen in the tables.
>>
>> 6) Antenna 26 has three small 'short shallow drops' on IFs A and C
>> only.
>>
>> Overall, phases look pretty good, other than steady winds likely
>> related to large baseline errors. There are a multiplicity of small
>> clunks and slopes, which I have come to understand are due to the VLA's
>> phase and delay compensation system. All of these are of 5 degree
>> amplitude or less.
>> Some VLA antennas have steady phase winds. For this observation,
>> nearly all of these are on the west arm (6, 8, 4, 5, and 22). The rate
>> increases more or less with baseline length. It is curious to me that
>> this is not seen on the east arm, except for antenna 15. In particular,
>> antennas 3 and 20 (at E64 and E48, respectively) have nice steady
>> phases. It is possible we hit the stationary point (which happens once
>> per day) by accident in this observation, but what's the probability ?
>> Either that, or a fortuitous atmospheric wedge positioned itself just
>> right ... Similarly, all north arm phases are flat, except for minor
>> slopes for antennas 7 and 26 (which are of opposite sign).
>> _______________________________________________
>> evlatests mailing list
>> evlatests at listmgr.cv.nrao.edu
>> http://listmgr.cv.nrao.edu/mailman/listinfo/evlatests
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 26 Jun 2007 16:22:26 -0600
> From: Rick Perley <rperley at nrao.edu>
> Subject: [evlatests] L-band
> To: evlatests at aoc.nrao.edu
> Message-ID: <468191A2.8000909 at aoc.nrao.edu>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> All the issues reported earlier at Xband for antennas 13, 14, 16,
> 18, 19, and 21 are the same at L-band.
>
> Flagging issues are also similar, but with some curious differences:
>
> 1) VLA antennas were not correctly flagged prior to their arrival on
> source.
> 2) Most EVLA antennas were flagged appropriately at the beginning.
> Two were not -- antenna 19 and 21 (which give no fringes, but are
> pointing, according to the operator). However, there is no indication
> from Tsys data that these antennas actually did anything -- there are
> still (!) no Tsys data in the monitor data from antenna 19, and antenna
> 21, although it has reasonable numbers listed, shows no variations
> expected when antennas move and change band.
> 3) For the last 10 seconds, the EVLA seems to have changed frequency
> -- or at least changed something -- as all the Tsys values change,
> amplitudes (for EVLA to EVLA antennas) change, and phases change. There
> is no change in VLA to VLA baselines.
> 4) For the last 10 seconds, it is the VLA that got flagged, even
> though nothing happened to them. (Exception - antenna 6 wasn't
> flagged). The EVLA antennas were not flagged.
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 26 Jun 2007 16:53:02 -0600
> From: Rick Perley <rperley at nrao.edu>
> Subject: [evlatests] More on Modcomp-free flagging
> To: evlatests at aoc.nrao.edu
> Message-ID: <468198CE.5000005 at aoc.nrao.edu>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> My test at noon stepped through the bands in the usual (going
> upwards in frequency) manner. The transition from X to U band provided
> some interesting characteristics of the present flagging.
>
> While at X-band,
>
> * The VLA antennas were flagged as bad (although the data are
> fine) 10 seconds before the end of the scan (as defined by the end of
> good VLA data).
>
> Then at U-band,
>
> * Unflagged VLA data appeared one second after the last good EVLA
> data at X-band. The data, although unflagged were not good.
> * Good (and unflagged) VLA data showed up 14 seconds later.
> (About right, if the command to change occurred at the end of the X-band
> data).
> * Eight of the EVLA antennas were correctly flagged. But two --
> 19 and 21 -- were not. These two antennas are not working at *any*
> band, yet the flagger has missed this fact -- even for U-band!
>
> As there are no EVLA U-band antennas, there is no 10-seconds of
> flagged, but good, VLA data at the end of the U-band scan. However, the
> beginning of the next band's data -- K -- is within one second of the
> end of the U-band data. The VLA data in the K-band file are flagged as
> good, but are not. As at the other bands, the good data begins about 15
> seconds later.
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 26 Jun 2007 17:49:43 -0600 (MDT)
> From: Ken Sowinski <ksowinsk at nrao.edu>
> Subject: [evlatests] "pulsing" explanation
> To: Rick Perley <rperley at nrao.edu>
> Cc: evlatests at nrao.edu
> Message-ID: <Pine.GSO.4.64.0706261735410.2956 at eki>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
> On Sat, 23 Jun 2007, Rick Perley wrote:
>
>> A) Pulsing Data.
>>
>> At all bands and all IFs and all sources, at all times, data from
>> most VLA antennas is 'pulsing'. There are three very clear behaviors:
>
> Here are the gory details as we understand it this afternoon.
> Corrections welcome.
>
> Rick reported this based on data taken Friday night, June 22.
> It has been happening on and off since then. After much
> confusion this afternoon we think we know that this was a
> result of two recent changes.
>
> 1. A change was made to the vxWorks half of the CMP which
> made it more prone to lose track of time.
>
> 2. A change was made to the executor which as a side effect
> caused the CMP synchronizing command to be sent only once
> per executor execution rather than once at the beginning of
> each script.
>
> The combined effect of these is that once the CMP lost sync
> it never recovered unless a new executor was started. The
> insidious part was that we thought the problem was deep
> becuase we all assumed that the CMP was being resynchronized
> at every new script.
>
>
> The change to the CMP has been backed out and we will revisit
> it on Hichem's return. This should make the CMP less likely
> to lose sync. Barry has fixed the executor bug; we will test
> it tomorrow or Thursday.
>
>
> I think that the phase errors which lead to large apparant antenna
> position changes are independent of this. Data is being taken
> now to verify or disprove that statement.
>
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 26 Jun 2007 20:11:18 -0600 (MDT)
> From: Ken Sowinski <ksowinsk at nrao.edu>
> Subject: Re: [evlatests] "pulsing" explanation
> To: Ken Sowinski <ksowinsk at nrao.edu>
> Cc: evlatests at nrao.edu
> Message-ID: <Pine.GSO.4.64.0706262009010.6874 at eki>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
> On Tue, 26 Jun 2007, Ken Sowinski wrote:
>
>> 1. A change was made to the vxWorks half of the CMP which
>> made it more prone to lose track of time.
>>
>> 2. A change was made to the executor which as a side effect
>> caused the CMP synchronizing command to be sent only once
>> per executor execution rather than once at the beginning of
>> each script.
>
> Further relection leads me to suggest that 1. is less important
> and what did us in was rebooting the CMP and not getting it
> properly synchronized because of 2.
>
>
>
> ------------------------------
>
> Message: 8
> Date: Wed, 27 Jun 2007 08:58:44 -0600
> From: Gustaaf van Moorsel <gvanmoor at nrao.edu>
> Subject: [evlatests] modcomp-free tests
> To: EVLA tests <evlatests at nrao.edu>
> Message-ID: <46827B24.4050803 at aoc.nrao.edu>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> I ran three consecutive tests yesterday, each 30 minutes in duration:
>
> 1 - spectral line, regular C-band (H2CO), in order to test doppler
> tracking for VLA and EVLA antennas
> 2 - spectral line, extended C-band (methanol), in order to see how
> the new system deals with 'no change'
> 3 - continuum, regular C-band, in order to test changes Walter made
> to mosaicking
>
> Disclaimer: some of the problems noted below may gave to do with the
> IAT midnight problem. Also, Ken warns me that 512 channels and 3
> seconds integration may have been too much for the system to handle.
>
> First results:
>
> 1 - Since I was not sure what program codes to use in FILLM, I filled
> with a blank program code, and specified the exact time range from
> the operator log. To my surprise this caused FILLM to load 35 seconds
> of the previous X-band observation, program code PEVLC_.
> From the log:
> 26 Jun 23:52:00 Starting program GVANTST
> From LISTR:
> 1058+015 0/23:52:00 - 0/23:52:35
>
> 2 - The first 30 minutes, with program code W3H2CO, resulted in an AIPS
> file with program code AW3H2. I assume this is according to the new
> naming scheme Walter put in
>
> 3 - The first part of the second 30 minutes, with program code W3OH, was
> loaded in the same file as the first, but with a different FREQID.
> This is the part of the second run that uses the same correlator mode
> as the first run, albeit with a vastly different frequency. I'd have
> thought that a different program code would result in a new file in-
> stead of appending. This may be an AIPS thing.
>
> 4 - The second part of the second run, with a much wider bandwidth (12.5)
> but still spectral line, somehow ended up as part of the file in the
> third run, a continuum mosaicking run at regular C-band. So the third
> file created by FILLM consists of:
> a - the second part of the second run (spectral line)
> b - the third run (mosaicking, continuum)
> This file is labeled 'CBAND', in other words, a continuum file, and
> AIPS gives it program code AW30HB, which is not like the code of the
> second run (W3OH), or the third run (GVMMSF).
>
> 5 - The naming of the mosaicking samples continues to be different from
> the old system. It insists on naming every pointing 1331+305, upon
> which AIPS adds modifiers when it sees that the positions do not
> agree. A typical name is '1331+305 04'.
>
> 6 - When observing two consecutive and identical mosaicking scans, when
> starting the second scan, the system no longer continues the original
> sequence but goes back, as it should. But it appears it does not go
> back to exactly the same position as the start of the first scan.
> Instead, it starts at the position of the *third* sample in the
> first scan.
>
>
>
> ------------------------------
>
> _______________________________________________
> evlatests mailing list
> evlatests at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/evlatests
>
>
> End of evlatests Digest, Vol 25, Issue 33
> *****************************************
More information about the evlatests
mailing list