Apollo’s status report for Dec 6th
What did you personally accomplish this week on the project?
This week I focused on the final report for the project. I worked on fixing the previous formatting issues of our report. I also worked to find and organize the sources for our report.
Is your progress on schedule or behind?
We are on schedule. Mars is working on integrating our project before our final demo next week.
What deliverables do you hope to complete in the next week?
Demo and Final report
Team Status Report for December 6
Team Status Report for December 6
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 at this stage is integration issues between our hardware and software subsystems now that we have assembled PCBs. We’re managing this through systematic unit testing of each board subsystem before full integration. Our contingency plan includes having the previous revision boards available as backup if critical issues emerge with the new assembly.
Another risk is time pressure for final documentation and demo preparation. We’re mitigating this by working on documentation in parallel with testing rather than waiting until all testing is complete. This ensures we can deliver quality documentation even if late-stage issues require debugging time.
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?
Yes, we made one significant design change this week: switching from a passive USB signal path to an active USB repeater board for signal integrity.
this was thought of a while ago, however we finally received our new usb boards.
Why this change was necessary: During our initial testing and analysis, we identified potential signal degradation issues with longer USB cable runs between the power cycling board and the target device. The passive approach would have limited our maximum cable length and potentially caused data recovery failures due to signal quality issues.
Costs incurred: The active repeater adds approximately $15 to our BOM cost and introduces an additional component that requires power and creates another potential failure point. It also adds slight complexity to our system integration.
Mitigation: The cost increase is well within our project budget. The reliability improvement significantly outweighs the added complexity, and active repeaters are well-characterized components with predictable behavior. This change actually reduces our overall risk by ensuring robust USB communication across various cable lengths and device types.
Provide an updated schedule if changes have occurred.
No schedule changes this week. We remain on track for final demo and report submission.
Unit Tests and System Tests
Unit Tests Conducted:
Power Delivery Subsystem:
- Voltage regulation verification (5V rail within ±5% tolerance)
- Current limiting functionality (verified 500mA limit)
- Power cycling timing accuracy (on/off sequences within 10ms of specification)
- Thermal performance under sustained load
USB Signal Path:
- Signal integrity measurements
- Data transmission verification at USB 2.0 speeds (480 Mbps)
Data Recovery Software Module:
- PDF file structure parsing (cross-reference table handling)
- File system metadata extraction
- Recovery success rate with known test files
Overall System Tests:
Speed Testing:
- Data transfer rates measured across full recovery pipeline
- Average throughput: [results pending complete integration]
Latency Testing:
- Power cycle to device enumeration time
- End-to-end recovery process timing
- Measured latency between power cycle initiation and data access
Recovery Rate Testing:
- Success rate with various file types (PDF, DOCX, images)
- Recovery reliability across different USB device types
- Partial recovery capability for corrupted files
Findings and Design Changes:
Design Change Implemented: Replaced passive USB signal path with active USB repeater board. The active repeater provides signal regeneration and impedance matching, ensuring reliable USB 2.0 communication across cable lengths up to 5 meters.
Impact: This change improved our system’s robustness and expanded our operational range. Testing shows clean signal quality and reliable enumeration with the active repeater, resolving the signal integrity issues we identified.
Progress Photos
Our revision 2 PCBs are fully assembled and undergoing systematic testing. Initial power-on tests show all subsystems functioning within specification. The active USB repeater integration is complete and performing well in preliminary tests.
Mars’s status report for December 6, 2025
What did you personally accomplish this week on the project?
This week I focused on testing our newly assembled PCBs and finalizing project documentation for FlashRescue. The boards arrived from assembly (revision 2) and I’ve been systematically validating their functionality.
I conducted initial power-on testing of the assembled boards, verifying proper voltage regulation across all power rails and checking for shorts or assembly defects. The USB power delivery circuits are functioning as expected based on our design specifications. I began functional testing of the power cycling subsystem, which controls USB power delivery for the data recovery process.
I also continued work on our project documentation, expanding the technical implementation details and organizing our design decisions into a coherent format for the final report. This includes documenting the PCB design rationale, component selection criteria, and system architecture. We want our documentation to stand out and clearly communicate our technical approach.
Additionally, I made progress on the PDF recovery debugging from last week, implementing fixes to the parsing logic for handling cross-reference tables.
I handled everything for the project this week.
Is your progress on schedule or behind?
We’re back on schedule now that the boards have arrived and passed initial testing. The assembly turnaround was faster than expected for a revision 2 board, which helped us recover from previous PCB delays. Having functional hardware puts us in a good position to complete integration testing on time.
What deliverables do you hope to complete in the next week?
just doing well in the final demo!
Apollo’s Status Report for Nov 22
What did you personally accomplish this week on the project?
This week I focused on strengthening the software-side documentation, refining our recovery test cases, and reviewing the feedback we received during the interim demo. Several TAs mentioned that parts of our technical explanation were not intuitive to people who haven’t been following our project closely. I spent time reorganizing our software documentation to make the recovery flow clearer in preparation for our final presentation.
Is your progress on schedule or behind?
I am on schedule based on our current project phase. Since we are waiting for hardware to arrive, my tasks this week focused on documentation.
What deliverables do you hope to complete next week?
-
Incorporate additional adjustments based on interim demo feedback to improve clarity for non-technical audiences.
-
Update and polish the recovery pipeline diagrams for the final presentation.
-
Continue strengthening the software implementation documentation for the final report.
-
Prepare the outline and visuals for the final presentation.
New Knowledge Gained
This project required me to deepen my understanding of file systems and data recovery, especially regarding how corruption manifests at different layers:
-
File system metadata structures (FAT32)
I learned how directory entries, allocation tables, and cluster chains behave when partially overwritten or fragmented, and how this affects both carving and reconstruction. -
Behavior of corrupted storage devices:
I studied how failed drives often present inconsistent enumeration behavior, sector read instability, and partially valid metadata, making recovery nontrivial. -
Entropy-based recovery insights:
I researched how entropy can help distinguish meaningful remnants (text blocks, image signatures) from fully overwritten or empty regions.
This deeper understanding is now directly shaping how we structure our recovery test cases and how we explain our approach in the report.
Learning Strategies Used
To acquire this knowledge efficiently, I used:
-
Technical blogs and digital forensics articles explaining real-world corruption patterns
-
YouTube tutorials on filesystem internals and data carving techniques
- Discussion with Mars to align how these insights influence our recovery methods and documentation
Team Status Report for November 22
What are the most significant risks that could jeopardize the success of the project?
The primary risk remains PCB fabrication and assembly timeline slipping, which would compress our validation testing window before the final demo. We’re actively managing this by maintaining close contact with the vendor – this week’s detailed coordination meeting locked down assembly specifications and timeline expectations. We now have confirmed dates and a clear understanding of which components require hand-soldering versus machine placement, reducing uncertainty.
A secondary risk is discovering critical issues during electrical validation that require board respins. We’re mitigating this through thorough pre-manufacturing design review and building in flexibility where possible.
A new risk that emerged this week is software bugs in the data recovery algorithms, particularly with PDF file reconstruction. We discovered parsing issues with PDF cross-reference tables that could limit our recovery capabilities for certain file types. We’re addressing this proactively during the PCB wait time by debugging and fixing these issues now, so software will be ready when hardware arrives.
Our contingency plan includes having backup hand-soldering capabilities if machine assembly faces delays, and we’re using the current PCB wait time productively for firmware development and algorithm debugging rather than being idle.
Were any changes made to the existing design of the system?
No fundamental design changes were made this week. We’re in the manufacturing transition phase and holding the design stable to enable PCB fabrication. The vendor coordination confirmed our design is manufacturable as-is, which validates our design decisions.
However, we refined our assembly approach based on vendor feedback: USB connectors and through-hole power components will be hand-soldered for mechanical reliability during repeated insertion cycles, while surface-mount components will be machine-placed. This is a process change rather than a design change, with no additional cost beyond what was budgeted.
Any design modifications discovered during validation testing will be documented and carefully evaluated for necessity versus workaround solutions. We expect minor tuning may be needed but are confident the core design is sound as this is the second revision.
Updated Schedule
We are approximately one week behind our original schedule due to PCB manufacturing delays. To compensate:
- Current week focus: Documentation development, PDF recovery debugging, virtual PCB testing preparation
- Next week: Complete virtual PCB validation scripts, finalize visual demonstration components
- When boards arrive: Immediate integration testing with pre-developed firmware and test infrastructure
By working on software and documentation during the PCB wait, we’re compressing the post-arrival bring-up timeline. We plan to recover the lost week through focused integration work once hardware is available.
Progress and Accomplishments
This week we made significant progress on multiple fronts:
Manufacturing Coordination: Successfully finalized all PCB assembly details with our vendor. We now have confirmed component placement strategy, assembly timeline, and clear division of responsibilities for parts sourcing. The power cycling board design has been validated as manufacturable with the thermal management and high-current routing meeting vendor requirements.
Software Development: Began debugging PDF file recovery algorithms, identifying issues with cross-reference table parsing. This proactive debugging during hardware wait time will ensure software is mature when boards arrive.
Documentation: Started organizing technical specifications and design decisions into formal documentation, which will streamline final report preparation and provide clear reference material for validation testing. I may make a blender final demonstration video for our project.
Test Planning: Developed comprehensive verification test plan for power cycling subsystem, including oscilloscope validation procedures, current delivery measurements, and endurance testing protocols. Virtual PCB testing scripts are in development to validate board functionality before physical testing.
System Validation Planning
Our overall system validation will test the complete use case: power cycling a failing USB drive and successfully recovering data that wouldn’t be accessible through normal means. Key validation metrics:
- Recovery success rate: Percentage of simulated failures successfully recovered (target >80%)
- Time to recovery: Total time from device insertion to data extraction (target <5 minutes)
- Data integrity: Verify recovered data matches original via checksum comparison
- File type coverage: Successfully recover multiple file types including PDFs, images, documents
- Compatibility: Test with multiple USB drive types and failure modes
The validation approach tests USB drives with known failure modes (corrupted file systems, wear-leveled failures, damaged partition tables) and measures whether FlashRescue can extract data that conventional recovery tools cannot. Success means our hardware power cycling enables data access that wouldn’t otherwise be possible. We may refine these metrics as testing progresses, but core validation criteria remain focused on real-world recovery scenarios.
Mars’s Status Report for November 22
What did you personally accomplish this week on the project?
This week I focused on finalizing our PCB manufacturing details and began working on both documentation and software debugging for the data recovery system. I keep meeting with the vendor for board assembly. I completed DFM analysis (image below)
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.
The boards are made! And are starting component placement and assembly (40% done) Which is pretty impressive for a revision 2 of PBC’s.
I also began working on project documentation too, organizing our design decisions and technical specifications into a coherent format. This will be essential for our final report and helps clarify our system architecture. We want to make our documentation stand out this time around.
Additionally, I started debugging a software issue we discovered with recovering data from PDF files. The recovery algorithm wasn’t properly reconstructing the PDF file structure, particularly with handling cross-reference tables and object streams. I’ve been tracing through the file format specifications to identify where our parsing logic breaks down.
Is your progress on schedule or behind?
Behind our original schedule due to PCB delays. However, 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. Using this time to work on software debugging and documentation helps us stay productive while waiting for hardware.
What deliverables do you hope to complete in the next week?
- Write test code to virtually validate revision 1 of our PCBs
- Continue debugging the PDF recovery issue and implement a fix
- Work on creating a visual demonstration for part of our final demo
- Expand project documentation with technical implementation details
New Tools and Learning Strategies
This week I needed to learn several new areas to accomplish my tasks:
PDF File Format Specification: To debug the PDF recovery issue, I had to dive deep into the PDF specification (ISO 32000). I started by reading Adobe’s PDF reference documentation, which is dense but authoritative. When I hit confusing sections, I supplemented this with blog posts and Stack Overflow discussions from developers who’ve parsed PDF files before. Seeing practical examples of how others handled cross-reference tables helped me understand what our code was doing wrong.
PCB Thermal Management: Understanding via-in-pad routing and thermal considerations for power MOSFETs was new territory for me. I watched several PCB design tutorials on YouTube focusing on high-current applications and read application notes from power MOSFET manufacturers. The combination of visual explanations in videos and detailed specifications in app notes gave me the confidence to make informed decisions during the vendor discussion.
Technical Documentation Best Practices: To write effective project documentation, I looked at examples from previous 18-500 projects and reviewed documentation standards for engineering projects. I also consulted with teammates about what information would be most valuable to include.
The most effective learning strategy was combining authoritative sources (official specifications, datasheets) with practical examples (forums, previous projects, tutorials). The specifications tell you what’s correct, but the examples show you how to actually implement it and what mistakes to avoid.
Apollo’s Status Report for Nov 15th
1. What did you personally accomplish this week on the project?
This week I focused on preparing the materials we need for the final stages of the project. I dedicated time to adding more software implementation documentation for the final report, including clearer explanations of the recovery pipeline, corruption cases, and the expected flow once hardware testing begins.
In parallel, I began researching entropy analysis techniques for full-format recovery. This included looking into how entropy patterns can differentiate meaningful residual data from overwritten sectors which is an approach that may strengthen our ability to identify recoverable regions even when file system metadata is missing.
2. Is your progress on schedule or behind?
I am on schedule for this phase. Since we are waiting on the new boards to arrive, my primary responsibilities center on validation planning, recovery research, and preparing software documentation.
3. What deliverables do you hope to complete next week?
-
Review any initial findings from Mars’s virtual PCB tests and adjust software validation requirements as needed.
-
Continue researching entropy-based classification methods to determine if low-entropy filtering can be incorporated into the recovery workflow.
-
Expand and refine software implementation documentation so it’s ready for integration with real hardware results once validation begins.
Apollo’s Status report for Nov 8th
1. What did you personally accomplish this week on the project?
This week I focused on research and documentation for the test cases we’ll use in our demo. I made sure our demo can clearly and convincingly show what our system can do with different types of corruption by surveying common USB failure modes and data-loss scenarios (e.g., partial corruption, boot sector corruption) and organized them into a structured set of demo-oriented test cases. For each case, I documented the expected drive behavior, what our imaging and recovery pipeline should demonstrate, and what metrics (recovery success, error logs, time to recover) we want to highlight during the demo.
I also started folding this work into our project documentation and final report draft, outlining a “Testing & Demo Scenarios” section that explains how our test cases map to real-world user problems. In parallel, I aligned the existing simulated test scripts with these documented scenarios so they can be reused as soon as Mars finishes initial board bring-up.
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 for the documentation and test-case preparation work. While Mars has been focused on the new software architecture and PCB delivery, I’ve used this time to ensure that our demo scenarios are well thought out and that we have a clear mapping between real-world failure modes and what we’ll show in the demo. Once the boards arrive and Mars completes initial bring-up, I’ll adapt these documented test cases to the actual hardware results and help integrate them into our final evaluation and report.
3. What deliverables do you hope to complete in the next week?
-
Review the interim demo results and identify any issues or improvements needed for the hardware–software workflow.
-
Compile a list of changes or fixes required before final integration and validation.
-
Begin refining and restructuring the final report, especially the testing methodology and demo results sections.
-
Integrate the documented test cases into the final report draft.
Team Status Report for November 15
What are the most significant risks that could jeopardize the success of the project?
The main risk is PCB fabrication timeline slipping, which would compress our validation testing window. We’re managing this by maintaining close contact with the vendor and having backup hand-soldering plans if machine assembly faces delays.
A secondary risk is discovering issues during electrical validation that require board respins. We’re mitigating this by thorough design review and having contingency circuits designed (like adjustable timing resistors) so we can tune parameters without a full redesign.
Were any changes made to the existing design of the system?
No design changes this week. We’re in the manufacturing transition phase, holding the design stable to get boards fabricated. Any changes discovered during validation testing will be documented and evaluated for necessity versus workarounds.
System Validation Planning
For overall system validation, we’ll test the complete use case: power cycling a failing USB drive and successfully recovering data that wouldn’t be accessible through normal means. Key validation metrics:
- Recovery success rate: Percentage of simulated failures successfully recovered (target >80%)
- Time to recovery: Total time from insertion to data extraction (target <5 minutes)
- Data integrity: Verify recovered data matches original via checksum comparison
- Compatibility: Test with multiple USB drive types and failure modes
The validation approach is straightforward – we’ll test with USB drives exhibiting known failure modes (corrupted file systems, wear-leveled failures, etc.) and measure whether FlashRescue can extract data that conventional recovery tools cannot. Success means our hardware power cycling enables data access that wouldn’t otherwise be possible. We may talk about updating metrics.