From setiquest wiki
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.
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.
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
- Must know how to code in Java.
- Familiarity with TCP/IP client server programming in Java
- Ability to study source code and write documentation.
- Familiar with programming in a Linux environment.
- Willingness to learn how to participate in an open source team project.
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.
- Jon Richards (mentor)
- Gagan Deep
- Akhand Pratap Singh
- Ionut Ignatescu
- Pushpalanka Jayawardhana
- Evan Uebel
- Andre Alves
Here are some rules we will follow:
- Follow General Guidelines
- Follow Coding Standards
- Sign SETI Institute Contributor Licensing Agreement (CLA) and scan/email to us.
- Collaborative communication for this project will use a combination of the Talk:Telescope_Simulator page and the #setiquest IRC channel. A status page at Talk:Telescope_Simulator_Status will be used to keep track of progress status.
- Issue tracking will be done at http://issues.setiquest.org/projects/telescope-simulator. If you have not already done so, please create an account at this location. All things your work on should be listed and updated, as well as time estimates and actual time.
- The source code will be hosted on GitHub, see the project page at https://github.com/setiQuest/Telescope-Simulator
- When we discuss times, lets use GMT.
- The source code will be Java wherever possible.
- The communication between independent software modules should use JSON and use the Jackson JSON Processor available at http://jackson.codehaus.org/
- Source code should be written with testing as the first consideration. We will plan out our classes, implement the tests, then write the code.
- We need to decide as a group what is the best method for implementing testing. Do we use JUnit?
- All details of communication between modules needs to be documented.
- All source code should be properly commented for Doxygen.
- We will peer review each other's source code.
- Source code should adhere to these following rules: General Guidelines. Peer review should point out where a programmer has not followed these rules.
- Documentation will take place on this WiKi. We will create a directory structure for this.
- We will use git as our source code repository software.
- GitHub will be used as the source code repository. Jon Richards will create a new project.
- All participants will need to get a free github.com account and fork the main project code.
- When a participant has code ready for the main branch, he issues a git merge request to the main project.
- We will use issues.setiquest.org as an issue tracker. A separate project will be created in issues.setiquest.org.
- All diagrams should be drawn using the free program inkscape. The format should be SVG and the SVG files should be checked into the git repository. When a diagram is uploaded and displayed in the WiKi it should be converted to PNG format first. The WiKi does not display SVG files.
When the project is successfully complete we will have the following:
- The Seeker will be able to connect to the BackendServer and it will not be able to tell that is is not the real BackendServer.
- The protocol between the Seeker and the BackendServer will be well documented.
- The Antenna Simulator can be used for other programs, such as the Virtual 3D Antenna.
This will be the planning stage. At this stage we need to plan together about how to do what we need to do.
- We had our first IRC planning meeting May 17, 8pm GMT. See Talk:Telescope_Simulator_Status for details.
- We need to discuss what Stage 2 should be.
Here are some initial ideas for Stage 2.
- Develop an architecture.
- Develop a high level design.
- We will have to have a group discussion to divide up the project into component and assign one component to a person. If spec'd out properly with well defined protocols delivered via JSON, we should be able to develop each major part mostly independently.
- Document the protocols?
To be determined (TBD).
To be determined (TBD).
To be determined (TBD).
- Testing code/JUnit/CppUnit - General Procedures
- Introduction to JSON
- Git forking, git commands, and pull requests
- Requirements Document
- Architecture Document
- Project Design Document
- https://github.com/setiQuest/Telescope-Simulator (source code)
- http://issues.setiquest.org/projects/telescope-simulator/issues (issue tracker)