Difference between revisions of "Patrick's Proposal for Documentation of Spacesim Circuitry"

Latest revision as of 17:29, 17 September 2013

Patrick’s Proposal for Documentation of Spacesim Circuitry, completed on October 20, 2012, was Patrick Melanson's third official proposal for Spacesim. The proposal deals with the ad-hoc nature of learning of Spacesim circuitry, leading to delays and less members knowing how the existing circuitry works.

Patrick’s Proposal for Documentation of Spacesim Circuitry

Preface

Circuitry is the most important part of the electrical components of Spacesim. We need to know how our circuitry works, and the current method of ad-hoc passing down of information isn’t suited to this task.

Introduction

A perusal of various circuitry-related articles on the Spacesim wiki will reveal that there is little functional documentation on how wiring works. There is some basic information regarding the operation of wiring-based systems (you have to have people on both ends of CAPCOM, everything must be green on the server software, etc.), and some information is self-evident, but the bulk of useful information that should be catalogued, categorized, and communicated is not there. This is the kind of information that is not obvious to someone who will try to learn how the wiring of various systems works, while the information already documented will be fairly easy to discover. While I’m certainly not blameless in not documenting what I’m doing, this is the most important thing related to alpha systems that should be done. The wiki article “Habitat” has sections relating to cameras and voice systems, with some descriptions therein, but mostly descriptions of the systems. No functional details are given. Without details such as wiring diagrams, subsequent years will have less original knowledge and will have to devote precious worksession time to learning the inner workings of such systems. This decreases the efficiency of the transition period between years, when grade 12 members graduate, and also leads to reduced understanding of how they systems work. Additionally, implementing this proposal this early on in the Hawking III’s lifespan (5th year) will result in very valuable archive material, as well as an effective teaching resource.

Proposals and Reasoning

• The camera system should have a circuit diagram made, including how to feed switcher on the roof of the habitat works, and documentation will be created for troubleshooting common issues. This is especially important for the camera system, as it is an important and complicated system, and one that has definitely been the source of many delays of the main mission in past years. Having a central repository for troubleshooting and knowledge on the camera systems will expedite the process of repairing and modifying the camera system.

• The CAPCOM network should have a circuit diagram made, including how the amplifier, speakers, and wiretap are all connected to the CAPCOM line. This will make turning on and diagnosing problems with the line much easier, and make future modifications to the existing setup (several are planned) much easier to implement. This will solve problems with communication between the astronauts (, simulators,) and MC, as everyone will be able to hear communications between the groups, and if a problem occurs, communication will be impaired for a much shorter period in the event that the CAPCOM experts are not there at the time.

• The computer network should have a network map, including the physical locations of all computers, their network drive letters, and the programs usually run on these computers (and their respective descriptions on the SERVER software). Additionally, a diagram of CAT5 cables should be made, illustrating the connections between all computers and the server, including the patch panel. The network map will make network setup much faster (a main cause of delays when starting training and mini-missions), as well as eliminate the confusion usually experienced when trying to relate programs to their descriptors on the SERVER software (e.g., the difference between ORBIT display and ORBIT mirror). Additionally, the wire map will make physical network cable diagnosis much easier, as it will provide a concise illustration of which cables are connected to where.

• The electrical circuit diagram should be obtained, or if there is none, created, including the different electrical systems of the habitat, and what they are plugged into. This will primarily make working with the electrical system much safer, as it will be immediately apparent to those working on it which wires are connected to high-voltage AC. Also, it will be useful to the simulators, as they will be able to turn of specific parts of the habitat’s electrical systems (read: lights), as well as make sure that, in the event of the power supply being cut (by simulators), specific appliances will react accordingly, for example, the refrigerator or fans will not lose power, but the emergency lights will.

When modifying a system, the person who is modifying will make a note that the system has been modified. At the end of the worksession, they will go home and put on the central, digital documentation that they have modified the system in question. Then, the appropriate changes to the documentation will be made. However, whether the changes are made is up to the modifier’s discretion (if they feel that they will make changes in the near future, or it is a work-in-progress, for example).

Summary

Having a centralized repository for storing all knowledge on the wiring of Spacesim will allow much more efficient troubleshooting, more technical details to the next generation of spacesimmers, and allow much easier modifications to existing systems.

Suggestions

http://www.draw.io/ is an open-source github project, coded in HTML5, which allows the saving of diagrams to Google drive, as well as the export of diagrams as images. The ocespacesim@gmail.com address can host these drawings and other documentation on its attached Google drive, from which others may collaborate on the documentation. This will create an online, digital, editable, archiveable, and shareable central repository for the above documentation.