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