Posted on

Mars’s Status Report for November 15

What did you personally accomplish this week on the project?

This week I coordinated with our PCB vendor to finalize manufacturing details for the power cycling board. We discussed component placement optimization, particularly for the high-current switching circuits that control USB power delivery. We reviewed via-in-pad routing for thermal management on the power MOSFETs and determined which components need to be hand-soldered versus machine-placed during assembly. Specifically, the USB connectors and any through-hole power components will require hand soldering to ensure mechanical stability during repeated plug/unplug cycles. Got confirmation on the assembly timeline and documented which parts we’re providing versus what they’ll source.

I also mapped out the verification test plan for when the boards arrive. For the power cycling subsystem, I’ll be validating:

  • Power cycle oscilloscope validation
  • Clean voltage transitions
  • Current delivery capability (must supply 500mA continuous per USB 2.0 spec)
  • Cycle endurance (board must reliably complete 1000+ cycles without degradation)

Is your progress on schedule or behind?

Behind our original schedule due to PCB delays.. The PCB vendor discussion was a critical milestone to ensure we get functional boards on the first revision. Having the assembly details locked down now prevents delays later when boards arrive.

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

I want to write test code to virtually test revision 1 of our PCB’s. I also will work on making a visual demonstration for part of our final demo.

Posted on

Team’s Status Report for November 8

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 risk heading into this week was PCB delivery timing for our demo. We successfully managed this risk by maintaining close communication with the manufacturer throughout the assembly process following our USB connector redesign. The boards are scheduled to arrive tomorrow morning, giving us a critical window for validation before the demo.

Hardware validation risk remains our primary concern. We need to verify that the high temperature USB connectors were correctly installed during assembly and that they perform as expected for USB enumeration and data transfer. We have comprehensive validation procedures prepared, including power supply verification, USB signal integrity checks, and basic read functionality testing. Our contingency plan includes having detailed software demonstrations ready even if we encounter unexpected hardware issues during bring up.

Software architecture risk was addressed this week through a complete redesign. The previous PyFTDI based implementation had fundamental limitations in low level control and timing precision. The new architecture provides much more direct control over USB communication and better integrates with our power cycling hardware. This was a significant undertaking but positions us much better for reliable operation. The new implementation has been thoroughly tested and is working end to end.

Integration risk is elevated given that we’re now working with a single team member handling both hardware and software responsibilities. This has streamlined decision making but increased workload. We’re managing this by focusing on critical path items and preparing comprehensive backup materials for the demo.

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?

We made a major software architecture change this week. The entire PyFTDI based implementation was scrapped and rebuilt from the ground up. This change was necessary because the PyFTDI approach had fundamental limitations in low level USB control and timing precision that would have caused issues as we scaled up functionality. The old architecture couldn’t provide the fine grained control we need for reliable power cycling coordination and USB communication recovery.

The new architecture gives us direct control over the USB communication layer and integrates much better with our hardware power cycling control. This required essentially rewriting the core imaging and recovery code, representing a substantial engineering investment of approximately 15 to 20 hours this week. However, the new implementation provides improved error handling, more predictable behavior, and better performance characteristics.

We’re mitigating the time cost of this redesign by leveraging the improved architecture’s capabilities to accelerate future development. The cleaner design will make adding features and debugging issues significantly faster. Testing has confirmed the new implementation works end to end with better reliability than the previous approach.

No hardware design changes occurred this week. The boards currently in production incorporate the high temperature USB connector changes from our previous revision.

Provide an updated schedule if changes have occurred.

Schedule remains consistent with our previous update, with boards arriving tomorrow morning (November 16th) and demo occurring shortly after:

Week 7 (current): PCB delivery November 16th morning, immediate board bring up and validation. Software architecture redesign completed and tested. Demo preparation and execution.

Weeks 8 through 9: Full board characterization including signal integrity measurements and power cycling timing verification. Testing with wider variety of USB drives across different manufacturers. Hardware issue documentation and rev2 improvement planning.

Weeks 10 through 11: System optimization, cross vendor drive compatibility validation, performance measurements, success rate analysis across different drive failure types.

Week 12: Final demonstration preparation, comprehensive documentation, demo video production, poster completion, final report drafting.

The critical path runs through successful demo execution and subsequent hardware validation. Software architecture is now solid and ready for integration with physical hardware.

Progress summary and demonstrations

Hardware Progress: Boards are scheduled for delivery tomorrow morning after successful completion of assembly with the high temperature USB connectors. All test equipment and verification procedures are prepared for immediate bring up upon arrival. Component inventory is complete with 100% BOM match for any potential repairs or modifications needed.

