Posted on

Team Status Report for October 11th

1. Most significant risks and management strategies

The primary risks continue to center on hardware-software integration timing and PCB performance validation as we transition into the manufacturing phase. With PCB fabrication now submitted and awaiting delivery (expected November 7th), our most critical hardware risk is verifying that the MOSFET-based VBUS power-cycling circuit meets the <10ms rise time and ≤5% overshoot specifications under real-world conditions with actual failed USB drives. To mitigate this, Mars has prepared a comprehensive bring-up test plan with oscilloscope validation procedures and has identified adjustable parameters (gate resistor values, bulk capacitance) that can be modified if initial measurements fall outside tolerance. We’ve also maintained relationships with multiple PCB vendors as backup options if fabrication defects are discovered.

On the software side, Apollo faces the challenge of maintaining <5ms FTDI command response latency while simultaneously performing GPIO-controlled power cycling and sustained USB data capture. The risk is that Python’s threading model may introduce unacceptable jitter that degrades recovery success rates. We’re addressing this through incremental development of the PyFTDI control layer with built-in timing instrumentation, allowing us to identify latency bottlenecks before full system integration. Apollo has also researched C extension options for performance-critical sections if Python proves insufficient.

Component lead times present a moderate risk, with the TUSB1064 USB redriver and IRLZ44N MOSFETs on 2-3 week delivery schedules. If these components arrive late, board bring-up will be delayed. We’re mitigating this by proceeding with FTDI interface testing using the development module while awaiting the complete custom PCB, ensuring software development continues in parallel.

File system reconstruction and error correction implementation remain longer-term technical risks. The diversity of USB drive controllers (Phison, SMI, Alcor) with varying ECC schemes means we may encounter unexpected data formats during testing. Our contingency is to implement a robust raw sector imaging capability first, allowing data capture even if file system reconstruction proves more complex than anticipated.

2. Changes to system design

No fundamental architectural changes were made this week. The three-subsystem architecture (Host Computer, Interface Hardware, Target Drive) remains unchanged, as does the layered software design (Protocol Control, Enumeration Management, Data Cloning, File System Reconstruction).

Minor refinements were made to the PCB design before fabrication submission. Mars adjusted the USB differential pair routing to maintain tighter impedance control (targeting 90Ω ±8% rather than the ±10% specification allows margin for manufacturing variation). Decoupling capacitor placement was optimized to reduce high-frequency noise on the FTDI power rails. The VBUS power cycling circuit received additional bulk capacitance (100µF total rather than the initially planned 47µF) to reduce inrush current stress on the MOSFET.

On the software side, Apollo clarified module boundaries and interfaces between the enumeration management layer and the data cloning engine. The recovery parameter database structure was refined to support vendor-specific timing configurations more efficiently. These are documentation and organization improvements rather than functional changes.

3. Schedule update

We remain on schedule with our 12-week project timeline, currently in Week 6:

  • Weeks 5-6 (current): PCB fabrication in progress, long-lead component orders placed, software framework development underway
  • Weeks 7-8 (upcoming): Expected PCB delivery November 7th, board assembly and bring-up testing, FTDI GPIO control validation
  • Weeks 9-10: System integration, initial recovery testing with controlled failure scenarios, throughput optimization
  • Week 11: Cross-vendor compatibility validation, performance testing, recovery success rate measurements
  • Week 12: Final demonstration preparation, documentation completion, poster and demo video creation

PCB fabrication lead time remains on track for the November 7th delivery target. Component deliveries are scheduled for late October/early November, providing adequate time for assembly before Week 7 begins. Software development can proceed independently using the FTDI development module, ensuring no schedule slip due to hardware lead times.

The critical path items (PCB fabrication → assembly → integration testing) have appropriate buffer time built into Weeks 10-11 to absorb unexpected technical challenges.

4. Progress summary and photos

This week marked a successful transition from detailed design into the manufacturing and implementation phase, with both hardware and software tracks maintaining momentum.

Hardware Progress: Mars completed and submitted the final PCB design package including Gerbers for all six layers, NC drill files, and pick-and-place files for assembly. All component orders were confirmed, with standard parts arriving within one week and long-lead items (TUSB1064, IRLZ44N) scheduled for 2-3 week delivery. The assembly procedure documentation was completed, providing step-by-step instructions for through-hole component installation that Mars will perform after receiving the assembled SMD components. The testing and bring-up plan now includes specific procedures for time-domain reflectometry measurements of USB impedance, oscilloscope characterization of VBUS power cycling waveforms, and USB protocol analyzer validation of enumeration sequences.

