Need to update packet header specs

There are a lot of instances of # type: ignore in the codebase. While they don't need to get removed, it might be a good idea to look into why they're there and get rid of them.

In order to support new developers joining the team, the GitHub wiki should be updated with a contribution guide.

Steps to be outlined

• How to create a branch/fork for development
• How to verify workflow issues before creating a pull request (flake8, pyright, running tests, etc)
• How to open a pull request and request reviews, etc
• How to mention issues in a pull request so as to link resolutions appropriately

Optional (would be nice to have)

Feel free to add additional steps as you see fit, like how to write clear commit messages, how to rebase/merge main into a development branch, how to revert commits/amend commit messages, etc.

When inputting a block header with a block subtype that its recognized by DataBlockSubtype yet not implemented, e.g.

It should raise NotImplementedError

yet it raises at v1/data_block.DataBlock.parse the DataBlockUnknownException

when it should go to the parse_data_block

Make index implementations less known throughout the program

Code breaks on mac when running main.py
Current fix: comment out lines 125 and 126 in /modules/serial/serial_manager.py
Not sure why its breaking though, its probably a piece of code from an older version

In order to create the most effective continuous integration procedure, test cases should have high coverage of the repository code.

Test cases should be developed as follows:

• For all feasibly testable modules
• For all code paths within those modules (100% coverage)
• With pytest compatibility
• With as short as possible runtime

All new modules should be accompanied by their own comprehensive testing. This will ensure that any refactors or code changes work before they are merged to main.

Problem

The current GitHub wiki does not contain a detailed installation process for using the ground station software.

Proposed solution

A detailed guide for installing both the ground station software and its prerequisite dependencies (everything necessary for the end user to operate it) should be added.

Should include

• Installing CP210x USB UART driver
• Cloning repo
• Installing Python 3.11+ and module requirements

Should also have additional steps for those working on development (i.e. setting up a virtual environment)

Future additions

Because most of the team will be using Windows, the installation guide should focus on installation and troubleshooting on Windows environments. When the need arises, installation for other operating systems (or different Windows versions, etc.) should also be included.

As soon as the ground station is capable of receiving velocity measurements, it should provide a magnitude to the UI. Currently x, y and z components are being sent separately (which is fine) but an additional magnitude of the velocity vector should be sent. This should include the heading as well.

Now that we've added logic for parsing V1 datablocks, we need to ensure that logic is used on reading telemetry payloads

Chosen solution: modify parse_rn2483_payload to have Datablock class passed in as an argument, different class will be passed in depending on packet version read in parse_rn_2483_transmission.

Work required:

• Create python protocol for type hinting
  • Protocol should contain enough parse method definition
• Modify telemetry.py with noted changes

Problem

There are no instructions on how to use the ground station software written in the GitHub wiki.

Proposed solution

A guide for how to operate the ground station software should be included in the GitHub wiki.

Should include

• Helpful command line arguments (try not to duplicate the -h help menu, but provide steps for discovering it)
• Best practices (log files should be .log not .txt)
• How to check ground station COM port from device manager (on Windows, Linux alternative can also be provided)
• Available websocket commands for the test.html file/web interface

Inline documentation in many different modules (such as the block modules or enum modules) are lacking full documentation.

• All functions, methods and classes should be given docstrings
  • Docstrings should ideally mention what is returned if applicable, if no return what the function does, and have an explanation of
    parameters if necessary (i.e. what are the units of the 'distance' parameter, etc).
• Module files should have a brief description comment at the beginning of the file
• All functions, methods and class attributes should be type annotated as specifically as possible

Doing so will not only make the code clearer for newcomers, but can also help with intelli-sense/LSP suggestions. This will speed up the development process and make errors less probable.

The GroundStation class has functions specifically related to the RN2483 chip. Changing the name to reflect this (such as to RN2483) and then making the class more general purpose would be ideal. Functions specific to groundstation could be moved to a derived class.

Problem

Currently, the ground-station-ui is recording the last n packets it receives (of each type) in local storage buffers. The constant writing operations are expensive and may affect the frontend performance. It also requires graph components to look for a localStorage write event to update themselves by reading from the buffer.

Proposed change

To have such a buffer implemented on the backend side of the telemetry server to save on frontend operations. It will be more efficient on the backend. It would also be useful to implement a websocket command to allow the frontend to request a different buffer size (i.e. store the last n packets in the buffer).

There is always one packet remaining in the buffer.

The new packet encoding versions have been written and are currently being used for packet parsing, we still have the old versions of modules and other pieces of code that should be deleted.

Description

When you run main.py outside your local ground-station directory, you get the error: FileNotFoundError: [Errno 2] No such file or directory: 'config.json', in main at line 69: config = load_config("config.json").

Steps to Reproduce

Run main.py outside local ground-station directory.

Expected behaviour

Not crash.

Environment

• OS: MacOS 13.5.1

Problem

Packet encoding broke. We need to write decoding for altitude data blocks.

Proposed Solution

See stub in modules/telemetry/v1/data_block.py

Problem

Packet encoding broke. We need to write decoding for debug message data blocks.

Proposed Solution

See stub in modules/telemetry/v1/data_block.py

Description

A clear and concise description of what the bug is.

Steps to Reproduce

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behaviour

A clear and concise description of what you expected to happen.

Environment

• OS: [e.g. iOS]
• Software version [e.g. 22]
• Branch

