<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
> Emmanual (cc'ed here) may remember/know more than I about how effective it was.<br>
> If the main purpose was to deal with the differing  analog filter<br>
> bandpasses, that is now moot because of the use of digital filtering.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Indeed, alternating the RCP and the LCP routes during an observing session in the pre-EVLA era was critical for Zeeman studies. In the post-upgrade era his technique was no longer needed, as the EVLA system has a robust performance when it comes to bandpass
 stability.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
EM<br>
<br>
<br>
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="appendonsend"></div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<hr style="display: inline-block; width: 98%;">
<div id="divRplyFwdMsg">
<div style="direction: ltr; font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<b>From:</b> Ken Sowinski <ksowinsk@aoc.nrao.edu><br>
<b>Sent:</b> Sunday, July 13, 2025 14:41<br>
<b>To:</b> Emmanuel Momjian <emomjian@aoc.nrao.edu>; Paul Demorest <pdemores@nrao.edu><br>
<b>Cc:</b> evlatests <evlatests@nrao.edu>; Ken Sowinski <ksowinsk@nrao.edu>; Hichem Ben Frej <hbenfrej@nrao.edu>; Cameron P. Sanchez <cpsanche@nrao.edu><br>
<b>Subject:</b> Re: S5/S6 investigation</div>
<div style="direction: ltr;"> </div>
</div>
<div class="elementToProof" style="font-size: 11pt;">On Fri, 11 Jul 2025, Paul Demorest wrote:<br>
> hi all,<br>
><br>
> Earlier this week, Cameron pointed out several antennas that are<br>
> reporting unexpected values for S5 and/or S6.  Ken and I investigated<br>
> some this week, and Hichem sent some useful info.  Here's a report for<br>
> the record, the short story is that a few of these switches do appear<br>
> stuck/broken, but the state they are stuck in is correct for normal<br>
> operations and there is no need to make any changes or repairs.  More<br>
> details for those interested:<br>
><br>
> These "transfer" switches have the effect of swapping the RCP and LCP<br>
> signals before the T304 inputs.  S5 swaps the A and C IFs, S6 swaps B<br>
> and D.  Each switch can have two states, which I will call "normal" and<br>
> "swapped".  In regular operation, all are in the normal state; the<br>
> executor is hard-coded to command them to normal at the start of each<br>
> scan.  The only way to temporarily set them to swapped is via a manual<br>
> MIB command from device browser or telnet.  I suppose these switches<br>
> were intended to help troubleshooting(?), but this functionality is<br>
> basically never used AFAIK.<br>
<br>
Some historical context.<br>
<br>
Yes, it was mainly for diagnostic pusrposes and was frequently used<br>
for that in the pre-EVLA days to isolate problems to before or after<br>
the xfr switch.  As Paul writes it has rarely been used since then,<br>
mostly because we never think of it, and have no easy access to it.<br>
<br>
It aso had an astronomical justification.  Milller ocassionally did Zeeman<br>
experiments using the xfr switch to alternately route RCP and LCP into<br>
the same IF and sampler to preclude bandpass differences between the<br>
two IFs that would otherwise require difficult bandpass calibrations.<br>
I imagine it must have worked because he did this many times.  Emmanual<br>
(cc'ed here) may remember/know more than I about how effective it was.<br>
If the main purpose was to deal with the differing  analog filter<br>
bandpasses, that is now moot because of the use of digital filtering.<br>
<br>
Ken<br>
<br>
<br>
> The two switches are combined into a single mon/ctrl point,<br>
> M301_SW.SW_S5_S6_MON/CMD.  There are only four allowed values:<br>
><br>
> 0x0 = both normal<br>
> 0x4 = S5 swapped, S6 normal<br>
> 0x8 = S5 normal, S6 swapped<br>
> 0xC = both swapped<br>
><br>
> Given that the switches are never exercised, we expect all antennas to<br>
> read 0x0 at all times.  Mostly this is true, except we see ea04=0x8,<br>
> ea14=0xC, ea17=0xC and ea27=0x4.  Ken and I both tried sending various<br>
> commands but it seems that for these antennas one or both switches are<br>
> stuck in the swapped state:  S6 for ea04, S5 for ea27 and both for<br>
> ea14/ea17.  For ea04 and ea27 the non-stuck switch does respond to<br>
> commands as expected.  For one normal antenna (ea01), both switches<br>
> responded to commands as expected.<br>
><br>
> Regarding the effect on data, it is easy to see if RCP and LCP are truly<br>
> swapped on an antenna:  On a typical low-polarization source,<br>
> parallel-hand correlation amplitude (vs the other normal antennas) will<br>
> be low while cross-hand correlation is high.  This is NOT seen during<br>
> regular observing so that either means: these stuck switches are<br>
> reporting an incorrect state; OR maybe someone has worked around the<br>
> problem by also swapping the input or output cables (thus cancelling out<br>
> the swap in the switch).  For practical purposes it doesn't really<br>
> matter too much which is the real explanation.  The current setup is<br>
> working fine and there is no need to mess with it.<br>
><br>
> I tested exercising the switches on ea01 and ea04 while observing a<br>
> bright source.  Both ea01 switches acted as expected:  The signal moved<br>
> from parallel-hand to cross-hand correlation when the relevant switch<br>
> was commanded to swapped position.  And the switches all revert to<br>
> normal position at the start of a new scan.  For ea04 I was able to swap<br>
> A/C via S5, but not able to get S6 to change its state.  So the<br>
> interpretation from looking at the data was consistent with the M&C<br>
> readings.<br>
><br>
> I did not check any antennas other than the ones mentioned here so it<br>
> might be possible there are others that are stuck in the "normal" state.<br>
><br>
> One final thought is that since we don't really need S5/S6, if these<br>
> could be repurposed to replace any of the other failing band/LO switches<br>
> that would be fine in my opinion.  I'd guess this is unlikely since it's<br>
> a different style switch though.<br>
><br>
> Cheers,<br>
> Paul</div>
</body>
</html>