Stanford SSI Wiki - User contributions [en]

How to Join SSI

2018-10-03T05:37:25Z

Kaimarshland:

Hello! There are a few things you need to do if you'd like to have full access to SSI's resources as a member.

=Becoming an official member=

# Pay dues ($10 in exchange for a t-shirt) to our financial officers - any leadership team member can accept these in cash, or you can Venmo our Financial Officer, Chloe Glikbarg, directly. Message her on Slack for details ({{slack-user|chloe}}). If dues present a financial hardship, message {{slack-user|tucks}}, {{slack-user|kai}}, or {{slack-user|chloe}}, and we'll waive them.
# Fill out this 30-second form: [https://stanfordssi.org/q https://stanfordssi.org/q]
# Join the SSI Slack [https://ssi-teams.slack.com/signup here].
# Join the SSI mailing list [https://mailman.stanford.edu/mailman/listinfo/ssi_general here].
# In order to allow you access to our workspace, [[End Station III]], you need to do the following things:
##Log into [https://axess.sahr.stanford.edu/ AXESS] and click "STARS" at the top
##Using either the "All Learning" list, or the Search Catalog, complete the following three safety trainings: '''EHS-4200: General Safety, Injury Prevention (IIPP), and Emergency Preparedness, EHS-1900: Chemical Safety for Laboratories, and EHS-2200: Compressed Gas Safety.''' If you've completed any of these previously for a laboratory class or other university purpose, you don't need to repeat them.
##Some time after completion, you will receive an email for each of these (can take up to 24 hours) certifying your completion. Save each e-mail as a PDF, or, less preferably, screenshot it. This PDF or screenshot '''must''' have your name on it. Ask in {{slack-channel|welcome-to-ssi}} if you have questions about EH&S training - mentioning {{slack-user|mc-safety}} in your question will notify people who can help.
##Sign into the [http://internal.stanfordssi.org internal site] using your Stanford email and under EH&S Safety Training, upload PDFs or screenshots proving your completion of the safety trainings.
##Attend a safety tour of ES3. Ask in {{slack-channel|welcome-to-ssi}} to coordinate a time.
##While in ES3, make sure to sign a copy of the Space Usage Agreement and leave it in the binder by the door. This is your record of completing the workspace safety tour.
##Send a message in Slack to our workspace manager {{slack-user|michaelyang}} that you've completed everything!

=Resources=