Additional context

Add any other context about the problem here.

Attachments

Include any log files, screenshots, test reports, etc.

Since I added the TestData.mission sample file, the JSON packets test is failing because the new .mission file is not in the same format. The tests should be agnostic to the missions in the missions/ directory.

Please update/remove the tests so they are either gone or are agnostic to the missions listed in the missions/ directory. The reason you're allowed to remove the tests is because much of the code it is testing will be deprecated shortly anyways.

Make the README.md file more descriptive, include required modules, a license, a brief overview of the program, etc.

Should probably be saved for later when the code is more refactored/complete.

Problem

The ground-station-ui should have a visual indication when anomalous measurements are detected from the rocket sensors. However, such calculations should not take place on the UI. Instead, the ground-station should detect such measurements and flag them so they are easily identifiable when the UI receives JSON packets through the websocket.

Proposed Solution

Have an intermediate step of checking for anomalous readings before sending out packets over the websocket to the UI.

Alternatives

N/A at this time.

Additional Context

It's important to consider how to best store the information of which measurements are anomalous. We don't want to create much extra clutter in the JSON packets, so storing on a per-measurement basis is probable not great:
Example:

{
    "measurements": {
        "temperature": {
            "value": 10,
            "anomalous": false
        },
        "altitude": {
            "value": 10000000000000000001,
            "anomalous": true
        }
    }
}

Instead, it might be better to only record anomalous measurements using a separate key:

{
    "measurements": {
        "temperature": 10,
        "altitude": 100000000000000000001
    },
    "anomalies": [
        "altitude"
    ]
}

Replace all format strings with f strings for readability.

Linear velocity data blocks are ready for transmission as per CarletonURocketry/packager#66.

Add the decoding class so that we can receive those packet types! Make sure to reference the spec in https://github.com/CarletonURocketry/telemetry-format/.

If the stop command is sent twice, backend breaks

Follow CUInSpace coding standards at PEP, including spaces between operators, spacing between function definitions, etc.

Several CPUs are being pinned because loops are running as fast as the CPU will run them.

Problem

Packet encoding broke. We need to write decoding for temperature data blocks.

Proposed Solution

See stub in modules/telemetry/v1/data_block.py

Problem

Although the repository currently has a good amount of inline documentation, it is only visible in the source code.

Proposed Solution

There should be a static webpage that hosts the documentation, which is automatically generated by a GitHub workflow. In order to do this, there should also be a standard doc-string format enforced (one that integrates well with Python tools & LSPs).

Additional Context

There are a couple different doc-string formats (list non-exhaustive):

• Sphinx
• Google
• reST

Ideally, the format that is selected should be able to have a description, parameters, return description, exceptions which could be raised and example usages. Exceptions and examples should be optional fields.

Additionally, the documentation generator should automatically pick up on the type annotations to be included in the documentation. This will avoid duplicating type information in doc strings, which is prone to mistakes. This generator should also pick up default values for keyword arguments.

Now that the ground station has been refactored to remove non-state-dependent functions outside of the process class, we should write tests to ensure we get all the correct info when we parse an entire transmission packet.

These tests should observe the ParsedTransmission dataclass and should assert that the values within that dataclass match what is expected. The tests should also be exhaustive and should test that we properly catch errors when they occur.

Currently, block headers have an additional field that labels whether or not they are valid.

See modules/telemetry/v1/block.py.

This should not be the design of the block header class. When constructed, BlockHeader should raise an exception if any of the parameters it's given could be considered invalid. This forces the calling code to handle the exception there and then or bubble it up for the higher level code.

As always, tests may need to be updated to reflect this change.

Please note that this issue is dependent on the completion of #36.

Problem

Packets are received very frequently and are subject to interference/noise, which may result in corrupted measurements being received. This will trigger anomalous fault detection incorrectly.

Additionally, what is considered an anomalous measurement for Spaceport might not be anomalous at Launch Canada (i.e. a temperature of 50 degrees Celsius on the launch pad at Spaceport is expected).

Proposed Solution

The threshold at which an anomalous fault is reported should be configurable, both in the value considered anomalous and how many packets within that range need to be received before a warning is issued.

For instance, this configuration for temperature at Spaceport (inside spaceport.json) says that a warning should be issued if at least 3 packets in a row are received which report a temperature lower than 10C or higher than 60C.

{
  "measurement": "temperature",
  "range": [10, 60],
  "packet_min": 3,
}

Additional Context

This configuration file's path should be able to be provided via both command line options or within the config.json file. Any config file provided over command line arguments will be used over the one within config.json.

The reasoning for a separate config file is to have different presets for each different competition/launch setting.

Angular velocity data blocks are ready for transmission as per CarletonURocketry/packager#66.

Add the decoding class so that we can receive those packet types! Make sure to reference the spec in https://github.com/CarletonURocketry/telemetry-format/.

In modules/telemetry/v1/block.py, the version and src_addr fields in PacketHeader should be constructed using the enums for packet versions and device addresses.

This will validate fields instead of having plain integers which could contain erroneous values (1000 for source address).

As always, tests may need to be updated to reflect this changes.

Problem

Packet encoding broke. We need to write decoding for pressure data blocks.

Proposed Solution

See stub in modules/telemetry/v1/data_block.py

The is_valid_packet_header should be renamed since it's not checking for validity, only for whether or not the call sign is recognized. The naming should reflect that, as should the docstring.