[evla-sw-discuss] Simple subarrays: a modest proposal

[Michael Rupen]

Hi Sonja --

   wow, thanks for the quick read!  A few comments on comments...


> Example: VCI documents (messages)  for a set of three subarrays, where
> master SB uses subarray A, while 'slave' SBs 1 and 2 use subarrays B and
> C.
> 
> Please correct me if I am wrong, but I believe that the Executor now
> transmits the following:
>
>  1. subArray-A-Obs123-Master, ActivationID=startSubA
>  2. actTrigger, activationID=startSubA, actTime=12:30:00
>  3. subArray-B-Obs123-Slave1, ActivationID=startSubB
>  4. actTrigger, activationID=startSubB, actTime=12:30:00
>  5. subArray-C-Obs123-Slave2, ActivationID=startSubC
>  6. actTrigger, activationID=startSubC, actTime=12:30:00
> 
> (actually activation  time is staggered by 30sec or so to avoid
> problems).
> 
> If I am right, that there is a way around this problem, but I am not sure
> how difficult it would be to make changes in the Executor to use a single
> Activation Trigger for all SBs in a set (master + slaves) and to transmit
> this:
>  1. subArray-A-Obs123-Master, ActivationID=startObs123
>  2. subArray-B-Obs123-Slave1, ActivationID=startObs123
>  3. subArray-C-Obs123-Slave2, ActivationID=startObs123
>  4. actTrigger, activationID=startObs123, actTime=12:30:00
> CM places received configuration messages (create/delete subarray) in the
> configuration queue.
> Configuration messages are removed from the queue (and processed) when
> Activation Trigger is received.
> To process all 3 messages as a single configuration,  Executor would have
> to assign the same Activation ID to all SBs  (configuration messages)
> that should be activated at the same time, and transmit a single
> Activation Trigger with that Activation ID after all messages are
> transmitted (master + slaves).
> 
> Note: the order in which messages  'create subarray' are transmitted does
> not matter, but the Activation Trigger must be transmitted last, to
> ensure that CM has received all subarrays before Activation Trigger is
> received.
> 
> In this case, CM would process all three subarrays one after the other,
> forward configuration to CBE for all three subarrays one after the
> other;  but this should not cause the type of problems that we see now
> (or should at least minimize them).


I fear that there are upstream (Executor) reasons which would make this
difficult, but I agree that it sounds lovely in principle!
Ken/Barry/Bryan should comment on that aspect.

I could imagine using the subarray name (as you have in the example
above) in such a way that CM would know these are related subarrays and
"stack" them together as you suggest, even without the Executor doing
it.  That would involve tweaking the Activation Trigger.  I suspect you
& Kevin will make similar arguments against this as those Ken et al.
will raise to doing this in the Executor ;)


> When you refer to "the limited number of DUMPTRIGs" isn't that  the
> number of DUMPTRIGs per Station Board, i.e. per antenna. 
> Nominally 16, but CMIB is not able to support that many. But that just
> limits the nummber of different DUMPTRIGS for the subbands of the same
> antenna.
>
>  Not sure what are the restrictions on routing the DUMPTRIGs.
> Perhaps I forgot.


There are limitations on the complexity of the individual DUMPTRIGs
based on the size of the HES they can hold, and some DUMPTRIGs are more
equal than others (i.e., the first two can be more complex).  So you
can't really have 16 equally complex DUMPTRIGs.  Further, I thought I
remembered some restrictions on DUMPTRIG routing, though now that you
mention it those may only apply when you're trying for >16 DUMPTRIGs
for a single set of stations.  Which would be very pleasant :)


Cheers,

           Michael