Software Progress: Major architectural overhaul completed this week. The entire PyFTDI based implementation was replaced with a new architecture providing much more direct control over USB communication and better integration with power cycling hardware. The new implementation has been thoroughly tested and demonstrates end to end functionality with improved error handling and more predictable behavior. Demo script has been prepared showcasing key functionality.

Integration: Currently operating with a single team member handling both hardware and software responsibilities; Hopefully the other team member is doing documentation, he has an update for this Friday to see his progress. This has required careful prioritization but has streamlined decision making processes. All preparation work is complete for rapid hardware validation tomorrow morning and demo execution. Comprehensive backup plans are in place in case of unexpected hardware issues.

Posted on

Mars’s Status Report for November 8th

What did you personally accomplish this week on the project?

This week I focused on final preparation for our demo and handled a critical board delivery situation. I’ve been working solo on both the hardware and software sides of the project now, which has required careful prioritization of tasks.

The major accomplishment this week was coordinating the first round of PCB delivery, which I’m scheduled to receive tomorrow morning, just in time for our demo. After the connector temperature rating issue we encountered previously, I maintained close communication with the manufacturer throughout the assembly process to ensure the high-temperature USB connectors were correctly installed and that the boards passed all their quality checks before shipment.

On the software side, I made a significant architectural decision: I completely scrapped the PyFTDI based approach and redesigned the entire software architecture from the ground up. The PyFTDI implementation had fundamental limitations in terms of low level control and timing precision that were going to cause issues as we scaled up functionality. The new architecture gives us much more direct control over the USB communication layer and better integrates with our power cycling hardware control. This was a substantial refactor, essentially rewriting the core imaging and recovery code, but it puts us in a much better position for robust, reliable data recovery operations. I’ve tested the new implementation thoroughly and it’s now working end to end with improved error handling and more predictable behavior.

Since I’m now handling both hardware and software responsibilities independently, I’ve had to be strategic about time management. I set up all the test equipment and verification procedures for tomorrow’s board bring up, organized the components and tools I’ll need for quick debugging, and prepared backup plans in case we encounter any issues during the demo. I also created a streamlined demo script that walks through the key functionality in a clear, time efficient manner.

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

I’m currently on schedule for the demo, though working solo has required some adjustments to my workflow. The software architecture redesign took significant time this week, but it was necessary to ensure we have a solid foundation moving forward. The PCB delivery timing worked out favorably. Receiving the boards tomorrow morning gives me a few hours to verify basic functionality before the demo, which should be sufficient given the thorough testing I’ve already done with the new software architecture.

The transition to working independently on all aspects of the project has actually streamlined some decision making processes, though it’s increased the workload considerably. I’ve maintained momentum by focusing on the most critical path items first: ensuring the boards arrive on time, having robust software that can demonstrate our core functionality even if we encounter minor hardware issues, and preparing comprehensive backup materials.

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

Next week my priorities are to receive and perform initial validation on the first PCB revision tomorrow morning, including power supply verification, USB enumeration testing, and basic read functionality with the new software architecture. I want to successfully demonstrate the data recovery system at our demo, showcasing both the hardware and software components working together.

After the demo, I plan to complete full characterization of the assembled boards, including signal integrity measurements on the USB lines and timing verification of the power cycling circuit. I’ll begin testing with a wider variety of USB drives to validate our recovery approach across different manufacturers and controller types. I need to document any hardware issues discovered during bring up and create a running list of potential rev2 improvements.

I also want to finalize the complete software documentation for the new architecture so the codebase is ready for evaluation. If time permits, I’ll start working on the final presentation materials and begin drafting sections of the final report.

I also press the vendor to get our REV 2 of the boards here on time.

Posted on

Apollo’s status report for Nov 1st

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

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.

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 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.

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

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.

Posted on

Team’s Status Report for November 1

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 risk this week emerged from the PCB manufacturing process: the USB connector specified in our design is not rated for the reflow soldering temperatures required during board assembly. The connector has a maximum temperature rating of 260°C, but our lead-free reflow profile peaks at 245-250°C, creating an unacceptable safety margin that risks damaging the connector’s plastic housing during assembly. We managed this by identifying a pin-compatible high-temperature replacement connector (rated to 280°C), updating the PCB design with minimal footprint adjustments, and resubmitting to the manufacturer with fast-tracked review to minimize additional delays.

However, we have positive news that significantly reduces our integration risk: Mars successfully got the imaging code working this week and demonstrated seamless data recovery from test drives. The complete data recovery pipeline is now functional end-to-end, including error correction and data block reconstruction. This major breakthrough means software development is actually ahead of our internal milestones, eliminating the previous risk of software delays impacting integration.

