carletonurocketry / packager Goto Github PK

An implementation should be made for the debug message data block implementation. The implementation should follow the style of existing types.

Note that the debug message block does not have a fixed length unlike some other radio packet blocks (although it does have a minimum length). This should be handled accordingly.

See /docs/radio_packet_format.pdf section 3.3.1 for more details.

For some reason I can't get QNXs port of <getopt.h> to work. It seems like they're missing critical pieces of it, like optarg and opterr. If someone could investigate why that is and get argument parsing working, that would be great.

It's currently unclear what arguments we will take to packager, but it is certain we'll need an argument to pass an HAM radio call sign (see the .use file for information on the desired syntax). This will need to be set up using getopt or something equivalent. There's no reason why QNX's port of this library shouldn't work.

The GNU docs for getopt can be found here

An implementation for the angular velocity data block needs to be added to the packet types. The implementation should follow the style of previous implementations.

See /docs/radio_packet_format.pdf section 3.3.4 for more information.

An implementation for the acceleration data block needs to be added to the packet types. The implementation should follow the style of previous implementations.

See /docs/radio_packet_format.pdf section 3.3.3 for more information.

An implementation for the altitude data block needs to be added to the packet types. The implementation should follow the style of previous implementations.

See /docs/radio_packet_format.pdf section 3.3.2 for more information.

Altitude data was just added to fetcher in this pull request, but packager does not recognize it.

Packager should be updated to read in the new altitude data produced by fetcher and package it into radio packet format. See the telemetry-format specifications for more information.

There should be some unit testing going on for our library functions. It will not have to be anything fancy; using asserts should be enough for the most part.

I am envisioning tests being in the directory structure like so:

C:.
├───.github
│   └───workflows
├───docs
├───nto-aarch64-o.le
├───nto-x86_64-o
├───src
│   └───include
└─tests
   ├───bin
   │   ├───packet_header_tests.exe
   │   ├───packet_data_tests.exe
   │   └───....
   └───packet_header_tests
       ├───packet_header_test.c
       └───...

The tests directory will contain sub directories for each group of unit tests (packet header tests, packet data tests, etc.). The Makefile within the tests directory should hook into QNX's build system (see other Makefiles in the nto-* directories) to create a bin directory full of all the unit test binaries. These test binaries should be executed via a make test command in the project's root Makefile.

This is just an idea and could be expanded on.

The automatically styled Doxygen website kinda looks like it was made in the 90s. It would be nice if we could add our own custom CSS rules (and include the InSpace logo, there's a spot in the Doxyfile to allow that).

An implementation for the KX134-1211 accelerometer data block needs to be added to the packet types. The implementation should follow the style of previous implementations.

See /docs/radio_packet_format.pdf section 3.3.8 for more information.

This GitHub repository has several workflows set up; however it's crucial that we ensure our codebase can be fully built within the QNX development environment. This includes:

• No compilation errors
• No compilation warnings
• No files missed by the Makefiles
• Use manual is included in binary
• All builds can be fully made

Having a workflow that checks all these things before PRs get merged would be incredibly helpful, since we don't want any one PR to be able to break the codebase. This could be hard to track down.

Because we don't have a Docker image containing all the QNX development tools, we are using an honour system to make sure developers check that their code compiles before submitting it as a PR. This shouldn't be a long-term solution.

This document contains information about how to set up the QNX Software Development Platform (SDP) as a Docker image. We will have to make our own. Note that you must be logged in to your myQNX account to view the document.

Following some research regarding bit-fields within C structs, it turns out that it's not possible to guarantee the order of the fields once compiled. This means that we cannot use our current type-union between byte arrays and structs in order to encode packet data, or our packets will not follow the spec when sent over radio.

C bit-fields standard

To resolve this issue, we will need to do the following:

Typedef packet types as being pure byte arrays:

typedef uint8_t PacketHeader[4];

Provide functions or macros for accessing parts of the byte array using masks:

uint8_t inline get_length(PacketHeader *p){
    return *p & 0x0FF0; // This is a made up mask that doesn't follow the real packet spec
}

Humidity data collection is being implemented in fetcher. Humidity is measured in relative percentage units.

Please see the telemetry-format repository to check for the packet encoding for humidity. This encoding needs to be implemented in packager.

An implementation for the MPU9250 IMU data block needs to be added to the packet types. The implementation should follow the style of previous implementations.

See /docs/radio_packet_format.pdf section 3.3.7 for more information.

An implementation for the block that requests telemetry data should be added to the packet types library. Follow the format of the existing types for guidance.

See /docs/radio_packet_format.pdf section 3.2.2 for more information about the block.

An implementation for the GNSS location data block needs to be added to the packet types. The implementation should follow the style of previous implementations.

See /docs/radio_packet_format.pdf section 3.3.5 for more information.

I have overlooked that the packet specification requires all packet entries to be in little endian format. This means that bytes are in reverse order of what we could consider human readable.

Ex:

Big Endian: 0x0321
Little Endian: 0x2103

Notice that only the bytes are reversed, not the bits.
The RPis are little endian machines (aarch64le) so nothing special is required. memcpy will copy memory in little endian format.

An implementation for the signal report block should be added to the packet types library. Follow the style of the other implementations.

See /docs/radio_packet_format.pdf section 3.1.1 for more information about the block structure.

An implementation for the GNSS metadata block needs to be added to the packet types. The implementation should follow the style of previous implementations.

See /docs/radio_packet_format.pdf section 3.3.6 for more information.