GPS: log GPS position to filesystem

[DeflateAwning]

• Write a function which logs the date and time to the GPS log file in the filesystem.
  • Function argument: how many seconds of logs to collect (default: 60)
• Cycle the log every 24h to a new file.
• Call this function once-per-hour (interval configurable with a configuration variable).

Notes

• GPS requires a "warm-up" period before recording data.
• None of this Issue requires sending data to the GPS. This is a receive-only task.

Implementation Steps

1. Setup a receive buffer in interrupt mode in the uart_handler.c file. Register the interrupt.
2. Create an RTOS task that has a loop that runs every 200ms. The GPS sends data every 1000ms, so 200 ms ensure that data is very likely to be dealt with by the time the GPS sends the next update.
3. In the RTOS task, read the buffer that gets written to with the interrupt. Parse the data into a struct, if there's new and complete data available. Then, set the write pointer back to 0.
4. Use DEBUG_UART_print_str or LOG_message (ideally the latter, eventually) to log the GPS data (probably in JSON format).
5. Future Step: if the timestamp provided in the latest GPS update is reliable (GPS indicates it has a fix, and is synced, etc.), then call the appropriate update function in timekeeping.c: TIM_set_current_unix_epoch_time_ms(time, GPS_ENUM_VALUE)

[mzcigler14]

there is a branch currently matjaz-GPS, let me know If you can see it

[mzcigler14]

finished code that parses the receive array if there are multiple logs in one receive, started writing out test prints, need to complete this and test with rasberry pi to make sure parsing is working properly.

[DeflateAwning]

Looks like some awesome progress in there! Am excited to see how testing goes!

A bit of feedback:

1. Need to restore main.c. Looks like a bunch of whitespace changes got in there.
2. Need to adhere to the guidelines in https://github.com/CalgaryToSpace/CTS-SAT-1-OBC-Firmware/blob/main/docs/C_General_Guidelines.md (e.g., namespace convention, enum naming, enum values, error propogation, etc.)

Let's work on getting just one or two commands/incoming data types working for now, and move the rest of the functions out of this branch (to be worked on later)

[DeflateAwning]

Question for the Orbit team to answer here:

1. How do we know when the GPS "has a fix", and that its timing and position data is valid, based on the response to commands? Answer: it's in the status field
2. Are there GPS "states" when the time it provides is valid, but the positions is not valid? Answer: yes, status field
3. Is there a way to get the uncertainty of the timestamp? Answer: yes, in the offset standard deviation
4. How does the PPS (pulse-per-second) output pin work? Does it pulse at the "top" of each second (i.e., when the number of milliseconds is 0)? Is any configuration required? Answer: On by default. Controlled with the PPSCONTROL command. Address more in #122.

Update: 2024-08-29 - updated with answers.

[DeflateAwning]

Two commands to focus on parsing, only. The rest will be handled by a future mechanism in #138 (arbitrary GPS commands).

Two main commands:

• BESTXYZ
• TIME

In BESTXYZ, parse out, and later make very easy to log/downlink the following fields:

• pos status
• pos type
• Location coordinates
• Location standard deviation
• diff_age
• sol_age

In TIME, parse out into a struct, and later use to update the clock:

• clock status (maybe not needed)
• utc offset
• utc status (valid, invalid, warning)

[NuclearTea]

@christopherkinyua was wondering what the status on this Issue is?

[christopherkinyua]

@christopherkinyua was wondering what the status on this Issue is?

Currently conducting tests with the GPS receiver. I need to solder pin headers onto my STM board then I can carry on with the testing. @NuclearTea