[evlatests] BD T304 power meters and attenuators

[Bob Hayward]

Just a reminder that a Look-Up-Table for some of the receiver bands, 
particularly those with bandwidths greater than 4 GHz, will require a 
lot of LUT "user cases". The required attenuator settings will be very 
dependent on the chosen RF center frequency as well as the LO's being 
used in the conversion chain. Also, every time a receiver or LSC or UX 
Converter Module or T304 Downconverter is swapped out, the LUT would 
probably have to regenerated. Logistically, the fewer receivers that 
operate with LUT's, the better.

On the other hand, we've seen how we can run into problems when there is 
strong RFI or when the shape of the bandpass at the input of the T304 
deceives the ALC into choosing an inappropriate Input Attenuator setting 
that can result in degraded sensitivity. This is because the RF Total 
Power Detector sees the power across a 5 GHz bandwidth while the Output 
Detector (in the 8-bit mode) sees only 1 GHz. A large mismatch in 
spectral density between the shape of the RF passband and the (1 GHz) 
chunk we want to look at can be bad news. So the ALC is not necessarily 
the best thing since sliced bread.

There may not be a nice simple solution...

-Bob

Rick Perley wrote:
> I am one of those who believe that we should fix (as in set and don't 
> change) the attenuators when in 8-bit sampler mode.  The dynamic range 
> offered by the samplers is far larger than the range of input powers for 
> all conceivable observations (excluding solar).  Even Cyg A and Cas A 
> multiply the total powers by factors of less than ten at L-band (the 
> worst case) -- that's less than 2 bits out of the eight.  The only 
> question remaining is:  what level should the system be set at?  Ken is 
> quite right that using a dynamic system to find and set the level could 
> be dangerous at L-band (and probably S-band as well), so a table value 
> strikes me as the best approach.  The variation in total system 
> temperature at these frequencies is very small -- virtually all the 
> power comes from the receivers themselves.  So a table of attenuator 
> values sounds good to me.
> 
> With 3-bit sampling, we have much less headroom, so we'll likely have to 
> adopt a dynamic approach, particularly at high frequencies where 
> atmospheric emission will greatly increase system power depending on 
> elevation and weather...  Rather than opine in advance of what we should 
> do, I'd prefer some careful tests to determine the best level to set, 
> and to determine by how much the sensitivity changes as the power changes. 
> 
> 
> 
> Ken Sowinski wrote:
>> Rob has told me that power meters are now available in all T304s.
>> This raises the question of what to make the default attenuator
>> setting algorithm for IFs B and D.  I would like to make the
>> ALC at scan change the default and no longer maintain the BD
>> attenuator settings in parminator.
>>
>> Some considerations.
>>
>> OPT generated script would have to set the BD T304s to use
>> set-and-remember whenever it does so for AC.
>>
>> Both IF pairs will now be reasonably set regardless of tuning
>> within a band.
>>
>> We will have to use this, probably without set-and-remember,
>> for the three bit samplers.
>>
>> Use of ALC modes will force us to understand how the attenuators
>> modify bandpasses.  If set-and-rememeber is used too avoid
>> attenuator changes, the details when multiple tunings within a band
>> are used can be messy.
>>
>> When eight bit samplers are used it can be argues that the best
>> approach might be to set all the attenuators from a table of
>> values.  There might be some merit to this at L band where
>> interfence can make ALC operation unreliable.
>>
>>
>> I argue we make ALC the default and allow the ovserver to choose
>> different strategies in the OPT based on the particular scenario
>> for that observation.  Someone will have to invent a few probable
>> and useful scenarios.
>>
>> _______________________________________________
>> evlatests mailing list
>> evlatests at listmgr.cv.nrao.edu
>> http://listmgr.cv.nrao.edu/mailman/listinfo/evlatests
>>   
> _______________________________________________
> evlatests mailing list
> evlatests at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/evlatests