Drone Autonomy Spec
write a reportwith all info for a new engineer to take over the PCB and fix it.
Thought for 9 sec
I’ll create a structured takeover report covering both boards, architecture, completed work, current live state, known blockers, recovery history, verification gates, and the exact order a new engineer should follow.
Worked for 2 mins 22 sec
Created the comprehensive PCB Engineering Takeover Report.
It covers:
- Both project links and board responsibilities
- Current CM5 and S32K344 architecture
- Power, camera, radar, autopilot, Wi‑Fi, FHSS and SIYI interfaces
- Board dimensions, stackups and enclosure direction
- Completed fixes and verified checks
- Routing-service failure and recovery history
- Known footprints, software and regulatory risks
- Recommended takeover sequence
- Fabrication-release gates
- Immediate first-day checklist and required engineer deliverables
The report clearly marks both boards HOLD for fabrication until routing, interface freeze, DRC, thermal, software and mechanical validation are complete.
Review takeover report
Audit live board states
Prepare migration package
Freeze external interfaces
Refine this doc
Ask about this doc
PCB Engineering Takeover Report
1. Purpose and release status
This is the engineering handoff for the two-board KRYSTAL drone companion system. It consolidates the design intent, current implementation, known defects, routing history, verification evidence, and the recommended recovery sequence.
Current release status: HOLD — neither board is approved for fabrication or flight.
The next engineer should treat all counts in this report as the last confirmed state and rerun live ERC/DRC/layout checks before making changes. Do not generate Gerbers until every release gate in Section 13 passes.
2. Projects
Safety / power / I/O base board
- Project: KRYSTAL Module
- Function: aircraft-power entry and protection, independent S32K344 safety control, CAN FD, MAVLink/UART, RS-485, load-cell acquisition, LoRaWAN, radar power/control, compute-board power and supervision.
- Last intended PCB architecture: six layers after four-layer routing congestion was encountered.
Compute / vision / communications board
- Project: KRYSTAL Compute Vision Board
- Function: Raspberry Pi CM5 Linux compute, dual remote cameras through GMSL2, Ethernet/video networking, optional external Wi-Fi and FHSS provisions, vision processing and high-level swarm coordination.
- Current compute module: Raspberry Pi Compute Module 5 CM5016032 — 16 GB RAM, 32 GB eMMC, no onboard Wi-Fi/Bluetooth.
3. Mission and system intent
KRYSTAL is intended to:
- Integrate with a Pixhawk/PX4/ArduPilot-class autopilot through redundant CAN FD and MAVLink/UART.
- Collect front and downward camera video for terminal guidance and GPS-denied navigation.
- Ingest external mmWave radar data through Ethernet, with separate protected radar power and synchronization/control.
- Transmit data/video through SIYI HM30/MK32 or equivalent IP link.
- Provide low-bandwidth LoRaWAN telemetry and a separate 917–925 MHz FHSS swarm-radio provision.
- Keep Linux compute outside the final safety authority; the S32K344 owns watchdogs, power enables, plausibility checks and failsafe behavior.
- Operate from a nominal 4S LiPo aircraft supply within the designed 9–36 V input range.
4. Mechanical architecture
Base board
- Historical working outline expanded to approximately 150 × 140 mm to accommodate rugged radar/power connectors and routing.
- Six-layer conversion was applied after four-layer routing saturated around the S32K344.
- The new engineer must read back the live outline and stackup because the layout/routing service experienced persistence and derived-state problems.
Compute board
- Confirmed outline: 156 × 152 mm, rounded rectangle with approximately 2 mm corner radius.
- Confirmed thickness: approximately 1.48 mm.
- Confirmed six-copper-layer stack:
- Top signal
- Solid GND
- Inner signal
- Power
- Solid GND
- Bottom signal
- Last verified placement had no outside-board components or body overlaps.
- Only
J_CAM_FRONTandJ_CAM_DOWNwere moved slightly inward during the last deterministic placement pass.
Enclosure direction
- Gasketed aluminum enclosure with external fins aligned to drone airflow.
- Lid-coupled thermal interfaces for the compute module and high-current converter.
- Waterproof pressure-equalization vent, conformal coating, sealed bulkhead connectors and vibration isolation.
- Aluminum enclosure requires external antenna feedthroughs; do not place operational Wi-Fi/FHSS/LoRa antennas entirely inside it.
- The enclosure concept must be resized to the final board outlines and connector bend radii.
5. Base-board architecture and major parts
Key implemented devices include:
U4— NXP S32K344 safety MCU.U2— TPS16850 integrated eFuse for the main protected bus.U3— LM5013-Q1 always-on 3.3 V rail.U11— LM5013-Q1 local 5 V CAN/autopilot rail.U5— TPS3430 watchdog, providing a hardware veto of the main eFuse enable.U7,U8— TCAN1462-Q1 CAN FD/SIC transceivers.U9— THVD1450 half-duplex RS-485 transceiver.U10— ADS1232 24-bit bridge/load-cell ADC.U13— TPS26630 protected compute-power branch.U14— TPS26630 protected radar-power branch.U12— TPS2553-Q1 current-limited autopilot 5 V accessory branch.
TPS26630 footprint status
U13 and U14 were corrected in-project:- 4 × 4 mm RGE VQFN-24 intent.
- Centered 2.7 × 2.7 mm grounded exposed pad.
- Separate perimeter GND pin retained.
- Erroneous overlapping central mount pads disabled.
- Pins 19–24 remain NC.
The electrical copper geometry appeared consistent with the TI package intent. Before fabrication, the engineer must still verify:
- Exact TI recommended land dimensions.
- Paste-window segmentation and coverage.
- Thermal-via diameter, pitch, array and via treatment.
- Mask clearances and assembly-house DFM.
6. Base-board external interfaces
J1— aircraft power input; prototype connection only. Replace/finalize as a sealed locking connector rated for at least the worst-case 8–10 A input path.J3— DF40 40-pin base-to-compute signal mezzanine.J8— dedicated protected compute-power connector.J4— radar/high-bandwidth Ethernet connector/path.J9— sealed radar power/control/synchronization connector.J6— autopilot CAN connector.J7— autopilot MAVLink/TELEM connector.J5— load-cell connector.J2— S32K344 debug connector.
Final mating connector families and pinouts must be checked against the exact autopilot, radar, camera and aircraft harness before release.
7. Compute-board architecture and major blocks
Compute
U_CM5— Raspberry Pi CM5 CM5016032, 16 GB RAM, 32 GB eMMC, no wireless.- Native Gigabit Ethernet is allocated to the base-board interface.
- PCIe Gen2 x1 remains an important expansion resource; do not repurpose it without reviewing the base interconnect and optional accelerator strategy.
Main 5 V power
- LM5148-based synchronous 9–36 V to 5 V converter, designed around a 10 A-class stage.
- Revised combined 5 V peak budget: 6.64 A / 33.20 W.
- Reflected worst-case 9 V input: approximately 4.10 A / 36.89 W.
- eFuse current-limit resistor changed from 4.02 kΩ to 3.16 kΩ.
- Calculated guaranteed-minimum input-current margin: approximately 29.3%.
- Compute power cabling requirement recorded as 18 AWG, at least 6 A.
Required physical validation:
- Thermal performance at minimum input voltage and maximum load.
- LM5148 loop/stability and transient response.
- MOSFET, inductor and capacitor temperature rise.
- Capacitor DC-bias and ripple-current derating.
- eFuse startup into approximately 1000 µF bulk capacitance.
- Connector/contact and cable voltage drop.
GMSL2 cameras
- MAX9296A-class dual GMSL2 deserializer infrastructure.
J_CAM_FRONTandJ_CAM_DOWNprovide the remote camera inputs.- MAX9296A Port A four-lane CSI-2 plus clock connects to CM5 MIPI0.
- Existing support includes 25 MHz reference, configuration straps, reset/power-down logic, supply decoupling, coax input networks and unused-input terminations.
- Added level translation:
U_GMSL_I2C_LS— TXS0102 for I2C.U_GMSL_EN_LSandU_GMSL_LOCK_LS— SN74LXC1T45 devices for control/status.- Correct rail pull-ups, safe default biases and bypass capacitors.
- No direct CM5 3.3 V control signal should remain connected to a 1.8 V-only MAX9296A control pin.
Open camera blockers:
- Exact camera modules, serializers and Power-over-Coax requirements are not frozen.
- Aggregate bandwidth must be recalculated from final resolution, pixel format, frame rate and blanking.
- Four CSI lanes at 2.0 Gbit/s/lane give an 8.0 Gbit/s raw ceiling before protocol overhead.
- Dual stream is expected to require virtual-channel aggregation.
- No proven Raspberry Pi/MAX9296A production V4L2/media-controller driver was identified. This is a major software/integration risk.
- Device-tree, serializer configuration, camera synchronization and timestamp strategy remain to be validated on hardware.
Wi-Fi
- Requirement: IEEE 802.11ac/a/b/g/n, dual band 2.412–2.472 GHz and 5.15–5.825 GHz, approximately 2 dBi external dual-band antenna.
U_WIFI— Murata LBEE5PK2AE-564 provision.- Host interface: USB 2.0 from CM5, with ESD protection.
U_WIFI_REGAP63203 createsRADIO_3V3from5V_SOM.- External U.FL antenna provision with 50 Ω RF metadata.
- Current state: DNP, excluded from BOM/pick-and-place pending:
- Raspberry Pi OS USB VID/PID, driver and firmware validation.
- Final 5 V power margin.
- Exact IMDA approval evidence for the module plus antenna/coax combination.
SIYI Ethernet
J_SIYI_ETHis retained as a DNP connector provision.- CM5 native Ethernet is already allocated.
- A raw/incomplete USB-Ethernet IC implementation was removed.
- A supported USB3-to-Gigabit implementation was deferred due to power and verified-part/driver constraints.
- The engineer should decide among:
- Validated USB3-to-Gigabit controller/module with Linux support.
- External Ethernet switch architecture.
- Network connection through the base board.
- Keep SIYI Ethernet external/off-board.
FHSS swarm radio
- Provisioned for 917–925 MHz Singapore-region operation.
- Includes default-off 3.3 V / 2 A low-noise supply, approximately 220 µF burst reservoir, level shifting, UART/control/status/synchronization and external sealed antenna provision.
- The actual radio remains TBD/DNP pending exact approved regional SKU, firmware region lock, antenna and IMDA evidence.
AI capability
- Current AI hardware is the CM5 CPU/GPU platform; the previous i.MX8M Plus integrated NPU direction was superseded.
- Hailo-8 is not implemented.
- An optional Hailo accelerator requires a verified PCIe/M.2 implementation, additional power margin, thermal solution, Linux support and enclosure review.
8. Communications architecture
- Primary GCS: Atreyd RAYN-C2 / QGroundControl through Wi-Fi router.
- Secondary safety link: RadioMaster TX16S Mark II 4IN1, external 2.4 GHz control link.
- Tertiary data/video: SIYI HM30/MK32, intended as Ethernet/IP and RTSP transport.
- Payload camera: SIYI A8 Mini may provide RTSP video but is not a substitute for the raw, synchronized front/down guidance cameras.
- LoRaWAN remains for small telemetry/event messages, not video or deterministic swarm control.
- FHSS is the intended drone-to-drone swarm link.
RF coexistence must consider simultaneous:
- 917–925 MHz FHSS/LoRaWAN.
- 2.4 GHz safety radio.
- 2.4/5 GHz Wi-Fi.
- 5 GHz SIYI links.
The engineer must establish antenna separation, filters, enclosure feedthroughs, allowed channels/EIRP and concurrency tests.
9. Last confirmed electrical checks
Compute schematic
A focused full ERC pass found only two CM5 library false positives:
U_CM5:VBUS_ENU_CM5:VBAT
Both are intentionally unused and marked NC, but the library/ERC engine does not honor the NC state for these power-class pins.
Focused ERC was clean for:
- LM5148 and the compute input eFuse.
- MAX9296A power/control block and level translators.
- Wi-Fi block when inspected in isolation.
- SIYI DNP connector provision.
The engineer must rerun a fresh full ERC and independently validate that no changes occurred after these checks.
Compute placement and stackup
Last verified before routing attempts:
- 132 components: 126 top, 6 bottom (
C1–C6). - No outside-board parts.
- No component-body overlaps.
- No missing footprints or invalid-layer objects.
- Six-layer stackup confirmed.
- High-speed metadata had been cleaned for active pairs:
- CSI-2: 100 Ω differential.
- Wi-Fi USB 2.0: 90 Ω differential.
- CM5 Ethernet: 100 Ω differential.
- PCIe: 85 Ω differential.
- Stale metadata was removed from unused/DNP SIYI and CSI2 nets.
Exact trace widths must be recalculated from the selected fabricator’s real dielectric thickness, Dk, copper thickness and solder-mask assumptions.
10. Critical routing-service incident
The Compute Vision Board is intentionally restored to a safe unrouted state because Flux routing/rule operations produced reproducible derived-layout corruption.
Observed failures
- Auto-route board-check/preflight repeatedly timed out with HTTP 524.
- The preflight initially reported 32 pin-width warnings, but post-fix verification could not complete.
- A full auto-route attempt partially applied 163 trace segments and two additional vias.
- Instead of decreasing, reported airwires increased from a historical 247 to 442.
- Applying eight net-scoped routing rule sets regenerated fills and changed GND stitching-via assignments.
- Reapplying the same intended rules reproduced the corruption mechanism.
Recovery history
- Bad transition identified at commit
#5105c5bb. - Clean preceding state: commit
#c52f37c6. - The project was restored to
#c52f37c6. - An attempted rules-only reapplication reproduced fill/via corruption and was rolled back.
Current safe compute-layout state
Last confirmed after recovery:
- 0 trace segments.
- 89 GND stitching vias.
- 1 fill.
- Board remains 156 × 152 mm and six layers.
- No reported dangling-trace, different-net-overlap or invalid-layer errors.
- Routing rules from the failed Phase 0 batch are not currently applied.
- The routing-state tool may report 442 airwire objects despite an earlier baseline of 247; treat this as a metric/derived-state discrepancy and derive the true unrouted connection count from a fresh netlist/layout audit.
Escalation
The routing/rules corruption and timeout issue was submitted to Flux engineering/support. Do not repeat full auto-route or apply the same net-scoped rule batch until the platform issue is confirmed resolved or the project is migrated/exported to a stable routing workflow.
11. Base-board routing status
The base board also experienced routing-service/application failures.
Known history:
- It was expanded and later converted to six layers after four-layer saturation around the S32K344.
- Earlier routing passes produced substantial routed copper but left dozens of airwires.
- Overlaps and dangling traces were cleaned at points in the process.
- Auto-router jobs sometimes converged internally but failed while applying results.
Because the base project has been modified repeatedly and its exact live routing count was not re-established during the latest compute recovery, the new engineer must perform a fresh audit before trusting historical counts.
First base-board checks:
- Read live board outline and actual layer stack.
- Count traces, vias, airwires, dangling traces and overlaps.
- Inspect whether existing copper matches the current schematic placements.
- Validate all high-current input/eFuse/radar/compute power paths.
- Validate Ethernet pair continuity and reference planes.
- Confirm the corrected U13/U14 footprints remain intact.
12. Recommended takeover sequence
Phase A — Freeze configuration
- Clone/fork or tag both projects before editing.
- Confirm exact external hardware:
- Autopilot model and connector pinout.
- mmWave radar model, voltage/current, Ethernet standard and synchronization levels.
- Front/down GMSL camera modules and serializers.
- SIYI air/ground units and Ethernet topology.
- FHSS radio SKU, antenna and region firmware.
- Wi-Fi module and approved antenna.
- Freeze board-to-board connector pin mapping.
Phase B — Schematic review
- Run fresh full ERC on both projects.
- Validate every IC against current datasheets.
- Confirm all power pins, decoupling, boot straps, clocks, reset and NC pins.
- Confirm GPIO mux assignments for S32K344 and CM5.
- Check voltage domains and translator directions.
- Recalculate the complete power tree from 9 V minimum input.
- Review safe startup, shutdown and watchdog state machines.
Phase C — Footprint/BOM review
- Validate every non-generic footprint against the manufacturer land pattern.
- Review exposed pads, paste apertures and thermal vias.
- Confirm production MPNs, lifecycle and availability.
- Verify voltage, ripple, current, saturation and temperature ratings.
- Verify connector mating parts, cable gauges, retention and sealing.
Phase D — Layout recovery
- Use a stable copy/workflow; do not route on the only good project state.
- Confirm planes/fills and GND stitching vias before applying rules.
- Apply one small rule at a time and diff fills/vias after each change until the platform defect is understood.
- If Flux remains unstable, export/migrate for layout in a mature external PCB workflow and preserve net names/constraints.
- Route in order:
- High-current power and returns.
- Clocks and critical control.
- CSI-2, USB, Ethernet, PCIe and GMSL-related high-speed paths.
- Sensitive analog/load-cell paths.
- CAN/RS-485/UART/GPIO.
- Remaining low-speed signals.
- Maintain solid return planes and place stitching vias at layer transitions.
Phase E — Mechanical/thermal/RF
- Update enclosure dimensions to final PCB outlines.
- Verify every connector cutout and cable bend radius.
- Perform thermal simulation or measured prototype testing at 9 V/full load.
- Validate lid-coupled heat paths and fin orientation.
- Validate IP sealing strategy, pressure vent, conformal coating and condensation control.
- Validate antenna placement and simultaneous-radio coexistence.
Phase F — Software/bring-up
- Prove CM5 boot and eMMC recovery/programming.
- Prove GMSL serializer/deserializer drivers and device tree.
- Capture two synchronized camera streams at final formats.
- Verify radar data ingestion and time synchronization.
- Verify MAVLink/CAN integration with the exact autopilot.
- Verify S32K watchdog/failsafe behavior under Linux crash, brownout and corrupt commands.
- Verify swarm-radio timing, security, lost-link and congestion behavior.
13. Fabrication release gates
Do not release manufacturing files until all are true:
- Exact schematic/BOM configuration is frozen.
- Full ERC is clean or every residual is formally justified.
- Every footprint has been checked against authoritative land patterns.
- Actual stackups and impedance tables are approved by the chosen fabricator.
- Zero airwires on both boards.
- Zero dangling traces, different-net copper overlaps, invalid-layer items or unresolved clearance violations.
- High-current traces, planes, vias, connectors and fuses pass current/thermal review.
- CSI-2, USB, Ethernet and PCIe routing passes impedance, pair matching and return-path review.
- Camera modules, serializers, drivers and dual-stream bandwidth are proven.
- Radar electrical interface and startup load are proven.
- Wi-Fi/FHSS/LoRa/SIYI antenna and Singapore IMDA strategy are approved.
- Enclosure fit, connector access, sealing and cooling are verified.
- Independent engineer issues a written fabrication PASS.
- Gerber/ODB++, drill, BOM, pick-and-place and assembly drawings pass final DFM review.
14. Required engineer deliverables
The takeover engineer should return:
- A PASS/HOLD review for each board.
- A numbered correction list with designators, nets and severity.
- Approved stackups and controlled-impedance tables.
- Updated power budget and thermal assumptions.
- Confirmed connector/harness table.
- Camera/radar/autopilot integration evidence.
- Final ERC/DRC reports.
- Routing completion evidence with zero airwires.
- Manufacturing package and DFM report.
- Updated bring-up and flight-test plans.
15. Existing project files to consult
Base project files
- Project specification
- Block-level electrical architecture
- Connector pinout matrix
- Communications architecture allocation
- Vision and camera architecture
- Compute/safety platform recommendation
- Compute backbone power budget
- External radar interface/load budget
- Critical design review and release gates
- Engineer review handoff
- Board bring-up plan
- Preliminary safety FMEA
- RF regulatory checklist
- Two-board sealed enclosure concept
Compute-project files
- Project specification
- Architecture block diagram
- CM5 migration and blocker closure
- Firmware and CM5 pin mapping
- Power budget and design notes
- Routing readiness blocker remediation
- Routing Phase 0 preflight
- SIYI Ethernet Pass 3
- Wireless regulatory evidence/TCF
- Board bring-up plan
- Critical design review
- Safety FMEA
- Optional Hailo-8 implementation gate
16. Immediate first-day checklist
- Create protected project snapshots.
- Read the current live schematic and layout rather than relying only on this report.
- Confirm commit
#c52f37c6remains the clean Compute Vision Board routing baseline. - Re-run compute ERC and verify only the two known CM5 library false positives remain.
- Re-run compute routing-state/DRC and verify 0 traces, 89 GND stitching vias and one fill before editing.
- Audit the base board’s current routing state from scratch.
- Contact Flux support regarding the routing/rules corruption before retrying auto-route.
- Freeze the external autopilot, radar, camera and radio hardware.
- Decide whether layout will continue in Flux or migrate to another EDA tool.
- Do not fabricate until the gates in Section 13 are signed off.
1. Purpose and release status
2. Projects
Safety / power / I/O base board
Compute / vision / communications board
3. Mission and system intent
4. Mechanical architecture
Base board
Compute board
Enclosure direction
5. Base-board architecture and major parts
TPS26630 footprint status
6. Base-board external interfaces
7. Compute-board architecture and major blocks
Compute
Main 5 V power
GMSL2 cameras
Wi-Fi
SIYI Ethernet
FHSS swarm radio
AI capability
8. Communications architecture
9. Last confirmed electrical checks
Compute schematic
Compute placement and stackup
10. Critical routing-service incident
Observed failures
Recovery history
Current safe compute-layout state
Escalation
11. Base-board routing status
12. Recommended takeover sequence
Phase A — Freeze configuration
Phase B — Schematic review
Phase C — Footprint/BOM review
Phase D — Layout recovery
Phase E — Mechanical/thermal/RF
Phase F — Software/bring-up
13. Fabrication release gates
14. Required engineer deliverables
15. Existing project files to consult
Base project files
Compute-project files
16. Immediate first-day checklist