Software Progress: Apollo expanded the PyFTDI control framework beyond initial proof-of-concept testing to support continuous data streaming with real-time GPIO control. The modular architecture now cleanly separates protocol handling, power control, and data capture functions, enabling parallel development and independent testing of each subsystem. Initial timing measurements confirm that PyFTDI command latency remains well under the 5ms requirement for simple GPIO operations, though more complex enumeration sequences require further optimization. The recovery parameter database schema was implemented, providing a framework for storing and retrieving vendor-specific timing configurations learned from successful recovery attempts.

Integration and Documentation: Both team members updated design documentation to reflect the final PCB stackup specifications, component selections, and test procedures. The hardware-software interface specification was refined to clearly define GPIO pin assignments, timing requirements for VBUS control signals, and status feedback mechanisms. Risk mitigation strategies were documented for each identified technical challenge.

Overall, the project has successfully transitioned from the design and planning phase into active implementation. Both hardware fabrication and software development are proceeding according to schedule, with no blocking issues identified. The team is well-positioned to begin integration testing when the PCB arrives in early November.

Posted on

Mars’s Status Reports for October 11

What did you personally accomplish this week on the project?

This week I successfully submitted our PCB fabrication order to the manufacturing house after resolving the procurement setup issues from last week. I confirmed the production timeline – we’re looking at a 10-business-day turnaround for fabrication plus 3 days for assembly, putting our expected delivery around November 7th.

I completed the component procurement process, ordering all remaining parts from our approved vendors. The majority of components are stocked and will arrive within 5-7 business days. However, I identified two long-lead-time components: the IRLZ44N MOSFET switching transistors (3-week lead time) and the TUSB1064 USB redriver IC (2-week lead time). I expedited shipping on both to compress delivery to approximately 2 weeks, which still keeps us on schedule for our first prototype assembly.

I developed a comprehensive assembly procedure document that details the manual assembly process for the through-hole components including USB Type-A connectors and test points. The document includes step-by-step instructions with reference images, soldering temperature specifications for different component types, and quality checkpoints to verify proper connections before powering up the board.

I drafted the initial testing and bring-up plan, which outlines a systematic approach to first-power scenarios. The plan starts with visual inspection and continuity testing of critical nets (VBUS, GND, USB differential pairs), progresses through low-power functional verification of the FTDI interface, and culminates in full VBUS power cycling tests with actual failed USB drives. I’ve identified the test equipment we’ll need and confirmed availability of oscilloscopes, vector network analyzers for impedance measurements, and USB protocol analyzers in our lab space.

Finally, I met with Apollo to review the hardware-software interface requirements and confirmed that our GPIO assignments for VBUS power control align with the PyFTDI software architecture. We identified the specific timing requirements for power cycling sequences and the status feedback signals needed for recovery progress monitoring.

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

My progress is on schedule. All planned deliverables were completed this week. The component lead times are within acceptable ranges and won’t impact our critical path since software development can proceed in parallel. I’ve built in buffer time for any unexpected delays during board bring-up.

What deliverables do you hope to complete in the next week?

Next week I plan to:

  • Finalize the testing and bring-up plan with detailed test procedures for USB signal integrity verification and power cycling characterization
  • Receive and inventory the standard lead-time components (bulk capacitors, resistors, ferrite beads) to verify quantities and part numbers against the BOM
  • Prepare the lab workspace with all necessary test equipment including oscilloscope, multimeter, and USB protocol analyzer
  • Create a hardware interface specification document detailing GPIO pin assignments, VBUS switching timing requirements, and USB enumeration signal monitoring points
  • Develop a risk mitigation strategy for the board bring-up phase, including backup plans if initial impedance measurements fall outside tolerance or VBUS rise times exceed specifications
  • Begin preliminary discussions with Apollo on the PyFTDI integration to ensure smooth hardware-software handoff when boards arrive

Part A written by: Mars
Part B written by: Mars

Part A: Global Factors Consideration

Our FlashRescue USB data recovery solution addresses a critical global need that transcends geographic and economic boundaries – the need to recover irreplaceable personal data from failed USB drives. While data recovery services exist, they’re concentrated in developed markets and priced at $300-$1500 per recovery, making them economically inaccessible to the majority of the world’s population. This pricing structure effectively means that users in developing economies face permanent data loss when drives fail, even though the technical barriers to recovery aren’t insurmountable.

