Description
When sensor configurations are changed during an active recording session to the SD card, the system continues writing to the current file instead of creating a new one.
This leads to a single file containing data from multiple, potentially incompatible sensor configurations.
Expected Behavior
- A new file should be created whenever the sensor configuration changes.
- Each file should contain data corresponding to exactly one consistent sensor configuration.
Current Behavior
- The active file is not rotated.
- Data from different configurations is appended to the same file.
Problem Scope
This behavior introduces ambiguity and makes post-processing difficult, as:
- Data schema may change mid-file
- Sensor streams may appear/disappear or change format
Additional Requirement: Handling Rapid Configuration Changes
The current implementation of the sensor configuration characteristic is in a way that multiple configuration updates are applied in quick succession, one for each sensor.
Undesired behavior:
- Creating a new file for each intermediate configuration change → leads to many fragmented files
Desired behavior:
- Avoid creating multiple files for rapid consecutive changes
- Only create a new file once the configuration stabilizes
Suggested Approaches
Possible strategies to handle this:
-
Debounce mechanism
- Wait for a short stabilization window (e.g., 100–500 ms)
- Only rotate the file after no further configuration changes occur
-
Transactional configuration updates
- Introduce a "configuration update session"
- Only trigger file rotation after the full configuration is applied
- This might pose problems, as our specification does not require settings all configurations
-
Explicit commit signal
- Require an explicit "configuration finalized" signal before rotating files
- This would mean a change in protocol
Acceptance Criteria
Description
When sensor configurations are changed during an active recording session to the SD card, the system continues writing to the current file instead of creating a new one.
This leads to a single file containing data from multiple, potentially incompatible sensor configurations.
Expected Behavior
Current Behavior
Problem Scope
This behavior introduces ambiguity and makes post-processing difficult, as:
Additional Requirement: Handling Rapid Configuration Changes
The current implementation of the sensor configuration characteristic is in a way that multiple configuration updates are applied in quick succession, one for each sensor.
Undesired behavior:
Desired behavior:
Suggested Approaches
Possible strategies to handle this:
Debounce mechanism
Transactional configuration updates
Explicit commit signal
Acceptance Criteria