• We need to update the readme with clearer installation procedures.

The mission timer component flickers to "waiting..." every few seconds.

Problem

The clear storage button was used as a debug tool to clear the local storage. It is really ugly and should not be exposed to end users.

Solution

Remove it.

If an altitude/pressure, etc. measurement is beyond the acceptable range for our test conditions, there should be some kind of warning indication on the graphs as well as on the main page.

Ideally, a graph will have some sort of red/warning colour for the text or display when measurements are bad that is easy to notice.

A CSS class should be created for the dashboard panels to make the edges glow red when one or more measurements are anomalous.

Make the navbar link for the page that is currently open be highlighted so there is an indication of which page is open.

Ideally, should be a button somewhere that calls the clear_telemetry function for debugging. Will be removed on production build.

Currently, local storage does not get cleared on reload (and it won't during the final product either, because if the connection gets interrupted, we don't want to lose historical data).

This is not a problem for production because live sensor data will more or less pick up where it left off. Right now, when the websocket restarts, it returns to it's initial data values and starts incrementing again. This is not good for testing because it means the charts will not appear to update until we wait a sufficient amount of time to catch up with where we last left off. Clearing local storage will fix this.

Give more examples on how to use useStorage hook.

• We need to replace the ECharts gauge with a custom Airbnb Visx gauge

Useful links:
https://airbnb.io/visx/

https://codesandbox.io/search/?query=visx%20gauge&page=1&configure%5BhitsPerPage%5D=12&refinementList%5Btemplate%5D=&refinementList%5Btags%5D=

We currently have a map page which is updated with the live GPS location of our rocket, but it requires an internet connection. If we could host our own map tiling server, that would be optimal.

Currently the location of all graph panels on our dashboard are set in stone. It would be better if they could be reordered through a click-and-drag interface so that each individual user of the dashboard can prioritize the information they want to see.

A few considerations:

• The panel widths are dynamic right now. If click-and-drag is implemented, it should have a sensible minimum width (or perhaps a width based on the style of the graph; i.e. time series graphs are longer)
• The panel being reordered should have some kind of visual indicator that it is being reordered (like a slightly transparent rendering of the panel which follows the cursor while it's dragged)
• The graph should continue to update whilst being dragged.

Currently, the Devil The Rocket mission replay file is hardcoded in the UI. The Replay.jsx page (or popup if that issue is completed) should pull the available mission names from the list given in the JSON entry.

When trying to build the SVG's cause build errors.
someone fix plz :3

• Make it work (add ui optimizations)
• Find a OS that actually can run it
• Figure out a way to make it run on raspberry pi

Backend sends an update frame when this command is used.

The graphs currently being used for the dashboard are from the Apache eCharts library. These graphs are not optimized to keep up with the speed at which telemetry data is provided (especially noticeable when playing missions back at more than 1x speed).

As a solution, a new chart library was suggested by @SippinOnJuiceBox, which has been optimized for fast data changes. You can find it here.

It would be good to transition all current graphs to this format.

This project is written in JavaScript (and already has docstrings written using JavaDoc style). There should be a GitHub workflow which automatically generates a static documentation website using JavaDoc and deploys it to this repository's GitHub pages.

Problem

Ground station PR adds a telemetry data buffer to the backend, which when merged will break UI parsing of data.
CarletonURocketry/ground-station#51

Proposed Solution

There should an update implemented that implements the new telemetry data buffer.

There should be issue templates for new members to format their issues & also a guideline for PR templates.

Problem

The telemetry server on the ground-station repo is able to provide a list of available COM ports in its websocket JSON data. This is necessary for starting the server connection to the ground station board using the websocket commend serial rn2483_radio connect <COMx>.

Proposed solution

Currently, the UI does not have a way to send this initial connection command. A list of available COM ports should be added so that when a user selects one, it sends the websocket command for connecting to the serial port. After this command, the selection menu could disappear until brought up again (should user be able to bring it up, should it only be brought up initially, should it be brought up every time connection is severed with the telemetry server?).