Create "MPI active and recording data" mode

[DeflateAwning]

Telecommands:

1. Turn MPI on and start recording
   • Arg: Run duration in seconds, from 1 sec to 20 minutes.
2. Turn off MPI early
   • Turns the MPI off immediately, if it's active currently

Requirements, when active and recording

• Start a file with the "recording start time" timestamp.
• Collect the data and write it to the filesystem.
• Monitor temperature (from EPS), and stop experiment early if too hot
• Monitor temperature (from MPI), and stop experiment early if too hot

Thread

• Use a thread to do the actual UART-to-array-to-FS operation
• Use a shared configuration variable, where the telecommand can set the variable, and the thread operated if enabled

[DeflateAwning]

@JohnathanBurchill, in the current plan, we want to make MPI data recording very "high priority" in a scheduling sense, but we don't want it to cause essential satellite functionality to stop working. For example, receiving telecommands, logging GPS data (if enabled), etc. must continue during MPI data collection.

As such, it is possible that, perhaps, every few seconds, a few frames of MPI data will be dropped (in a predictable/expected/documented manner) to ensure satellite operation continues smoothly. Obviously the goal is to use features like Direct Memory Access (DMA), thread/task management, etc. to minimize the dropped data.

Can you give some suggestions on allowable vs. problematic thresholds for this collection? Is dropping the following amount of data reasonable?

• 1 full contiguous second per 30-second period of data collection
• 2 frames every 3 seconds

Note that each frame will be timestamped, so dropped frames will not "skew" the data, but will instead just appear as gaps (if analyzed appropriately).

[JohnathanBurchill]

@JohnathanBurchill, in the current plan, we want to make MPI data recording very "high priority" in a scheduling sense, but we don't want it to cause essential satellite functionality to stop working. For example, receiving telecommands, logging GPS data (if enabled), etc. must continue during MPI data collection.

As such, it is possible that, perhaps, every few seconds, a few frames of MPI data will be dropped (in a predictable/expected/documented manner) to ensure satellite operation continues smoothly. Obviously the goal is to use features like Direct Memory Access (DMA), thread/task management, etc. to minimize the dropped data.

Can you give some suggestions on allowable vs. problematic thresholds for this collection? Is dropping the following amount of data reasonable?

• 1 full contiguous second per 30-second period of data collection
• 2 frames every 3 seconds

Note that each frame will be timestamped, so dropped frames will not "skew" the data, but will instead just appear as gaps (if analyzed appropriately).

As a starting point, either way is fine. I'd like to aim to get all the data though. Happy to discuss.

The MPI bytes do not stream continuously. At a baud rate of 23400, the 150 bytes of an MPI frame take about 6 ms to transmit to the OBC. The frame rate is about 32 per second - much of the MPI operation involves integrating ion signal (31 ms), and that is typically a lot longer than the time it takes to transmit a frame (6 ms). Maybe there is a way to build the byte capture into the UART interrupt using a ram buffer with flags to signal a lower-priority task to write the buffer to a drive.

[DeflateAwning]

That sounds much more manageable than I had in my head. 150 bytes/frame x 32 frames/s = 4800 bytes/sec.

If we use a buffer of 19,200 bytes (4800x4), the writeback (which occurs when the buffer is half-full) could happen once every 2 seconds. This will be easy to hit.

I don't think we'll need to drop any data anymore.