moot for week of 29 July 2005

2. The Delegates
2.1 Description and parameters
2.2 Responsible services

MOOT Report for Week of 29 July 2005

1. Modes

In the LIM Design document the modes are listed—without the color-coding or bracketed remark—as

**LIM Operating Modes**
Name	Description
Boot	Primary Boot Code (PBC) running [in the SIU] and LIM not running.
Terminal	Initial LIM mode.
Quiescent	Ready for physics observations, calibration, or diagnostics.
Hold	Stable mode for troubleshooting.
Diagnostic [aka Engineering]	Diagnostic functions are active.
Calibration	Charge injection calibration functions are active.
Physics	Normal sky survey or pointed observation activity is in progress.
ToO	Target of Opportunity observation activity is in progress.
ARR	Autonomous Repoint Request activity is in progress.

From MOOT's perspective, the last three can be treated as variants of Physics mode and the first four can also be grouped together into just one or two major MOOT modes. For now lump together the first four line in the table into a made-up category called Unavailable

2. Delegates

Concentrate on Physics and Calibration to start as the most in need of the tracking MOOT is intended to provide.

2.1 Delegates and their parameters

See preliminary list for Physics below. It is most likely incomplete and inaccurate; it's included in the hope that other people will take a look and make suggestions to get it closer to reality.

Players or Plumbing: which towers, etc. are powered on and engaged; which of redundant components are in use
Housekeeping: scheduling information
Low-rate science counters: ??
Flight software configuration: Stack sizes and similar system-level stuff
Event filter: CAL gains and pedestals); energy cuts(not very volatile), sampling parameters, summary statistics rate; (register) discriminator settings (except it's not just the event filter that is a client for these, so they probably belong under some other, more general delegate
Timing: Various timing values set into registers concerning trigger delays and readout
Trigger: Register values used to parametrize trigger conditions, e.g. prescale value, definition of CNO condition,.. Does this also include masking/enabling of 3-in-a-row combinations?
TKR-specific enable/disable configuration: Masks to establish what's on and off; include splits here? What about masking/enabling trigger primitives? Does that go here or under Trigger?
Other TKR-specific config: thresholds
CAL-specific enable/disable configuration: Masks to establish what's on and off. What about masking/enabling trigger primitives? Does that go here or under Trigger?
Other CAL-specific config: thresholds
ACD-specific enable/disable configuration: Masks to establish what's on and off
Other ACD-specific config: thresholds

One can make a case for combining some of these (e.g., TKR-specific enable/disable configuration; other TKR-specific configuration) to make a slightly shorter list. I've tentatively opted for the finer division because it seems likely these different kinds of configuration might be updated at different times.

The list for Calibration would be very similar to the above, however it would include an additional delegate for the charge injection parameters (e.g., dac settings).

2.2 Responsible services

Who is responsible for making sure that a particular configuration value gets to the right place; e.g. who sets a particular register or register field? The question is further complicated by the fact that some registers might have more than one "owner": one component might set a register to an initial safe value; then when the truly responsible party (e.g., a software task like Event Filter) is ready it can set it to the correct final value. And some registers have individual fields which don't necessarily belong to the same function.

Delegate	Parameter	FSW handler
Players	all	PIG
Housekeeping	all	LHK
Low-rate Science Counters	all	LMC
FSW system parameters	all	FMX?
Filter	cal gains, pedestals	written in FSW code, handled by FMX
Filter	energy cuts	written in FSW code, handled by FMX?
Filter	sampling parameters	written in FSW code, handled by FMX?
Filter	summary statistics rates	written in FSW code, handled by FMX?
??	discriminator settings	LATC?
Timing	"one-time write" registers in terminology of LATC User Guide	written in FSW code, handled by FMX?
Trigger configuration	ROI, etc.	These correspond to GEM registers which are settable from LATC, but is that the way they will be set? Or will they be set by FSW code?

3. A little more about MOOD

Last week's notes suggested MOOD would have a minimum of two tables, known as Configs and History. It might be preferable to have, in addition to these tables, a table per delegate or perhaps just a single Delegates table. A row in Configs would then have references to rows in Delegates where the detailed information would reside.

Another table, very much like the one now used in the Offline calibration metadata database, could be used to keep track of source files like those input to LATC and other FSW services. Such files would more or less correspond to parameter values for the delegates. The table should be designed in such a way that MOOT can look up the files it needs by their properties and discover the filename, file format, etc.

4. Schedule, To do

From last week

Make a list of modes and delegates. Aim for completeness, though it likely won't be achieved. See 1. and 2. above
Make a stab at listing parameters for the major delegates involved in Calibration and Physics modes. See 2.1 above.
Come up with one or two milestone-type jobs with a completion date on the order of a month from now. Carry over to this week's list.

For next week

Come up with one or two milestone-type jobs with a completion date at least a bit before Aug. 20 (when I go on vacation for 10 days).
Refine MOOD design; take into account interactions with Bryson's Activity Database.
Refine delegate parameter list

Last week (21 July 2005)

Initial draft: 28 July 2005
Last revised:

J. Bogart