The hardware design I’ve developed explicitly considers global accessibility through several key decisions. The power management circuitry accommodates USB power delivery from various host sources worldwide, handling the voltage variations and noise characteristics present in different regions’ USB implementations. More fundamentally, the use of widely-available commodity components (FTDI FT2232H, standard MOSFETs, common USB redrivers) rather than specialized recovery hardware means the design can be replicated anywhere these components are available – which includes most countries with electronics distribution networks.

The impedance-controlled 6-layer PCB design, while adding cost, serves a global accessibility purpose beyond just signal integrity. Failed USB drives often exhibit degraded electrical characteristics – weak signals, timing violations, or marginal compliance with USB specifications. By implementing robust signal conditioning with the TUSB1064 redriver and maintaining tight impedance control, the hardware can successfully interface with drives that wouldn’t work with simpler circuits. This is particularly important for users in regions where drives may have experienced harsher operating conditions – extreme temperatures, unstable power, physical stress – making electrical degradation more likely.

Perhaps most importantly, the open-source nature of both hardware and software enables global adaptation and improvement. Users with electronics skills anywhere in the world can build, modify, and improve the design. The comprehensive documentation and clear derivations I’ve provided in the hardware specifications allow technically-capable individuals to understand not just what the design does, but why each decision was made. This educational transparency supports a global community of practitioners who can adapt the design for local conditions, share improvements, and collectively advance data recovery accessibility. For users in regions without access to professional recovery services, this community-based approach may represent their only viable option for recovering critical data.

Part B: Cultural Factors Consideration

The FlashRescue design acknowledges that people’s relationships with their data vary significantly across cultural contexts, and these differences influence both what constitutes “important data” and how recovery should be approached. In some Western contexts, USB drives primarily store convenience copies of data that exists elsewhere – documents synced to cloud services, photos backed up automatically. However, in many global contexts, USB drives serve as primary or sole storage for irreplaceable content: family photos with no other copies, small business financial records, academic work, or personal documents that cannot be entrusted to cloud services.

Cultural attitudes toward data privacy and ownership significantly influence the recovery solution’s design requirements. The hardware architecture I’ve implemented maintains complete user control throughout the recovery process, with no cloud dependencies, no required internet connectivity, and no data transmission to external services. This design choice respects cultural and individual values around data privacy – whether driven by professional confidentiality requirements, concerns about government surveillance, religious or cultural sensitivities around image capture and storage, or simply personal preference for data sovereignty. Users maintain physical possession of their drive throughout recovery, and the open-source nature of the software means there are no hidden data collection mechanisms.

The technical accessibility design also reflects cultural considerations around technology adoption and self-sufficiency. Some cultures emphasize learning technical skills and performing repairs independently rather than relying on service providers. The modular hardware design with clearly-labeled through-hole components and the educational documentation support this value system by making the technology understandable and maintainable by technically-inclined users. The command-line interface, while perhaps less approachable than a graphical interface, provides transparency into the recovery process that respects users who want to understand exactly what operations are being performed on their data.

Additionally, the cost structure (<$200 for a reusable tool versus $300-$1500 per recovery) enables a community-based recovery model where technically capable individuals can help friends, family, or community members recover data. This aligns with cultural values in communities that emphasize mutual aid and collective problem-solving rather than purely commercial service relationships. The open documentation and adaptable design support this use case by making it feasible for community workshops, repair cafes, or informal technology support networks to offer recovery services.

Posted on

Mars’s Status report for October 4th

What did you personally accomplish this week on the project?

This week I successfully completed the PCB layout and routing in Altium, marking a major milestone in our hardware development. The layout process required careful consideration of signal integrity, power distribution, and thermal management. I positioned all components according to the placement strategy I outlined last week, with the power management section located near the input connector and the NMOS switching transistors arranged to minimize trace inductance.

The routing phase consumed significant time as I optimized trace widths for the high-current paths (using 100mil traces for the main power lines) while keeping signal traces appropriately sized. I implemented a solid ground plane on the bottom layer to provide a low-impedance return path and better thermal dissipation for the switching components.

I ran comprehensive Design Rule Checks (DRC) and addressed all violations. The initial DRC flagged 23 violations – primarily clearance issues around the dense power management IC area and a few trace width violations on high-current paths. After iterating on the layout, I resolved all critical errors and reduced the warnings to just 2 minor clearance notices that are within acceptable tolerances.

I generated the complete manufacturing file package including Gerbers (all copper layers, silkscreen, soldermask), NC drill files, and pick-and-place files for the assembly house. I also created a detailed assembly drawing that clearly marks which components will be machine-assembled versus hand-soldered.

