[evla-sw-discuss] System design decisions needed for Widar

[Barry Clark]

I'm pleased that Sonja is thinking so much along the lines I think are
necessary.  I included a bunch of stuff in my message mostly so she
would squawk if we had a difference in philosophical viewpoints.

A couple of rather minor comments - setting the gains of the
intermediate stages of the subband filters is a rather esoteric
operation, necessitated only by very strange circumstances.  Setting
the gain of the requantizer is something everybody will want to do, and
t'were well it were done quickly.  There should be a command to grab the
last mean square from the requantizer, and use it to set that gain only.

The 'read rms' command interests me.  An equivalent 'read requantizer
gain' command could be used to implement a 'set and forget' requantizer
gain setting mode, similar to what I have done for the T304 attenuators,
where the attenuator settings from the first ALC command are returned
and stored in the script execution space, and used to set attenuators
whenever you return to the same setup in the same script.  (But, of
course, implementing this would mean Executor would have to know more
about the correlator than it otherwise would.)  I'm not sure how useful
such a mode might be, but I didn't know how useful doing it in the T304
would be until I got yelled at.

Sonja Vrcic wrote:
> 
> Here is my contribution to the dialog.  Sorry if it is too detailed for 
> general discussion. 
> 
> 
> Michael Rupen wrote:
>> A few comments on Barry's discussion points...
>>
>>
>> Seems to me we should start by allowing the user to command a _filter gain
>> check & setup via the VCI _(probably originating in the OPT, passed along
>> via the Executor at observe time), at his/her convenience.  If solar folks
>> want this to happen all the time (assuming we can do the setting very fast)
>> maybe that's a special VCI command as part of the relevant scan(s).
>>
>> Do we want a filter gain check option as well as the filter gain setting?
>> Perhaps we use standard setups (or "no change") unless those filter gains
>> get us too far from optimal, at which point we reset them.
>>
>>   
> VCI  message subarray  allows user to specify action: create (add), 
> delete or modify.
> A subset of subarray parameters that can be modified is still to be 
> defined.
> Filter gain settings should be on that list.
> 
> The exact syntax for filter gain parameters is still to be defined.
> The Station Board filter (FPGA) allows software to set scale for each of 
> the four stages and for re-quantizer.
> 
> The Station Board GUI allows user to specify:
> i)  Desired RMS  for filter stages (applies for all used stages), and
> ii) Desired RMS for re-quantizer.
> 
> GUI allows user to specify RMS for each filter (subband) independently. 
> I presume that VCI should provide the same functionality.
> 
> The GUI algorithm measures the actual RMS for each stage and modifies 
> the scales to achieve desired RMS.
> 
> The following is a proposal for the VCI parameters and functionality for 
> the "filter gain check and setup via VCI" (as mentioned above):
> 
> New parameters to be added to the VCI message subarray/baseband/subband:
> - desired RMS
> - desired RMS for re-qunatizer
> - action: "Measure RMS",  "Set RMS", "Read RMS"
> 
> If action="Measure RMS" there is no need to specify desired RMS.  At 
> activation time, the Station Board CMIB(s) will begin measurement , 
> which may require changes in filter configuration (i.e. output data may 
> be affected).
> If action="Set RMS", at activation time, Station Board CMIB(s) will 
> first measure RMS, and then adjust filter scale, for each used filter 
> stage and for the re-quantizer.
> If action="Read RMS",  ConfigurationMapper will obtain desired RMS and 
> measured RMS from CMIBs  and send that to originator of the query.  CMIB 
> should provide the time stamp for measured RMS, so that we know when the 
> measurement was performed.
> 
> It is my understanding that the filter gain parameters / commands (as 
> specified above) should be specified for each subband independently, and 
> apply for all the stations in a subarray. 
> 
> 
>>> 7.  Scans and subscans.
>>>
>>>     
>>> Also, as mentioned above, it is perhaps expedient to be
>>> able to tell subband filters "This is a new scan - set your output power
>>> level to something sensible." This clearly has to go through the VCI
>>> interface - any problems with that?  We need to decide the message content.
>>> In particular, we would rather like to send a single message, and have
>>> the ConfigurationMapper keep track of what station boards to forward
>>> it to.
>>> (also see footnote 2)
>>>     
> 
> As already mentioned above, VCI message  subarray at action="modify" could 
> be used to modify parameters.
> 
> If preferred, a new XML message "scan" or subScan" can be introduced 
> that would contain only parameters that can be modified without adding 
> additional resources. 
> 
> ....
> ....
>> Perhaps David H. can help out here.  My recollection is that you can send
>> an update to a configuration by name, possibly saying stations=all or some
>> such.
>>   
> Yes. Actually, at this time, it is a requirement that all the stations 
> in a subarray have the same configuration (basebands/subbands).
>> Also there's the question of whether we can send actual filter gain
>> settings. I think we need to be able to do this, and may have this as the
>> standard mode (as compared to ALC loops).
>>
>>   
> Does this mean:  set the actual filter scales via VCI ?
> Could be added.  Easy to implement. The specified scales would be passed 
> to filter(s) without changes.
> Also, the change would be instantaneous, RMS measurements not required !
> 
> ......................
>>> 9.  How does configuration information get from the OPT to the CBE?
>>>     
>>
>> I see this as part of the overall correlator configuration covered in
>> question 8 above.  I think the rest of the discussion below is really about
>> who does the configuration of the CBE.  That's between Sonja and Martin;
>> all the OPT knows about is the need to send VCI commands saying "do this
>> somehow."  Maybe I'm missing something?
>>   
> No, you are right.
> 
> .....................
> ................................
>>   
>>>  From an ethereal plane, one might simply recommend
>>> combining ConfigurationMapper and the CBE master. 
> I strongly believe that Configuration Mapper and CBE Master should be 
> two processes or tasks.
> Nothing prevent them to run on the same machine (MCCC), except 
> performance and reliability.
> But, I would like to keep them as independent as possible.
> 
> Martin and I still have to determine details. In general we agreed that:
> - ConfigurationMapper will send the list of baselines/products  for the 
> new configuration to the CBE Master.
> - For each baseline/product ConfigurationMapper will specify the 
> BaselineBoard; and
> - CBE master will assign CBE Node where to send products (i.e.  
> destination IP address).
> 
> 
> Sonja
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> evla-sw-discuss mailing list
> evla-sw-discuss at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss