HABMC

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.

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.