Seeker (SSE)

From setiquest wiki

Jump to: navigation, search

The Search System Executive (SSE) acts as a master controller for scheduling and monitoring SonATA observations and is represented by the Seeker in the following diagram. The SSE will configure, control and monitor all hardware in SonATA and all resources needed to conduct observations and system tests.

The SSE Software operates on Linux. SonATA will be allocated two of the RF tunings, and currently will use up to 3 dual-polarized beams.

SonataFlow-seeker.png

The Seeker Module is a multi-threaded module that contains the User Interface, the Site, the Scheduler, Strategy, and Activity components, and the interfaces (proxies) to the Signal Processing Modules and the telescopes. The SSE selects the targets and frequencies to observe, points the telescope and beamformers, and tunes the RF receiver. The SSE also tunes and synchronizes the Channelizers and DXs during the observations. There are a number of scripts and executable modules that comprise the SSE.


Sonata-system-overview.png

The first step in the SonATA start up procedure is to source an environmental variables file that defines the physical configuration of the SonATA system. SonATA is very flexible in its configuration. All the components can run on a single host or on multiple hosts. There can be up to 3 single or dual polarization data streams (beams) coming into the system. There is a Channelizer for each beam and polarization. The number of DXs can vary from one to twenty-four or more per beam depending on the capabilities of the host computers.

Next, the runsse.sh script is executed to start SonATA. The runsse.sh script starts the seeker module and the controlcomponents.expect script. It uses the environmental variables to make a list of system components (i.e. the telescope interface, the Archiver, and the Signal Processing Modules-Channelizers, DXs) that will be started by the controlcomponents.expect script.

The User Interface runs as a thread within the seeker and reads text commands to specify component parameters and to start the observations.

The Site manages all the components that are not part of the seeker module, i.e. the ones started by the controlcomponents.expect script. When a component connects to a TCP/IP socket the Site creates a proxy to handle all the communication. Each proxy runs as a separate thread.

Another thread within the seeker is the Scheduler. It maintains a factory map of strategy types and activity types and their initialization routines. The Scheduler starts a Strategy requested by a user command. The Strategy requests the Scheduler to create an Activity that corresponds to that Strategy. It is possible to run a sequence of strategies with one command. For normal observing the list of strategies includes antenna selection, beamformer initialization, and calibration, and observing.

There are strategies for beamformer initialization and calibration as well as targeted SETI observing. The Strategy runs as a separate thread. For the Observing Strategy, each Activity, an observation, is defined by the target list and frequency range. Each Activity has a fixed length Data Collection. There are many other parameters, but they do not change between Activities.The Strategy can run in automatic mode where it selects the target stars and frequencies based on the observation history in the database. It also can run in user mode where the user can specify the targets and frequency.

The Activity sends point and tune requests to the telescope and beamformers. After the telescope is on target and the beamformers are ready, the Activity creates an Activity Unit for each DX to handle all the communication to and from that DX. The Activity coordinates all the Activity Units so that they are synchronized to start at the same time and wait for completion of all units before proceeding to the next state.

An Activity Unit communicates with its parent Activity and a single DxProxy that communicates with a single DX process. There is an Activity Unit for each and every DX process. An Activity Unit persists only as long as the one Activity it is a part of. The DxProxy persists as long the DX process is running. The DxProxy will terminate on a fatal error in the DX process or on a shutdown or reset socket command. The DxProxy can communicate with two Activity Units at a time -- one Activity being in Data Collection and the other in Signal Detection.

The Archiver is a separate module that stores channelized data from the DXs to the disk for possible post-processing.

Each observation passes through a series of states -- initialization, telescope pointing and tuning, beamformer tuning, baseline accumulation and data collection (collectively referred to as Data Collection); followed by signal detection, candidate selection, primary confirmation, secondary conformation, candidate resolution, and candidate archiving (collectively referred to as Signal Detection). If there are unresolved candidates, a followup observation is queued.

The system operates with a two-stage pipeline when running an Observing Strategy: that is, there are two observations active at once, one in Data Collection while the previous is in Signal Detection.

External links


← SonATA Overview Index Seeker Module →
Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox