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.