== [https://ssi-teams.slack.com/ Slack] ==

Slack is the lifeblood of SSI. It is a messaging client that allows everyone within SSI to communicate. There are general channels (like {{slack-channel|rockets}}), which allow us to push out general updates to everyone interested in the rockets team and direct messages which allows one to one or smaller group communication. Notifications are pushed directly to your phone/computer/anything that has internet so that way we can infringe on all of your free time!

To see what a list of what channels there are to join, check out the [[Slack Directory]].

[https://ssi-teams.slack.com/signup '''Join the SSI Slack here.''']

==[https://calendar.google.com/calendar/embed?src=5or10qu0uhtfqcdqb3knrpn3r8@group.calendar.google.com&ctz=America/Los_Angeles SSI Calendar]==
Home to all of our events across all our teams.

== [https://stanfordssi.org/leadership SSI Leadership] ==
Find out who's in charge of things you're interested in and contact them! You can find all of us on Slack as well.

==The Wiki==

This wiki is a great place to find guides, overviews, and generally useful documentation on SSI projects. Many of the most current plans and docs are in the drive though.

==[https://drive.google.com/open?id=0B5ethK6WQZfAWXgtR25KOEloN2M SSI Drive]==

The drive contains a lot of important documentation for each team. We are trying to put more emphasis on using the wiki as a place for longer-term knowledge storage.

== [https://stanfordssi.org/mailing-list The Mailing List] ==
We use SSI General for organization-wide announcements, and it's a good way to hear about events that get lost in the depths of slack (Slack is still by and large the primary mode of communication for most of us though).

== [[End Station III]] ==

End Station III (also known as ES3) can be considered the temple to SSI’s religion, the hub, nerve center, or kernel of all project activity. End Station III houses work sessions, team meetings, and project storage. Keycard access is required to access the building.

[[File:whereisesiii.png|thumb|left]]

== [[Find a Project]] ==

If you're ever feeling overwhelmed or lost about all the things going on in SSI, use this page to see what's what! Reach out to someone working on a project you're interested in and they'll help you get started. If you have questions or just want to chat, poke any leadership member.

[[Category:Getting started]]

How to Join SSI

2018-10-03T05:37:05Z

Kaimarshland:

Hello! There are a few things you need to do if you'd like to have full access to SSI's resources as a member.

=Becoming an official member=

# Pay dues ($10 in exchange for a t-shirt) to our financial officers - any leadership team member can accept these in cash, or you can Venmo our Financial Officer, Chloe Glikbarg, directly. Message her on Slack for details ({{slack-user|chloe}}). If dues present a financial hardship, message {{slack-user|tucks}}, {{slack-user|kai}}, or {{slack-user|chloe}}, and we'll waive them.
# Fill out this 30-second form: [[https://stanfordssi.org/q]]
# Join the SSI Slack [https://ssi-teams.slack.com/signup here].
# Join the SSI mailing list [https://mailman.stanford.edu/mailman/listinfo/ssi_general here].
# In order to allow you access to our workspace, [[End Station III]], you need to do the following things:
##Log into [https://axess.sahr.stanford.edu/ AXESS] and click "STARS" at the top
##Using either the "All Learning" list, or the Search Catalog, complete the following three safety trainings: '''EHS-4200: General Safety, Injury Prevention (IIPP), and Emergency Preparedness, EHS-1900: Chemical Safety for Laboratories, and EHS-2200: Compressed Gas Safety.''' If you've completed any of these previously for a laboratory class or other university purpose, you don't need to repeat them.
##Some time after completion, you will receive an email for each of these (can take up to 24 hours) certifying your completion. Save each e-mail as a PDF, or, less preferably, screenshot it. This PDF or screenshot '''must''' have your name on it. Ask in {{slack-channel|welcome-to-ssi}} if you have questions about EH&S training - mentioning {{slack-user|mc-safety}} in your question will notify people who can help.
##Sign into the [http://internal.stanfordssi.org internal site] using your Stanford email and under EH&S Safety Training, upload PDFs or screenshots proving your completion of the safety trainings.
##Attend a safety tour of ES3. Ask in {{slack-channel|welcome-to-ssi}} to coordinate a time.
##While in ES3, make sure to sign a copy of the Space Usage Agreement and leave it in the binder by the door. This is your record of completing the workspace safety tour.
##Send a message in Slack to our workspace manager {{slack-user|michaelyang}} that you've completed everything!

=Resources=

== [https://ssi-teams.slack.com/ Slack] ==

Slack is the lifeblood of SSI. It is a messaging client that allows everyone within SSI to communicate. There are general channels (like {{slack-channel|rockets}}), which allow us to push out general updates to everyone interested in the rockets team and direct messages which allows one to one or smaller group communication. Notifications are pushed directly to your phone/computer/anything that has internet so that way we can infringe on all of your free time!

To see what a list of what channels there are to join, check out the [[Slack Directory]].

[https://ssi-teams.slack.com/signup '''Join the SSI Slack here.''']

==[https://calendar.google.com/calendar/embed?src=5or10qu0uhtfqcdqb3knrpn3r8@group.calendar.google.com&ctz=America/Los_Angeles SSI Calendar]==
Home to all of our events across all our teams.

== [https://stanfordssi.org/leadership SSI Leadership] ==
Find out who's in charge of things you're interested in and contact them! You can find all of us on Slack as well.

==The Wiki==

This wiki is a great place to find guides, overviews, and generally useful documentation on SSI projects. Many of the most current plans and docs are in the drive though.

==[https://drive.google.com/open?id=0B5ethK6WQZfAWXgtR25KOEloN2M SSI Drive]==

The drive contains a lot of important documentation for each team. We are trying to put more emphasis on using the wiki as a place for longer-term knowledge storage.

== [https://stanfordssi.org/mailing-list The Mailing List] ==
We use SSI General for organization-wide announcements, and it's a good way to hear about events that get lost in the depths of slack (Slack is still by and large the primary mode of communication for most of us though).

== [[End Station III]] ==

End Station III (also known as ES3) can be considered the temple to SSI’s religion, the hub, nerve center, or kernel of all project activity. End Station III houses work sessions, team meetings, and project storage. Keycard access is required to access the building.

[[File:whereisesiii.png|thumb|left]]

== [[Find a Project]] ==

If you're ever feeling overwhelmed or lost about all the things going on in SSI, use this page to see what's what! Reach out to someone working on a project you're interested in and they'll help you get started. If you have questions or just want to chat, poke any leadership member.

[[Category:Getting started]]

How to Join SSI

2018-07-20T05:02:33Z

Kaimarshland:

Hello! There are a few things you need to do if you'd like to have full access to SSI's resources as a member.

=Becoming an official member=

# Pay dues ($10 in exchange for a t-shirt) to our financial officers - any leadership team member can accept these in cash, or you can Venmo our Financial Officer, Chloe Glikbarg, directly. Message her on Slack for details ({{slack-user|chloe}}). If dues present a financial hardship, message {{slack-user|tucks}}, {{slack-user|kai}}, or {{slack-user|chloe}}, and we'll waive them.
# Join the SSI Slack [https://ssi-teams.slack.com/signup here].
# Join the SSI mailing list [https://mailman.stanford.edu/mailman/listinfo/ssi_general here].
# In order to allow you access to our workspace, [[End Station III]], you need to do the following things:
##Log into [https://axess.sahr.stanford.edu/ AXESS] and click "STARS" at the top
##Using either the "All Learning" list, or the Search Catalog, complete the following three safety trainings: '''EHS-4200: General Safety, Injury Prevention (IIPP), and Emergency Preparedness, EHS-1900: Chemical Safety for Laboratories, and EHS-2200: Compressed Gas Safety.''' If you've completed any of these previously for a laboratory class or other university purpose, you don't need to repeat them.
##Some time after completion, you will receive an email for each of these (can take up to 24 hours) certifying your completion. Save each e-mail as a PDF, or, less preferably, screenshot it. This PDF or screenshot '''must''' have your name on it. Ask in {{slack-channel|welcome-to-ssi}} if you have questions about EH&S training - mentioning {{slack-user|mc-safety}} in your question will notify people who can help.
##Sign into the [http://internal.stanfordssi.org internal site] using your Stanford email and under EH&S Safety Training, upload PDFs or screenshots proving your completion of the safety trainings.
##Attend a safety tour of ES3. Ask in {{slack-channel|welcome-to-ssi}} to coordinate a time.
##While in ES3, make sure to sign a copy of the Space Usage Agreement and leave it in the binder by the door. This is your record of completing the workspace safety tour.
##Send a message in Slack to our workspace manager {{slack-user|michaelyang}} that you've completed everything!

=Resources=

== [https://ssi-teams.slack.com/ Slack] ==

Slack is the lifeblood of SSI. It is a messaging client that allows everyone within SSI to communicate. There are general channels (like {{slack-channel|rockets}}), which allow us to push out general updates to everyone interested in the rockets team and direct messages which allows one to one or smaller group communication. Notifications are pushed directly to your phone/computer/anything that has internet so that way we can infringe on all of your free time!

To see what a list of what channels there are to join, check out the [[Slack Directory]].

[https://ssi-teams.slack.com/signup '''Join the SSI Slack here.''']

==[https://calendar.google.com/calendar/embed?src=5or10qu0uhtfqcdqb3knrpn3r8@group.calendar.google.com&ctz=America/Los_Angeles SSI Calendar]==
Home to all of our events across all our teams.

== [https://stanfordssi.org/leadership SSI Leadership] ==
Find out who's in charge of things you're interested in and contact them! You can find all of us on Slack as well.

==The Wiki==

This wiki is a great place to find guides, overviews, and generally useful documentation on SSI projects. Many of the most current plans and docs are in the drive though.

==[https://drive.google.com/open?id=0B5ethK6WQZfAWXgtR25KOEloN2M SSI Drive]==

The drive contains a lot of important documentation for each team. We are trying to put more emphasis on using the wiki as a place for longer-term knowledge storage.

== [https://stanfordssi.org/mailing-list The Mailing List] ==
We use SSI General for organization-wide announcements, and it's a good way to hear about events that get lost in the depths of slack (Slack is still by and large the primary mode of communication for most of us though).

== [[End Station III]] ==

End Station III (also known as ES3) can be considered the temple to SSI’s religion, the hub, nerve center, or kernel of all project activity. End Station III houses work sessions, team meetings, and project storage. Keycard access is required to access the building.

[[File:whereisesiii.png|thumb|left]]

== [[Find a Project]] ==

If you're ever feeling overwhelmed or lost about all the things going on in SSI, use this page to see what's what! Reach out to someone working on a project you're interested in and they'll help you get started. If you have questions or just want to chat, poke any leadership member.

[[Category:Getting started]]

How to Join SSI

2018-05-17T05:29:16Z

Kaimarshland:

Hello! There are a few things you need to do if you'd like to have full access to SSI's resources as a member.

=Becoming an official member=

# Pay dues ($10 in exchange for a t-shirt) to our financial officers - any leadership team member can accept these in cash, or you can Venmo our Financial Officer, Chloe Glikbarg, directly. Message her on Slack for details ({{slack-user|chloe}}). If dues present a financial hardship, message {{slack-user|tucks}}, {{slack-user|kai}}, or {{slack-user|chloe}}, and we'll waive them.
# Join the SSI Slack [https://ssi-teams.slack.com/signup here].
# Join the SSI mailing list [https://mailman.stanford.edu/mailman/listinfo/ssi_general here].
# In order to allow you access to our workspace, [[End Station III]], you need to do the following things:
##Log into [https://axess.sahr.stanford.edu/ AXESS] and click "STARS" at the top
##Using either the "All Learning" list, or the Search Catalog, complete the following three safety trainings: '''EHS-4200: General Safety, Injury Prevention (IIPP), and Emergency Preparedness, EHS-1900: Chemical Safety for Laboratories, and EHS-2200: Compressed Gas Safety.''' If you've completed any of these previously for a laboratory class or other university purpose, you don't need to repeat them.
##Some time after completion, you will receive an email for each of these (can take up to 24 hours) certifying your completion. Save each e-mail as a PDF, or, less preferably, screenshot it. This PDF or screenshot '''must''' have your name on it. Ask in {{slack-channel|welcome-to-ssi}} if you have questions about EH&S training - mentioning {{slack-user|mc-safety}} in your question will notify people who can help.
##Sign into the [http://internal.stanfordssi.org internal site] using your Stanford email and under EH&S Safety Training, upload PDFs or screenshots proving your completion of the safety trainings.
##Attend a safety tour of ES3. Ask in {{slack-channel|welcome-to-ssi}} to coordinate a time.
##While in ES3, make sure to sign a copy of the Space Usage Agreement and leave it in the binder by the door. This is your record of completing the workspace safety tour.
##Send a message in Slack to our workspace manager {{slack-user|michaelyang}} that you've completed everything!

=Resources=

== [https://ssi-teams.slack.com/ Slack] ==

Slack is the lifeblood of SSI. It is a messaging client that allows everyone within SSI to communicate. There are general channels (like {{slack-channel|rockets}}), which allow us to push out general updates to everyone interested in the rockets team and direct messages which allows one to one or smaller group communication. Notifications are pushed directly to your phone/computer/anything that has internet so that way we can infringe on all of your free time!

To see what a list of what channels there are to join, check out the [[Slack Directory]].

[https://ssi-teams.slack.com/signup '''Join the SSI Slack here.''']

==[https://calendar.google.com/calendar/embed?src=5or10qu0uhtfqcdqb3knrpn3r8@group.calendar.google.com&ctz=America/Los_Angeles SSI Calendar]==
Home to all of our events across all our teams.

== [https://stanfordssi.org/leadership SSI Leadership] ==
Find out who's in charge of things you're interested in and contact them! You can find all of us on Slack as well.

==The Wiki==

This wiki is a great place to find guides, overviews, and generally useful documentation on SSI projects. Many of the most current plans and docs are in the drive though.

==[https://drive.google.com/open?id=0B5ethK6WQZfAWXgtR25KOEloN2M SSI Drive]==

The drive contains a lot of important documentation for each team. We are trying to put more emphasis on using the wiki as a place for longer-term knowledge storage.

== [http://stanfordssi.org/join All The Mailing Lists] ==
We use SSI General for any organization-wide announcements, but use team-specific mailing lists for most of the updates and team announcements (Slack is still by and large the primary mode of communication for most of us though)

== [[End Station III]] ==

End Station III (also known as ES3) can be considered the temple to SSI’s religion, the hub, nerve center, or kernel of all project activity. End Station III houses work sessions, team meetings, and project storage. Keycard access is required to access the building.

[[File:whereisesiii.png|thumb|left]]

== [[Find a Project]] ==

If you're ever feeling overwhelmed or lost about all the things going on in SSI, use this page to see what's what! Reach out to someone working on a project you're interested in and they'll help you get started. If you have questions or just want to chat, poke any leadership member.

[[Category:Getting started]]

Find a Project

2017-10-02T00:56:25Z

Kaimarshland: /* Diversity */

= SSI Overload =
So you've joined [https://ssi-teams.slack.com/join] Slack, maybe gone to a meeting or two, but you're not sure what you can do or what there even is to do with so many teams swirling around? Well you've come to right place! Below are all the projects each team is working on, what skills they utilize or where they're especially looking for help, and who you can contact to jump in! Think of this like a jobs listing page except that the jobs are always available and you apply by poking the person of contact and saying you want the job -- and it's probably yours.

As you can see from the length of this list, there will always be more SSI to do than you will have hours in a day, week, month, or year -- don't feel pressured to overextend yourself! If you have questions, are feeling overwhelmed, or just want to chat with someone, don't hesitate to reach out to a leadership member. ''SSI exists for, and because of, its members (that's you.) Your sanity, health, and overall well-being always come first.''

= Balloons =

== HABMC ==
HABMC has a request list a mile long, but here are a couple highlights. Feel free to slack {{slack-user|kai}} if you have ideas or questions
* 3D visualizations using Cesium or Unity
* Natural Language Processing for the commands module
* Create a mobile app using React Native
* Improved [[Balloons Radio Projects|RF integrations]]
* Overhaul security on websocket connections
* Navigation algorithms

== ValBal ==
ValBal (Valve and Ballast), is a world record-breaking high-altitude balloon payload that autonomously maintains a set altitude for days of flight by venting helium gas and dropping ballast. If you are interested in MechE, EE, CS, Physics, or even MatSci or ChemE, there's a place for you on the ValBal team!

*MechE -- '''Lead: Paige Brown'''
ValBal's current design is a 3 part 3D printed nylon structure that uses motors to vent helium gas directly from the balloon neck, cut down the payload in the event of an emergency, and turn a wheel to dispense bb pellets as ballast from a lower compartment. The structure supports, at its heart, the avionics, which powers and control the motors and sensors. Contact {{slack-user|paigebrown}} if you're interested in:
**Computer Aided Design (CAD) in SolidWorks
**3D printing
**Messing with dry ice
**Laser cutting
**Random jank manufacturing tricks
**and everything else that goes into making ValBal mechanics run smoothly

*EE -- '''Lead: Aria Tedjarati'''
ValBal’s current electrical system consists of two compact, low-cost, 4 layer printed circuit boards with a custom avionics platform and a prototype digital radio communication link. The avionics consist of a multitude of sensors, a GPS, a two-way satellite communications system, motor drivers, power regulation, an embedded micro-controller, and much, much more! The digital radio system consists of a 433 MHz GFSK modulated, Reed-Solomon error corrected link that has been proven to reach ranges of 200 km at data-rates significantly greater than that of the Iridium constellation at 1/5th of the power consumption and 1/20th the cost. There are a multitude of ways to join the electrical engineering aspect of ValBal, so if any of this stuff interests you, join! Contact {{slack-user|ariatedjarati}} for more information.

*CS -- '''Lead: Davy Ragland''' Contact {{slack-user|dragland}}

*Physics -- As a physics major, there are plenty of opportunities for you to work on ValBal. It is an insanely complex system; the flight dynamics are not yet completely understood and require simulating atmospheric and thermal effects. Good models are critical to create a good controller, another key component to ValBal that limits our possible endurance. At the same time, you can help with the design of the payload itself, considering how to optimize it for the harsh environment and coming up with good designs. Contact {{slack-user|jcreus}} for more inforation and a good dose of jank.

*MatSci/ChemE -- '''Lead: Paige Brown'''
ValBal has a '''fatal problem''': latex balloons are quickly weakened by UV radiation and ozone at high altitudes, leading to mission ending failure in just a few days. If this sounds like an interesting problem to you, and you want to be an integral part of helping us circumnavigate the world someday, come help us figure out how to strengthen or alter the latex balloon with s c i e n c e. Contact {{slack-user|paigebrown}} if you're interested!

== HABEES ==
HABEES (High Altitude Balloon Electrical Engineering Systems) is the umbrella project for all EE & CS projects outside of ValBal (that is, largely oriented at standard profile balloon launches). Because of this, there is a nearly limitless number of possibilities and projects to pursue within HABEES -- with that said, if you're new to EE or CS, or a veteran, and just generally want some ideas of what you can make, here's a bunch! Contact {{slack-user|kirillsafin}} to discuss working on any of these!

* HONEY EE -- the primary electronics in HABEES revolve around the HONEY architecture. If you're interested in EE, you can test circuits and/or make PCB's for this architecture and have it fly with other boards. Head over to the [[Gen_2_Architecture | HONEY]] page to understand more about it. Below are some project ideas for circuits/boards you can make for HONEY!
** Motor/Servo Driver
** External/Internal Payload Heaters
** Atmospheric Gas Sensors
** Wind Sensors
** SSTV Radio Board
** WinLink Radio Email Board
** APRS Radio Board
** 12V Battery Management System
** General Purpose Radio Transceiver
** Camera Board
** CubeSat Mapping Board
** Literally anything else
* HONEY CS -- although there's a lot of electronics in HABEES, they all need some software; and, even better, that software always has room for improvement, so here's some possible projects!
** Software for tracking something (with motors/servos)
** Improving filtering/error checking for sensors
** Compression algorithms for logged & transmitted data
** Enhancing speed, quality, and throughput of CAN Bus
** Enhancing TestBench (QueenBee) test software
** Introducing/Developing radio encoding & decoding schemes
** Developing forward & reverse error correction for radio links
** Developing Point-To-Point radar link software

== BUZZ ==
BUZZ is the umbrella subteam for balloons radio projects. It operated as part of HABEES, and works to develop/try/test new radio technologies within balloons. ValBal also develops independent and system-specific radio systems. Some ideas for possible projects, as well as ongoing projects, are below: Talk to {{slack-user|kirillsafin}} and {{slack-user|ariatedjarati}} about them!
* Improved ATV link quality
* Teensy-native SSTV Transmission & Reception
* APRS development
* Native GFSK/FSK/OOK transceivers & software
* WiFi downlink/uplink (2.4GHz / 5 GHz)
* Stanford Ground Station (high gain, directional)
* Portable Field Ground Station
* Balloons National Ground Station Networ
* WinLink Global Radio E-Mail
* Digital Video/Image encoding

= Rockets =

== Daedalus ==

Daedalus is our suite of technology development projects. The work done here pushes forwards on our long-term plan for a space shot. Each project will involve some mechanical, electrical, programming and simulations work, so feel free to join any one of them - but each focuses on a different aspect of rocketry.

Icarus - Reefed Parachute, '''Lead: Saylor'''

*Icarus is building a rocket with a reefed parachute - one which changes size during flight to adjust the rocket descent. This project will intimately involve:
** Mechanics and mechanical engineering - designing, simulating and building a deployment mechanism.
** Mechanics and aerodynamics - designing the parachute and its aerodynamic properties.
** Electrical engineering - PCB design, electrical integration and programming. Focus on high reliability and low size & power.

Charybdis - Spin Stabilization '''Contact: William'''

*Charybdis is building a rocket that spins like a rifle bullet, then stops spinning mid-air to deploy parachutes.
** Mechanical engineering - designing reliable deployment mechanism.
** Aerodynamics and simulation - designing fin system to create desired spin.

Argus - Distributed RF Camera System '''Lead: John'''

*Argus is building a rocket equipped with a new camera system, allowing us to easily take video (and possibly stream live!) from the interior and exterior of rockets as they fly.
** Electrical Engineering - circuit board design, electrical integration.
** Signals - RF & transmission tech.

== Competition (IREC/SA Cup) ==
* Structures, '''Lead: Will'''
** Design and test all airframe hardware
** Design and build tools for integration of the rocket
** Ensure all subsystems are designed and build to correct dimensions
* Payload, '''Lead: WANTED'''
** Design and execute an interesting research project of your choice
** Design a payload of 8.8lbs to be carried to 30,000ft
* Recovery, '''Lead: Saylor'''
** Design and sew a parachute and test it to confirm its Coefficient of Drag
** Design and test a deployment mechanism for our rocket
** Ensure our rocket comes down in one piece
* Avionics, '''Leads: Sharon, Julea''' {{slack-user|splatt}} {{slack-user|juleachin}}
** Design, implement, and test all the hardware and software that goes into our flight computers
** Design and manufacture structures for avionics bay and work with other subteams to implement interfaces and integration processes
** Design and test radio communications system for our rocket to talk to the ground
** Write software to parse and visualize data, build a protective cooling case for laptops & other electronics so they don't die in the blazing desert heat and dust (yes there's a story here)
* Launch Operations, '''Lead: Tylor Jilk'''
** Work with each subteam to coordinate and prepare launch materials
** Plan & execute travel and launch logistics
** Oversee launch procedures, checklists, and go/no calls
** Many more additional projects for ground support designable around personal interests
* Simulations, '''Lead: Ruqayya'''
** Develop computer simulations to predict the flight path of our rocket
** Inform the decision making of the team with analysis of motors, weights and design

= Satellites =
=== STAR-CROSSD===
The Stanford Timing And Ranging –Cross-linking Optical Small Satellite Demonstration mission is an ambitious proposal seeking to place two cubesats in low Earth orbit and establish a laser-based data link between them across hundreds of kilometers. Such a mission has never before been attempted. If successful, the technology developed will enable a dramatic leap forward in the capabilities of both cubesats and larger satellitesto communicate high volumes of data across long distances.

Optical links using lasers are capable of dramatically higher data transmission speeds than existing radio systems, but have never been successfully demonstrated at the cubesat scale. A cubesat-sized optical communications system willenable high-speed links between cubesats, allowing for networks built from affordable satellites.Miniaturizing an optical communications system to fit in a cubesat would also make it far easier for larger satellites to add optical networking capabilities, an almost essential component of proposed internet satellite constellations.

Satellites with optical links can not only transmit data faster, but also better synchronize their timekeeping with each other and measure their separation distance, important features of boththe GPS system and groups of scientific satellites. With an optical network, satellites could conduct previously impossible scientific missions and significantly improve the accuracy of GPS

Now is the perfect time to get involved with STAR-CROSSD. A number of subsystems need to be analyzed, designed, built, and tested, with opportunities to learn about electrical, mechanical, and software engineering, satellite operations, and more.

=== POINTR ===
Polar Orbiting INfrared Tracking Receiver (POINTR) has been Satellites’ primary focus since February. POINTR is an in flight demonstration of an optical receiver pointing, acquisition and tracking (PAT) system. The optical receiver payload hosted on Audacy’s 3U cubesat would be pointed to the ground to acquire and track a beacon laser sent from a suitable ground facility, currently proposed as NASA JPL’s OCTL facility. This mission would demonstrate the operational and technical requirements related to two satellites establishing an optical communications link with each other. The requirements include mission planning, command and execution of a pointing maneuver, acquisition of an incoming optical signal and tracking of the optical signal. This mission can be broken into four main goals:

* Demonstrate a subset of technology for full bidirectional optical communications mission within the constraints placed by Audacy’s primary mission.

* Increase chance of bidirectional optical communications mission success.

* Develop experience within SSI designing and building space hardware.

* Contribute to the cubesat and satellite optical communications technical fields.

=== Our Subteams ===
* '''Avionics'''
**'''The Gist'''The Avionics group works on all of the core electrical systems for the Satellites team, including electrical power distribution, sensors, and computing. Learn how to design and reflow Printed Circuit Boards (PCBs) and work with signal-processing to understand light signals in the inky darkness of space!
**'''The People To Talk to''' Sasha, Shi, Meera

* '''GNC'''
**'''The Gist''' The GNC group ("Guidance, Navigation, and Control") is responsible for determining and controlling the position and rotation of satellites in space even while hundreds or sometimes thousands of miles away. Join GNC to work with us on cutting-edge technologies and a system to control our satellites in orbit from the comfort of the SSI space bunker.
**'''The People To Talk to''' Sasha

* '''Optics'''
**'''The Gist''' Optics is all about putting light to work - starting from simple laser pointers to finally sending a communications signal across 10 kilometers in space! We use lasers, lenses, filters, sensors and even moving mirrors to send light flying through space and catch it on the other side.
**'''The People To Talk to''' Michael Taylor

* '''Software'''
**'''The Gist''' The software team tackles the many different challenges of software needed for satellites: from flight software to web development, we do it all. For flight software, we take advantage of parallel communications modules to manage real-time requirements on pointing control. For web development, we are partnering with the ground operations team to build thorough mission control software and web interface. If any of this seems daunting or complicated, don’t worry. We all started from scratch. Join software and get your code in space!
**'''The People To Talk to''' Orien, Joan

* '''Ground Ops'''
**'''The Gist''' The Ground Operations team will build mission control software and web interface to analyze satellite behavior in-flight and react accordingly. Aside from software, physics and orbital mechanics are crucial parts of this team’s ability. This team is responsible for testing spacecraft stability, fault tolerance, and final mission success.
**'''The People To Talk to''' Orien

*'''Structures'''
**'''The Gist''' The Structures team designs and builds all necessary flight mechanics, ranging from the overall structure to individual component mounts. We go through the full development process - whiteboard drawings, SolidWorks, and finally manufacturing.The Structures team is also responsible for many of the environmental considerations, such as the thermal and vacuum requirements of space, as well as the shock and vibration profile of launch.
**'''The People To Talk to''' Anjali, Sandip

= Biology =

== Enzymatic DNA Synthesis Methods ==
'''Lead: Michael Uttmark''' {{slack-user|uttmark}}
** Test commercial blocking groups for compatibility with [[Terminal Deoxynucleotidyl Transferase]]
** Chemically synthesize nucleotides with different reversible blocking groups
** Characterize and optimize [[Enzymatic Synthesis Methods | enzymatic DNA synthesis]] reaction efficiency
** Build and run stochastic computer models of DNA synthesis to optimize reaction parameters
** Research purification methods for synthesized DNA
** Design and test your own synthesis method!

== Sequence Verification ==
** Execute and optimize any one of our existing verification procedures--[[Polyacrylamide Gel Electrophoresis]], [[Pyrosequencing]], or [[Ligation and Sequencing]]
** Adapt LCMS or MALDI-TOF procedures for detecting single-base addition or determining the sequence of a sample.
** Come up with new ways to verify single-base addition to a starting strand of DNA

== Microfluidic Device Design ==
** Design and program an [[Electrowetting on Dielectric]] microfluidic PCB
** Simulate and test how a microfluidic system would work in microgravity
** Port our DNA synthesis method to a solid substrate like controlled pore glass or streptavidin-biotin magnetic beads
** Optimize an integrated microfluidic protocol for DNA synthesis and verification on the electrowetting PCB and on the [[Beckman Biomek 2000]] liquid handling robot in lab
** Research and test other automated [https://en.wikipedia.org/wiki/Microfluidics fluid handling methods], like [https://en.wikipedia.org/wiki/Acoustic_droplet_ejection acoustic droplet ejection] or [https://en.wikipedia.org/wiki/Optoelectrowetting optoelectrowetting].
** Build a system for cooling and temperature control of the device, perhaps using [https://en.wikipedia.org/wiki/Thermoelectric_cooling Peltiers]
** Write an algorithm to minimize the number of groups of compatible templates needed for the [[Enzymatic Synthesis Methods | exonuclease method]]
** Figure out how to power our PCB from a cubesat or other launch vehicle
** Build testing rigs for DNA synthesis methods that are needed for experiments in lab

= Policy =

== DC Trip ==
* Be a lead/co-lead for our DC trip in partnership with Citizens for Space

== [[SpaceJams]] ==
* Be a Discussion Lead(s) for a week and do a deep dive on a topic/news article of your choice

== Your Project Here ==
* Message {{slack-user|rebeccawong}} and let's chat about what you're interested in doing!

= Operations =

== Community ==
* Come up with a theme for Special Dinner and make decorations (like a model Falcon 9!)
* Help {{slack-user|dragland}} run SSI general dinners
* Plan and run general community events like Trivia Night, Pathfinder, and Movie Night
== Diversity ==
* Find diverse speakers to bring to campus
* Organize diversity mixers (including with other engineering groups)
* Help {{slack-user|ruqayyatoorawa}} run workshops

== Events ==
* Find an interesting company and arrange a tour or talk
* Help handle logistics of an existing talk, like by meeting an astronaut and walking him to Durand 450
* Give a CEO or Venture Capitalist a tour of ESIII
== Finance ==
* Complete reimbursements
* Apply for grants & seek out new sponsors
== Marketing ==
* Design awesome swag (t-shirts, jackets, posters)
* Reach out to reporters
* Social media guru! (Facebook, Twitter, and Instagram posts)
* Creating Snapchat filters for events
* Designing flyers for upcoming talks
* Going on launches to take pictures and videos
== Outreach ==
* Start discussions with local highschools and their science clubs
* Organize or join an existing trip to a local school
== Sponsors ==
* Pursue a sponsorship (we'll walk you through how!)
* Compile a list of bay-area aerospace companies
== Website ==
* Overhaul the budgeting system
* Give the sponsors page dynamic content
* Manage this very wiki
* Manage our public and internal websites
== Workspace ==
* Make space-themed artwork to decorate ESIII
* Plant more herbs
* Paint a mural
* Track inventory of supplies and parts

[[Category:Getting started]]

Operations Team

2017-09-19T23:58:00Z

Kaimarshland: /* Diversity */

Operations is the place in SSI to learn professional skills and connect to the wider aerospace community. The skills you’ll learn are so diverse -- from graphic design to how to get a sponsorship -- that they’re near impossible to summarize. Space is so much more than just the technology, and Operations where it all happens. If you want to know how to manage a group of 200 members with a six figure budget, make space art to decorate our workspace, or get connected to the top of the space industry, Operations is the place for you.

Space would hardly be possible without the people behind the hardware, getting sponsorships, building community, and talking to CEOs and Venture Capitalists across the industry. We’ve brought in speakers like Charlie Bolden, the then-administrator of NASA, and this year will be hosting Gwynne Shotwell, the President of SpaceX. We have a half dozen different efforts that form the backbone of SSI. The current team lead is Kai Marshland {{slack-user|kai}} -- feel free to reach out if you want to get involved!

Operations is split into a number of subgroups

= Events =
Operations brings space to Stanford and sends its members out into the world. The entire Operations team started with Events and we’re only getting better. In the fall, we’re bringing in two NASA astronauts, one of whom was the Chief Scientist for all of NASA, and Gwynne Shotwell, the President of SpaceX; later in the year, we’ll be working with Ubiquity and Bessemer Ventures to run a panel with more CEOs followed by a networking event. Throughout the year, we host talks & tours at Stanford while sending our members beyond.

= Marketing =
Marketing is where you can learn graphic design in order to make lovely materials like Approaching SSI, or reach out to magazines like Wired, Techcrunch, and the Stanford Daily in order to showcase our projects to the world. Oh, and if you want to manage our social media (aka make dank memes) this is the place to be. You have Marketing to thank for all of our gorgeous materials, posters, and swag.

= Website =
Our Website group manages both the beautiful main website and the internal site, which in addition to looking gorgeous brims with tools like the reimbursement system and resume book. Through a full, feature-rich system (if you want to make enterprise software, this is a great way to get started) the Website makes managing SSI a dream.

= Diversity =
We want space to be the most welcoming community possible, and that starts with SSI. Diversity are the ones who run workshops and talks, connect with engineering diversity organizations, and work to make SSI a space for everyone.

= Outreach =
Outreach efforts focus on bringing our stories to local schools and even the Maker Faire. Outreach launches SSI straight out of the Stanford bubble and into the real world.

= Finance =
Finance should really be called the wolves of wall-ssi, because they focus on managing the six-figure budget, handling reimbursements, and interfacing with Stanford administrators.

= Workspace =
Workspace manages the 60-foot-tall underground bunker we call home. That means running a machine shop, planting herbs, and painting space-themed murals across our cavernous space.

= Community =
At the core of any team is the people, and with Community you’ll help welcome and foster connections between people from all walks of life. By organizing events like special dinners, watergun fights, and spring retreat, you will help make SSI more than just a group of talented engineers, but rather (in the words of one of our members) “the best family one could ask for.”

= Sponsors =
Sponsorships leverages the alumni network and SSI’s own contacts in order to keep SSI funded. Extorting aerospace executives makes SSI's projects possible.

= Alumni =
Here in the valley, you're an ancient, creaking Methuselah by the time you reach 22. Unless, of course, you're part of the SSI alumni network, which is run by the group of the same name. Alumni keeps this running, organizing events for aged 20-somethings to rest their aching bones.

This year we're starting an official program for our beloved elderly. If you've got ideas or want to help build up this awesome network, poke Rebecca {{slack-user|rebeccawong}}

----

<noinclude>[[Category:Operations]]</noinclude>

HABMC

2017-09-19T07:33:06Z

Kaimarshland:

The Stanford Student Space Initiative has launched dozens of high altitude balloons. These balloons can go up to 100,000 feet or travel as far as Morocco. Yet these flights would hardly be valuable without the ability to read, parse, and visualize the data streaming back to the ground.

The data comes from sensors on board the balloon, which is then heavily compressed and sent over the Iridium satellite network. Naturally, what exactly that data is varies with each flight, which means that HABMC has to be extremely flexible. In addition to visualizing the telemetry data sent on every flight, HABMC has to be capable of everything from displaying ozone concentrations to detecting voltage spikes -- all in real time.

== How to get involved ==
At a balloons meeting, talk to Kai, or just talk to him on slack {{slack-user|kai|}}.
You can also check out our tutorials [https://github.com/stanford-ssi/habmc-tutorials]

== Public Page ==
The public page of HABMC shows the position and altitude of the balloon, as provided by the ValBal communications system. This allows us to provide detailed information to the FAA and other viewers without overwhelming them with a vast quantity of potentially misleading data.

== SSI Interface ==
If you're logged in as a member of the space initiative or have an access code, you can view the full SSI page, jam-packed with features.

=== Dashboard ===
The dashboard provides a quick overview of the flight. Fully customizable for each payload, it displays a series of graphs to understand recent trends, underneath which is a map of the flight and charts detailing remaining quantities such as battery and ballast. Below the map lies a table of the configuration on the payload itself that gives exact numbers about how the payload is set to behave.

[[File: Dashboard_world_record.png | 500px | center]]

=== Maps, Charts, & Graphs ===
We often want finer control over how we delve into and analyze the data. To that end, we built the charts utility, capable of graphing an arbitrary number of variables against each other. The user may zoom into the data by time period, or look at the whole mission.

[[File: Charts.png | 500px | center]]

Naturally, to see position data we have maps as well. On most flights we have three redundant positioning systems: a primary GPS baked into the board, an external GPS, and position estimates given by the Iridium satellite network. Each of these systems has their own foibles; for example, HABMC is capable of filtering out erroneous Iridium position estimates and displaying error bounds on the map itself.

=== Raw Data Viewing ===
Sometimes charts, maps, and graphs aren’t enough and the flight controllers need to read the data directly. To that end, HABMC provides tables of all transmissions, the raw, compressed details, and every other piece of data the suite has access to. To make some of this data more readable, it shows the most recent transmission’s data grouped and sorted appropriately; one can also browse through old transmissions in this mode. Finally, should the flight controllers want to access the data directly, HABMC offers a full API.

=== Messages ===
HABMC can also send messages back to the balloon, in addition to getting data from it. These messages, however, are far from human readable. HABMC builds these messages through a more intuitive interface, then verifies that they’re in the correct format before ultimately sending them to our payload. It will also store these messages and notify the flight controllers so as to ensure that everyone stays informed.

=== Configuration and permissions ===
From the start, HABMC was designed to handle a wide variety of flight profiles. It’s able to understand three different parsing formats; much of the UI is even customizable. HABMC can even be set to notify the flight controllers via Slack or SMS when it detects a suspicious transmission. To safeguard these features, HABMC has a sophisticated user management system to grant select permissions only to those who need them.

=== Prediction & Footprint Calculator ===
We almost always want to know where the balloon will go. To that end, we have a full predictor utility. Although it currently relies on the GFS weather model, it’s designed to be compatible with the more-accurate ECMWF model should we gain access. The predictor, written from the group up in Rust, takes this data and turns it into real predictions.

[[File: Predictor.png | 500px | center]]

Of course, there are a lot of uncertainties when it comes to prediction, such as descent rate and burst altitude. Thus, when we want to know where the payload will land, we use HABMC’s footprint calculator. This system generates a probability distribution about where the balloon will ultimately come down.

[[File: Footprint.png | 500px | center]]

=== Navigation ===
One of the core features of our novel altitude stabilization platform, ValBal, is that it’s capable of flying at whatever altitude we tell it to, and adjusting that altitude mid-flight. Since there are different wind patterns at different altitudes, by strategically adjusting altitudes the balloon can optimize ground distance or even aim for a specific location. For example, the balloon might fly at 13km to travel west, then ascend to 15km briefly to steer north toward its final destination.

[[File: Navigation.png | 500px | center]]

In this screenshot, the naive option of flying at the single altitude with the fastest winds is shown in blue; active guidance is shown in green. In the same total flight time, with active guidance the balloon can fly over twice as far.

=== Commands Module ===
On the launch site, we often suffer from an unreliable internet connection -- yet we still need to know how our payload is performing. To that end, HABMC also hosts a natural language processing module. While we may not have internet, we almost always have SMS service: the commands module allows us to text commands and queries to HABMC. Example messages include “When was the last transmission?” or “Push the launch time back by 15 minutes”, to which HABMC will respond appropriately.

=== Livestreaming ===
Sending live video down through SSTV can be displayed on HABMC as well. Piping the data through ffmpeg on the client to Youtube Live lets us maintain maximum compatibility with inputs and deliver the video at maximum spee

[[File: Livestream.png | 500px | center]]

=== High-bandwidth radio backend ===
Capable of storing data and delivering high-bandwidth transmissions as fast as the database can handle, the radio code turns HABMC into a truly real time control suite. With the system in place, it can display the data from multiple transmissions per second.

[[File:Live-graphs.gif | 500px | center]]

== Technical Facts ==
HABMC is written with Ruby on Rails and React.js, hosted on Heroku. External services include a prediction and navigation server (written in Rust), an InfluxDB for storing high-bandwidth radio transmissions, a Postgres primary database, writer and followers for radio transmission (written in Node), Newrelic for analytics, and Cloudflare as a CDN.

== History ==

=== Origin ===
Kirill Safin first created HABMC, designed as a way of understanding ValBal launches. At this stage, functionality was minimal; it had the skeleton of the entire site, written with angular. The only pages that had any content were the SPOT GPS pages with their embedded maps displaying where the balloons were. Beyond that, the core achievement was the skeleton itself: it was well designed and provided an excellent foundation for what was to come.

=== Version 1.0 ===
The next stage of HABMC, when it was still written with PHP, involved fleshing out the skeleton. We built the dashboard, which contains graphs and indicators of the flight vitals. The full map, which provided a larger view of the flight path, the transmissions page, which listed the parsed transmissions, and a utility to send messages to the balloon through RockBlock were all added as well. We created a couple pages to see what was happening at a lower level: a page to show us the raw, unparsed transmissions and a page that mapped the position estimate based on the iridium satellite network. One of the more exciting things that we added was the predictor utility, which made an educated guess as to where the balloon would go next, based off NOAA data. And to delve deeper into the data, we created the charts and graphs page, which graphed arbitrary data streams against each other. Finally, to control it all, we had a configuration page.

To power all of this, we had a complex backend, written at this point in PHP. When a transmission came in, it would be stored in a SQL database. Then, to parse and understand it, the transmission would be compared with the parser configuration we had set from the frontend. The backend was also responsible for keeping track of that configuration and making calculations (such as velocity) that were not in the transmission.

The data would also update in realtime, but it did so much less efficiently than it does now. Pages would repeatedly ping the backend and update their data if necessary. While this worked well from the user's perspective, as they never had to reload the page to see new data, it was terrible from the server's perspective. Each chart or graph, of which there were nine on the dashboard alone, had to make a request to the server every few seconds, meaning that the backend was bombarded with requests, most of which did nothing.

In this stage too a Github was created for easier code maintenance. While the deploy process still involved manually uploading the files via FTP, this simplified the challenges of working with multiple people on one project.

=== Version 2.0 ===
The release of version 2 involved turning HABMC from a clunky interface to a more elegant bundle of code. To start, we rewrote the entire backend in Ruby on Rails. As GoDaddy does not support Rails apps, we transitioned to hosting HABMC on Heroku. Advantages here included better load monitoring and simpler deploys. The real advantages, though, came from the updated backend: we had a much more MVC oriented architecture, maintenance was easier, and security was stronger. Further, this allowed us to refactor the JavaScript that powered the core of HABMC. Prior to this, all of the JavaScript lived in one behemoth of a file. Taking advantage of the asset pipeline meant that we could separate this out into a couple dozen distinct files, making the codebase as a whole much simpler and understandable. Routing these files through the asset pipeline additionally meant that we could first minify and then gzip them (and all other static assets such as stylesheets), meaning that the end files were about a tenth the size.

A host of new features arrived between Version 1 and Version 2, like a login system and plotting FAA zones on maps. It also included an architectural change to reduce server load: rather than pinging the server constantly, we moved to a model with push notifications, based on websockets. To further reduce the load, we also batched requests when a change was triggered.

=== Version 3.0 ===
The frontend underwent a complete overhaul, getting rewritten from the ground up in React to be as efficient as possible. This made all of HABMC snappier -- and also way more maintainable. While we were at it, we redid the styles, switching to a dark theme.

=== Future Plans ===
At this point, the core functionality of HABMC has stabilized, but there's always more to be done. Throughout the pipeline, HABMC can improve; old features need to be made more efficient, and new features need to be built. Many features, like navigation and radio integrations, need to mature to support the rigour of flight.

Above all, going into the future HABMC will continue the relentless cycle of refinement and improvement to build it into an ever more powerful mission control suite.

{{balloon-footer}}

[[Category: High Altitude Balloons]][[Category: Projects]]

File:Live-graphs.gif

2017-09-19T07:27:42Z

Kaimarshland:

File:Livestream.png

2017-09-19T07:27:14Z

Kaimarshland:

File:Navigation.png

2017-09-19T07:26:24Z

Kaimarshland:

File:Footprint.png

2017-09-19T07:25:46Z

Kaimarshland:

File:Predictor.png

2017-09-19T07:25:16Z

Kaimarshland:

File:Charts.png

2017-09-19T07:24:43Z

Kaimarshland:

File:Dashboard world record.png

2017-09-19T07:22:36Z

Kaimarshland:

HABMC

2017-09-19T07:21:53Z

Kaimarshland:

The Stanford Student Space Initiative has launched dozens of high altitude balloons. These balloons can go up to 100,000 feet or travel as far as Morocco. Yet these flights would hardly be valuable without the ability to read, parse, and visualize the data streaming back to the ground.

The data comes from sensors on board the balloon, which is then heavily compressed and sent over the Iridium satellite network. Naturally, what exactly that data is varies with each flight, which means that HABMC has to be extremely flexible. In addition to visualizing the telemetry data sent on every flight, HABMC has to be capable of everything from displaying ozone concentrations to detecting voltage spikes -- all in real time.

== How to get involved ==
At a balloons meeting, talk to Kai, or just talk to him on slack {{slack-user|kai|}}.
You can also check out our tutorials [https://github.com/stanford-ssi/habmc-tutorials]

== Public Page ==
The public page of HABMC shows the position and altitude of the balloon, as provided by the ValBal communications system. This allows us to provide detailed information to the FAA and other viewers without overwhelming them with a vast quantity of potentially misleading data.
[[File: HABMC_Public.png | 500px | right]]

== SSI Interface ==
If you're logged in as a member of the space initiative or have an access code, you can view the full SSI page, jam-packed with features.

=== Dashboard ===
The dashboard provides a quick overview of the flight. Fully customizable for each payload, it displays a series of graphs to understand recent trends, underneath which is a map of the flight and charts detailing remaining quantities such as battery and ballast. Below the map lies a table of the configuration on the payload itself that gives exact numbers about how the payload is set to behave.

=== Maps, Charts, & Graphs ===
We often want finer control over how we delve into and analyze the data. To that end, we built the charts utility, capable of graphing an arbitrary number of variables against each other. The user may zoom into the data by time period, or look at the whole mission.

Naturally, to see position data we have maps as well. On most flights we have three redundant positioning systems: a primary GPS baked into the board, an external GPS, and position estimates given by the Iridium satellite network. Each of these systems has their own foibles; for example, HABMC is capable of filtering out erroneous Iridium position estimates and displaying error bounds on the map itself.

=== Raw Data Viewing ===
Sometimes charts, maps, and graphs aren’t enough and the flight controllers need to read the data directly. To that end, HABMC provides tables of all transmissions, the raw, compressed details, and every other piece of data the suite has access to. To make some of this data more readable, it shows the most recent transmission’s data grouped and sorted appropriately; one can also browse through old transmissions in this mode. Finally, should the flight controllers want to access the data directly, HABMC offers a full API.

=== Messages ===
HABMC can also send messages back to the balloon, in addition to getting data from it. These messages, however, are far from human readable. HABMC builds these messages through a more intuitive interface, then verifies that they’re in the correct format before ultimately sending them to our payload. It will also store these messages and notify the flight controllers so as to ensure that everyone stays informed.

=== Configuration and permissions ===
From the start, HABMC was designed to handle a wide variety of flight profiles. It’s able to understand three different parsing formats; much of the UI is even customizable. HABMC can even be set to notify the flight controllers via Slack or SMS when it detects a suspicious transmission. To safeguard these features, HABMC has a sophisticated user management system to grant select permissions only to those who need them.

=== Prediction & Footprint Calculator ===
We almost always want to know where the balloon will go. To that end, we have a full predictor utility. Although it currently relies on the GFS weather model, it’s designed to be compatible with the more-accurate ECMWF model should we gain access. The predictor, written from the group up in Rust, takes this data and turns it into real predictions.

Of course, there are a lot of uncertainties when it comes to prediction, such as descent rate and burst altitude. Thus, when we want to know where the payload will land, we use HABMC’s footprint calculator. This system generates a probability distribution about where the balloon will ultimately come down.

=== Navigation ===
One of the core features of our novel altitude stabilization platform, ValBal, is that it’s capable of flying at whatever altitude we tell it to, and adjusting that altitude mid-flight. Since there are different wind patterns at different altitudes, by strategically adjusting altitudes the balloon can optimize ground distance or even aim for a specific location. For example, the balloon might fly at 13km to travel west, then ascend to 15km briefly to steer north toward its final destination.

In this screenshot, the naive option of flying at the single altitude with the fastest winds is shown in blue; active guidance is shown in green. In the same total flight time, with active guidance the balloon can fly over twice as far.

=== Commands Module ===
On the launch site, we often suffer from an unreliable internet connection -- yet we still need to know how our payload is performing. To that end, HABMC also hosts a natural language processing module. While we may not have internet, we almost always have SMS service: the commands module allows us to text commands and queries to HABMC. Example messages include “When was the last transmission?” or “Push the launch time back by 15 minutes”, to which HABMC will respond appropriately.

=== Livestreaming ===
Sending live video down through SSTV can be displayed on HABMC as well. Piping the data through ffmpeg on the client to Youtube Live lets us maintain maximum compatibility with inputs and deliver the video at maximum spee

=== High-bandwidth radio backend ===
Capable of storing data and delivering high-bandwidth transmissions as fast as the database can handle, the radio code turns HABMC into a truly real time control suite. With the system in place, it can display the data from multiple transmissions per second.

== Technical Facts ==
HABMC is written with Ruby on Rails and React.js, hosted on Heroku. External services include a prediction and navigation server (written in Rust), an InfluxDB for storing high-bandwidth radio transmissions, a Postgres primary database, writer and followers for radio transmission (written in Node), Newrelic for analytics, and Cloudflare as a CDN.

== History ==

=== Origin ===
Kirill Safin first created HABMC, designed as a way of understanding ValBal launches. At this stage, functionality was minimal; it had the skeleton of the entire site, written with angular. The only pages that had any content were the SPOT GPS pages with their embedded maps displaying where the balloons were. Beyond that, the core achievement was the skeleton itself: it was well designed and provided an excellent foundation for what was to come.

=== Version 1.0 ===
The next stage of HABMC, when it was still written with PHP, involved fleshing out the skeleton. We built the dashboard, which contains graphs and indicators of the flight vitals. The full map, which provided a larger view of the flight path, the transmissions page, which listed the parsed transmissions, and a utility to send messages to the balloon through RockBlock were all added as well. We created a couple pages to see what was happening at a lower level: a page to show us the raw, unparsed transmissions and a page that mapped the position estimate based on the iridium satellite network. One of the more exciting things that we added was the predictor utility, which made an educated guess as to where the balloon would go next, based off NOAA data. And to delve deeper into the data, we created the charts and graphs page, which graphed arbitrary data streams against each other. Finally, to control it all, we had a configuration page.

To power all of this, we had a complex backend, written at this point in PHP. When a transmission came in, it would be stored in a SQL database. Then, to parse and understand it, the transmission would be compared with the parser configuration we had set from the frontend. The backend was also responsible for keeping track of that configuration and making calculations (such as velocity) that were not in the transmission.

The data would also update in realtime, but it did so much less efficiently than it does now. Pages would repeatedly ping the backend and update their data if necessary. While this worked well from the user's perspective, as they never had to reload the page to see new data, it was terrible from the server's perspective. Each chart or graph, of which there were nine on the dashboard alone, had to make a request to the server every few seconds, meaning that the backend was bombarded with requests, most of which did nothing.

In this stage too a Github was created for easier code maintenance. While the deploy process still involved manually uploading the files via FTP, this simplified the challenges of working with multiple people on one project.

=== Version 2.0 ===
The release of version 2 involved turning HABMC from a clunky interface to a more elegant bundle of code. To start, we rewrote the entire backend in Ruby on Rails. As GoDaddy does not support Rails apps, we transitioned to hosting HABMC on Heroku. Advantages here included better load monitoring and simpler deploys. The real advantages, though, came from the updated backend: we had a much more MVC oriented architecture, maintenance was easier, and security was stronger. Further, this allowed us to refactor the JavaScript that powered the core of HABMC. Prior to this, all of the JavaScript lived in one behemoth of a file. Taking advantage of the asset pipeline meant that we could separate this out into a couple dozen distinct files, making the codebase as a whole much simpler and understandable. Routing these files through the asset pipeline additionally meant that we could first minify and then gzip them (and all other static assets such as stylesheets), meaning that the end files were about a tenth the size.

A host of new features arrived between Version 1 and Version 2, like a login system and plotting FAA zones on maps. It also included an architectural change to reduce server load: rather than pinging the server constantly, we moved to a model with push notifications, based on websockets. To further reduce the load, we also batched requests when a change was triggered.

=== Version 3.0 ===
The frontend underwent a complete overhaul, getting rewritten from the ground up in React to be as efficient as possible. This made all of HABMC snappier -- and also way more maintainable. While we were at it, we redid the styles, switching to a dark theme.

=== Future Plans ===
At this point, the core functionality of HABMC has stabilized, but there's always more to be done. Throughout the pipeline, HABMC can improve; old features need to be made more efficient, and new features need to be built. Many features, like navigation and radio integrations, need to mature to support the rigour of flight.

Above all, going into the future HABMC will continue the relentless cycle of refinement and improvement to build it into an ever more powerful mission control suite.

{{balloon-footer}}

[[Category: High Altitude Balloons]][[Category: Projects]]

Operations Team

2017-09-19T07:00:38Z

Kaimarshland: /* Marketing */

Operations is the place in SSI to learn professional skills and connect to the wider aerospace community. The skills you’ll learn are so diverse -- from graphic design to how to get a sponsorship -- that they’re near impossible to summarize. Space is so much more than just the technology, and Operations where it all happens. If you want to know how to manage a group of 200 members with a six figure budget, make space art to decorate our workspace, or get connected to the top of the space industry, Operations is the place for you.

Space would hardly be possible without the people behind the hardware, getting sponsorships, building community, and talking to CEOs and Venture Capitalists across the industry. We’ve brought in speakers like Charlie Bolden, the then-administrator of NASA, and this year will be hosting Gwynne Shotwell, the President of SpaceX. We have a half dozen different efforts that form the backbone of SSI. The current team lead is Kai Marshland {{slack-user|kai}} -- feel free to reach out if you want to get involved!

Operations is split into a number of subgroups

= Events =
Operations brings space to Stanford and sends its members out into the world. The entire Operations team started with Events and we’re only getting better. In the fall, we’re bringing in two NASA astronauts, one of whom was the Chief Scientist for all of NASA, and Gwynne Shotwell, the President of SpaceX; later in the year, we’ll be working with Ubiquity and Bessemer Ventures to run a panel with more CEOs followed by a networking event. Throughout the year, we host talks & tours at Stanford while sending our members beyond.

= Marketing =
Marketing is where you can learn graphic design in order to make lovely materials like Approaching SSI, or reach out to magazines like Wired, Techcrunch, and the Stanford Daily in order to showcase our projects to the world. Oh, and if you want to manage our social media (aka make dank memes) this is the place to be. You have Marketing to thank for all of our gorgeous materials, posters, and swag.

= Website =
Our Website group manages both the beautiful main website and the internal site, which in addition to looking gorgeous brims with tools like the reimbursement system and resume book. Through a full, feature-rich system (if you want to make enterprise software, this is a great way to get started) the Website makes managing SSI a dream.

= Diversity =
If you’ve ever resented the fact that the space industry has historically been dominated by balding white men, the Diversity group works to make our own group as inclusive as possible as we train the next generation of industry leaders. We want space to be the most welcoming community possible, and that stretches far beyond SSI -- but Diversity the ones who run workshops, train each other, and work to make that happen.

= Outreach =
Outreach efforts focus on bringing our stories to local schools and even the Maker Faire. Outreach launches SSI straight out of the Stanford bubble and into the real world.

= Finance =
Finance should really be called the wolves of wall-ssi, because they focus on managing the six-figure budget, handling reimbursements, and interfacing with Stanford administrators.

= Workspace =
Workspace manages the 60-foot-tall underground bunker we call home. That means running a machine shop, planting herbs, and painting space-themed murals across our cavernous space.

= Community =
Community is why SSI feels like a home. Community runs dinners, trivia night, and even our spring retreat. Plus, if you like memes, we might have a channel on slack for that which technically falls under operations. Community is what makes SSI, in the words of one of our members, “the family I always wish I had.”

= Sponsors =
Sponsorships leverages the alumni network and SSI’s own contacts in order to keep SSI funded. Extorting aerospace executives makes SSI's projects possible.

= Alumni =
Here in the valley, you're an ancient, creaking Methuselah by the time you reach 22. Unless, of course, you're part of the SSI alumni network, which is run by the group of the same name. Alumni keeps this running, organizing events for aged 20-somethings to rest their aching bones.

This year we're starting an official program for our beloved elderly. If you've got ideas or want to help build up this awesome network, poke Rebecca {{slack-user|rebeccawong}}

----

<noinclude>[[Category:Operations]]</noinclude>

HABMC

2017-09-19T06:55:50Z

Kaimarshland:

HABMC is the online mission control from which we can monitor balloons launches. It updates automatically in real time.

== How to get involved ==
At a balloons meeting, talk to Kai, or just talk to him on slack {{slack-user|kai|}}.
You can also check out our tutorials [https://github.com/stanford-ssi/habmc-tutorials]

== Public Page ==
The public page of HABMC shows the position and altitude of the balloon, as provided by the ValBal communications system. This allows us to provide detailed information to the FAA and other viewers without overwhelming them with a vast quantity of potentially misleading data.
[[File: HABMC_Public.png | 500px | right]]

== SSI Interface ==
If you're logged in as a member of the space initiative or have an access code, you can view the full SSI page. This means that we have better control over our historical data and a variety of utilities.

=== Dashboard ===
This page has an overview of the flight so far. The first row has the current altitude, ascent rate, temperature, ballast drops, vents, and battery voltage, along with each of their changes since the last transmission and a graph of the last several data points. The next row contains a map of the most recent transmissions, and a map of the whole flight thus far. The third row has indicators for remaining ballast, cutdown state, and battery state. The fourth row consists of a graph displaying a couple of the most important metrics together.

=== Full Map ===
This page provides a full look at the flight so far, much larger than the version on the dashboard.

=== Transmissions ===
This is a table all parsed transmissions that have come in so far.

=== Send Message ===
This interface allows you to send messages to the balloon. In addition to having a place to enter the message, it shows the encoded version of the message and the cost to send. It requires both a set of rockblock credentials and to be logged in as an administrator. It then confirms with you before actually sending the message to avoid incorrect calls.

=== Sent Messages ===
This is just a table of all messages that have been sent to the balloon on this mission. Currently only administrators can view it.

=== SPOT Pages ===
These pages each have an embedded map showing where the spot GPS is. There are four, one for each SPOT.

=== Iridium Transmissions ===
This page provides a look at the raw, encoded version of the messages we have received from the balloon, in addition to some metadata that RockBlock provides us.

=== Iriridium Map ===
This map shows us the position of the balloon, based on where the Iridium Satellite Network thinks it is. It also shows a circle giving the estimated accuracy of the position. Given that this has very low acccuracy, typically close to 12km, this should only be used if all other positioning systems go down.

=== Predictor ===
This allows the user to run predictions on the balloon, from its current position, using manually input parameters of altitude and duration. If these parameters are not provided, it takes defaults from the last recorded position of the balloon.
It then plots the prediction on the map, while keeping all prior predictions as well. One is able to remove these predictions with a clear button.

=== Charts and Graphs ===
This page allows the plotting of any values versus any other given values. For example, the user can pick an “X axis” value, where logical options might be time or distance from launch site, and can then plot any number of other values on the Y axis. This could include voltage, solar current, velocity, altitude, temperature, etc (nearly any valuable flight parameter).

=== Configuration ===
This is a page that takes a bunch of parameters and settings for operation of the mission. In general, it is just a form that allows admins to set things like the format of the message, the flight ceiling and floor, and the maximum ballast capacity that are used to understand what the transmissions really mean.

== Technical Facts ==
HABMC is written with Ruby on Rails and React.js, hosted on Heroku. External services include a prediction and navigation server (written in Rust), an InfluxDB for storing high-bandwidth radio transmissions, a Postgres primary database, writer and followers for radio transmission (written in Node), Newrelic for analytics, and Cloudflare as a CDN.

== History ==

=== Origin ===
Kirill Safin first created HABMC, designed as a way of understanding ValBal launches. At this stage, functionality was minimal; it had the skeleton of the entire site, written with angular. The only pages that had any content were the SPOT GPS pages with their embedded maps displaying where the balloons were. Beyond that, the core achievement was the skeleton itself: it was well designed and provided an excellent foundation for what was to come.

=== Version 1.0 ===
The next stage of HABMC, when it was still written with PHP, involved fleshing out the skeleton. We built the dashboard, which contains graphs and indicators of the flight vitals. The full map, which provided a larger view of the flight path, the transmissions page, which listed the parsed transmissions, and a utility to send messages to the balloon through RockBlock were all added as well. We created a couple pages to see what was happening at a lower level: a page to show us the raw, unparsed transmissions and a page that mapped the position estimate based on the iridium satellite network. One of the more exciting things that we added was the predictor utility, which made an educated guess as to where the balloon would go next, based off NOAA data. And to delve deeper into the data, we created the charts and graphs page, which graphed arbitrary data streams against each other. Finally, to control it all, we had a configuration page.

To power all of this, we had a complex backend, written at this point in PHP. When a transmission came in, it would be stored in a SQL database. Then, to parse and understand it, the transmission would be compared with the parser configuration we had set from the frontend. The backend was also responsible for keeping track of that configuration and making calculations (such as velocity) that were not in the transmission.

The data would also update in realtime, but it did so much less efficiently than it does now. Pages would repeatedly ping the backend and update their data if necessary. While this worked well from the user's perspective, as they never had to reload the page to see new data, it was terrible from the server's perspective. Each chart or graph, of which there were nine on the dashboard alone, had to make a request to the server every few seconds, meaning that the backend was bombarded with requests, most of which did nothing.

In this stage too a Github was created for easier code maintenance. While the deploy process still involved manually uploading the files via FTP, this simplified the challenges of working with multiple people on one project.

=== Version 2.0 ===
The release of version 2 involved turning HABMC from a clunky interface to a more elegant bundle of code. To start, we rewrote the entire backend in Ruby on Rails. As GoDaddy does not support Rails apps, we transitioned to hosting HABMC on Heroku. Advantages here included better load monitoring and simpler deploys. The real advantages, though, came from the updated backend: we had a much more MVC oriented architecture, maintenance was easier, and security was stronger. Further, this allowed us to refactor the JavaScript that powered the core of HABMC. Prior to this, all of the JavaScript lived in one behemoth of a file. Taking advantage of the asset pipeline meant that we could separate this out into a couple dozen distinct files, making the codebase as a whole much simpler and understandable. Routing these files through the asset pipeline additionally meant that we could first minify and then gzip them (and all other static assets such as stylesheets), meaning that the end files were about a tenth the size.

A host of new features arrived between Version 1 and Version 2, like a login system and plotting FAA zones on maps. It also included an architectural change to reduce server load: rather than pinging the server constantly, we moved to a model with push notifications, based on websockets. To further reduce the load, we also batched requests when a change was triggered.

=== Version 3.0 ===
The frontend underwent a complete overhaul, getting rewritten from the ground up in React to be as efficient as possible. This made all of HABMC snappier -- and also way more maintainable. While we were at it, we redid the styles, switching to a dark theme.

=== Future Plans ===
At this point, the core functionality of HABMC has stabilized, but there's always more to be done. Throughout the pipeline, HABMC can improve; old features need to be made more efficient, and new features need to be built. Many features, like navigation and radio integrations, need to mature to support the rigour of flight.

Above all, going into the future HABMC will continue the relentless cycle of refinement and improvement to build it into an ever more powerful mission control suite.

{{balloon-footer}}

[[Category: High Altitude Balloons]][[Category: Projects]]

HABMC

2017-09-19T06:52:24Z

Kaimarshland: /* Technical Background */

HABMC is the online mission control from which we can monitor balloons launches. It updates automatically in real time.

== Public Page ==
The public page of HABMC shows the position and altitude of the balloon, as provided by the ValBal communications system. This allows us to provide detailed information to the FAA and other viewers without overwhelming them with a vast quantity of potentially misleading data.
[[File: HABMC_Public.png | 500px | right]]

== SSI Interface ==
If you're logged in as a member of the space initiative or have an access code, you can view the full SSI page. This means that we have better control over our historical data and a variety of utilities.

=== Dashboard ===
This page has an overview of the flight so far. The first row has the current altitude, ascent rate, temperature, ballast drops, vents, and battery voltage, along with each of their changes since the last transmission and a graph of the last several data points. The next row contains a map of the most recent transmissions, and a map of the whole flight thus far. The third row has indicators for remaining ballast, cutdown state, and battery state. The fourth row consists of a graph displaying a couple of the most important metrics together.

=== Full Map ===
This page provides a full look at the flight so far, much larger than the version on the dashboard.

=== Transmissions ===
This is a table all parsed transmissions that have come in so far.

=== Send Message ===
This interface allows you to send messages to the balloon. In addition to having a place to enter the message, it shows the encoded version of the message and the cost to send. It requires both a set of rockblock credentials and to be logged in as an administrator. It then confirms with you before actually sending the message to avoid incorrect calls.

=== Sent Messages ===
This is just a table of all messages that have been sent to the balloon on this mission. Currently only administrators can view it.

=== SPOT Pages ===
These pages each have an embedded map showing where the spot GPS is. There are four, one for each SPOT.

=== Iridium Transmissions ===
This page provides a look at the raw, encoded version of the messages we have received from the balloon, in addition to some metadata that RockBlock provides us.

=== Iriridium Map ===
This map shows us the position of the balloon, based on where the Iridium Satellite Network thinks it is. It also shows a circle giving the estimated accuracy of the position. Given that this has very low acccuracy, typically close to 12km, this should only be used if all other positioning systems go down.

=== Predictor ===
This allows the user to run predictions on the balloon, from its current position, using manually input parameters of altitude and duration. If these parameters are not provided, it takes defaults from the last recorded position of the balloon.
It then plots the prediction on the map, while keeping all prior predictions as well. One is able to remove these predictions with a clear button.

=== Charts and Graphs ===
This page allows the plotting of any values versus any other given values. For example, the user can pick an “X axis” value, where logical options might be time or distance from launch site, and can then plot any number of other values on the Y axis. This could include voltage, solar current, velocity, altitude, temperature, etc (nearly any valuable flight parameter).

=== Configuration ===
This is a page that takes a bunch of parameters and settings for operation of the mission. In general, it is just a form that allows admins to set things like the format of the message, the flight ceiling and floor, and the maximum ballast capacity that are used to understand what the transmissions really mean.

== Technical Facts ==
HABMC is written with Ruby on Rails and React.js, hosted on Heroku. External services include a prediction and navigation server (written in Rust), an InfluxDB for storing high-bandwidth radio transmissions, a Postgres primary database, writer and followers for radio transmission (written in Node), Newrelic for analytics, and Cloudflare as a CDN.

== History ==

=== Origin ===
Kirill Safin first created HABMC, designed as a way of understanding ValBal launches. At this stage, functionality was minimal; it had the skeleton of the entire site, written with angular. The only pages that had any content were the SPOT GPS pages with their embedded maps displaying where the balloons were. Beyond that, the core achievement was the skeleton itself: it was well designed and provided an excellent foundation for what was to come.

=== Version 1.0 ===
The next stage of HABMC, when it was still written with PHP, involved fleshing out the skeleton. We built the dashboard, which contains graphs and indicators of the flight vitals. The full map, which provided a larger view of the flight path, the transmissions page, which listed the parsed transmissions, and a utility to send messages to the balloon through RockBlock were all added as well. We created a couple pages to see what was happening at a lower level: a page to show us the raw, unparsed transmissions and a page that mapped the position estimate based on the iridium satellite network. One of the more exciting things that we added was the predictor utility, which made an educated guess as to where the balloon would go next, based off NOAA data. And to delve deeper into the data, we created the charts and graphs page, which graphed arbitrary data streams against each other. Finally, to control it all, we had a configuration page.

To power all of this, we had a complex backend, written at this point in PHP. When a transmission came in, it would be stored in a SQL database. Then, to parse and understand it, the transmission would be compared with the parser configuration we had set from the frontend. The backend was also responsible for keeping track of that configuration and making calculations (such as velocity) that were not in the transmission.

The data would also update in realtime, but it did so much less efficiently than it does now. Pages would repeatedly ping the backend and update their data if necessary. While this worked well from the user's perspective, as they never had to reload the page to see new data, it was terrible from the server's perspective. Each chart or graph, of which there were nine on the dashboard alone, had to make a request to the server every few seconds, meaning that the backend was bombarded with requests, most of which did nothing.

In this stage too a Github was created for easier code maintenance. While the deploy process still involved manually uploading the files via FTP, this simplified the challenges of working with multiple people on one project.

=== Version 2.0 ===
The release of version 2 involved turning HABMC from a clunky interface to a more elegant bundle of code. To start, we rewrote the entire backend in Ruby on Rails. As GoDaddy does not support Rails apps, we transitioned to hosting HABMC on Heroku. Advantages here included better load monitoring and simpler deploys. The real advantages, though, came from the updated backend: we had a much more MVC oriented architecture, maintenance was easier, and security was stronger. Further, this allowed us to refactor the JavaScript that powered the core of HABMC. Prior to this, all of the JavaScript lived in one behemoth of a file. Taking advantage of the asset pipeline meant that we could separate this out into a couple dozen distinct files, making the codebase as a whole much simpler and understandable. Routing these files through the asset pipeline additionally meant that we could first minify and then gzip them (and all other static assets such as stylesheets), meaning that the end files were about a tenth the size.

A host of new features arrived between Version 1 and Version 2, like a login system and plotting FAA zones on maps. It also included an architectural change to reduce server load: rather than pinging the server constantly, we moved to a model with push notifications, based on websockets. To further reduce the load, we also batched requests when a change was triggered.

== Version 3.0 ==
The frontend underwent a complete overhaul, getting rewritten from the ground up in React to be as efficient as possible. This made all of HABMC snappier -- and also way more maintainable. While we were at it, we redid the styles, switching to a dark theme.

=== Future Plans ===
At this point, the core functionality of HABMC has stabilized, but there's always more to be done. Throughout the pipeline, HABMC can improve; old features need to be made more efficient, and new features need to be built. Many features, like navigation and radio integrations, need to mature to support the rigour of flight.

Above all, going into the future HABMC will continue the relentless cycle of refinement and improvement to build it into an ever more powerful mission control suite.

{{balloon-footer}}

[[Category: High Altitude Balloons]][[Category: Projects]]

HABMC

2017-09-19T06:48:49Z

Kaimarshland: /* History */

HABMC is the online mission control from which we can monitor balloons launches. It updates automatically in real time.

== Public Page ==
The public page of HABMC shows the position and altitude of the balloon, as provided by the ValBal communications system. This allows us to provide detailed information to the FAA and other viewers without overwhelming them with a vast quantity of potentially misleading data.
[[File: HABMC_Public.png | 500px | right]]

== SSI Interface ==
If you're logged in as a member of the space initiative or have an access code, you can view the full SSI page. This means that we have better control over our historical data and a variety of utilities.

=== Dashboard ===
This page has an overview of the flight so far. The first row has the current altitude, ascent rate, temperature, ballast drops, vents, and battery voltage, along with each of their changes since the last transmission and a graph of the last several data points. The next row contains a map of the most recent transmissions, and a map of the whole flight thus far. The third row has indicators for remaining ballast, cutdown state, and battery state. The fourth row consists of a graph displaying a couple of the most important metrics together.

=== Full Map ===
This page provides a full look at the flight so far, much larger than the version on the dashboard.

=== Transmissions ===
This is a table all parsed transmissions that have come in so far.

=== Send Message ===
This interface allows you to send messages to the balloon. In addition to having a place to enter the message, it shows the encoded version of the message and the cost to send. It requires both a set of rockblock credentials and to be logged in as an administrator. It then confirms with you before actually sending the message to avoid incorrect calls.

=== Sent Messages ===
This is just a table of all messages that have been sent to the balloon on this mission. Currently only administrators can view it.

=== SPOT Pages ===
These pages each have an embedded map showing where the spot GPS is. There are four, one for each SPOT.

=== Iridium Transmissions ===
This page provides a look at the raw, encoded version of the messages we have received from the balloon, in addition to some metadata that RockBlock provides us.

=== Iriridium Map ===
This map shows us the position of the balloon, based on where the Iridium Satellite Network thinks it is. It also shows a circle giving the estimated accuracy of the position. Given that this has very low acccuracy, typically close to 12km, this should only be used if all other positioning systems go down.

=== Predictor ===
This allows the user to run predictions on the balloon, from its current position, using manually input parameters of altitude and duration. If these parameters are not provided, it takes defaults from the last recorded position of the balloon.
It then plots the prediction on the map, while keeping all prior predictions as well. One is able to remove these predictions with a clear button.

=== Charts and Graphs ===
This page allows the plotting of any values versus any other given values. For example, the user can pick an “X axis” value, where logical options might be time or distance from launch site, and can then plot any number of other values on the Y axis. This could include voltage, solar current, velocity, altitude, temperature, etc (nearly any valuable flight parameter).

=== Configuration ===
This is a page that takes a bunch of parameters and settings for operation of the mission. In general, it is just a form that allows admins to set things like the format of the message, the flight ceiling and floor, and the maximum ballast capacity that are used to understand what the transmissions really mean.

== Technical Background ==
HABMC is written with Ruby on Rails and Angular.js. While in a previous iteration the backend was written with PHP and hosted on GoDaddy, it is currently hosted on Heroku. We have a Postgres database and use NewRelic for analytics.

So that the data can updated with minimal latency, we open up a websocket connection from the client to the server. Then, as soon as the data changes on the server, such as when a new transmission comes in, a message is sent through the websocket back to the client that tells it to refresh its data. This refresh is done with a HTTP request, rather than sending the data through the websocket, because HTTP requests are much more developed than websockets. These HTTP requests are able to support functionality like authorization, CORS, and caching easily, in addition to avoiding repeated code on the initial load of the page.

== History ==

=== Origin ===
Kirill Safin first created HABMC, designed as a way of understanding ValBal launches. At this stage, functionality was minimal; it had the skeleton of the entire site, written with angular. The only pages that had any content were the SPOT GPS pages with their embedded maps displaying where the balloons were. Beyond that, the core achievement was the skeleton itself: it was well designed and provided an excellent foundation for what was to come.

=== Version 1.0 ===
The next stage of HABMC, when it was still written with PHP, involved fleshing out the skeleton. We built the dashboard, which contains graphs and indicators of the flight vitals. The full map, which provided a larger view of the flight path, the transmissions page, which listed the parsed transmissions, and a utility to send messages to the balloon through RockBlock were all added as well. We created a couple pages to see what was happening at a lower level: a page to show us the raw, unparsed transmissions and a page that mapped the position estimate based on the iridium satellite network. One of the more exciting things that we added was the predictor utility, which made an educated guess as to where the balloon would go next, based off NOAA data. And to delve deeper into the data, we created the charts and graphs page, which graphed arbitrary data streams against each other. Finally, to control it all, we had a configuration page.

To power all of this, we had a complex backend, written at this point in PHP. When a transmission came in, it would be stored in a SQL database. Then, to parse and understand it, the transmission would be compared with the parser configuration we had set from the frontend. The backend was also responsible for keeping track of that configuration and making calculations (such as velocity) that were not in the transmission.

The data would also update in realtime, but it did so much less efficiently than it does now. Pages would repeatedly ping the backend and update their data if necessary. While this worked well from the user's perspective, as they never had to reload the page to see new data, it was terrible from the server's perspective. Each chart or graph, of which there were nine on the dashboard alone, had to make a request to the server every few seconds, meaning that the backend was bombarded with requests, most of which did nothing.

In this stage too a Github was created for easier code maintenance. While the deploy process still involved manually uploading the files via FTP, this simplified the challenges of working with multiple people on one project.

=== Version 2.0 ===
The release of version 2 involved turning HABMC from a clunky interface to a more elegant bundle of code. To start, we rewrote the entire backend in Ruby on Rails. As GoDaddy does not support Rails apps, we transitioned to hosting HABMC on Heroku. Advantages here included better load monitoring and simpler deploys. The real advantages, though, came from the updated backend: we had a much more MVC oriented architecture, maintenance was easier, and security was stronger. Further, this allowed us to refactor the JavaScript that powered the core of HABMC. Prior to this, all of the JavaScript lived in one behemoth of a file. Taking advantage of the asset pipeline meant that we could separate this out into a couple dozen distinct files, making the codebase as a whole much simpler and understandable. Routing these files through the asset pipeline additionally meant that we could first minify and then gzip them (and all other static assets such as stylesheets), meaning that the end files were about a tenth the size.

A host of new features arrived between Version 1 and Version 2, like a login system and plotting FAA zones on maps. It also included an architectural change to reduce server load: rather than pinging the server constantly, we moved to a model with push notifications, based on websockets. To further reduce the load, we also batched requests when a change was triggered.

== Version 3.0 ==
The frontend underwent a complete overhaul, getting rewritten from the ground up in React to be as efficient as possible. This made all of HABMC snappier -- and also way more maintainable. While we were at it, we redid the styles, switching to a dark theme.

=== Future Plans ===
At this point, the core functionality of HABMC has stabilized, but there's always more to be done. Throughout the pipeline, HABMC can improve; old features need to be made more efficient, and new features need to be built. Many features, like navigation and radio integrations, need to mature to support the rigour of flight.

Above all, going into the future HABMC will continue the relentless cycle of refinement and improvement to build it into an ever more powerful mission control suite.

{{balloon-footer}}

[[Category: High Altitude Balloons]][[Category: Projects]]

Operations Team

2017-09-19T05:43:25Z

Kaimarshland:

Operations is the place in SSI to learn professional skills and connect to the wider aerospace community. The skills you’ll learn are so diverse -- from graphic design to how to get a sponsorship -- that they’re near impossible to summarize. Space is so much more than just the technology, and Operations where it all happens. If you want to know how to manage a group of 200 members with a six figure budget, make space art to decorate our workspace, or get connected to the top of the space industry, Operations is the place for you.

Space would hardly be possible without the people behind the hardware, getting sponsorships, building community, and talking to CEOs and Venture Capitalists across the industry. We’ve brought in speakers like Charlie Bolden, the then-administrator of NASA, and this year will be hosting Gwynne Shotwell, the President of SpaceX. We have a half dozen different efforts that form the backbone of SSI. The current team lead is Kai Marshland {{slack-user|kai}} -- feel free to reach out if you want to get involved!

Operations is split into a number of subgroups

= Events =
Operations brings space to Stanford and sends its members out into the world. The entire Operations team started with Events and we’re only getting better. In the fall, we’re bringing in two NASA astronauts, one of whom was the Chief Scientist for all of NASA, and Gwynne Shotwell, the President of SpaceX; later in the year, we’ll be working with Ubiquity and Bessemer Ventures to run a panel with more CEOs followed by a networking event. Throughout the year, we host talks & tours at Stanford while sending our members beyond.

= Marketing =
Marketing is where you can learn graphic design in order to make gorgeous materials like this very pamphlet, or reach out to magazines like Wired, Techcrunch, and the Stanford Daily in order to showcase our projects to the world. Oh, and if you want to manage our social media (aka make dank memes) this is the place to be. You have them to thank for all of our gorgeous materials, posters, and swag.

= Website =
Our Website group manages both the beautiful main website and the internal site, which in addition to looking gorgeous brims with tools like the reimbursement system and resume book. Through a full, feature-rich system (if you want to make enterprise software, this is a great way to get started) the Website makes managing SSI a dream.

= Diversity =
If you’ve ever resented the fact that the space industry has historically been dominated by balding white men, the Diversity group works to make our own group as inclusive as possible as we train the next generation of industry leaders. We want space to be the most welcoming community possible, and that stretches far beyond SSI -- but Diversity the ones who run workshops, train each other, and work to make that happen.

= Outreach =
Outreach efforts focus on bringing our stories to local schools and even the Maker Faire. Outreach launches SSI straight out of the Stanford bubble and into the real world.

= Finance =
Finance should really be called the wolves of wall-ssi, because they focus on managing the six-figure budget, handling reimbursements, and interfacing with Stanford administrators.

= Workspace =
Workspace manages the 60-foot-tall underground bunker we call home. That means running a machine shop, planting herbs, and painting space-themed murals across our cavernous space.

= Community =
Community is why SSI feels like a home. Community runs dinners, trivia night, and even our spring retreat. Plus, if you like memes, we might have a channel on slack for that which technically falls under operations. Community is what makes SSI, in the words of one of our members, “the family I always wish I had.”

= Sponsors =
Sponsorships leverages the alumni network and SSI’s own contacts in order to keep SSI funded. Extorting aerospace executives makes SSI's projects possible.

= Alumni =
Here in the valley, you're an ancient, creaking Methuselah by the time you reach 22. Unless, of course, you're part of the SSI alumni network, which is run by the group of the same name. Alumni keeps this running, organizing events for aged 20-somethings to rest their aching bones.

----

<noinclude>[[Category:Operations]]</noinclude>

Space at Stanford

2017-09-19T04:57:24Z

Kaimarshland:

This is a conference we once considered running. Ultimately, due to lack of time, it was canceled.

[[Category: Operations]]

Find a Project

2017-09-17T20:08:34Z

Kaimarshland:

Balloons Radio Projects

2017-09-17T19:05:58Z

Kaimarshland:

== SSTV: slow scan tv ==

Sending low resolution pictures very slowly (90s transmisison per pic) using frequency modulated analog signals at low bandwidth. This needs to be picked up ourselves with a hand held radio and decoding using a phone app or a computer program. This is a ONE WAY comms method (from balloon to ground ONLY).

== APRS: automated packet reporting system ==
Sending data, position, atltiude, callsign, to receive stations all around the world. This is a low bandwidth DIGITAL signal that is frequency modulated. No need to pick up ourselves, will be automatically uploaded to aprs.fi. This is a ONE WAY comms method (from balloon to ground ONLY).

== ATV: amateur TV ==
Can be digital or analog (in our case it is analog), amplitude modulated signals, extremely high bandwidth (several MHz), live stream television. Need old huge TV for receiver. This is a ONE WAY comms method (from balloon to ground ONLY).

== (G)FSK, OOK ==
ValBal's long range digital radio system used to send any information we want at variable speeds & bandwidths. Can get anywhere from 500bps to 1Mbps, and anywhere from 1000km to 10km range depending on speed and antenna type. Need personal receiver, demodulator, rpi, to upload to [[HABMC]]. Eventually will be used to have 1Hz refresh rate on HABMC for vb and give active control. This is a partial duplex comms method (bidirectional, but not at the same time).

[[Category:Balloons]]

Habmc

2017-09-17T18:54:39Z

Kaimarshland: Redirected page to HABMC

#REDIRECT [[HABMC]]

HABMC

2017-09-17T18:50:37Z

Kaimarshland: Created page with "HABMC is the online mission control from which we can monitor balloons launches. It updates automatically in real time. == Public Page == The public page of HABMC shows the p..."

HABMC is the online mission control from which we can monitor balloons launches. It updates automatically in real time.

== Public Page ==
The public page of HABMC shows the position and altitude of the balloon, as provided by the ValBal communications system. This allows us to provide detailed information to the FAA and other viewers without overwhelming them with a vast quantity of potentially misleading data.
[[File: HABMC_Public.png | 500px | right]]

== SSI Interface ==
If you're logged in as a member of the space initiative or have an access code, you can view the full SSI page. This means that we have better control over our historical data and a variety of utilities.

=== Dashboard ===
This page has an overview of the flight so far. The first row has the current altitude, ascent rate, temperature, ballast drops, vents, and battery voltage, along with each of their changes since the last transmission and a graph of the last several data points. The next row contains a map of the most recent transmissions, and a map of the whole flight thus far. The third row has indicators for remaining ballast, cutdown state, and battery state. The fourth row consists of a graph displaying a couple of the most important metrics together.

=== Full Map ===
This page provides a full look at the flight so far, much larger than the version on the dashboard.

=== Transmissions ===
This is a table all parsed transmissions that have come in so far.

=== Send Message ===
This interface allows you to send messages to the balloon. In addition to having a place to enter the message, it shows the encoded version of the message and the cost to send. It requires both a set of rockblock credentials and to be logged in as an administrator. It then confirms with you before actually sending the message to avoid incorrect calls.

=== Sent Messages ===
This is just a table of all messages that have been sent to the balloon on this mission. Currently only administrators can view it.

=== SPOT Pages ===
These pages each have an embedded map showing where the spot GPS is. There are four, one for each SPOT.

=== Iridium Transmissions ===
This page provides a look at the raw, encoded version of the messages we have received from the balloon, in addition to some metadata that RockBlock provides us.

=== Iriridium Map ===
This map shows us the position of the balloon, based on where the Iridium Satellite Network thinks it is. It also shows a circle giving the estimated accuracy of the position. Given that this has very low acccuracy, typically close to 12km, this should only be used if all other positioning systems go down.

=== Predictor ===
This allows the user to run predictions on the balloon, from its current position, using manually input parameters of altitude and duration. If these parameters are not provided, it takes defaults from the last recorded position of the balloon.
It then plots the prediction on the map, while keeping all prior predictions as well. One is able to remove these predictions with a clear button.

=== Charts and Graphs ===
This page allows the plotting of any values versus any other given values. For example, the user can pick an “X axis” value, where logical options might be time or distance from launch site, and can then plot any number of other values on the Y axis. This could include voltage, solar current, velocity, altitude, temperature, etc (nearly any valuable flight parameter).

=== Configuration ===
This is a page that takes a bunch of parameters and settings for operation of the mission. In general, it is just a form that allows admins to set things like the format of the message, the flight ceiling and floor, and the maximum ballast capacity that are used to understand what the transmissions really mean.

== Technical Background ==
HABMC is written with Ruby on Rails and Angular.js. While in a previous iteration the backend was written with PHP and hosted on GoDaddy, it is currently hosted on Heroku. We have a Postgres database and use NewRelic for analytics.

So that the data can updated with minimal latency, we open up a websocket connection from the client to the server. Then, as soon as the data changes on the server, such as when a new transmission comes in, a message is sent through the websocket back to the client that tells it to refresh its data. This refresh is done with a HTTP request, rather than sending the data through the websocket, because HTTP requests are much more developed than websockets. These HTTP requests are able to support functionality like authorization, CORS, and caching easily, in addition to avoiding repeated code on the initial load of the page.

== History ==

=== Origin ===
Kirill Safin first created HABMC, designed as a way of understanding ValBal launches. At this stage, functionality was minimal; it had the skeleton of the entire site, written with angular. The only pages that had any content were the SPOT GPS pages with their embedded maps displaying where the balloons were. Beyond that, the core achievement was the skeleton itself: it was well designed and provided an excellent foundation for what was to come.

=== First Iteration ===
The next stage of HABMC, when it was still written with PHP, involved fleshing out the skeleton. We built the dashboard, which contains graphs and indicators of the flight vitals. The full map, which provided a larger view of the flight path, the transmissions page, which listed the parsed transmissions, and a utility to send messages to the balloon through RockBlock were all added as well. We created a couple pages to see what was happening at a lower level: a page to show us the raw, unparsed transmissions and a page that mapped the position estimate based on the iridium satellite network. One of the more exciting things that we added was the predictor utility, which made an educated guess as to where the balloon would go next, based off NOAA data. And to delve deeper into the data, we created the charts and graphs page, which graphed arbitrary data streams against each other. Finally, to control it all, we had a configuration page.

To power all of this, we had a complex backend, written at this point in PHP. When a transmission came in, it would be stored in a SQL database. Then, to parse and understand it, the transmission would be compared with the parser configuration we had set from the frontend. The backend was also responsible for keeping track of that configuration and making calculations (such as velocity) that were not in the transmission.

The data would also update in realtime, but it did so much less efficiently than it does now. Pages would repeatedly ping the backend and update their data if necessary. While this worked well from the user's perspective, as they never had to reload the page to see new data, it was terrible from the server's perspective. Each chart or graph, of which there were nine on the dashboard alone, had to make a request to the server every few seconds, meaning that the backend was bombarded with requests, most of which did nothing.

In this stage too a Github was created for easier code maintenance. While the deploy process still involved manually uploading the files via FTP, this simplified the challenges of working with multiple people on one project.

=== Recent Development ===
The most recent stage involved turning HABMC from a clunky interface to a more elegant bundle of code. To start, we rewrote the entire backend in Ruby on Rails. As GoDaddy does not support Rails apps, we transitioned to hosting HABMC on Heroku. Advantages here included better load monitoring and simpler deploys. The real advantages, though, came from the updated backend: we had a much more MVC oriented architecture, maintenance was easier, and security was stronger. Further, this allowed us to refactor the JavaScript that powered the core of HABMC. Prior to this, all of the JavaScript lived in one behemoth of a file. Taking advantage of the asset pipeline meant that we could separate this out into a couple dozen distinct files, making the codebase as a whole much simpler and understandable. Routing these files through the asset pipeline additionally meant that we could first minify and then gzip them (and all other static assets such as stylesheets), meaning that the end files were about a tenth the size.

Another achievement with the new server was creating a login system, based on Google Oauth. This provided the structural background for separating out who could view or edit what. For example, this let us make it so that only admins could edit the current mission configuration. This login infrastructure required, beyond integration with Google, session control and tables in the Postgres database for both users and various roles. It also needed a way to edit these roles for super admins, which resulted in a page that allowed easy viewing and changing of user roles.

A few new features also were released. One of these was the ability to plot FAA Zones on maps, helping us plan our way around restricted areas. We also added mission concurrency as an option. When multiple flights are active, users are able to select from a dropdown which flight to view; charts and graphs update accordingly. Additionally, we routed sent messages through the backend. Before, messages would be posted directly to RockBlock, in a completely opaque way. Now, messages are routed through the backend, storing them and providing an additional layer of security for the balloon alongside letting us view historically sent messages.

We also did a rewrite of the styles, making it look much better on mobile. This also included changing the editing of the parser, which determines the format of the incoming messages. Rather than having a difficult comma separated list that was prone to typos, we moved to a more stylish autocomplete.

To reduce server load, rather than pinging the server constantly, we moved to a model with push notifications, based on websockets. To further reduce the load, we also batched requests when a change was triggered.

=== Future Plans ===
In the near future, we will be building a log file analyzer. This will let us upload and explore historical flights, providing a united system of examining our data. We will also be working on active guidance -- systems that tell us which altitudes to fly the balloon at to avoid restricted FAA zones.

{{balloon-footer}}

[[Category: High Altitude Balloons]][[Category: Projects]]

Habmc

2017-09-17T18:50:23Z

Kaimarshland: Replaced content with "# REDIRECT HABMC"

# REDIRECT [[HABMC]]

Balloons Radio Projects

2017-09-17T18:49:14Z

Kaimarshland: Created page with "== SSTV: slow scan tv == Sending low resolution pictures very slowly (90s transmisison per pic) using frequency modulated analog signals at low bandwidth. This needs to be p..."

== SSTV: slow scan tv ==

Sending low resolution pictures very slowly (90s transmisison per pic) using frequency modulated analog signals at low bandwidth. This needs to be picked up ourselves with a hand held radio and decoding using a phone app or a computer program. This is a ONE WAY comms method (from balloon to ground ONLY).

== APRS: automated packet reporting system ==
Sending data, position, atltiude, callsign, to receive stations all around the world. This is a low bandwidth DIGITAL signal that is frequency modulated. No need to pick up ourselves, will be automatically uploaded to aprs.fi. This is a ONE WAY comms method (from balloon to ground ONLY).

== ATV:- amateur TV ==
Can be digital or analog (in our case it is analog), amplitude modulated signals, extremely high bandwidth (several MHz), live stream television. Need old huge TV for receiver. This is a ONE WAY comms method (from balloon to ground ONLY).

== (G)FSK, OOK ==
ValBal's long range digital radio system used to send any information we want at variable speeds & bandwidths. Can get anywhere from 500bps to 1Mbps, and anywhere from 1000km to 10km range depending on speed and antenna type. Need personal receiver, demodulator, rpi, to upload to [[HABMC]]. Eventually will be used to have 1Hz refresh rate on HABMC for vb and give active control. This is a partial duplex comms method (bidirectional, but not at the same time).

[[Category:Balloons]]

Habmc

2016-02-01T23:48:21Z

Kaimarshland: /* Public Page */

HABMC is the online mission control from which we can monitor balloons launches. It updates automatically in real time.

== Public Page ==
The public page of HABMC shows the position and altitude of the balloon, as provided by the ValBal communications system. This allows us to provide detailed information to the FAA and other viewers without overwhelming them with a vast quantity of potentially misleading data.
[[File: HABMC_Public.png | 500px | right]]

== SSI Interface ==
If you're logged in as a member of the space initiative or have an access code, you can view the full SSI page. This means that we have better control over our historical data and a variety of utilities.

=== Dashboard ===
This page has an overview of the flight so far. The first row has the current altitude, ascent rate, temperature, ballast drops, vents, and battery voltage, along with each of their changes since the last transmission and a graph of the last several data points. The next row contains a map of the most recent transmissions, and a map of the whole flight thus far. The third row has indicators for remaining ballast, cutdown state, and battery state. The fourth row consists of a graph displaying a couple of the most important metrics together.

=== Full Map ===
This page provides a full look at the flight so far, much larger than the version on the dashboard.

=== Transmissions ===
This is a table all parsed transmissions that have come in so far.

=== Send Message ===
This interface allows you to send messages to the balloon. In addition to having a place to enter the message, it shows the encoded version of the message and the cost to send. It requires both a set of rockblock credentials and to be logged in as an administrator. It then confirms with you before actually sending the message to avoid incorrect calls.

=== Sent Messages ===
This is just a table of all messages that have been sent to the balloon on this mission. Currently only administrators can view it.

=== SPOT Pages ===
These pages each have an embedded map showing where the spot GPS is. There are four, one for each SPOT.

=== Iridium Transmissions ===
This page provides a look at the raw, encoded version of the messages we have received from the balloon, in addition to some metadata that RockBlock provides us.

=== Iriridium Map ===
This map shows us the position of the balloon, based on where the Iridium Satellite Network thinks it is. It also shows a circle giving the estimated accuracy of the position. Given that this has very low acccuracy, typically close to 12km, this should only be used if all other positioning systems go down.

=== Predictor ===
This allows the user to run predictions on the balloon, from its current position, using manually input parameters of altitude and duration. If these parameters are not provided, it takes defaults from the last recorded position of the balloon.
It then plots the prediction on the map, while keeping all prior predictions as well. One is able to remove these predictions with a clear button.

=== Charts and Graphs ===
This page allows the plotting of any values versus any other given values. For example, the user can pick an “X axis” value, where logical options might be time or distance from launch site, and can then plot any number of other values on the Y axis. This could include voltage, solar current, velocity, altitude, temperature, etc (nearly any valuable flight parameter).

=== Configuration ===
This is a page that takes a bunch of parameters and settings for operation of the mission. In general, it is just a form that allows admins to set things like the format of the message, the flight ceiling and floor, and the maximum ballast capacity that are used to understand what the transmissions really mean.

== Technical Background ==
HABMC is written with Ruby on Rails and Angular.js. While in a previous iteration the backend was written with PHP and hosted on GoDaddy, it is currently hosted on Heroku. We have a Postgres database and use NewRelic for analytics.

So that the data can updated with minimal latency, we open up a websocket connection from the client to the server. Then, as soon as the data changes on the server, such as when a new transmission comes in, a message is sent through the websocket back to the client that tells it to refresh its data. This refresh is done with a HTTP request, rather than sending the data through the websocket, because HTTP requests are much more developed than websockets. These HTTP requests are able to support functionality like authorization, CORS, and caching easily, in addition to avoiding repeated code on the initial load of the page.

== History ==

=== Origin ===
Kirill Safin first created HABMC, designed as a way of understanding ValBal launches. At this stage, functionality was minimal; it had the skeleton of the entire site, written with angular. The only pages that had any content were the SPOT GPS pages with their embedded maps displaying where the balloons were. Beyond that, the core achievement was the skeleton itself: it was well designed and provided an excellent foundation for what was to come.

=== First Iteration ===
The next stage of HABMC, when it was still written with PHP, involved fleshing out the skeleton. We built the dashboard, which contains graphs and indicators of the flight vitals. The full map, which provided a larger view of the flight path, the transmissions page, which listed the parsed transmissions, and a utility to send messages to the balloon through RockBlock were all added as well. We created a couple pages to see what was happening at a lower level: a page to show us the raw, unparsed transmissions and a page that mapped the position estimate based on the iridium satellite network. One of the more exciting things that we added was the predictor utility, which made an educated guess as to where the balloon would go next, based off NOAA data. And to delve deeper into the data, we created the charts and graphs page, which graphed arbitrary data streams against each other. Finally, to control it all, we had a configuration page.

To power all of this, we had a complex backend, written at this point in PHP. When a transmission came in, it would be stored in a SQL database. Then, to parse and understand it, the transmission would be compared with the parser configuration we had set from the frontend. The backend was also responsible for keeping track of that configuration and making calculations (such as velocity) that were not in the transmission.

The data would also update in realtime, but it did so much less efficiently than it does now. Pages would repeatedly ping the backend and update their data if necessary. While this worked well from the user's perspective, as they never had to reload the page to see new data, it was terrible from the server's perspective. Each chart or graph, of which there were nine on the dashboard alone, had to make a request to the server every few seconds, meaning that the backend was bombarded with requests, most of which did nothing.

In this stage too a Github was created for easier code maintenance. While the deploy process still involved manually uploading the files via FTP, this simplified the challenges of working with multiple people on one project.

=== Recent Development ===
The most recent stage involved turning HABMC from a clunky interface to a more elegant bundle of code. To start, we rewrote the entire backend in Ruby on Rails. As GoDaddy does not support Rails apps, we transitioned to hosting HABMC on Heroku. Advantages here included better load monitoring and simpler deploys. The real advantages, though, came from the updated backend: we had a much more MVC oriented architecture, maintenance was easier, and security was stronger. Further, this allowed us to refactor the JavaScript that powered the core of HABMC. Prior to this, all of the JavaScript lived in one behemoth of a file. Taking advantage of the asset pipeline meant that we could separate this out into a couple dozen distinct files, making the codebase as a whole much simpler and understandable. Routing these files through the asset pipeline additionally meant that we could first minify and then gzip them (and all other static assets such as stylesheets), meaning that the end files were about a tenth the size.

Another achievement with the new server was creating a login system, based on Google Oauth. This provided the structural background for separating out who could view or edit what. For example, this let us make it so that only admins could edit the current mission configuration. This login infrastructure required, beyond integration with Google, session control and tables in the Postgres database for both users and various roles. It also needed a way to edit these roles for super admins, which resulted in a page that allowed easy viewing and changing of user roles.

A few new features also were released. One of these was the ability to plot FAA Zones on maps, helping us plan our way around restricted areas. We also added mission concurrency as an option. When multiple flights are active, users are able to select from a dropdown which flight to view; charts and graphs update accordingly. Additionally, we routed sent messages through the backend. Before, messages would be posted directly to RockBlock, in a completely opaque way. Now, messages are routed through the backend, storing them and providing an additional layer of security for the balloon alongside letting us view historically sent messages.

We also did a rewrite of the styles, making it look much better on mobile. This also included changing the editing of the parser, which determines the format of the incoming messages. Rather than having a difficult comma separated list that was prone to typos, we moved to a more stylish autocomplete.

To reduce server load, rather than pinging the server constantly, we moved to a model with push notifications, based on websockets. To further reduce the load, we also batched requests when a change was triggered.

=== Future Plans ===
In the near future, we will be building a log file analyzer. This will let us upload and explore historical flights, providing a united system of examining our data. We will also be working on active guidance -- systems that tell us which altitudes to fly the balloon at to avoid restricted FAA zones.

{{balloon-footer}}

[[Category: High Altitude Balloons]][[Category: Projects]]

File:HABMC Public.png

2016-02-01T23:44:23Z

Kaimarshland: Public page of HABMC

Public page of HABMC

Habmc

2016-02-01T23:40:26Z

Kaimarshland:

HABMC is the online mission control from which we can monitor balloons launches. It updates automatically in real time.

== Public Page ==
The public page of HABMC shows the position and altitude of the balloon, as provided by the ValBal communications system. This allows us to provide detailed information to the FAA and other viewers without overwhelming them with a vast quantity of potentially misleading data.

== SSI Interface ==
If you're logged in as a member of the space initiative or have an access code, you can view the full SSI page. This means that we have better control over our historical data and a variety of utilities.

=== Dashboard ===
This page has an overview of the flight so far. The first row has the current altitude, ascent rate, temperature, ballast drops, vents, and battery voltage, along with each of their changes since the last transmission and a graph of the last several data points. The next row contains a map of the most recent transmissions, and a map of the whole flight thus far. The third row has indicators for remaining ballast, cutdown state, and battery state. The fourth row consists of a graph displaying a couple of the most important metrics together.

=== Full Map ===
This page provides a full look at the flight so far, much larger than the version on the dashboard.

=== Transmissions ===
This is a table all parsed transmissions that have come in so far.

=== Send Message ===
This interface allows you to send messages to the balloon. In addition to having a place to enter the message, it shows the encoded version of the message and the cost to send. It requires both a set of rockblock credentials and to be logged in as an administrator. It then confirms with you before actually sending the message to avoid incorrect calls.

=== Sent Messages ===
This is just a table of all messages that have been sent to the balloon on this mission. Currently only administrators can view it.

=== SPOT Pages ===
These pages each have an embedded map showing where the spot GPS is. There are four, one for each SPOT.

=== Iridium Transmissions ===
This page provides a look at the raw, encoded version of the messages we have received from the balloon, in addition to some metadata that RockBlock provides us.

=== Iriridium Map ===
This map shows us the position of the balloon, based on where the Iridium Satellite Network thinks it is. It also shows a circle giving the estimated accuracy of the position. Given that this has very low acccuracy, typically close to 12km, this should only be used if all other positioning systems go down.

=== Predictor ===
This allows the user to run predictions on the balloon, from its current position, using manually input parameters of altitude and duration. If these parameters are not provided, it takes defaults from the last recorded position of the balloon.
It then plots the prediction on the map, while keeping all prior predictions as well. One is able to remove these predictions with a clear button.

=== Charts and Graphs ===
This page allows the plotting of any values versus any other given values. For example, the user can pick an “X axis” value, where logical options might be time or distance from launch site, and can then plot any number of other values on the Y axis. This could include voltage, solar current, velocity, altitude, temperature, etc (nearly any valuable flight parameter).

=== Configuration ===
This is a page that takes a bunch of parameters and settings for operation of the mission. In general, it is just a form that allows admins to set things like the format of the message, the flight ceiling and floor, and the maximum ballast capacity that are used to understand what the transmissions really mean.

== Technical Background ==
HABMC is written with Ruby on Rails and Angular.js. While in a previous iteration the backend was written with PHP and hosted on GoDaddy, it is currently hosted on Heroku. We have a Postgres database and use NewRelic for analytics.

So that the data can updated with minimal latency, we open up a websocket connection from the client to the server. Then, as soon as the data changes on the server, such as when a new transmission comes in, a message is sent through the websocket back to the client that tells it to refresh its data. This refresh is done with a HTTP request, rather than sending the data through the websocket, because HTTP requests are much more developed than websockets. These HTTP requests are able to support functionality like authorization, CORS, and caching easily, in addition to avoiding repeated code on the initial load of the page.

== History ==

=== Origin ===
Kirill Safin first created HABMC, designed as a way of understanding ValBal launches. At this stage, functionality was minimal; it had the skeleton of the entire site, written with angular. The only pages that had any content were the SPOT GPS pages with their embedded maps displaying where the balloons were. Beyond that, the core achievement was the skeleton itself: it was well designed and provided an excellent foundation for what was to come.

=== First Iteration ===
The next stage of HABMC, when it was still written with PHP, involved fleshing out the skeleton. We built the dashboard, which contains graphs and indicators of the flight vitals. The full map, which provided a larger view of the flight path, the transmissions page, which listed the parsed transmissions, and a utility to send messages to the balloon through RockBlock were all added as well. We created a couple pages to see what was happening at a lower level: a page to show us the raw, unparsed transmissions and a page that mapped the position estimate based on the iridium satellite network. One of the more exciting things that we added was the predictor utility, which made an educated guess as to where the balloon would go next, based off NOAA data. And to delve deeper into the data, we created the charts and graphs page, which graphed arbitrary data streams against each other. Finally, to control it all, we had a configuration page.

To power all of this, we had a complex backend, written at this point in PHP. When a transmission came in, it would be stored in a SQL database. Then, to parse and understand it, the transmission would be compared with the parser configuration we had set from the frontend. The backend was also responsible for keeping track of that configuration and making calculations (such as velocity) that were not in the transmission.

The data would also update in realtime, but it did so much less efficiently than it does now. Pages would repeatedly ping the backend and update their data if necessary. While this worked well from the user's perspective, as they never had to reload the page to see new data, it was terrible from the server's perspective. Each chart or graph, of which there were nine on the dashboard alone, had to make a request to the server every few seconds, meaning that the backend was bombarded with requests, most of which did nothing.

In this stage too a Github was created for easier code maintenance. While the deploy process still involved manually uploading the files via FTP, this simplified the challenges of working with multiple people on one project.

=== Recent Development ===
The most recent stage involved turning HABMC from a clunky interface to a more elegant bundle of code. To start, we rewrote the entire backend in Ruby on Rails. As GoDaddy does not support Rails apps, we transitioned to hosting HABMC on Heroku. Advantages here included better load monitoring and simpler deploys. The real advantages, though, came from the updated backend: we had a much more MVC oriented architecture, maintenance was easier, and security was stronger. Further, this allowed us to refactor the JavaScript that powered the core of HABMC. Prior to this, all of the JavaScript lived in one behemoth of a file. Taking advantage of the asset pipeline meant that we could separate this out into a couple dozen distinct files, making the codebase as a whole much simpler and understandable. Routing these files through the asset pipeline additionally meant that we could first minify and then gzip them (and all other static assets such as stylesheets), meaning that the end files were about a tenth the size.

Another achievement with the new server was creating a login system, based on Google Oauth. This provided the structural background for separating out who could view or edit what. For example, this let us make it so that only admins could edit the current mission configuration. This login infrastructure required, beyond integration with Google, session control and tables in the Postgres database for both users and various roles. It also needed a way to edit these roles for super admins, which resulted in a page that allowed easy viewing and changing of user roles.

A few new features also were released. One of these was the ability to plot FAA Zones on maps, helping us plan our way around restricted areas. We also added mission concurrency as an option. When multiple flights are active, users are able to select from a dropdown which flight to view; charts and graphs update accordingly. Additionally, we routed sent messages through the backend. Before, messages would be posted directly to RockBlock, in a completely opaque way. Now, messages are routed through the backend, storing them and providing an additional layer of security for the balloon alongside letting us view historically sent messages.

We also did a rewrite of the styles, making it look much better on mobile. This also included changing the editing of the parser, which determines the format of the incoming messages. Rather than having a difficult comma separated list that was prone to typos, we moved to a more stylish autocomplete.

To reduce server load, rather than pinging the server constantly, we moved to a model with push notifications, based on websockets. To further reduce the load, we also batched requests when a change was triggered.

=== Future Plans ===
In the near future, we will be building a log file analyzer. This will let us upload and explore historical flights, providing a united system of examining our data. We will also be working on active guidance -- systems that tell us which altitudes to fly the balloon at to avoid restricted FAA zones.

{{balloon-footer}}

[[Category: High Altitude Balloons]][[Category: Projects]]

Habmc

2016-01-31T19:51:40Z

Kaimarshland: