The Sphinx-generated documentation says that the pressure field in the MPL3 documentation is 8 bytes long. However, it's only 4 bytes. The associated type column is correct, saying "uint32_t".

Not relevant to this repo, but is it a known issue that in the Launch-11 data, the length field for MPL3 messages is in the wrong endianness?

Feeding http://annex.psas.pdx.edu/Launch-12/flightcomputer.log to the psas_packet tools causes an exception in psas_packet.messages.printable partway through the log. It looks to me like it's de-synchronizing partway through the log, and then trying to interpret random data as a message header. But I haven't figured out how that's happening.

I'm going through the list of projects on the PSAS website, making a list of the active/old projects. Is this still a thing? Is it going on LV3? It hasn't been pushed to in like 2 years.

Currently for each new data container we do something like this:

struct FooData {
    type field1;
    type field2;
}

struct FooMessage {
    char ID[4];
    uint8_t timestamp[6];
    uint16_t length;
    struct FooData data;
}

Instead we should have a single struct for the header and then either have struct FooMessage be a combination of the two structs, or have FooData be expanded inside FooMessage, or something.

The scale factor in messages.py for the ADIS gyro measurements yields degrees per second, but the units are labelled as Hertz. It's easy to fix either one; which should it be? I'm inclined toward either degrees or radians per second, personally.

Thinking long term, we probably should know what version of this package generated a logfile. In particular the way to encode/decode types has already changed a couple of times since we have had bugs in the firmware for sensors and argued about units etc. For example, the current master branch will fail at decoding the first drop tower data, but not the second (we changed a message header definition between the two).

We might also want comments like local time for file creation (I know it's in the filename, but it might not always be) or just regular comments like "launch 11", or "droptower test 5, didn't go so well".

There is precedent, like EXIF data in JPEG, but my favorite is the scientific FITS image format, which is very old and since it was "expensive" to load an image 1981 it includes a user definable ASCII metadata, literally designed so you could run head -c 80 random-image.fits and figure out what the image might be before waiting an hour to load it.

It would be great if 8 years from now we could grab a logfile from 2015 and, without any special knowledge (e.g., remembering the quirks from that launch) still be able to unpack it.