Author: kaichung

1. What did you personally accomplish this week on the project?

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.

2. Is your progress on schedule or behind?

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.

3. What deliverables do you hope to complete next week?

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.

1. What did you personally accomplish this week on the project?

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.

2. Is your progress on schedule or behind?

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.

3. What deliverables do you hope to complete next week?

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.

1. What did you personally accomplish this week on the project?
This week I focused on establishing the foundation of our software framework for FlashRescue. I set up the FTDI FT2232H development environment and successfully interfaced with it using the PyFTDI library. I wrote and tested Python scripts to enumerate connected devices and toggle GPIO pins, which confirmed that we can reliably communicate with the FTDI and use it for precise control of the hardware.

I also drafted the structure of the recovery workflow, mapping out modules for raw sector capture, error correction, and file reconstruction. To better understand feasibility, I ran timing tests using a logic analyzer on GPIO toggling to measure responsiveness. The results showed that we can achieve sub-10 ms switching, which aligns with our project requirement for controlled USB power cycling. In addition, I researched open-source forensic imaging tools to identify potential approaches we could adapt for error correction and file carving.

2. Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?
I am on schedule. According to our Gantt chart, Weeks 3–4 are dedicated to schematic capture and initial software framework development, and my work on FTDI setup, GPIO control, and recovery module planning is aligned with that timeline. The main risk I see on the software side is the complexity of reverse engineering file systems, which could extend development time. To mitigate this, I’m taking an incremental approach by starting with raw sector capture and simple recovery methods before layering in more advanced error correction and reconstruction.

3. What deliverables do you hope to complete in the next week?
Looking ahead to next week, I plan to:

• Expand the FTDI test scripts into a modular Python framework capable of both GPIO control and streaming raw USB data.

• Implement the first draft of a sector-level data logger to store raw captures for offline analysis.

• Write a stub for the error correction module so we have placeholders ready for integration.

• Begin designing a simple command-line interface (CLI) that will allow interaction with recovery functions.