GLAST Large Area Telescope Gamma-ray Large Area Space Telescope GLAST Large Area Telescope ISOC Use of LAT Diagnostic APIDs 8 March 2005 Rob Cameron rac@slac.stanford.edu 650-926-2989

Agenda Background: Summarize Alert APID and Diagnostic APID potential conflict Review current LAT diagnostic APID telemetry usage Unsolicited, solicited, dwell Determine operational constraints to avoid alert/diag conflicts Assess impact of operational constraints

Background Diagnostic Telemetry has the following uses: Its use would be limited to specific activities where additional data is required Component checkouts: Calibration data Trouble shooting: Table dumps, Memory dumps Its use would be limited to specific times Scheduled downlinks, lasts for the duration of a contact or several contacts Command driven (MOC, ATS or RTS initiated) Event Driven (Fault detection) Because of these (agreements from 11/02), Diagnostic telemetry is assigned same priority (queue) as alert telemetry Only difference is the ‘Alert’ APID range initiates a link.

Background (cont.) TDRSS MA link 1 kbps downlink for shared Alert and Diagnostic telem Presence of Diagnostic telem can impact Alert data Resulting potential problems from continuous Diag data Potential delay of alert data – science impact possible Presence of diagnostic data will prevent alert-initiated link from closing – thermal / power impact possible Link closes after 180 seconds with NO data in the alert/diag queue SSR Partition sizing (very minor issue)

LAT Diagnostic APID Usage Unsolicited Command Response can be turned on, off, or restricted to response only on error EPU boot rare, but (currently) unlimited duration, until stopped by ground cmd NOTE: EPU boot data stream might be put in HSK TCS status 1700 bits/packet can be turned on/off can be throttled: 0.1 Hz max packet rate? NOTE: most important TCS status will be put in HSK Solicited MSG system: contents TBD MEM: SIU, EPU mem dump, OS and App pool space, symbols LFS: directory and file listings, FS status, file dump LIM: Instrument manager: contents TBD Dwell Commanded number of samples Higher cadence HSK

Resolving Any Conflict Potential solutions SC changes: lower diagnostic priority, diagnostic telemetry doesn’t keep alert link open ($$$) LAT changes: change “routinely if enabled” and “unsolicited” Diagnostic packets as packets sent across the science data or HSK channels Operational: ISOC keeps all or subset of “routinely if enabled” features disabled or at low rate during science collection

Operational Constraints TCS NOTE: Cannot keep TCS diag on, as the Alert-initiated MA link would never close EPU Boot rare NOTE: continuous diag data stream is a concern unless moved to HSK, but assess impact of extra 3.2 kbps in HSK MEM used infrequently? use only during RT for monitoring? (But not a concern for pool space: small dataset) LFS File System Status: monitor at least daily, during RT (but only a small response) Directory or Root Listing: used infrequently, only during RT? File Dump: use only during RT, and/or use via science stream MSG, LIM TBD impact NOTE: ISOC should plan to dump and clear MSG log at least daily, during RT ITC, command response Response should be on for all ATS commands low rate, limited response – acceptable impact Response can also be on for file uploads during RT Dwell Constraint on ISOC usage, to be assessed case by case Duration should be limited as much as possible NOTE: Should ISOC use diag commanding in ATS, to coincide with planned RT schedule? Potential impact on Alert capability if scheduled RT comm is missed

Considerations from Erik Andrews EPU ‘Reboot’ a special case with special considerations EPU providing 3.7 kbps of telemetry (is this true?) If SA link is ‘on’, then rate is 1, 2, or 4 kbps. (This would be a concern). If MA link is ‘on’, then 1 kbps will be the rate. Reasonable to buffer/store this data on the SIU? Command Response – Does a command log exist? Could one be maintained and then dumped periodically. Would contain cmds and disposition/status. Errors – Does an error log exist? Would likely include a flag in a tlm packet header somewhere to indicate errors existed (or log empty/not empty) TCS, LSW – since not yet built, maybe can use alternative to ‘unsolicited’? Testing thoughts - What telemetry (of any kind) does FSW need for its FSW testing to verify requirements? What telemetry (of any kind) does DAQ need for its testing of the subsystem to verify requirements? What telemetry (of any kind) does LAT I&T need for its verification and testing of instrument requirements? What telemetry (of any kind) does LAT I&T / ISOC need for Observatory I&T (or on-orbit) testing and checkout?