# Presentation: 111084

## Onboard Science Processing

- S. Ritz
- F-FIDT March 2002

## Agenda for This Session

- Look at the existing requirements, ensure common understanding
- Top-level implications for onboard software
- Algorithm concepts
- Burst alert handling
- Discussion, next steps

## Context: Instrument Triggering and Onboard Data Flow

- _Hardware trigger_ based on special signals from each tower; _initiates readout_
-  Function: 	• “did anything happen?”
-                  	• keep as simple as possible

**• ****TKR 3 *****x*****•*****y***** pair  planes in a row********
**  **_**workhorse **__****__** **__**trigger**_

**Instrument Total L1T Rate: <4 kHz>**

**•  ****subset of full background rejection analysis, with loose cuts**
** ****only use quantities that**
**are simple and robust**
**do not require application of sensor calibration constants**

- _full instrument_ information available to processors.
- Function:  reduce data to fit within downlink
- Hierarchical process: first make the simple selections that require little CPU and data unpacking.

**Total L3T Rate: <25-30 Hz>**

**•  ****complete event **
**   ****information**
**•  ****signal/bkgd tunable, **
**   ****depending on analysis**
**   ****cuts:**
**      **** ********cosmic-rays********~ 1:~few**

**Spacecraft**

_***OR***_

**(average event**
**  ****size: ~8-10 kbits)**

****4 kHz orbit averaged without throttle (1.8 kHz with throttle); peak L1T rate is approximately 13 kHz without throttle and 6 kHz with throttle).**

- Upon a L1T, _all towers_ are read out within 20s

**Level 1 Trigger**

**On-board  Processing**

- _On-board science analysis:_
-  transient detection (AGN flares, bursts)

## Requirements

