v156f1 setup error
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: <John.Reynolds_at_email.protected>
Date: Wed, 6 Apr 2005 17:41:45 +1000 (EST)
Richard,
A closer examination of the smouldering log record allows a
reconstruction of events.
The summary is that it appears v156f1 was indeed recorded here in the
wrong S2 mode (32x4-2 instead of 32a4-2, with buggery cable OUT), so that
RCP was recorded on both IFs (instead of RCP and LCP).
It's clear now how this happened. The idea had obviously been to modify
the procedures file (v156f1pa.prc) to substitute S2 mode 32a4-2 for
32x4-2. This had been attempted, but the PI had cunningly defined two
setups (setup01 and setup02) in the procedures file, and the distracted
observer (probably me) had only changed the mode of the first setup. Of
course Murphy is always wide awake is such situations, so the schedule
didn't use setup01 at all, but instead used only setup02. Thus the effect
of the modification was nil!
An extract of the procedure file in question is appended.
The preceding experiment v162c1 was fine - LCP recorded on both channels,
using S2 mode 32x4-2 with buggery cable OUT, as intended.
>>> The bandpass on J1337-6509 for Parkes looks like the parallel hands are
>>> in product 1 and 4 (as opposed to 1 and 2) (I.e. RR and LR rather than
>>> RR & LL (not the labelled values)).
Just what you'd expect - LL weak or missing, and one of the cross-hand
products (LR or RL) a duplicate of RR.
>>> This maybe fixable with in AIPS. Perhaps. Do Tasso or John have any
>>> ideas which might save a recorrelation?
If only! The good news though is that no recorrelation is necessary.
Sorry 'bout that. I guess it might be a good general practice to avoid
multiple setups in schedule files unless they actually have a purpose. The
schedule for this observation contained an unused setup for 6700MHz,
preceding the setup for 6528MHz which was the only one used, despite the
fact that it also specified the wrong frequency! (Since neither setup
actually specified the correct frequency one might wonder even harder why
the second was needed, but I recall there were some last-hour suggestions
to change the frequency of this observation, but these were not adopted).
Cheers,
John R
v156f1pa.prc file used at Parkes - only first setup modified.
define proc_library 00000000000x
" v156f1 PARKES Pa
" drudg version 001211 compiled under FS 9.4.18
" < S2 recorder >
enddef
define setup01 00000000000x <---- 1st mode not used
pcalon
rec_mode=32a4-2,$ <---- mode modified
user_info=1,label,station
user_info=2,label,source
user_info=3,label,experiment
user_info=1,field,,auto
user_info=2,field,,auto
user_info=3,field,v156f1
data_valid=off
enddef
define setup02 04320211250x
pcalon
rec_mode=32x4-2,$ <---- 2nd mode not modified
user_info=1,label,station
user_info=2,label,source
user_info=3,label,experiment
user_info=1,field,,auto
user_info=2,field,,auto
user_info=3,field,v156f1
data_valid=off
enddef
Received on 2005-04-06 17:42:00
Date: Wed, 6 Apr 2005 17:41:45 +1000 (EST)
Richard,
A closer examination of the smouldering log record allows a
reconstruction of events.
The summary is that it appears v156f1 was indeed recorded here in the
wrong S2 mode (32x4-2 instead of 32a4-2, with buggery cable OUT), so that
RCP was recorded on both IFs (instead of RCP and LCP).
It's clear now how this happened. The idea had obviously been to modify
the procedures file (v156f1pa.prc) to substitute S2 mode 32a4-2 for
32x4-2. This had been attempted, but the PI had cunningly defined two
setups (setup01 and setup02) in the procedures file, and the distracted
observer (probably me) had only changed the mode of the first setup. Of
course Murphy is always wide awake is such situations, so the schedule
didn't use setup01 at all, but instead used only setup02. Thus the effect
of the modification was nil!
An extract of the procedure file in question is appended.
The preceding experiment v162c1 was fine - LCP recorded on both channels,
using S2 mode 32x4-2 with buggery cable OUT, as intended.
>>> The bandpass on J1337-6509 for Parkes looks like the parallel hands are
>>> in product 1 and 4 (as opposed to 1 and 2) (I.e. RR and LR rather than
>>> RR & LL (not the labelled values)).
Just what you'd expect - LL weak or missing, and one of the cross-hand
products (LR or RL) a duplicate of RR.
>>> This maybe fixable with in AIPS. Perhaps. Do Tasso or John have any
>>> ideas which might save a recorrelation?
If only! The good news though is that no recorrelation is necessary.
Sorry 'bout that. I guess it might be a good general practice to avoid
multiple setups in schedule files unless they actually have a purpose. The
schedule for this observation contained an unused setup for 6700MHz,
preceding the setup for 6528MHz which was the only one used, despite the
fact that it also specified the wrong frequency! (Since neither setup
actually specified the correct frequency one might wonder even harder why
the second was needed, but I recall there were some last-hour suggestions
to change the frequency of this observation, but these were not adopted).
Cheers,
John R
v156f1pa.prc file used at Parkes - only first setup modified.
define proc_library 00000000000x
" v156f1 PARKES Pa
" drudg version 001211 compiled under FS 9.4.18
" < S2 recorder >
enddef
define setup01 00000000000x <---- 1st mode not used
pcalon
rec_mode=32a4-2,$ <---- mode modified
user_info=1,label,station
user_info=2,label,source
user_info=3,label,experiment
user_info=1,field,,auto
user_info=2,field,,auto
user_info=3,field,v156f1
data_valid=off
enddef
define setup02 04320211250x
pcalon
rec_mode=32x4-2,$ <---- 2nd mode not modified
user_info=1,label,station
user_info=2,label,source
user_info=3,label,experiment
user_info=1,field,,auto
user_info=2,field,,auto
user_info=3,field,v156f1
data_valid=off
enddef
Received on 2005-04-06 17:42:00