Hardware integration risk remains centered on verifying VBUS power-cycling performance and USB signal integrity with the new connector. Mars has prepared comprehensive validation procedures including impedance verification for the USB differential pairs with the replacement connector. Our contingency plan includes tunable parameters in the power cycling circuit if adjustments are needed during bring-up.

Component availability risk is well-managed. Standard parts have been inventoried with 100% BOM match. The high-temperature USB connector and remaining long-lead components (MOSFETs and replacement redriver) align with our revised November 19th PCB delivery schedule.

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?

We made one critical hardware change this week: replacing the USB connector with a high-temperature rated alternative. This change was necessary because the original connector’s temperature rating (260°C max) was incompatible with our lead-free reflow soldering process (245-250°C peak), which the PCB manufacturer identified during their design review before fabrication began. Using the original connector would risk plastic housing damage during assembly, potentially causing mechanical failure or compromised electrical connections.

The replacement connector is pin-compatible and maintains the same impedance specifications for USB differential pairs, requiring only minimal PCB footprint adjustments. Costs include an additional 5-day schedule delay (PCB delivery now November 19th instead of November 14th), revised fabrication charges, and approximately 6 hours of engineering time for redesign and verification.

We’re mitigating these costs through several approaches: the manufacturer fast-tracked our revised design through their review process to minimize additional delays; since the imaging and data recovery software is now fully functional, we’re expanding our software test suite using simulated hardware responses to validate edge cases without waiting for physical boards; and we’ve optimized our bring-up procedures to parallelize signal integrity measurements, potentially recovering 1-2 days during validation.

We are having a revised board that is just the 2 usb connectors being made first to confirm that in assembly those don’t get damaged. those will get delivered before anything else.

Provide an updated schedule if changes have occurred.

Revised schedule accounting for the USB connector issue and incorporating the software development breakthrough:

Weeks 5-6 (current): Board redesign completed with high-temperature USB connector, new PCB fabrication in progress. Major software milestone achieved – imaging code fully functional with successful data recovery demonstrations. Software development now ahead of schedule.

Weeks 7-8 (upcoming): PCB delivery November 19th, board assembly and bring-up with new connector. Signal integrity validation focusing on USB differential pair impedance with replacement connector. VBUS power cycling characterization. Software team expanding test coverage and edge case handling while hardware is in fabrication.

Weeks 9-10: System integration with functional software stack, initial recovery testing with failed drives across multiple failure modes, throughput optimization, user interface refinement.

Week 11: Cross-vendor drive compatibility validation, performance measurements, success rate analysis across different drive failure types.

Week 12: Final demonstration preparation, comprehensive documentation, demo video production, poster completion.

The critical path now runs through hardware validation and integration testing. Software development is no longer blocking, having achieved the major milestone of functional end-to-end data recovery. The 5-day hardware delay is partially offset by accelerated software readiness.

Progress summary and demonstrations

Hardware Progress: Mars managed the USB connector crisis by identifying the temperature rating incompatibility during manufacturer review, sourcing a high-temperature replacement (280°C rated), updating the PCB design while maintaining signal integrity requirements, and expediting the revised fabrication. Standard components have been inventoried with 100% BOM match. The testing and bring-up plan has been finalized with detailed procedures for USB signal integrity verification with the new connector. Hardware interface specifications are complete. We are considering producing one test board with just USB connectors to verify USB 3 SuperSpeed compliance before full system bring-up, which could also serve as a demo backup platform.

Software Progress: Major breakthrough this week – Mars successfully got the imaging code working and demonstrated seamless data recovery from test drives.  Mars redid the software architecture entirely, and will work to get Apollo to update the documentation.

Integration: The team has updated hardware-software interface documentation to reflect the connector change and revised timeline. With software now functional and hardware expected November 19th, we’re well-positioned for rapid integration testing. The primary focus is preparing comprehensive bring-up procedures to validate the new USB connector’s signal integrity and leveraging the fabrication period to expand software test coverage and optimize the data recovery algorithms.

Posted on

Mars’s Status Report for November 1, 2025

What did you personally accomplish this week on the project?

This week I achieved a major breakthrough on the software side: I successfully got the imaging code working and was able to recover data seamlessly from test drives. After extensive debugging and optimization of the PyFTDI integration, the software prototype can now execute complete read cycles, handle error correction, and reconstruct recoverable data blocks. I validated the recovery process with multiple test scenarios including partially corrupted drives and drives with intermittent connection issues. The data recovery pipeline is now functional end-to-end, which represents a significant de-risking of our project goals.

