Fix/erase sector timing

[Elan456]

Description

Sector erasing in DataSaverSPI now triggers after each flush to prep for the next flush. This eliminates the 50 ms latency spike caused by the sector erase blocking the buffer flush. As long as the 256 byte flush buffer isn't filled within 50 ms, the eraseSector can happen without causing latency spikes, otherwise this fixes still reduces the latency by no less than 10 ms.

Summary of Changes

• DataSaverSPI tracks which sector has been prepared
• DataSaverSPI will prep the next sector has soon as the buffer filling the previous sector is written rather than waiting for the first flush of the new sector
• Made a GroundLevelEstimator test less flaky my increasing the epsilon and number of samples

Motivation

• The erase sector spike was directly causing MARTHA to not be able to go above 96 Hz and caused some loops to take 50 ms instead of the typical 10 ms. With this fix, we can hit upwards of 970 Hz when all rate limits are removed.
• To improve this further, you could use a larger buffer (such as 512 bytes) and then have more time to finish erasing the sector before then next buffer needs to be written. At MARTHA"s current data rates, a 256-byte buffer is still enough (excluding instances where we write a bunch of data all at the same time such as on 2-second intervals, but that only causes a 12 ms loop not a 50 ms one now.)

---

Testing

• Ran on MARTHA 1.4 for 2 minutes and observed 2 minutes of uncorrupted data in the data dump with an average Hz of 99.787

Check all that apply:

• I have added or modified unit tests to cover these changes.
• I have manually tested the changes on the target device(s) or environment(s).
• Existing tests were reviewed to ensure they still work as expected.
• If tests were not added or modified, explain why:

  (Provide reasoning here)

---

Checklist

• My code follows the style guidelines of this project.
• I have performed a self-review of my own code.
• I have commented my code where necessary for clarity.
• I have made corresponding updates to documentation (if applicable).

[Copilot]

Pull request overview

I read the AGENTS.md.

This PR aims to reduce SPI flash logging latency spikes by pre-erasing the next sector immediately after each buffer flush, so sector erase time can overlap with buffer fill time.

Changes:

• Add preparedSectorNumber_ tracking and pre-erase logic in DataSaverSPI::flushBuffer().
• Add a unit test asserting the next sector is erased before the write crosses a sector boundary.
• Reduce flakiness in GroundLevelEstimator noise test by increasing samples/epsilon.

Reviewed changes

Copilot reviewed 4 out of 5 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
src/data_handling/DataSaverSPI.cpp	Implements “pre-erase next sector after flush” behavior and tracks prepared sectors.
include/data_handling/DataSaverSPI.h	Adds preparedSectorNumber_ member and <limits> include.
test/test_datasaver_spi/test_DataSaverSPI.cpp	Adds a regression test for pre-erasing the next sector at the sector boundary.
test/test_ground_level_estimator/main.cpp	Increases sample count and tolerance to reduce test flakiness.
.gitignore	Ignores .codex.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 6 changed files in this pull request and generated 4 comments.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 6 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 6 changed files in this pull request and generated 2 comments.

[Mayday-01]

I see nothing that breaks would break MARTHA or dynamically allocate resources. That said, I noticed on lines 36 and 54 of src/data_handling/DataSaverSPI.cpp that a repeated if structure occurs that could probably be a function in the DataSaverSPI.h