- Requirements on transient recognition and localization are *meaningless* without specifying the characteristics of the flux (#photons, energy, time period).
- The Science Requirements Document (SRD) shows these requirements:
- 10 arcmin(3 arcmin goal) GRB localization accuracy onboard for any burst that has >100 detected photons with E>1 GeV arriving within 20 seconds.
- 5 second (2 second goal) notification time to spacecraft relative to time of detection of GRB
-  NO requirements on AGN flare detection onboard in SRD.

## Broad Implications for Onboard Reconstruction

- With 100 photons, the mean per-photon pointing error for E>1 GeV onboard is _comfortably LARGE_.  Rudimentary gamma direction reconstruction onboard is anyway needed for earth albedo gamma rejecton.  The crude precision needed to meet the SRD requirements should not be a driver (but better is better).
- The expected (non-transient) gamma rate (E>20 MeV) is a few Hz; the residual rate for downlink (independent of science analysis onboard) is ~30 Hz.  Recognizing that >100 photons with E>1 GeV have arrived within a 20 second interval from one direction should not require precision reconstruction or background rejection better than that needed to meet telemetry requirements.  Must prove this.

## Additional Goals in LAT Performance Spec (PS)

- AGN flare localization < 2° for flares that occur within the LAT FOV at high gal. lat., with F > 2 x 10-6 ph cm-2 s-1 (E > 100 MeV) that last for more than 1000 secs.
- For these flare parameters, notify spacecraft <1 min after recognition of flare.
- This recognition and localization goal is not easy:
- Assuming 30 Hz event rate (residual photon candidate rate after standard onboard filter), on average there will be ~5 photons per square degree bin in the FOV after 1000s.  Change in flux corresponds to ~5 detected photons.
- => Meeting the goal is not possible without additional onboard filtering (additional factor 10 needed --- not crazy to consider).
- This is a GOAL, and should not be a driver.  First approach should be to extend GRB onboard analysis to longer timescales and see how well we do.  A simple energy cut will also help here.
**The science justifies making an effort!  However, it should be lower priority than other onboard software tasks.  **

## Algorithm Concepts

- Earliest idea was to construct two-dim histograms of fixed angular size, filled and examined on different timescales (seconds, minutes, hours) for significant fluctuations.  Note that day-long timescale transients will be found on the ground with quicklook analyses.  This is NOT OPTIMAL:
- PSF changes rapidly with energy, so setting the bin size is not straightforward.  A minimum energy cut might help, but binning throws away useful information that would not require large CPU resources to exploit!
**Alternative idea** (Jay Norris): Don’t bin the events.  Instead, keep updated lists of events (time, sky position, energy) over different time scopes, and examine these lists periodically for clustering.  Different strategies possible (seed with highest energy events; examine all pairs for closest neighbors; etc.).  With our event rates, these lists are not long and do not require significant resources.
- This uses more of the information in a more efficient manner.

## Jay’s First Look

- 			 Search sliding 20-event window – forming their N(N-1)/2 distances.
- 			 Choose cluster for event with smallest average distance within 35 circle.
- 			 Form joint spatial and temporal Likelihood for events within circle,
- 					*L*  =  - log{ ()  (t) } .
- 			 Set threshold such that GLAST sees ≲ 1 false trigger per ~ week.
**Summary:  GLAST GRB Tracker Trigger Algorithm**
-  		 Unbinned (in time and space) approach fully exploits available information.
- 		 Triggers on ~ 85% of BATSE-like bursts, ~ 233 / 270 (number per year).
- 		 Triggers on ~ 78% of these bursts visible to GLAST in less than *one second*,
- 			With *fewer than one* *false trigger* *per 3 days*.
- 		 Refinements will include:
- 			–  Spatial dependence of diffuse gamma flux
- 			    (Galactic Plane emission could dominate residual CR flux after L3T.)
- 			–  Temporal dependence of on-board residual cosmic-ray flux
- 		**– ****Reconsideration of L3T background rejection**
**	****	****-Reconsideration of clustering algorithm (make simpler)**
**	****	****-Degrade PSF to reflect better what can be expected onboard**
- 	 If trigger provided by GRB context instrument, then perhaps
- 		include this information in the algorithm?

**Jay’s First Look**

## Observatory Handling of Transients (Bursts)

**	****	****	****	****If the burst is bright enough that an on-board analysis provides >90% certainty that a burst occurred within the LAT FOV, the observatory will slew to keep the burst direction within 30 degrees (TBR) of the LAT z axis during >80% of the entire non-occulted viewing period (neglecting SAA effects).  Such events are estimated to occur approximately once per week.**

**Observatory Handling of Transients (Bursts)**

_**Summary of plan**_
**During all-sky scanning operations, detection of a sufficiently significant burst will cause the observatory to interrupt the scanning operation autonomously and to remain pointed at the burst region during all non-occulted viewing time for a period of 5 hours (TBR).****  There are two cases:**

** ****1. **_**The burst occurs within the LAT FOV.**_** **

**2. **_**The burst occurs outside the LAT FOV.**_

**After six months, this strategy will be re-evaluated.  In particular, the brightness criterion for case 2 and the stare time will be revisited, based on what has been learned about the late high-energy emission of bursts.**

## Observatory Handling of Transients (AGN)

_**PLAN FOR THE FIRST YEAR**_
**Most AGN science can be best addressed by the all-sky scan****.**
** **
**Unusually large flares will be treated as **_**Targets of Opportunity**_**, and studied in a coordinated multi-wavelength campaign.  **
_**Thus, autonomous repointing of the spacecraft is not required for AGN science during the first year.**_
- This approach will be re-evaluated after the first year, as new knowledge about AGN might demand a new strategy.

## Burst Alerts Information Flow

_**S/C**_

_**GBM**_

_**LAT**_

- Classification, Location,
- Hardness, Initial Flux

- Flux, Fluence, Hardness
- (Running Updates)

- Parameters

- Science Repoint Candidate

- Quick Test?

**Burst Alerts Information Flow**

- S/C Repoint
- Decision

- Mode Change
- ?

- Direct link

- < 2 s

- Begin R/T downlink

- Continue R/T,
- 5 - 10 min.

- GBM

- LAT

- GBM/LAT

- S/C

- LAT information
- +
- GBM Information packet
**Repoint request**

- < 5ms

- 2 to ~60 s

- Parameters

- GBM Information Packet

## Next Steps

- define performance requirements for onboard reconstruction (efficiency, PSF, etc.)
- false alarm probability requirements
- algorithm definition (repoint requests, localization, alerts) with flight software group.
**Join the fun!**