Carnegie Mellon ECE Capstone, Fall 2025 : Mars Kapadia, Apollo Lu
This week I focused on the final report for the project. I worked on fixing the previous formatting issues of our report. I also worked to find and organize the sources for our report.
We are on schedule. Mars is working on integrating our project before our final demo next week.
Demo and Final report
This week I focused on strengthening the software-side documentation, refining our recovery test cases, and reviewing the feedback we received during the interim demo. Several TAs mentioned that parts of our technical explanation were not intuitive to people who haven’t been following our project closely. I spent time reorganizing our software documentation to make the recovery flow clearer in preparation for our final presentation.
I am on schedule based on our current project phase. Since we are waiting for hardware to arrive, my tasks this week focused on documentation.
Incorporate additional adjustments based on interim demo feedback to improve clarity for non-technical audiences.
Update and polish the recovery pipeline diagrams for the final presentation.
Continue strengthening the software implementation documentation for the final report.
Prepare the outline and visuals for the final presentation.
This project required me to deepen my understanding of file systems and data recovery, especially regarding how corruption manifests at different layers:
File system metadata structures (FAT32)
I learned how directory entries, allocation tables, and cluster chains behave when partially overwritten or fragmented, and how this affects both carving and reconstruction.
Behavior of corrupted storage devices:
I studied how failed drives often present inconsistent enumeration behavior, sector read instability, and partially valid metadata, making recovery nontrivial.
Entropy-based recovery insights:
I researched how entropy can help distinguish meaningful remnants (text blocks, image signatures) from fully overwritten or empty regions.
This deeper understanding is now directly shaping how we structure our recovery test cases and how we explain our approach in the report.
To acquire this knowledge efficiently, I used:
Technical blogs and digital forensics articles explaining real-world corruption patterns
YouTube tutorials on filesystem internals and data carving techniques
This week I focused on preparing the materials we need for the final stages of the project. I dedicated time to adding more software implementation documentation for the final report, including clearer explanations of the recovery pipeline, corruption cases, and the expected flow once hardware testing begins.
In parallel, I began researching entropy analysis techniques for full-format recovery. This included looking into how entropy patterns can differentiate meaningful residual data from overwritten sectors which is an approach that may strengthen our ability to identify recoverable regions even when file system metadata is missing.
2. Is your progress on schedule or behind?
I am on schedule for this phase. Since we are waiting on the new boards to arrive, my primary responsibilities center on validation planning, recovery research, and preparing software documentation.
Review any initial findings from Mars’s virtual PCB tests and adjust software validation requirements as needed.
Continue researching entropy-based classification methods to determine if low-entropy filtering can be incorporated into the recovery workflow.
Expand and refine software implementation documentation so it’s ready for integration with real hardware results once validation begins.
This week I focused on research and documentation for the test cases we’ll use in our demo. I made sure our demo can clearly and convincingly show what our system can do with different types of corruption by surveying common USB failure modes and data-loss scenarios (e.g., partial corruption, boot sector corruption) and organized them into a structured set of demo-oriented test cases. For each case, I documented the expected drive behavior, what our imaging and recovery pipeline should demonstrate, and what metrics (recovery success, error logs, time to recover) we want to highlight during the demo.
I also started folding this work into our project documentation and final report draft, outlining a “Testing & Demo Scenarios” section that explains how our test cases map to real-world user problems. In parallel, I aligned the existing simulated test scripts with these documented scenarios so they can be reused as soon as Mars finishes initial board bring-up.
I am on schedule for the documentation and test-case preparation work. While Mars has been focused on the new software architecture and PCB delivery, I’ve used this time to ensure that our demo scenarios are well thought out and that we have a clear mapping between real-world failure modes and what we’ll show in the demo. Once the boards arrive and Mars completes initial bring-up, I’ll adapt these documented test cases to the actual hardware results and help integrate them into our final evaluation and report.
3. What deliverables do you hope to complete in the next week?
Review the interim demo results and identify any issues or improvements needed for the hardware–software workflow.
Compile a list of changes or fixes required before final integration and validation.
Begin refining and restructuring the final report, especially the testing methodology and demo results sections.
Integrate the documented test cases into the final report draft.
This week marked a major milestone for our software development. Mars successfully completed the imaging code and demonstrated full data recovery from test drives, validating that our end-to-end recovery pipeline is now functional. My primary focus was supporting this milestone through software integration, documentation, and testing infrastructure development.
I reviewed the updated imaging and data recovery code structure and began drafting the technical documentation, in preparation for our final report. This will ensure smooth onboarding for future updates and clear traceability during integration.
In parallel, I began working on expanding our software test suite expanding on the various file systems that we are able to recover. This allows us to continue validating and improving recovery reliability while hardware fabrication is in progress.
I am currently on schedule, largely due to the successful imaging code milestone that puts software development ahead of the original plan. Although hardware fabrication was delayed by about five days due to the USB connector replacement, this has given us extra time to finalize documentation and expand the test suite.
To ensure we stay ahead, I am coordinating closely with Mars to synchronize software modules and interface definitions so that integration will be seamless once the new boards arrive on November 19th. By completing all software-side preparation early, we can begin full system testing immediately when the hardware becomes available.
Next week, I plan to:
Finalize and review the complete software documentation for the imaging and recovery modules, including API specifications and developer notes.
Expand the automated test suite
Develop the initial user interface prototype (CLI) to display recovery progress and log summaries.
This week, I continued advancing the software recovery framework and addressing the development delays identified during our team review. Building on last week’s work, I expanded the byte-by-byte recovery script to communicate directly with an actual USB drive rather than local files. During this testing phase, we encountered access problems when interfacing with the Windows operating system’s USB layer. Windows automatically attempted to mount and manage the USB device, which blocked our low-level read operations and restricted access to raw data sectors.
To address this, I began experimenting with PyUSB, which provides more direct control over USB endpoints and allows communication at a lower level without relying on the operating system’s mass storage drivers. Early tests showed that PyUSB can successfully open the device and issue control transfers, though additional handling is required to manage device permissions and stability under Windows. This testing confirmed the feasibility of our software-based recovery approach while revealing key challenges we’ll need to solve for reliable data capture.
In parallel, I integrated the updated GPIO mappings and timing parameters from Mars’s hardware interface specification into the software control layer, ensuring synchronization with the redesigned PCB. I also implemented initial error detection features to flag incomplete reads and permission faults, setting the foundation for the raw sector imaging mode that will be finalized during the hardware fabrication period.
I am currently behind schedule, as core recovery algorithms and data capture functionality still require further development. The USB communication layer is operational but needs additional debugging to handle OS-level access restrictions and stability concerns. To catch up, I am focusing exclusively on the core recovery functionality and will use the one-week hardware delay caused by the redriver redesign to accelerate development. Mars will also assist with software work during the fabrication period so we can recover schedule alignment before the new boards arrive in mid-November.
Next week, I plan to:
Implement the raw sector imaging mode for complete drive-level data capture through the USB interface.
Continue refining PyUSB communication routines to ensure reliable and permission-safe access under Windows.
Add integrity verification tools such as checksum validation and recovery logging.
Develop test datasets across multiple file types to evaluate recovery accuracy and throughput.
This week, I focused on developing and testing the data recovery pipeline. Building on the sustained logging framework from last week, I implemented a basic byte-by-byte recovery test case using a JPEG file as the sample dataset. The goal was to verify that the current FTDI streaming implementation could reliably capture and reconstruct continuous data without loss or misalignment.
I wrote a Python test script that reads sequential bytes through HdX py and compares the captured output against the original JPEG to measure data integrity. The initial tests successfully confirmed that our logging layer preserves file structure, validating the correctness of the read path and file I/O routines. This test also provided early insight into throughput behavior under sustained transfers, which will inform further optimization once the custom PCB is available.
In addition to the recovery testing, I refined the recovery module interfaces and continued organizing the code into clear functional layers. I also reviewed the finalized PCB design submission with Mars to ensure that FTDI signal mappings align with the expected software control scheme.
I’m on schedule. The byte-by-byte recovery test case demonstrated that the software framework is functionally ready for integration, and the next steps will focus on expanding testing to larger files and longer transfer durations. The codebase structure is stable and ready to interface with the hardware when it arrives from fabrication.
Next week, I plan to:
Extend the recovery tests to handle multi-file capture scenarios and confirm data consistency across sessions.
Add configurable parameters to the recovery module for adjustable read block sizes and timeout thresholds.
Begin implementing visualization tools to inspect captured binary data and verify correct file signatures during recovery testing.
Part C Written by Apollo
Environmental Factors Consideration
Our FlashRescue project contributes positively to environmental sustainability by reducing electronic waste and promoting the reuse of existing storage devices. By enabling users to recover data from failed USB drives, the system helps prevent unnecessary disposal of hardware and limits the release of toxic materials such as lead and rare metals into the environment. The device’s low power consumption further minimizes energy usage during operation. For our project itself we plan to use sustainably sourced and recyclable materials for the PCB and enclosure, ensuring that both the product’s function and its physical construction align with environmentally responsible design practices.
The primary risks have shifted toward integration and timing verification as the project moves from design to early implementation. On the hardware side, PCB fabrication is now underway. The major risk is ensuring the MOSFET-based VBUS power-cycling circuit meets the < 10 ms rise/fall and ≤ 5 % overshoot specification once boards arrive. To mitigate this, Mars has scheduled oscilloscope validation immediately after bring-up and has kept a secondary vendor on standby in case of fabrication defects.
For software, the key challenge is synchronizing FTDI GPIO control with sustained data capture without exceeding the 20 µs jitter budget. We are addressing this by building a modular Python test suite that logs timing metrics separately from recovery logic, allowing us to debug latency before full system integration.
File-system reverse-engineering remains a longer-term risk, but work continues on a simplified recovery path that performs raw sector imaging first, followed by optional error-correction passes.
No architectural changes were introduced this week. Minor schematic tweaks were made before sending the board out for fabrication — primarily tightening trace routing on the differential USB pairs and relocating decoupling capacitors for better impedance control.
Software structure remains the same (control / capture / reconstruction), but module boundaries have been clarified in the documentation to improve parallel development between hardware and software.
We remain on schedule with the Gantt chart milestones:
Week 5–6 (current): PCB fabrication + software modularization and sustained logging tests.
Week 7–8: Board assembly and FTDI GPIO verification.
Week 9–10: System integration and initial data recovery trials.
Fabrication lead-time estimates confirm that boards will arrive in roughly two weeks, aligning with our planned integration window.
This week’s focus was on transitioning from design to execution.
Hardware: Finalized and submitted PCB Gerber files for fabrication; reviewed component order confirmations and arranged assembly logistics.
Software: Expanded the FTDI framework beyond initial tests to support continuous byte logging and modular control. Initial throughput measurements will begin once sample data is available.
Documentation: Updated design documentation to reflect final board stack-up, test metrics, and risk mitigation strategies.
Overall, the project has successfully moved from planning into early implementation, with both tracks maintaining momentum.
This week I shifted from design preparation to implementation work. I refined the FTDI FT2232H software environment and began modularizing my earlier test scripts into distinct components for control and data logging. I improved the raw-byte capture script to handle sustained reads and verified that data can be streamed and saved reliably over longer durations.
I also documented the interfaces between modules — control (GPIO and power-cycling), capture, and reconstruction — so integration with the upcoming PCB firmware will be straightforward. Throughout the week I coordinated with Mars to align timing expectations between the hardware’s MOSFET switching and the FTDI control layer.
I’m on schedule. With the design review complete, this week’s goals focused on establishing a working modular framework and preparing for hardware arrival. The FTDI environment and sustained logging scripts meet those objectives. No major blockers at this stage.
Next week, I plan to:
Add configurable parameters to the logging tool (capture duration, file naming, and data-rate display).
Begin implementing a simple command-line interface (CLI) to unify control and logging operations.
Develop a test harness that measures FTDI GPIO latency so we can compare it against our < 20 µs target when hardware arrives.
1. What did you personally accomplish this week on the project?
This week I focused mainly on preparing our design presentation, which took up the bulk of my time. On the software side, I set up the FTDI FT2232H development environment and confirmed that I could communicate with the device through the PyFTDI library. I wrote a small script to read raw bytes and log them into binary files, which serves as the starting point for our sector capture module. In addition, I began drafting the recovery workflow at a high level, breaking it into modules for raw capture, error correction, and reconstruction so the codebase will be easier to expand as hardware testing begins.
2. Is your progress on schedule or behind?
I am on schedule. The design presentation was expected to be the main focus this week, and I was still able to make progress on FTDI setup and recovery planning. This keeps me aligned with our Gantt chart milestones.
3. What deliverables do you hope to complete in the next week?
Next week, I plan to:
Improve the byte logging script to handle longer sustained captures.
Refine the recovery workflow modules with placeholders for error correction and reconstruction.
Draft the initial structure for a command-line interface (CLI) so testing can be done in a structured way moving forward.