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

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

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.