However, we encountered a critical hardware setback this week. After extensive communication with the PCB manufacturer, I discovered that the USB connector we specified in our design is not rated for the reflow soldering temperatures required during board assembly. This issue was identified during the manufacturer’s design review process before fabrication began. The connector we selected has a maximum temperature rating of 260°C, but our lead-free reflow profile peaks at 245-250°C, which is too close to the limit and risks damaging the connector’s plastic housing during assembly.

I researched alternative USB connectors and identified a high-temperature rated replacement (rated to 280°C) that is pin-compatible with our existing design, requiring only minimal PCB footprint adjustments. I updated the schematic and PCB layout, verified the new connector maintains our impedance specifications for the USB differential pairs, and resubmitted the design to the manufacturer. This change added approximately 5 days to our fabrication timeline.

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 approximately 5 days behind schedule due to the USB connector temperature rating issue discovered during manufacturer review. The new expected board delivery date is now around November 19th, representing an additional delay beyond our previous November 14th target.

To mitigate this delay, I’ve taken several actions: First, since the imaging and data recovery code is now fully functional, I’m working with Apollo to expand our software test suite using simulated hardware responses, allowing us to validate edge cases and error conditions without waiting for physical boards. Second, I’ve confirmed with the manufacturer that the revised design has been fast-tracked through their review process to avoid any additional delays. Third, I’m pre-staging all components, test equipment, and bring-up procedures so we can begin validation immediately upon board arrival.

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

Next week I plan to:

  • Complete comprehensive software documentation for the imaging and data recovery code, including API specifications and integration guides for Apollo
  • Develop additional test cases for the software prototype covering corner cases like sudden disconnections during reads, drives with physical bad sectors, and drives requiring multiple recovery attempts
  • Monitor the PCB fabrication status and confirm the high-temperature USB connector has been correctly installed during assembly
  • Prepare a detailed board bring-up checklist that prioritizes safety verification (no shorts, correct voltage levels) before attempting USB enumeration with the new connector
  • Create a contingency plan document outlining backup approaches if the new USB connector exhibits any issues during testing
  • Work with Apollo to finalize the user interface for the data recovery tool so we can begin user testing as soon as hardware validation is complete
Posted on

Apollo’s Status report for Oct 25th

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

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.

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 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.

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

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.

Posted on

Team Status Report for October 25

Team Status Report for October 25, 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 risk this week was the unexpected unavailability of the TUSB1064 USB redriver IC, which went out of stock before our order could be fulfilled. We managed this by immediately evaluating alternative components, redesigning the affected PCB sections, and placing a new expedited fabrication order (7-day turnaround). This minimizes schedule impact while maintaining our signal integrity requirements.

Software development is now behind schedule, which creates risk for integration when hardware arrives. Apollo is behind on implementing the recovery algorithms and data capture framework. To address this, Mars will step in to assist with software development during the hardware fabrication period. We’re focusing efforts on core recovery functionality rather than auxiliary features, and leveraging the one-week hardware delay as additional development time. Our contingency plan is to implement a simplified recovery mode that performs raw sector imaging first, deferring complex file system reconstruction if necessary.

Hardware integration risk remains centered on verifying that the VBUS power-cycling circuit meets specifications with actual failed USB drives. Mars has prepared validation procedures and identified tunable parameters that can be adjusted if needed.

Component lead times present reduced risk since standard parts have arrived and been inventoried. Remaining long-lead items (MOSFETs and replacement redriver) are expected within 2 weeks, aligning with our revised PCB delivery schedule.

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?

We made one significant hardware change: replacing the TUSB1064 USB redriver IC with an alternative component due to supply chain unavailability. Waiting for restocking (potentially 8+ weeks) would have caused unacceptable delays.

Costs include approximately one week schedule delay (PCB delivery now November 14th instead of November 7th), additional fabrication charges, and 8 hours of engineering time for redesign. We’re mitigating through expedited fabrication, using the delay for software catch-up, and streamlined bring-up procedures.

No fundamental architecture changes were made. The three-subsystem design and layered software architecture remain unchanged.

Provide an updated schedule if changes have occurred.

Revised schedule accounting for hardware delay and software development challenges:

Weeks 5-6 (current): Board redesign completed, new PCB fabrication in progress, software prototype demonstrated but core recovery algorithms behind schedule

Weeks 7-8 (upcoming): PCB delivery November 14th, board assembly and bring-up, signal integrity validation. Mars and Apollo both working on software to catch up on recovery functionality.

Weeks 9-10: System integration, initial recovery testing with failed drives, throughput optimization

Week 11: Cross-vendor compatibility validation, performance measurements, success rate analysis

Week 12: Final demonstration preparation, documentation, demo video, poster

