To make a reasonable (conservative) cost estimate we have used the basic design below. This is not necessarily the actual design which will be used inside the camera, in particular some or all modules currently shown in the "Guider Linux Box" may move into the DAQ, and as a consequence some of the communication paths with the observatory may differ from those shown. In particular the DAQ/Guider may communicate to/from the TCS without going via CCS/OCS.
Strawman assumptions
- Guiding Star Catalog and any other configuration needed for guiding are considered part of "camera configuration" and delivered to the camera using the standard configuration system. CCS will record this in the configuration database and ensure the correct configuration is delivered to the Guider.
- We will use a very simple interface between the Guider HCU and the "Guider ROI Selection" and "Guider Centroid Finding" modules. One possibility is that those modules are written as standalone (C++/Python) modules and the Guider HCU starts them and communicates with them via stdin/stdout pipes. Guider configuration would be stored as files in the linux file system on the guider linux box.
- Data flow is as shown below
- Pointing info (per visit) provided by OCS and relayed by CCS to guider linux box.
- Configuration delivered as needed by OCS, stored in camera database and on the guider linux box.
- Guider ROI selection is sent to the Guider HCU, where it is converted to sequencer code (and/or sequencer parameters) loaded into the guider REBs
- Data flows from DAQ to to guider centroid finding (using existing planned push/pull interface)
- Guider centroid fining output is relayed by CCS/OCS to TCS. Some test will be required to confirm that this can meet the latency requirements. Alternatives are a direct interface from guider box to TCS, or use of dedicated DAQ communication.
