[evla-sw-discuss] Controlling the baseband slope correctors

[Bryan Butler]

(and actually where i say "band changes" below, i really mean "frequency 
changes", since the bandpass will change within a band with a frequency 
change for the higher frequencies.)


Bryan Butler wrote, On 8/9/10 09:15:
> barry - are you thinking that the rms and slope will actually change on 
> 10 second timescales?  or is that just to react to band changes?  i'd 
> have thought it'd be stable except for band change, so 10 seconds is too 
> often when not changing bands and not often enough when doing so 
> (because you want things settled down more quickly than 10 seconds in 
> some cases on a band change).  i wonder if we could send a trigger to 
> the CMIB to ask for this, rather than having it every 10 seconds, to cut 
> down on traffic?
> 
> 	-bryan
> 
> 
> Barry Clark wrote, On 8/4/10 16:56:
>> To set the baseband slope correctly, the least complicated approach
>> is to use the Wide Band Correlator on the station board to see the
>> overall shape of the spectrum, and have it report the correction
>> needed to the Executor, which would then forward it to the slope
>> corrector in the T304 modules.
>>
>> This is because the required slope is a function of antenna, band,
>> and location within the band.  To do it by tabulation would require
>> maintenance of a very large table which would change from time to
>> time as receivers are serviced or replaced.  (The slope required
>> may also be a function of which T304s are installed, although these
>> are believed to be much more uniform than the receivers.)
>>
>> The Executor could handle this information in the same way it currently
>> handles reference pointing, phasing, and, indeed, setting T304 levels.
>>
>> What the Executor would like to see is just an rms and slope from
>> the WBC, one for each baseband in the array.  I suggest the following
>> XML descriptor.
>>
>>    <xsd:complexType name="WbcDataType">
>>      <xsd:sequence>
>>        <xsd:element name="rms" type="xsd:float" />
>>        <xsd:element name="slope" type="xsd:float" />
>>      </xsd:sequence>
>>      <xsd:attribute name="antId" type="xsd:string" />
>>      <xsd:attribute name="baseBand" type="xsd:string" />
>>      <xsd:attribute name="avg" type="xsd:double" />
>>      <xsd:attribute name="time" type="xsd:dateTime" />
>>    </xsd:complexType>
>>
>> These would probably come packaged in an envelope, either for a lot
>> of antennas if they come from some collector in the correlator, or
>> with just a couple if they come directly from the station board.
>>
>> Worst case is eight basebands from 28 antennas, 224 elements in all.
>> The whole works might fit in a 16K datagram.  I think a reasonable
>> averaging time (avg above) would be 10 seconds.  (The consideration
>> is only to keep the traffic at a low level while still getting answers
>> on a script-type timescale.)  I guess CM will need to send this
>> averaging time to the StB.
>>
>> These need only be sent when in three bit mode.
>>
>> The rms above is just the lag zero autocorrelation, divided by
>> averaging time and suitably scaled.
>>
>> The slope is a little more difficult.  If computation is not a
>> consideration, you calculate the spectrum and see which slope
>> corrector works best, calculating the goodness of fit of
>>     a*10^{0.1*n*(f/bw)}
>> for, say, n in the range -10 to 10 and reporting the best n.
>> If calculation is a problem, a reasonable guess can be made directly
>> from the lags.  (The lag beyond which the correlation is low is
>> a measure of the magnitude of the slope; whether there are nulls
>> before then gives the sign.)
>> _______________________________________________
>> evla-sw-discuss mailing list
>> evla-sw-discuss at listmgr.cv.nrao.edu
>> http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss
> _______________________________________________
> evla-sw-discuss mailing list
> evla-sw-discuss at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss