Requirements overview
link to COO Detector server page
FITS Format
Slide from Aug 8 email:
Update on ‘KPF current observation ID’ or ‘obsID’
This will be an integer stored in a KTL keyword
At the start of each observation, KTL will send the obsID to the Archons via:
innum (to use in FITS filename)
key (to be included in each header
Timelines
Telemetry
What data was being plotted at Caltech on the web pages, and how was it pulled from the Archons?
Trigger setting in ACF - has this been done?
Add in config table here
Detector Server Commands (Annotated for KPF)
Modified and updated from “Archon Detector Controller Server Command List (KPF comments).xlsx”
I don't see 'extexpose' or 'extreadout' as suggested by Dave in timeline annotations
ID | Command | Description | SG KPF Notes |
1 | abort | abort an exposure in progress (ARC-only) |
|
2 | amplifier | set or get which detector amplifier(s) to use | Is this how we could choose different amplifier schemes? |
3 | basename | base image name for FITS image files | KPF can set this in the config file as it will never change (Green: "KPF_Green_", Red: "KPF_Red_") |
4 | bias | bias voltage | Steve K: would we ever adjust this or is it set once and for all in the ACF file? (If we're adjusting it we'll want the value for telemetry) |
5 | buffer | PCI/e image buffer mapping (ARC-only) |
|
6 | cds | CDS/Deinterlace configuration key (Archon-only) | I'm not sure what this is, or if it's used by the KPF Archons |
7 | close | close the connection to the detector controller | No doubt needed by KPF software |
8 | datacube | data cube state | I'm not sure if this is used to make a our FITS with the amplifiers separate? (Manual implies it is more for combining images from multiple exposure runs). |
9 | echo | test server communication | No doubt useful to KPF software development |
10 | exit | exit the server | Likely needed by KPF software |
11 | expose | initiate an exposure | I don't think KPF needs this since we are triggering from TTL? |
12 | exptime | exposure time | I don't think KPF needs this since we are triggering from TTL? |
13 | fitsnaming | FITS filename format | Here we should be able to use the 'number' setting, since with imnum below we can specify which number to use (i.e. we can give it the current obsID) |
14 | framestatus | read the frame status (Archon-only) | Not implemented yet, but I don't think KPF needs this. |
15 | geometry | detector geometry (ARC-only) |
|
16 | getp | get parameter value (Archon-only) | We could used this to get telemetry, one parameter at a time. However, the native Archon commands STATUS and SYSTEM might be easier/faster as telemetry is returned en mass. |
17 | hdrshift | HDR bit-shift value (Archon-only) | I'm not sure what this is, or if it's used by the KPF Archons |
18 | heater | control HeaterX module (Archon-only) | We will definitely want to query and change the HeaterX values for tuning and engineering/maintenance. |
|
| set target | |
|
| set PID parameters | |
|
| set ramp and ramp rate | |
19 | imdir | base image directory for FITS image files | Since this won't change it can be hard-set in the config file. |
20 | imnum | image number for FITS image files | KPF will want to use this and set it to the obsID for each exposure. Then images will be named G_obsID.FITS or R_obsID.FITS |
21 | inreg | write to VCPU input register (Archon-only) | I'm not sure if our Archons are using this |
22 | interface | return the detector interface type | Perhaps we want this as a record in case it changes? Keyword? |
23 | key | add FITS keyword to user-defined database | Would be nice to send the obsID ot the header as a keyword as well (records it for posterity since filename obsID will disappear once it is absorbed into the L0 FITS). This might be the only FITS keyword we send to the Archons. |
24 | load | load firmware into detector controller | We'll want this for engineering only, so that we can upload a new ACF file if needed. Not sure what manual means by 'power to detector will be off after' (does another command need to follow this?) |
25 | loadtiming | load timing script and parameters (Archon-only) | Is this needed as part of an ACF upload? |
26 | longexposure | long exposure mode to extend exptime unit (Archon-only) | Since we are using a TTL-driven trigger exposure I don't think we'll need this |
27 | mode | camera mode (Archon-only) | The default KPF mode will be all 4 quadrants being separate. Is this what we'd use for different readout modes (1, 2, 4 quadrants?) |
28 | open | open a connection to the detector controller | No doubt needed by KPF software |
29 | sensor | set or get temperature sensor current (Archon-only) | Steve K: do the KPF Archons have any of these sensors? |
30 | setp | set parameter value (Archon-only) | I don't think we will set any parameters on the Archon? Not sure what these parameters would be (Steve K?) |
31 | shutter | set or get the shutter enable state on expose | I think we would only use this if we were monitoring the shutter out as an idicator the exposure has begun. |
32 | systemfile | generate a system file (Archon-only) | Not yet implemented, I think not needed by KPF as we'd just use the native Archon commands SYSTEM and STATUS instead |
33 | useframes | set or get the useframes flag (ARC-only) |
|
34 | writekeys | when to write FITS header keywords | Likely we use "before exposure" setting? But perhaps also depends on what Archon does internal telemetry? |
35 | writep | write parameter value to configuration memory (Archon-only) | Not yet implemented. I'm also not sure if we need it. |
Native Archon commands called out in Detector Controller Server manual:
FRAME | Not sure if this is useful to save as telemetry for KPF |
STATUS | Likely our source of telemetry? Or hand-pick parameters? |
SYSTEM | Likely good to log in case hardware changed out at some point |
Add Comment