For OEM sourcing and perception teams: an approved solid-state LiDAR sample is only a stable design input when its optical stack, detector path, firmware, mechanics, and output contract are controlled. If one of those boundaries changes silently, the part number may stay the same while the evidence behind your pilot no longer does.
Quick answer: manage oem solid state lidar components with four linked baselines: a golden bill of materials (BOM), a golden physical sample, a frozen firmware/configuration record, and a replayable regression dataset. Every proposed substitution should identify the changed boundary, the reason, the effective lot or revision, and the smallest test set that can show whether the approved behavior remains intact.
Best for: sourcing engineers, quality leads, embedded developers, and UAV or robotics teams moving from an evaluation sample toward a repeatable pilot build.
OEM solid-state LiDAR components: define the controlled baseline
A useful component list is not a teardown guess. It is a supplier-agreed map of the functional boundaries that can change performance or integration. Start with the illumination source, receiver and timing path, optical elements, processor and firmware, power and thermal design, mechanical envelope, connectors, interface behavior, and controlled documents. Ask the supplier which details can be disclosed, which are proprietary, and which change notifications it will provide.
That boundary map matters because a compact direct time-of-flight system is an interacting measurement chain. STMicroelectronics’ current official Time-of-Flight portfolio overview describes direct-ToF solutions in terms of emitter, receiver, and processor functions, alongside documentation and evaluation tools. An OEM does not need another vendor’s internal design; it needs enough boundary visibility to know what a proposed change could affect and what evidence should be refreshed.
| Controlled boundary | Record in the golden baseline | Ask for on a proposed change | First regression question |
|---|---|---|---|
| Emitter and drive | Wavelength claim, operating mode, safety documentation revision | Changed source, drive setting, pulse behavior, or safety file | Did detection behavior or the documented laser classification change? |
| Receiver and timing | Detector family, timing/processing revision, approved configuration | Detector, timing, or acquisition-algorithm delta | Did bias, invalid-return rate, noise, or depth repeatability move? |
| Optics and window | Lens/window/filter revision and mechanical stack reference | Material, coating, adhesive, alignment, or supplier change | Did field coverage, crosstalk, ambient-light behavior, or edge quality move? |
| Processor and firmware | Firmware hash/version, configuration export, boot and update method | Release notes, default changes, known limits, rollback path | Are output values, invalid markers, timing, and startup behavior unchanged? |
| Power and thermal path | Input requirement, typical load claim, thermal interface and operating limits | Regulator, PCB stack, thermal material, or layout delta | Does the module remain stable across the approved supply and temperature test? |
| Mechanics and interconnect | Drawing revision, mass, connector, pinout, datum, and keep-out area | Dimension, housing, cable, connector, or assembly-process delta | Does it still fit, align, and survive the approved mounted-state test? |
| Interface and data | Protocol revision, frame definition, rate, units, coordinate convention | Schema, timing, transport, SDK, or platform-support delta | Can the golden host capture and replay the same valid data contract? |
Build four linked golden records, not one spreadsheet
A BOM alone cannot prove that two revisions behave the same. Pair it with three other records:
- Golden BOM: the supplier-controlled component or functional-boundary revision, plus approved alternates where disclosure is possible.
- Golden sample: a labeled physical unit with its lot, hardware revision, firmware, configuration, and test date.
- Golden configuration: host software version, interface settings, mounting pose, power setup, and firmware/configuration export.
- Golden dataset: raw or minimally processed outputs from repeatable scenes, including ordinary targets and deliberately difficult cases.
The dataset is what makes a substitution discussion concrete. Use the same target positions, illumination notes, power setup, mount, warm-up procedure, capture duration, and comparison metrics. Purpleriver’s sample datasets page is a useful starting point for requesting data, while the compact dToF evaluation workflow shows how to turn a sample into a bench process.
Why SPAD and optical changes deserve targeted retesting
A 2025 primary study on ranging precision in SPAD-based dToF LiDAR models how dead time and pile-up can reduce information in time-of-flight measurements, and examines photon flux, laser pulse width, and time quantization as operating-point variables. That paper does not report MRP-LD1 performance. Its practical value for an OEM is narrower: a detector, emitter, or timing change should not be treated as a paperwork-only substitution. It should trigger a measurement comparison under the same controlled scenes.
Why laser documentation belongs in change control
The FDA’s current laser products and instruments guidance explains hazard classes and points manufacturers to applicable US records, reports, and performance requirements. For a buyer, the action is to request the class statement and its supporting document revision, then ask whether a source, drive, optic, housing, or firmware change affects that documentation. A module-level Class 1 statement is useful evidence; it is not a substitute for the OEM’s final-system review.
Classify each change before choosing the retest
Do not repeat the entire qualification plan for every label edit, and do not accept a major optical change with a visual check. Use a delta-based decision chart.
| Change class | Examples | Minimum evidence | Disposition |
|---|---|---|---|
| A — documentation only | Typographic correction with no design, process, configuration, or label-scope effect | Redline, reason, affected documents, supplier declaration of no technical change | Document review; update the baseline |
| B — firmware or configuration | Algorithm revision, default change, SDK/parser update | Release notes, rollback image, protocol diff, golden-scene replay | Data-contract and application-threshold regression |
| C — electrical or mechanical | Connector, regulator, PCB, cable, housing, adhesive, or mounting datum | Drawing/BOM delta, fit check, supply/thermal capture, mounted-state comparison | Integration review plus affected environmental tests |
| D — optical or measurement chain | Emitter, SPAD receiver, timing path, lens, filter, cover window, alignment process | Component/process delta, safety-document review, full golden-scene comparison | Reopen affected performance and system-safety approvals |
| Unknown | Supplier will not identify the affected boundary | Written clarification and containment of affected lots | Do not approve the substitution until risk can be bounded |
Use published MRP-LD1 facts as an example baseline
The current Featured product is the MRP-LD1 Drone LiDAR Sensor. The table below repeats only values in the Featured WooCommerce export. It is a starting specification record, not a claim about undisclosed internal component makes or production controls.
| Parameter | Published value | Change-control use |
|---|---|---|
| Ranging / scanning principle | dTOF / SPAD | Flag receiver, timing, and processing changes for depth regression |
| Emitter | 940 nm VCSEL | Link source or optical changes to safety-document and scene retests |
| Laser safety | Class 1 (FDA Recognized Eye-Safe) | Freeze the supporting statement and document revision |
| Range | Indoor 0.5–25 m; outdoor 0.2–8 m | Retest the application’s actual operating band, not only endpoints |
| Published accuracy | 0.2–1 m ≤±3 cm; 1–5 m ≤±5 cm; 5–8 m ≤±10 cm; 8–15 m ≤±20 cm | Use the relevant band when defining acceptance thresholds |
| Ambient-light resistance | 80 Klux | Keep a repeatable bright-scene capture in the regression set |
| Field of view | 60° horizontal × 45° vertical | Recheck coverage after optical, housing, or mounting changes |
| Resolution / frame rate | 40 × 30 / 10 fps | Compare completeness, timing, and application thresholds |
| Interfaces | UART / UVC / UDP | Freeze the chosen transport, parser, and host capture |
| Software support | Windows / ARM / Linux / Android | Record the exact platform, SDK, and tool version used by the OEM |
| Power / weight | 5 V / 1.2 W / 8 g | Recheck the power and mounted-state envelope after relevant revisions |
| Temperature | Operating -20–60°C; storage -30–70°C | Map thermal-path changes to the affected test window |
Application case: control a module revision in a compact perception build
Hypothetical evaluation scenario: a team has approved an MRP-LD1 sample for a compact multirotor obstacle-support prototype and a bench robotics rig. The module’s published 8 g weight, 5 V input, 1.2 W consumption, 60° × 45° field of view, 40 × 30 output, and UART/UVC/UDP options fit the first evaluation. This is a planning example, not a reported customer result.
- The team labels its approved sample and records hardware, firmware, mount, interface, host, and power setup.
- It saves synchronized captures from a flat reference, a stepped target, a dark target, a bright-light scene, and the mounted obstacle scene.
- The supplier later proposes a cover-window material revision. The OEM classifies it as an optical-path change rather than a cosmetic edit.
- The supplier provides the material/coating delta, affected lots, effective date, and statement about laser documentation.
- The OEM repeats field coverage, invalid-return, edge, ambient-light, and application-threshold checks with the new sample against the frozen setup.
- Only after the delta is understood does purchasing update the approved revision or alternate list.
This workflow keeps the decision proportional. It does not assume the revision is harmful, and it does not assume that an unchanged connector means unchanged sensing behavior.
Freeze the interface, data, and host contract
A component baseline is incomplete if the data path is described only as “UART,” “UVC,” or “UDP.” Choose the evaluation path using the UART, UVC, or UDP interface guide, then record what makes a frame usable to your application.
| Data-contract item | Freeze before approval | Regression after a change |
|---|---|---|
| Transport | Physical connection, protocol revision, settings, and startup order | Reconnect, cold start, sustained capture, error recovery |
| Frame identity | Dimensions, rate, payload length, units, and coordinate convention | Schema diff and parser test against saved frames |
| Validity | Invalid markers, confidence/quality meaning, saturation and missing-data behavior | Golden-scene completeness and false-valid comparison |
| Timing | Timestamp source, latency budget, sequence behavior, host time relation | Jitter, dropped/repeated frames, stale-data handling |
| Configuration | Firmware, SDK, configuration file, defaults, and checksums where available | Export comparison, rollback test, release-note review |
| Application handoff | Transform, filtering, threshold, stop/clearance logic owner | Replay through the same downstream decision path |
Store supplier manuals, SDK references, and revision notices beside the baseline. The Purpleriver documentation hub provides the inquiry path for product documents; your project record should still identify the exact files and versions used for approval.
Common mistakes when controlling a solid-state LiDAR BOM
- Freezing only the sales part number: it does not show which optical, electrical, firmware, or process revision produced the approved evidence.
- Demanding a full proprietary teardown: the useful request is change-impact visibility and agreed notification boundaries, not unnecessary supplier IP.
- Treating every change equally: a document correction and an emitter, receiver, optic, or timing change need different evidence.
- Keeping a golden sample without a golden configuration: the unit cannot be reproduced if host software, mount, power, and firmware are unknown.
- Saving screenshots instead of data: screenshots cannot reliably expose timing, invalid-return, schema, or downstream threshold changes.
- Interpreting Class 1 as final-system approval: preserve the module claim and supporting revision while keeping final-system responsibilities explicit.
- Approving a substitution by ideal-target range alone: repeat the application scenes and the failure-prone scenes that mattered during the original approval.
RFQ and change-notification checklist
| Request | What a useful answer contains |
|---|---|
| Configuration identity | Orderable part, hardware revision, firmware, configuration, interface/protocol revision |
| Controlled boundary list | Emitter, receiver/timing, optics, processor, power, mechanics, interconnect, firmware, documents |
| Approved alternates | Known alternate, affected function, prior evidence, and limitations where disclosure permits |
| Change-notification content | Reason, before/after delta, affected lots, effective date, last-order or transition information if applicable |
| Safety-document impact | Whether the change affects the laser class statement, labels, reports, or supporting records |
| Data-contract impact | Protocol, schema, timing, default, SDK, parser, and compatibility changes |
| Regression evidence | Comparable scenes, raw outputs, setup, sample count, metrics, and acceptance decision |
| Containment and rollback | How old/new revisions are identified, separated, traced, and rolled back during evaluation |
| Escalation owners | Named functions for optics, firmware, quality, integration, and commercial coordination |
Turn your component list into a controlled evaluation package
Send the intended platform, operating scenes, interface, range band, change-notification needs, and first regression plan. Purpleriver can then respond against the published MRP-LD1 baseline and the documentation available for your evaluation.
