Telescope Simulator

From setiquest wiki

Jump to: navigation, search


Project Overview - Telescope Simulator

We wish to develop a telescope simulator. In this context the "telescope" is the entire data gathering device consisting of the antenna dishes, as well as the controlling computer and software. SonATA controls and monitors the ATA telescope solely through a TCP socket, passing back and forth ASCII commands. We would like a program to mimic the real operation of the telescope.

Note that this does not involve simulating the actual signal data that would be received with a real telescope in place. This simulator only deals with physical properties such as setup, pointing positions, antenna health, that kind of thing.

Architecture of the Proposed Telescope Simulator


In the "real" SonATA system the program called the seeker is the main brains of SonATA. It decides what target is to be observed, sets up all the necessary components to perform the signal analysis. It also tells the telescope the necessary parameters for observation such as what frequencies to observe at, which antennas to use, where to point the antennas.

As far as the seeker is concerned, it controls the telescope by connecting via TCP to a program called the BackendServer. The BackendServer is a process that lives on the same LAN as the telescope control system. The seeker tells the BackendServer what to do and the BackendServer actually issues the commands directly to the telescope systems necessary to complete the task.

This project will involve creating a simulator BackendServer that reacts to all the same commands as the real BackendServer. If a seeker would connect up to it there should be no way for the seeker to know it is not connected to the real BackendServer.

Referring to the diagram above, this system will have 3 major components. These 3 components should communicate with each other over TCP/IP and the protocol should involve key/value pairs formatted in JSON.


The BackendServer will send and receive commands from the seeker over a TCP/IP connection. Currently these commands are simple line delimited ASCII commands. We would like to change the format of these commands to be key/value pairs formatted in a JSON format. This will involve changing the existing Seeker and the BakendServer source code.

The project will involve reading the existing BackendServer code, which is JAVA, and creating a document spec of all the ASCII commands and how they function. Then a new BackendServer should be created that implements these commands as a simulator. We will provide guidance in creating the spec and help with the understanding of the BackendServer code and functionality.

Antenna Simulator

The Antenna Simulator will mimic the real antennas. Whenever the BackendServer needs to interact with the antennas it will communicate with the Antenna Simulator.

This will involve creating a document spec detailing the behavior of the antennas and the control/monitor data that needs to exist to mimic a real set of antennas.

This will be written in Java. It will be comprised of a public class that the BackendServer can instantiate and use to communicate with the Antenna Simulator. Also, when this class is instantiated it will open up a TCP socket so other processes can communicate with it to get antenna information. The 3D telescope project will possibly use this TCP/IP connection.

Beamformer Simulator

One of the major components that the BackendServer controls is the Beamformer. A spec will have to be written on the behavior of the Beamformer. Commands will have to be properly defined and implemented. The commands and responses to/from the Beamformer can be derived by dissecting the BackendServer source code.

This will be a Java class. This class will be instantiated by the BackendServer simulator. This does NOT need to have a server like the Antenna Simulator.

Required Participant Qualifications

  1. Must know how to code in Java.
  2. Familiarity with TCP/IP client server programming in Java
  3. Ability to study source code and write documentation.
  4. Familiar with programming in a Linux environment.
  5. Willingness to learn how to participate in an open source team project.

Additional Considerations

The end goal is to create the telescope simulator as described. But just as important is another goal: learn how to create, plan, manage, and successfully complete an open source project as a group. Each participant needs to be willing to learn how to participate effectively.

Jon Richards and SETI has never managed an open source group like this, so we all have to learn how to work together effectively in a well structured manner. We all should expect to learn some proper software engineering management techniques.

It is expected that at the end of each stage the requirements will be reviewed and possibly modified. At the end of each stage we will have a "deliverable" product. For example, at the end of stage 2 we'll have a fairly developed plan. At the end of stage 3 we will have documents explaining the architecture and communication protocols, and so forth.




Here are some rules we will follow:

Project Deliverables

When the project is successfully complete we will have the following:

Stage 1

This will be the planning stage. At this stage we need to plan together about how to do what we need to do.

Stage 2

Here are some initial ideas for Stage 2.

Stage 3

To be determined (TBD).

Stage 4

To be determined (TBD).

Stage 5

To be determined (TBD).

Project Documents

External links

Personal tools