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.

Posted on

Team Status Report for October 11th

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.

Posted on

Mars’s Status Reports for October 11

What did you personally accomplish this week on the project?

This week I successfully submitted our PCB fabrication order to the manufacturing house after resolving the procurement setup issues from last week. I confirmed the production timeline – we’re looking at a 10-business-day turnaround for fabrication plus 3 days for assembly, putting our expected delivery around November 7th.

I completed the component procurement process, ordering all remaining parts from our approved vendors. The majority of components are stocked and will arrive within 5-7 business days. However, I identified two long-lead-time components: the IRLZ44N MOSFET switching transistors (3-week lead time) and the TUSB1064 USB redriver IC (2-week lead time). I expedited shipping on both to compress delivery to approximately 2 weeks, which still keeps us on schedule for our first prototype assembly.

I developed a comprehensive assembly procedure document that details the manual assembly process for the through-hole components including USB Type-A connectors and test points. The document includes step-by-step instructions with reference images, soldering temperature specifications for different component types, and quality checkpoints to verify proper connections before powering up the board.

I drafted the initial testing and bring-up plan, which outlines a systematic approach to first-power scenarios. The plan starts with visual inspection and continuity testing of critical nets (VBUS, GND, USB differential pairs), progresses through low-power functional verification of the FTDI interface, and culminates in full VBUS power cycling tests with actual failed USB drives. I’ve identified the test equipment we’ll need and confirmed availability of oscilloscopes, vector network analyzers for impedance measurements, and USB protocol analyzers in our lab space.

Finally, I met with Apollo to review the hardware-software interface requirements and confirmed that our GPIO assignments for VBUS power control align with the PyFTDI software architecture. We identified the specific timing requirements for power cycling sequences and the status feedback signals needed for recovery progress monitoring.

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. All planned deliverables were completed this week. The component lead times are within acceptable ranges and won’t impact our critical path since software development can proceed in parallel. I’ve built in buffer time for any unexpected delays during board bring-up.

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

Next week I plan to:

  • Finalize the testing and bring-up plan with detailed test procedures for USB signal integrity verification and power cycling characterization
  • Receive and inventory the standard lead-time components (bulk capacitors, resistors, ferrite beads) to verify quantities and part numbers against the BOM
  • Prepare the lab workspace with all necessary test equipment including oscilloscope, multimeter, and USB protocol analyzer
  • Create a hardware interface specification document detailing GPIO pin assignments, VBUS switching timing requirements, and USB enumeration signal monitoring points
  • Develop a risk mitigation strategy for the board bring-up phase, including backup plans if initial impedance measurements fall outside tolerance or VBUS rise times exceed specifications
  • Begin preliminary discussions with Apollo on the PyFTDI integration to ensure smooth hardware-software handoff when boards arrive

Part A written by: Mars
Part B written by: Mars

Part A: Global Factors Consideration

Our FlashRescue USB data recovery solution addresses a critical global need that transcends geographic and economic boundaries – the need to recover irreplaceable personal data from failed USB drives. While data recovery services exist, they’re concentrated in developed markets and priced at $300-$1500 per recovery, making them economically inaccessible to the majority of the world’s population. This pricing structure effectively means that users in developing economies face permanent data loss when drives fail, even though the technical barriers to recovery aren’t insurmountable.

The hardware design I’ve developed explicitly considers global accessibility through several key decisions. The power management circuitry accommodates USB power delivery from various host sources worldwide, handling the voltage variations and noise characteristics present in different regions’ USB implementations. More fundamentally, the use of widely-available commodity components (FTDI FT2232H, standard MOSFETs, common USB redrivers) rather than specialized recovery hardware means the design can be replicated anywhere these components are available – which includes most countries with electronics distribution networks.

The impedance-controlled 6-layer PCB design, while adding cost, serves a global accessibility purpose beyond just signal integrity. Failed USB drives often exhibit degraded electrical characteristics – weak signals, timing violations, or marginal compliance with USB specifications. By implementing robust signal conditioning with the TUSB1064 redriver and maintaining tight impedance control, the hardware can successfully interface with drives that wouldn’t work with simpler circuits. This is particularly important for users in regions where drives may have experienced harsher operating conditions – extreme temperatures, unstable power, physical stress – making electrical degradation more likely.

