1 / 8

GLAST Large Area Telescope ISOC Use of LAT Diagnostic APIDs 8 March 2005 Rob Cameron

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

yagil
Download Presentation

GLAST Large Area Telescope ISOC Use of LAT Diagnostic APIDs 8 March 2005 Rob Cameron

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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 • Solicited • 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?

More Related