1. 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

2. 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

3. 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.

4. 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)

5. 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

6. 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

7. 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

8. 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?