The critical path now includes software development completion as a blocking item. Mars will assist with software during fabrication to get back on schedule.

Progress summary and demonstrations

Hardware Progress: Mars managed the component crisis by redesigning the board with a replacement redriver IC and placing an expedited fabrication order. Standard components arrived and were inventoried with 100% BOM match. The testing and bring-up plan was finalized with detailed validation procedures. The hardware interface specification document was completed. Lab workspace preparation is underway. We may have 1 board produced that is just usb connectors so we can verify that all the requirements for USB 3 super speed are setup in place. And we could also use this board for the demo, as USB 3 is more critical than power cycling.

Software Progress: Apollo demonstrated a working prototype that communicates with the FTDI chip and controls GPIO pins, validating the PyFTDI interface approach. However, core recovery functionality including data capture algorithms, file system reconstruction, and error handling remain incomplete. Mars will now assist with software development during the hardware fabrication period to accelerate progress and catch up to schedule.

Integration: The team reviewed hardware-software interface requirements and updated documentation to reflect the component change and revised timeline. The primary focus moving forward is accelerating software development over the next two weeks to enable on-schedule integration testing when boards arrive mid-November.

Posted on

Mars’s Status Report for October 25, 2025

What did you personally accomplish this week on the project?

This week I finalized the testing and bring-up plan with detailed procedures for USB signal integrity verification and power cycling characterization. The plan now includes specific test sequences for each verification stage: initial continuity checks of critical nets, FTDI enumeration testing at low power, signal integrity measurements of USB differential pairs using the vector network analyzer, and full VBUS power cycling with actual failed drives. I documented the expected voltage levels, rise times, and impedance measurements at each test point to establish clear pass/fail criteria.

I received and inventoried the standard lead-time components that arrived this week, including the bulk capacitors, resistors. I verified all quantities and part numbers against our BOM – everything matched perfectly and we have sufficient quantities for the initial prototype builds plus spares. One connector I had to do a replacement oder from.

I completed the hardware interface specification document detailing GPIO pin assignments for VBUS power control, timing requirements for power cycling sequences (minimum 500ms off-time between cycles, 100ms ramp monitoring), and USB enumeration signal monitoring points. This document provides Apollo with all the information needed for PyFTDI integration.

However, we encountered a significant issue this week: the TUSB1064 USB redriver IC that I had ordered went out of stock at our supplier before the order could be fulfilled. This component is critical for signal conditioning and was a key part of our design for handling degraded USB signals from failed drives. After investigating alternatives and consulting with Apollo, we made the decision to redesign the board to use a different, more readily available redriver IC. I completed the schematic updates, re-routed the affected PCB traces while maintaining our impedance-controlled design requirements, and placed a new fabrication order. The new timeline puts us at approximately 2 weeks for fabrication and assembly, pushing our expected delivery to around November 14th.

I met with Apollo to review the software prototype integration. We successfully demonstrated a working software prototype that can communicate with the FTDI chip and control GPIO pins for power sequencing. This de-risks a major portion of the project since we’ve now validated that the PyFTDI library works as expected for our use case and can handle the timing-critical power cycling operations.

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 approximately one week behind schedule due to the component availability issue and required board redesign. The new expected delivery date of November 14th represents a one-week slip from our original November 7th target.

To mitigate this delay, I’ve taken several actions: First, I expedited the new PCB fabrication order by selecting the faster turnaround option (7-day instead of 10-day fabrication). Second, Now ive started to also work on the software. Apollo can continue developing and testing the recovery algorithms without waiting for hardware, effectively parallelizing our work streams. Third, I’m pre-positioning all other components and test equipment so that we can begin board bring-up immediately upon delivery rather than waiting for additional setup time. Finally, I’ve identified which test procedures can be streamlined during initial bring-up without compromising safety or thoroughness, potentially recovering 1-2 days during the validation phase.

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

Next week I plan to:

  • Receive and inventory the long-lead-time components (IRLZ44N MOSFETs and the replacement USB redriver IC) and verify they match specifications
  • Develop a comprehensive risk mitigation strategy document for the board bring-up phase, including contingency plans for out-of-spec impedance measurements, VBUS timing issues, and signal integrity problems
  • Prepare detailed assembly instructions for the replacement USB redriver component, including any layout differences from the original design
  • Check if the labs have the test equipment do test our signal integrity results.
  • Work with Apollo to expand the software prototype to include data recovery test cases that we can validate immediately when hardware arrives
  • Create a revised project schedule that accounts for the one-week slip and identifies opportunities to recover time in later phases
Posted on

Apollo’s Status Report Oct 11th

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.