Functional (Capability) Requirements The following section outlines the core functional goals of the system, addressing what the system must do to be considered a success. These capabilities define the behavior visible to the user, irrespective of the internal scheduling or design constraints.

System-Level Functional Requirements

1. Image Capture at Real-Time Intervals The system must reliably capture exactly 1801 video frames: ● 1 Hz mode: 1 frame per second for 30 minutes ● 10 Hz mode: 10 frames per second for 3 minutes ● In both cases, the total number of frames is fixed (1801), and the spacing between each captured frame must be tightly controlled, with microsecond-level accuracy in timestamps.

2. Reference Clock Synchronization Frame captures must be synchronized with a physical external clock: ● Analog clock (e.g., wall clock) for 1 Hz mode ● Digital stopwatch for 10 Hz mode ● The software must use this reference to determine when a frame should be selected and saved from a stream of incoming camera data.

3. High-Resolution Image Dumping Captured frames are stored as PGM (grayscale) images with a resolution of 640×480 (as defined in the code: HRES and VRES constants). Each image file must include: ● An embedded timestamp of when it was acquired ● A header formatted according to the PGM specification ● Sequential file names (e.g., capture_0001.pgm, capture_0002.pgm, ...)

4. Precise Timestamp Logging Each frame saved must include accurate timestamps: ● Time of capture using CLOCK_MONOTONIC ● Time difference from the target frame time (error in milliseconds) ● Optionally logged to syslog or console for traceability This allows post-experiment validation of drift, jitter, and correctness.

5. Time-Stamped Video Data Correlation Frames should visually correlate to the external clock visible in the camera’s field of view. That is: ● The first frame (capture_0001.pgm) must show 00:00.0 ● The final frame (capture_1801.pgm) must show 30:00.0 (1 Hz mode) or 03:00.0 (10 Hz mode)

Software Behavior Requirements 6. Threaded Operation with Real-Time Services Two concurrent real-time services (threads) must be implemented: ● Service 1 (S1): Captures and timestamps video frames at high frequency ● Service 2 (S2): Evaluates timing accuracy and selects the best frame to save ● Service 3 (S3): Add the already selected frame to queue and signal file saver thread ● Service 4 (S4): Applies optional brightness adjustment, watermark, and tint; writes frame to disk; optionally displays SDL preview. ● Service 5 (S5): Generates CPU load for detailed testing under interference. ● Both services must be pinned to the same CPU core and operate under SCHED_FIFO.

7. Dynamic Frame Evaluation and Selection At 10 Hz, multiple frames will be captured around each target tick. The system must: ● Evaluate each captured frame’s timestamp ● Identify the frame with the minimum error from the reference time ● Buffer all frames in a circular queue (60-frame ring buffer in 10 Hz mode)

8. Buffered Frame Saving The selected “best” frame from the ring buffer is stored in a separate array (saved_frames) for deferred saving. During the 3/30-minute session, a dedicated file-saving thread writes all 1801 frames to disk in order.

9. Graceful Termination & Frame Count Enforcement The system must automatically stop after exactly 1801 saved frames, ensuring: ● No memory leaks or dangling threads ● Proper shutdown of camera device and threads ● Logging confirmation ("Completed 1801 frames")

10. Frame Transformation (optional) The code includes the ability to toggle between: ● Direct grayscale (PGM) ● Color (YUYV to RGB, PPM format) ● This must be glitch-free, toggling the transformation should not affect timing or cause dropped frames.