Embedded Hardware + PCB + Mechanical Design. 5 Complete Prototypes Required

# Embedded Hardware + PCB + Mechanical Design — 5 Complete Prototypes Required I am looking for an experienced embedded hardware engineer or small engineering team to take ownership of the complete electrical and mechanical development of a compact, battery-powered embedded device. **This is not a schematic-only or PCB-layout-only project.** The final deliverable is **5 fully assembled, enclosed, working hardware prototypes delivered to me**. I will develop the firmware. When the project is complete, I should be able to take a unit out of the box, connect a programmer or USB cable, flash my firmware, and immediately begin firmware development and testing. I also need all source and manufacturing files necessary to independently order and build additional identical units after the project is complete. ## Physical Requirements * Smaller than a standard hockey puck; smaller is preferred * Lightweight * Suitable for mounting on mobile equipment * Internal rechargeable battery * USB-C power and charging * Professional-looking 3D-printed enclosure * Secure internal PCB and battery mounting * No loose wiring, hot glue, exposed PCBs, or breadboard-style construction * Clearly labeled external connectors * Status LEDs * Per-interface activity LEDs preferred * Serviceable enclosure * Prototype should look and feel like an early commercial product, not a bench prototype The exact shape does not need to be circular. A small rectangular design is acceptable if it results in a better product. ## Core Hardware The device should include: * STM32 or comparable MCU * RTC with backup power so time is maintained across main power cycles * microSD storage * USB-C * Ethernet * Rechargeable battery * Battery charging * Battery protection * Battery/fuel monitoring * Status LEDs * Debug/programming interface * Expansion capability * Optional WiFi/BLE if practical within the size and power constraints Processor selection is open to recommendation and should be justified. ## Interfaces The hardware needs to support monitoring/interfacing with: * UART * RS232 * RS485 * CAN * CAN FD * I2C * GPIO * Analog voltage * Current measurement where practical Multiple interfaces may be active simultaneously. The system should be designed so events from different interfaces can be correlated against a common high-resolution timebase. ## Modular Interface Requirement I do not want a different main device for each interface. The preferred architecture is a standardized set of ports on the main device with protocol-specific adapters, modules, or cables. For example, the same device could be configured using different adapters for CAN, RS232, I2C, analog, etc. I am open to the contractor proposing the best architecture. Adapters should be replaceable and additional adapter types should be possible in the future without redesigning the core device. The interface system should account for: * Different voltage domains * Level translation * ESD protection * Overvoltage protection * Bus loading * Signal integrity * Grounding * Isolation where appropriate * Adapter identification if practical ## Passive and Active Interfaces The hardware should be designed primarily for high-impedance/passive monitoring without materially affecting the connected electrical interface. However, supported digital interfaces must also be electrically capable of active transmission under firmware control. Passive receive and active transmit functionality should be designed so transmission can be positively disabled in hardware when not required. The device should power up in a passive/non-driving state. ## Data Acquisition The architecture should be capable of sustained simultaneous data acquisition. For design purposes, assume a demanding use case including approximately: * 2 CAN/CAN FD channels * 2 high-speed UART/serial channels * 4 GPIO channels * 4 analog channels at approximately 10 kHz These numbers are intended for architecture and sizing and can be discussed before final design. The contractor should account for: * DMA * Buffering * Storage write latency * microSD stalls * Burst traffic * Cross-channel timestamp accuracy * Unexpected power loss The design should not rely on average microSD write speed alone to guarantee lossless acquisition. ## Timing The system requires: * RTC for persistent absolute time * High-resolution hardware timebase for acquired events * Consistent timestamp correlation between interfaces Please propose an appropriate timestamp resolution and architecture. ## Storage Use removable microSD unless a better solution is proposed. The design should tolerate unexpected power loss without destroying previously committed recordings. Firmware implementation is my responsibility, but the hardware architecture must provide the necessary memory, storage, power monitoring, and other capabilities to implement this reliably. ## Power Target: * At least 24 hours of practical battery-powered data acquisition * Longer runtime preferred * Ethernet and wireless do not necessarily need to remain powered continuously Battery size, weight, capacity, expected runtime, and power-management strategy should be part of the design. I understand there are tradeoffs between physical size, battery capacity, processing performance, interface count, and runtime. I expect the contractor to identify and quantify these rather than simply agreeing to an unrealistic combination of requirements. ## Ethernet Ethernet is required. A full-size RJ45 connector is not required if it conflicts with the size target. A compact connector with an Ethernet adapter cable is acceptable. ## Firmware Responsibility **I will write the product firmware.** The contractor is responsible for enough hardware bring-up/testing firmware or test code to prove that the delivered hardware works. I expect documentation sufficient for me to immediately begin firmware development, including: * MCU part number * Complete pin mapping * Clock configuration * Programming/debug interface * Peripheral assignments * Power-control GPIOs * Adapter identification method * Schematics * Hardware notes * Datasheets/part references * Any required boot configuration The MCU must be accessible through a standard programming/debug interface such as SWD. ## Required Prototype Deliverables The project is not complete with bare PCBs. I require **5 complete physical units delivered to me**. Each unit must include: * Fully assembled PCB * All SMT components populated * Battery * Complete power system * Connectors * LEDs * 3D-printed enclosure * Mechanical hardware * Labels/markings * Any required internal wiring * Programming/debug access The five units should be mechanically and electrically identical. I should not need to solder, assemble, print, modify, or source anything before beginning firmware development. ## Interface Adapters The prototype delivery should also include a usable initial set of protocol adapters/cables. At minimum, I would like adapters for: * UART * RS232 * RS485 * CAN/CAN FD * I2C * Analog/GPIO Please state in your proposal how many of each adapter/cable are included in your price. ## Prototype Quality These are engineering prototypes, but presentation quality matters. The enclosure should: * Have clean surface finish * Fit correctly * Have properly aligned connector openings * Have readable interface labels * Have secure fasteners * Have no exposed electronics * Securely retain the battery * Be suitable for showing to another engineer or potential customer Professional FDM, SLA, SLS, MJF, or another appropriate manufacturing process is acceptable. Please recommend the process you would use. ## Hardware Validation Before shipping the five units, the contractor must perform and document basic hardware validation. At minimum: * All power rails verified * USB power verified * Battery charging verified * Battery operation verified * MCU programming/debug verified * RTC verified * microSD verified * Ethernet PHY/interface verified * LEDs verified * Each modular port electrically verified * Each supplied adapter electrically verified * Analog inputs verified against known voltages * Basic communication through each supported digital adapter demonstrated * Current consumption measured in major operating states * No obvious thermal issues during extended operation I am not expecting finished product firmware. Simple test firmware, scripts, development-board firmware, loopback tests, or test equipment may be used for hardware validation. A short validation report should be provided with the prototypes. ## Manufacturing Deliverables I need everything necessary to manufacture additional units without the contractor. This includes: * Native KiCad project * Complete schematic source * Complete PCB layout source * Gerbers * Drill files * Pick-and-place/CPL files * BOM with exact manufacturer part numbers * JLCPCB/LCSC part numbers where applicable * PCB stack-up requirements * Assembly drawings * Programming/debug documentation * Test points and test procedure * Cable/adapter schematics * Cable/adapter BOMs * Cable pinouts * Connector manufacturer part numbers The PCB and BOM should be designed with automated SMT assembly through JLCPCB or a comparable manufacturer in mind. ## Mechanical Deliverables Provide: * Native mechanical CAD source * STEP files * STL/3MF files as appropriate * PCB STEP model * Complete enclosure assembly STEP * Individual enclosure components * Mechanical drawings * Fastener specifications * Battery specifications * Label/artwork source files * Print/manufacturing settings or recommendations I should be able to send these files to another supplier and reproduce the enclosure without additional design work. ## Source Ownership All source files and design work created for this project must be provided upon completion. No locked files, flattened-only deliverables, or contractor-dependent manufacturing processes. I need to be able to independently modify and manufacture the hardware after completion. # Proposal Requirements — Please Read **Generic proposals will not be considered.** Your proposal should demonstrate how you would approach this specific design. Please address the following: ### 1. Architecture Describe your proposed core hardware and modular interface architecture. Would you use: * One PCB * Multiple PCBs * Protocol-specific adapter boards * Active cables Explain your reasoning. ### 2. Processor Which MCU would you use and why? Please provide a specific family or part rather than simply "STM32." ### 3. Capture Pipeline Explain how data moves from an interface through: **Capture → Timestamping → Buffering → Storage** I am specifically interested in how you would prevent data loss while multiple interfaces are active simultaneously. ### 4. Timestamping Explain how CAN, UART, GPIO, and analog measurements would share a common timestamp reference. Please distinguish between persistent RTC time and the high-resolution event timestamp. ### 5. Storage Explain how you would handle unpredictable microSD write stalls without losing incoming data. ### 6. Memory Estimate the RAM requirements and whether you expect external RAM to be necessary. ### 7. Power Budget Provide a preliminary power budget. Please estimate: * Major subsystem power consumption * Total active power * Expected average logging power * Required battery energy/capacity * Approximate battery size/weight * Expected runtime Please calculate power/energy rather than simply adding currents from components operating at different voltages. ### 8. Interface Ports Describe your proposed standardized connector and approximate pinout. Explain how different protocol adapters would connect to the same core device. ### 9. Passive Monitoring Explain how the hardware would avoid materially loading or interfering with the bus being monitored. ### 10. Active Transmission Explain how transmit circuitry would remain electrically disabled during passive operation and how it could later be enabled by firmware. ### 11. Power Loss Explain what hardware provisions you would include to support recovery from unexpected battery or external-power loss. The design should not depend solely on successfully flushing all buffered data after power failure is detected. ### 12. PCB Estimate: * PCB dimensions * Layer count * Major placement considerations ### 13. Mechanical Describe: * Proposed enclosure construction * 3D-printing/manufacturing method * Approximate finished dimensions * Battery placement * Connector placement * How the enclosure will be assembled and serviced ### 14. Technical Risks Identify the three requirements you believe create the largest engineering risks or tradeoffs. ### 15. Challenge the Requirements Tell me what you think I am asking for that is: * Unrealistic * Unnecessary * Overly expensive * Likely to cause problems * Better solved another way I would rather have requirements challenged now than discover the problem after fabrication. ### 16. Prototype Plan Explain how you would go from requirements to five tested, assembled units. ### 17. Schedule Provide the estimated duration and major milestones from project start through delivery of the five physical prototypes. ### 18. Price Clearly state what your price includes. Specifically identify whether your proposal includes: * Engineering/design labor * PCB fabrication * Components * PCB assembly * Batteries * Connectors * Adapter PCBs * Adapter cables * Mechanical hardware * 3D printing * Prototype assembly * Testing * Shipping * Five completed units If fabrication, materials, or shipping are quoted separately from engineering labor, clearly state the estimated additional cost. ### 19. Previous Work Please show examples of products where **you personally** performed relevant work, particularly: * Embedded hardware design * Mixed-signal electronics * PCB design * Battery-powered products * Mechanical/enclosure design * Prototype manufacturing * Products taken from schematic through physical assembled hardware **Photos of physically assembled hardware are much more useful than renders alone.** # Important I am not looking for a polished proposal that simply repeats the requirements above. I am specifically looking for **engineering judgment**. If you believe something above is wrong, say so. If you need to make assumptions, state them. If a requirement creates a significant technical tradeoff, explain it. Actual calculations, sketches, block diagrams, component recommendations, photographs of previous hardware, and concrete examples are preferred over a long generic written response. The successful contractor should be capable of taking this project from requirements through **five complete, tested, enclosed prototypes delivered to me and ready for firmware development.** ## Budget / Quoting I understand that prototype fabrication, components, assembly, 3D printing, and shipping have real costs. Please provide a fixed-price engineering proposal and clearly identify any prototype/material/shipping costs separately if necessary. The important number for me is the **total expected cost to reach five complete physical units delivered to me**, not simply the PCB design cost.