Perhaps most importantly, the open-source nature of both hardware and software enables global adaptation and improvement. Users with electronics skills anywhere in the world can build, modify, and improve the design. The comprehensive documentation and clear derivations I’ve provided in the hardware specifications allow technically-capable individuals to understand not just what the design does, but why each decision was made. This educational transparency supports a global community of practitioners who can adapt the design for local conditions, share improvements, and collectively advance data recovery accessibility. For users in regions without access to professional recovery services, this community-based approach may represent their only viable option for recovering critical data.

Part B: Cultural Factors Consideration

The FlashRescue design acknowledges that people’s relationships with their data vary significantly across cultural contexts, and these differences influence both what constitutes “important data” and how recovery should be approached. In some Western contexts, USB drives primarily store convenience copies of data that exists elsewhere – documents synced to cloud services, photos backed up automatically. However, in many global contexts, USB drives serve as primary or sole storage for irreplaceable content: family photos with no other copies, small business financial records, academic work, or personal documents that cannot be entrusted to cloud services.

Cultural attitudes toward data privacy and ownership significantly influence the recovery solution’s design requirements. The hardware architecture I’ve implemented maintains complete user control throughout the recovery process, with no cloud dependencies, no required internet connectivity, and no data transmission to external services. This design choice respects cultural and individual values around data privacy – whether driven by professional confidentiality requirements, concerns about government surveillance, religious or cultural sensitivities around image capture and storage, or simply personal preference for data sovereignty. Users maintain physical possession of their drive throughout recovery, and the open-source nature of the software means there are no hidden data collection mechanisms.

The technical accessibility design also reflects cultural considerations around technology adoption and self-sufficiency. Some cultures emphasize learning technical skills and performing repairs independently rather than relying on service providers. The modular hardware design with clearly-labeled through-hole components and the educational documentation support this value system by making the technology understandable and maintainable by technically-inclined users. The command-line interface, while perhaps less approachable than a graphical interface, provides transparency into the recovery process that respects users who want to understand exactly what operations are being performed on their data.

Additionally, the cost structure (<$200 for a reusable tool versus $300-$1500 per recovery) enables a community-based recovery model where technically capable individuals can help friends, family, or community members recover data. This aligns with cultural values in communities that emphasize mutual aid and collective problem-solving rather than purely commercial service relationships. The open documentation and adaptable design support this use case by making it feasible for community workshops, repair cafes, or informal technology support networks to offer recovery services.

Posted on

Mars’s Status report for October 4th

What did you personally accomplish this week on the project?

This week I successfully completed the PCB layout and routing in Altium, marking a major milestone in our hardware development. The layout process required careful consideration of signal integrity, power distribution, and thermal management. I positioned all components according to the placement strategy I outlined last week, with the power management section located near the input connector and the NMOS switching transistors arranged to minimize trace inductance.

The routing phase consumed significant time as I optimized trace widths for the high-current paths (using 100mil traces for the main power lines) while keeping signal traces appropriately sized. I implemented a solid ground plane on the bottom layer to provide a low-impedance return path and better thermal dissipation for the switching components.

I ran comprehensive Design Rule Checks (DRC) and addressed all violations. The initial DRC flagged 23 violations – primarily clearance issues around the dense power management IC area and a few trace width violations on high-current paths. After iterating on the layout, I resolved all critical errors and reduced the warnings to just 2 minor clearance notices that are within acceptable tolerances.

I generated the complete manufacturing file package including Gerbers (all copper layers, silkscreen, soldermask), NC drill files, and pick-and-place files for the assembly house. I also created a detailed assembly drawing that clearly marks which components will be machine-assembled versus hand-soldered.

The hybrid assembly plan is now finalized – the fab house will handle all SMD components (approximately 85 parts) while I’ll manually assemble the 12 through-hole connectors and mounting hardware. I’ve coordinated with our chosen fabrication house to confirm their capabilities and received confirmation that they can meet our timeline. I also placed orders for the through-hole components I’ll be assembling manually.

