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 šŸ™‚

Posted on

Mars’s Status Report for September 20, 2025

What did you personally accomplish this week on the project?

I did a bit of work with Apollo and we brainstormed ideas for implementation. I have a rough idea of the hardware required which is bounded by the specs presented, and I started to come up with a rough hand drawing of what the PCB will look like. I’ve started the first step in the PCB process, doing component capture step. This is where you select components, and add in those models into Altium. I’ve found a type of nmos transistor that I both think would be suitable, and would be able to come in time. Furthermore, I am also trying to decide if I do hand assembly or if I have the PCB fabrication house do the entire assembly and component placement.

The nmos transistor I selected has the right voltage and current ratings for what we need, and the package size should work well with the layout I’m sketching out. I’m still working through some of the other key components like the power management ICs and making sure everything plays nicely together. The component availability has been pretty good so far, which is helping keep things on track timeline-wise. For the assembly question, I’m leaning towards having the fab house do it since it would be more reliable and probably faster, but I need to get quotes to see if it fits the budget. If costs are too high, I might do a hybrid approach where they place the fine-pitch components and I handle the through-hole stuff myself. I’m also double-checking that all the footprints I’m adding to Altium match what I can actually get, since that’s bitten me before on other projects.

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. The component selection phase is progressing well and I’m making good headway on understanding the hardware requirements and constraints.

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

Next week I plan to finish the component capture process in Altium, finalize the selection of remaining key components like power management ICs, and get assembly quotes from PCB fabrication houses to make the final decision on assembly approach. I also want to complete the preliminary schematic design and start transitioning into the PCB layout phase.