<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<font size="-1"><br>
<big>Here is my contribution to the dialog. Sorry if it is too
detailed for general discussion. <br>
</big></font><br>
<br>
Michael Rupen wrote:
<blockquote cite="mid:Pine.LNX.4.64.0909220823310.26590@scamper"
type="cite">
<pre wrap="">A few comments on Barry's discussion points...
Seems to me we should start by allowing the user to command a <u>filter gain
check & setup via the VCI </u>(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.
</pre>
</blockquote>
VCI message subarray allows user to specify action: create (add),
delete or modify. <br>
A subset of subarray parameters that can be modified is still to be
defined. <br>
Filter gain settings should be on that list. <br>
<br>
The exact syntax for filter gain parameters is still to be defined.<br>
The Station Board filter (FPGA) allows software to set scale for each
of the four stages and for re-quantizer. <br>
<br>
The Station Board GUI allows user to specify:<br>
i) Desired RMS for filter stages (applies for all used stages), and <br>
ii) Desired RMS for re-quantizer.<br>
<br>
GUI allows user to specify RMS for each filter (subband) independently.
I presume that VCI should provide the same functionality. <br>
<br>
The GUI algorithm measures the actual RMS for each stage and modifies
the scales to achieve desired RMS.<br>
<br>
The following is a proposal for the VCI parameters and functionality
for the "filter gain check and setup via VCI" (as mentioned above):<br>
<br>
New parameters to be added to the VCI message subarray/baseband/subband:<br>
- desired RMS<br>
- desired RMS for re-qunatizer<br>
- action: "Measure RMS", "Set RMS", "Read RMS"<br>
<br>
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).<br>
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. <br>
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. <br>
<br>
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. <br>
<br>
<br>
<blockquote cite="mid:Pine.LNX.4.64.0909220823310.26590@scamper"
type="cite">
<blockquote type="cite">
<pre wrap="">7. Scans and subscans.
</pre>
</blockquote>
<blockquote type="cite">
<pre wrap="">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)
</pre>
</blockquote>
</blockquote>
<br>
As already mentioned above, VCI message subarray@action="modify" could
be used to modify parameters. <br>
<br>
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. <br>
<br>
....<br>
....<br>
<blockquote cite="mid:Pine.LNX.4.64.0909220823310.26590@scamper"
type="cite">
<pre wrap="">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.
</pre>
</blockquote>
Yes. Actually, at this time, it is a requirement that all the stations
in a subarray have the same configuration (basebands/subbands).<br>
<blockquote cite="mid:Pine.LNX.4.64.0909220823310.26590@scamper"
type="cite">
<pre wrap="">
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).
</pre>
</blockquote>
Does this mean: set the actual filter scales via VCI ? <br>
Could be added. Easy to implement. The specified scales would be
passed to filter(s) without changes. <br>
Also, the change would be instantaneous, RMS measurements not required
! <br>
<br>
......................
<blockquote cite="mid:Pine.LNX.4.64.0909220823310.26590@scamper"
type="cite">
<blockquote type="cite">
<pre wrap="">9. How does configuration information get from the OPT to the CBE?
</pre>
</blockquote>
<pre wrap=""><!---->
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?
</pre>
</blockquote>
No, you are right. <br>
<br>
.....................<br>
................................<br>
<blockquote cite="mid:Pine.LNX.4.64.0909220823310.26590@scamper"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap=""> From an ethereal plane, one might simply recommend
combining ConfigurationMapper and the CBE master. </pre>
</blockquote>
</blockquote>
I strongly believe that Configuration Mapper and CBE Master should be
two processes or tasks.<br>
Nothing prevent them to run on the same machine (MCCC), except
performance and reliability. <br>
But, I would like to keep them as independent as possible. <br>
<br>
Martin and I still have to determine details. In general we agreed that:<br>
- ConfigurationMapper will send the list of baselines/products for the
new configuration to the CBE Master. <br>
- For each baseline/product ConfigurationMapper will specify the
BaselineBoard; and <br>
- CBE master will assign CBE Node where to send products (i.e.
destination IP address).<br>
<br>
<br>
Sonja <br>
</body>
</html>