Finally, I prepared the fabrication submission package and reviewed it thoroughly with Apollo to ensure the board interfaces correctly with the software/firmware requirements.

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. All planned deliverables for this week were completed, and the PCB design is ready for fabrication submission. The DRC resolution took slightly longer than anticipated, but I absorbed that time without impacting the overall schedule.

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

Next week I plan to:

  • Submit the PCB fabrication order and confirm the manufacturing timeline with the fab house, there was an issue getting things set in to buy.
  • Order all remaining components that haven’t been procured yet, particularly any long-lead-time items
  • Create a detailed assembly procedure document for the manual assembly tasks
  • Begin developing the testing and bring-up plan for when the boards arrive
  • Coordinate with the team on enclosure/mechanical integration to ensure the PCB mounting points align with our mechanical design
  • Start preliminary work on the firmware integration requirements to ensure a smooth bring-up process when hardware arrives
Posted on

Team Status Report October 4th

1. Most significant risks and management strategies

The primary risks have shifted toward integration and timing verification as the project moves from design to early implementation. On the hardware side, PCB fabrication is now underway. The major risk is ensuring the MOSFET-based VBUS power-cycling circuit meets the < 10 ms rise/fall and ≤ 5 % overshoot specification once boards arrive. To mitigate this, Mars has scheduled oscilloscope validation immediately after bring-up and has kept a secondary vendor on standby in case of fabrication defects.

For software, the key challenge is synchronizing FTDI GPIO control with sustained data capture without exceeding the 20 µs jitter budget. We are addressing this by building a modular Python test suite that logs timing metrics separately from recovery logic, allowing us to debug latency before full system integration.

File-system reverse-engineering remains a longer-term risk, but work continues on a simplified recovery path that performs raw sector imaging first, followed by optional error-correction passes.

2. Changes to system design

No architectural changes were introduced this week. Minor schematic tweaks were made before sending the board out for fabrication — primarily tightening trace routing on the differential USB pairs and relocating decoupling capacitors for better impedance control.
Software structure remains the same (control / capture / reconstruction), but module boundaries have been clarified in the documentation to improve parallel development between hardware and software.

3. Schedule update

We remain on schedule with the Gantt chart milestones:

  • Week 5–6 (current): PCB fabrication + software modularization and sustained logging tests.

  • Week 7–8: Board assembly and FTDI GPIO verification.

  • Week 9–10: System integration and initial data recovery trials.
    Fabrication lead-time estimates confirm that boards will arrive in roughly two weeks, aligning with our planned integration window.

4. Progress summary

This week’s focus was on transitioning from design to execution.

  • Hardware: Finalized and submitted PCB Gerber files for fabrication; reviewed component order confirmations and arranged assembly logistics.

  • Software: Expanded the FTDI framework beyond initial tests to support continuous byte logging and modular control. Initial throughput measurements will begin once sample data is available.

  • Documentation: Updated design documentation to reflect final board stack-up, test metrics, and risk mitigation strategies.

Overall, the project has successfully moved from planning into early implementation, with both tracks maintaining momentum.

Posted on

Apollo’s Status Report for October 4th

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

This week I shifted from design preparation to implementation work. I refined the FTDI FT2232H software environment and began modularizing my earlier test scripts into distinct components for control and data logging. I improved the raw-byte capture script to handle sustained reads and verified that data can be streamed and saved reliably over longer durations.

I also documented the interfaces between modules — control (GPIO and power-cycling), capture, and reconstruction — so integration with the upcoming PCB firmware will be straightforward. Throughout the week I coordinated with Mars to align timing expectations between the hardware’s MOSFET switching and the FTDI control layer.

2. Is your progress on schedule or behind?

I’m on schedule. With the design review complete, this week’s goals focused on establishing a working modular framework and preparing for hardware arrival. The FTDI environment and sustained logging scripts meet those objectives. No major blockers at this stage.

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

Next week, I plan to:

  • Add configurable parameters to the logging tool (capture duration, file naming, and data-rate display).

  • Begin implementing a simple command-line interface (CLI) to unify control and logging operations.

  • Develop a test harness that measures FTDI GPIO latency so we can compare it against our < 20 µs target when hardware arrives.