The hybrid assembly plan is now finalized – the fab house will handle all SMD components (approximately 85 parts) while I’ll manually assemble the 12 through-hole connectors and mounting hardware. I’ve coordinated with our chosen fabrication house to confirm their capabilities and received confirmation that they can meet our timeline. I also placed orders for the through-hole components I’ll be assembling manually.

Finally, I prepared the fabrication submission package and reviewed it thoroughly with Apollo to ensure the board interfaces correctly with the software/firmware requirements.

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

My progress is on schedule. All planned deliverables for this week were completed, and the PCB design is ready for fabrication submission. The DRC resolution took slightly longer than anticipated, but I absorbed that time without impacting the overall schedule.

What deliverables do you hope to complete in the next week?

Next week I plan to:

  • Submit the PCB fabrication order and confirm the manufacturing timeline with the fab house, there was an issue getting things set in to buy.
  • Order all remaining components that haven’t been procured yet, particularly any long-lead-time items
  • Create a detailed assembly procedure document for the manual assembly tasks
  • Begin developing the testing and bring-up plan for when the boards arrive
  • Coordinate with the team on enclosure/mechanical integration to ensure the PCB mounting points align with our mechanical design
  • Start preliminary work on the firmware integration requirements to ensure a smooth bring-up process when hardware arrives
Posted on

Team Status Report October 4th

1. Most significant risks and management strategies

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.

2. Changes to system design

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.

3. Schedule update

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.

4. Progress summary

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.

Posted on

Apollo’s Status Report for October 4th

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.

Posted on

Apollo’s Status Report for Sep 27th

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.

Posted on

Team status report for September 26 2026

What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?

Our most significant risks continue to center around component availability and the complexity of file system reverse engineering. For hardware, we’ve successfully mitigated some supply chain risks by finalizing our component selections this week and confirming availability with multiple suppliers. We’ve also made the decision to use a hybrid PCB assembly approach to balance cost and reliability.

On the software side, the file system reverse engineering complexity remains our primary technical risk. We’re managing this by taking an incremental development approach, starting with raw sector capture and simple recovery methods before moving to advanced reconstruction algorithms. We’ve also identified several open-source forensic tools that we can adapt, reducing the need to build everything from scratch.

A new risk that has emerged is the integration complexity between our custom hardware and the FTDI-based software framework. Our contingency plan involves extensive early testing of the hardware-software interface to identify issues before full system integration.

Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

No major design changes were made this week. The core system requirements and specifications remain stable as we’ve moved from planning into implementation phases.

Minor refinements were made to the PCB layout approach based on component footprint verification and assembly cost analysis. These adjustments don’t affect the fundamental system architecture but optimize for manufacturability and cost-effectiveness. The decision to use hybrid assembly (fab house for fine-pitch components, manual for through-hole) represents a process optimization rather than a design change.

Provide an updated schedule if changes have occurred.

No schedule changes have occurred. Both hardware and software development tracks remain on schedule according to our Gantt chart. Hardware is progressing from component capture to PCB layout as planned, while software has successfully established the FTDI framework foundation and is moving toward modular development.

Progress photos and accomplishments:

This week marked significant progress in both hardware and software development. On the hardware front, we completed the component capture phase in Altium, finalized all major component selections including power management ICs and NMOS transistors, and began PCB layout work. The preliminary schematic is complete and we’ve obtained fabrication quotes that confirmed our hybrid assembly approach is both cost-effective and schedule-compatible.

On the software side, we established a solid foundation with the FTDI FT2232H development environment. Successful GPIO control tests demonstrated sub-10ms switching capability, which meets our USB power cycling requirements. The initial recovery workflow structure has been drafted with clear modules for raw sector capture, error correction, and file reconstruction.

Team coordination has been excellent, with regular check-ins ensuring that hardware interface requirements align with software framework development. We’re well-positioned to begin integration testing once the PCB fabrication is complete.

Special Questions for This Week

Part A was written by Mars Kapadia, Part B was written by Apollo, and Part C was written by Mars and Apollo.

Part A: Public Health, Safety, and Welfare Considerations

Our FlashRescue data recovery system directly supports public welfare by helping individuals and organizations recover critical data that may be essential for their well-being. From a safety perspective, our design prioritizes electrical safety through proper isolation and current limiting in the USB interface circuitry. The power cycling functionality is designed with fail-safes to prevent damage to connected devices or potential electrical hazards.

