Gregorian cal selection failure Nov17

Most receivers have 2 diodes that can feed polA or polB. The possible selections are:

cal type	polA	polB
hcal	Diode1	Diode2
hcorcal	Diode1	Diode1
hxcal	Diode2	Diode1
h90cal	Diode2+90deg	diode2
lcal	Diode1	Diode2
lcorcal	Diode1	Diode1
lxcal	Diode2	Diode1
l90cal	Diode2+90deg	Diode2

Where H is the high cal and L is a lowcal (an attenuator gets switched in).

The cal type selection failed on 13Nov17. It was fixed on 05dec17 14:00 ast.

The hi/low cal selection continued to work.

There are two bits that select the type of cal (and 1 more bit for the h/l cal).
The bits come from:

downstairs gpib command ->
hp3488 digital output device in dome ->
cal multiplexer on the the rotary floor ->
the bits then fan out (in parallel) to the 12 receivers postamp chassis.

When a cal type request (eg corcal) is made, the request ends up going to all of the receivers at the same time.

The problem occurs if a receiver postamp chassis is powered off.

When this happens, the ttl level drops to below 3 volts.
It looks like the corcal then ends up being selected..no matter what was requested.
When debugging the problem,

We checked all receivers and only the 430 receiver was selecting the hcorcal correctly.
This is probably related to a ttl threshold voltage.. where the 430 box meets the ttl high criteria (just barely).

The cband wide postamp chassis was powered off 13Nov17 at 09:42 ast.

The problem was also seen in the daily tsys measurements:

For each receiver, the system temperature is measured using all of the cal selections.
on 13Nov17 the tsys values for the different selections changed by a few kelvins.

It would ask for hxcal, but the selection would remain at hcal.

I looked at the cal deflections for runs with polarization data (cross correlations between polA,polB)

A3119 mock spectrometer data (.ps) (.pdf)

This is lband wide data.
The colors are: red:I, green:Q, blue:U,, purple:V
For the correlated cal, the diode is injected with close to the same phase in polA and polB

So the cal should come out in stoke U (linear 45 degrees between A,B)
The caldeflection (calon-caloff) should be in the blue trace, and it's amplitude should equal stokes I.

The table shows the caldeflection for the different dates (usually the first scan of the date).

page	date	Correlated cal deflection	Hcorcal
1	03sep17	StokesU=StokesI	works
2	08sep17	StokesU=StokesI	works
3	09sep17	StokesU=StokesI	works
4	10sep17	StokesU=StokesI	works
5	02dec17	StokesU=0	no hcorcal
6	03dec17	StokesU=0	no hcorcal
7	04dec17	StokesU=0	no hcorcal
8	05dec17 12AM ast	StokesU=0	no hcorcal
9	05dec17 19:00 ast	StokesU=StokesI	works
10	06dec17 12am ast	StokesU=StokesI	works

I also looked at interim correlator data for x102 and A3172 (.ps) (.pdf)

page	date	proj	Rcvr	correlated cal deflection	Hcorcal
1	06Nov17	x102	cband	StokesU=StokesI	works
2	22Nov17	x102	lbw	StokesU=0	no hcorcal
3	28Nov17	a3172	lbw	StokesU=0	no hcorcal
4	02dec17	a3172	lbw	StokesU=0	no hcorcal
5	06dec17	a3172	lbw	StokesU=StokesI	works

Summary:

The caltype selection failed on 13Nov17 at 09:42 ast

The hi/low cal selection continued to work.

This was caused by powering off the cband wide postamp chassis.
The problem was fixed (cband wide chassis powered back on ) 05dec17 14:00 ast.
While the cbw postamp chassis was powered off.

all receivers (except maybe 430 dome) had hcal (uncorrelated cal) selected. independently of what the user asked for.

This gave two problems:

If you were doing polarization work, and needed the correlated cal to measure the phase difference between polA and polB lines,

You don't have that information. PolA and polB had different diodes, so there is no correlation between them.

The header information will say that the hcorcal was selected (even though the hcal was used).
When processing the data, the cal values for hcorcal and hcal are a little different, so the calibration will be off by a little.

processing: x101/171205/lbwcarl_mock, lbwcarl_icor.pro

 home_~phil