We’re implementing proper ESD protection and following industry standards for USB device safety to ensure our hardware doesn’t pose risks to users or their equipment. The software framework includes error handling and validation to prevent potentially harmful operations that could further damage corrupted storage devices.

Part B: Social Factors

Data recovery has significant social implications, particularly regarding privacy and digital equity. Our tool democratizes data recovery by providing an accessible, cost-effective alternative to expensive professional services. This is especially important for individuals and small organizations who cannot afford commercial data recovery solutions.

We’re designing the system with user privacy in mind – all recovery operations happen locally without data transmission to external servers. The open-source nature of our software framework will allow community contribution and transparency, ensuring the tool remains accessible and trustworthy. We’re also considering the educational value of our project in teaching data recovery concepts to other engineering students and practitioners.

Part C: Economic Factors

Our project addresses the economic burden of data loss, which costs individuals and businesses significant money in both recovery services and lost productivity. By providing an affordable, reusable solution, FlashRescue can save users hundreds or thousands of dollars compared to professional data recovery services.

The economic sustainability of our design is ensured through the use of readily available, cost-effective components and open-source software. Our hybrid assembly approach balances initial development costs with reliability, and the modular design allows for future cost optimization. We’re targeting a total component cost under $200, making the solution accessible to a broad user base while remaining economically viable for small-scale production or educational use.

Posted on

Mars’s Status Report for September 26 2025

What did you personally accomplish this week on the project?

This week I made significant progress on the PCB design process. I successfully completed the component capture phase in Altium, finalizing the selection of all major components including the NMOS transistors I identified last week and the power management ICs. I spent considerable time verifying that all component footprints in Altium match the actual available parts to avoid any manufacturing issues down the line.

I also obtained assembly quotes from three different PCB fabrication houses and made the decision to go with a hybrid assembly approach – having the fab house handle the fine-pitch surface mount components while I’ll manually assemble the through-hole components. This strikes a good balance between reliability and cost considerations.

The preliminary schematic design is now complete and I’ve begun the PCB layout phase. I’ve established the board outline based on our mechanical constraints and started placing the critical components like the power management section and the main switching transistors. The layout is progressing according to the hand-drawn sketch I developed last week, with some minor optimizations for better signal routing.

I also coordinated with Apollo this week to ensure the PCB design aligns with the software interface requirements and timing constraints we discussed during our brainstorming sessions.

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

My progress remains on schedule. The component selection and preliminary schematic phases were completed as planned, and I’m now transitioning into PCB layout on track with our project timeline.

What deliverables do you hope to complete in the next week?

Next week I plan to:

  • Complete the PCB layout and routing in Altium
  • Run design rule checks (DRC) and resolve any violations
  • Generate and review the manufacturing files (Gerbers, drill files, pick and place files)
  • Finalize the hybrid assembly plan and coordinate component ordering
  • Begin preparation for the PCB fabrication submission to meet our manufacturing timeline

The goal is to have the PCB design fully ready for fabrication by the end of next week so we can maintain our hardware development schedule.

Posted on

Apollo’s Status Report for Sep 20th

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.

Posted on

Team Status Report for September 20 2025

What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?

The most significant risks include component availability and lead times, especially for specialized hardware components needed for USB interfacing. We’re managing this by identifying suitable components early in the design phase and checking availability before finalizing selections. Our contingency plan involves having backup component options identified and maintaining relationships with multiple suppliers. Another risk is the complexity of reverse engineering file systems, but we’re mitigating this through early collaboration and research into existing tools and methodologies.

Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

No major changes have been made to the existing design at this point. We’re still in the early component selection and planning phase, so the core requirements and system specifications remain stable. Any minor adjustments have been related to component package sizes and footprint considerations during the PCB layout sketching phase.

Provide an updated schedule if changes have occurred.

No schedule changes have occurred. We remain on track with the component capture phase and preliminary design work.

Progress photos and accomplishments:

This week we made solid progress on both hardware and software fronts. On the hardware side, we’ve begun the component capture process in Altium, identified suitable NMOS transistors that meet our voltage and current requirements, and created preliminary hand-drawn PCB layout sketches. We’ve also started evaluating assembly options between hand assembly and professional PCB assembly services. On the software side, we discussed with Apollo the type of software needed for reverse engineering file systems and explored the hardware requirements necessary to interface with USB systems. The team collaboration has been productive in establishing the technical foundation for both aspects of the project. Nothing to put in ‘photos’ yet, but next week that could change 🙂