Technical buying guide
SPAD LiDAR Sensor Sample Buy: An RFQ-to-Bench Evidence Plan
A SPAD LiDAR sensor sample buy is most useful when the RFQ, receiving record, and first bench test answer the same question: can this module produce the documented data on the intended host and in a representative scene? Do not use one promising depth image as a deployment decision. Define the evidence you need before the sample ships, then preserve the conditions that produced it.
This guide gives an embedded-perception lead a practical path from a sample request to a reviewable first evaluation. It uses the MRP-LD1 only as an exported product example; the host, mounting, perception logic, planning, and final system validation remain the buyer’s responsibility.
Quick answer
Send an RFQ that names the target platform, expected working-distance band, lighting and target conditions, host operating system, preferred interface, requested output, and evaluation timing. When the sample arrives, record the delivered revision, accessories, power arrangement, host setup, interface configuration, scene conditions, raw outputs, and observed limitations. Then review the evidence against the question you actually need to answer—not against an assumed range or a marketing image.
What a SPAD LiDAR sensor sample buy should prove—and what it should not
A sample is an opportunity to reduce uncertainty, not a shortcut around system engineering. For a direct time-of-flight (dToF) module, the useful first question is usually narrow: “Can our host receive and preserve the documented output while we exercise representative scene conditions?” The next question is whether the observed behavior is enough to justify a larger, application-specific validation plan.
That distinction matters because SPAD dToF measurement is affected by scene and signal conditions. A recent peer-reviewed review of SPAD-array dToF LiDAR explains that background light, target reflectivity, incidence angle, timing behavior, and signal-processing choices can influence a measurement. That is why a useful sample plan deliberately records target material and geometry, lighting, mounting, and capture settings. It does not imply that one bench result predicts every outdoor, moving, or production scenario.
Begin with the intended use boundary. A UAV team might be checking whether a compact module can provide a depth-data input for a controlled prototype. A mobile-robot team might be checking whether a host can acquire data through its chosen interface. An inspection team might be checking whether a documented target set can be retained with the source data. These are valid early questions; none alone proves navigation, obstacle avoidance, mapping quality, safety, or regulatory fitness.
For a broader pre-order question set, compare this plan with the site’s LiDAR module evaluation-sample checklist. Keep the final RFQ specific to the project rather than copying a generic list.
Use an RFQ-to-bench decision chart
| Stage | Question to resolve | Evidence to keep | Decision it can support |
|---|---|---|---|
| RFQ scope | What platform, host, interface, scene, and output are being evaluated? | Written use case, host OS, interface preference, distance band, scene notes, requested files/documents | Whether the requested sample is aligned with the real prototype question |
| Receiving record | What exactly arrived, and what was connected? | Module identifier/revision if supplied, accessory list, photos, power arrangement, cable/interface path | Whether later observations can be traced to the tested configuration |
| First data path | Can the stated host receive the expected output without an undocumented conversion? | Host version, driver/SDK version where supplied, configuration, raw sample file, timestamp or capture index | Whether interface bring-up is ready for scene testing |
| Representative scene check | What changes when material, angle, distance band, or ambient conditions change? | Scene log, target description, mounting notes, raw output, and an observation log | Whether to expand, revise, or stop the evaluation plan |
| Technical review | What remains unknown before vehicle or process integration? | Pass/concern/open-question list tied to the retained record | Whether an application-specific validation phase is justified |
The chart is deliberately evidence-focused. It does not assign universal pass thresholds, because those thresholds depend on the platform, risk assessment, target scene, response logic, and project owner. A team should set its own acceptance and abort rules before testing.
Documented MRP-LD1 facts to check during sample planning
The Featured product in this run is the MRP-LD1 Drone LiDAR Sensor. The table below repeats exported product facts that can help frame an evaluation request. They are not a prediction of the result in your installation.
| Exported field | Documented value | Evaluation implication |
|---|---|---|
| Architecture | Solid-state SPAD dToF LiDAR | Ask which data output and host path the first test will retain. |
| Depth/point-cloud output | Real-time depth images and 3D point-cloud data | Define the raw output you need to archive and how a reviewer will open it. |
| Resolution and frame rate | 40 × 30; 10 fps | State whether that output format and cadence fit the proposed host-side experiment. |
| Field of view | 60° horizontal × 45° vertical | Sketch the proposed mounting and keep coverage questions separate from a full-system claim. |
| Interfaces | UART, UVC, UDP | Declare the preferred path and the host that will receive it before the sample is sent. |
| Software support | Windows, ARM, Linux, Android | Identify the exact host environment and any SDK/document request in the RFQ. |
| Size/power facts | 8 g; 1.2 W; 5 V supply | Record the proposed power and mounting arrangement rather than assuming vehicle readiness. |
| Exported operating baselines | 0.5–25 m indoors; 0.2–8 m outdoors; 80 Klux ambient-light resistance | Write the actual distance band, target, angle, and illumination in the test record; validate the intended scene. |
The product page also identifies UAV obstacle avoidance and altitude hold, robot navigation and obstacle avoidance, AR/VR auxiliary focusing, and industrial inspection/security as evaluation application groups. It explicitly does not turn the module into a complete obstacle-avoidance system: the host processor, perception logic, planning, controller, and validated response are separate responsibilities. For a scene-specific range discussion, see the site’s MRP-LD1 indoor/outdoor range validation guide.
Application case: a warehouse AMR proof of concept
Imagine a small team exploring a mobile robot that must identify aisle-end fixtures during a supervised proof of concept. The right initial sample question is not “Will this sensor make the robot safe?” Instead, the team asks: “Can our Linux host acquire and retain the depth or point-cloud output through the selected interface while the module views the material and lighting conditions we plan to model next?”
The RFQ names the host, proposed mounting zone, interface preference, approximate working-distance band, aisle materials, and whether the team needs depth images, point-cloud output, or both. At receiving, the team records the supplied items and connection path. On the bench, it captures a small set of repeatable scenes: a matte carton, a darker surface, and a reflective fixture at controlled positions, with scene notes rather than a blanket performance verdict.
Each retained capture carries a configuration note and a review outcome: observed, needs follow-up, or outside scope. Only after the evidence is reviewed does the team decide whether to define a controlled mobile test. This prevents a successful static demo from being mistaken for validated navigation behavior.
Interface, data, and integration handoff
Choose the first interface based on the host’s real constraints, not on the shortest cable on the bench. The exported MRP-LD1 options are UART, UVC, and UDP. The first sample record should state which path was used, the host operating system, the power arrangement, the configuration used, and what raw data was retained. The site’s guide to UART, UVC, and UDP selection is a useful starting point for aligning that choice with integration scope.
Retain source data before making visualization or filtering choices. Add a plain-language note for units, coordinate convention if known, capture order/timestamp, scene conditions, and any transformation used for review. A rendered image can help a discussion, but it is not a substitute for the source capture and a reproducible record. The site’s point-cloud dataset evaluation guide can help structure that handoff.
For UAV prototypes, record the boundary between the sensor and the controller explicitly. The LiDAR sensor-to-flight-controller data-contract guide is relevant when a project moves from a host-side sample review to a defined downstream interface. It does not replace vehicle-specific safety, control, or flight validation.
Ask for laser documentation; do not infer a compliance result
When a project needs laser-classification information, ask the supplier for the model-specific label, applicable classification/certification documentation, and the conditions under which the statement applies. The MRP-LD1 export labels the product as Class 1 (FDA recognized), but a buyer should still keep the actual documentation with the project record and confirm applicability with the responsible compliance team.
The FDA’s Laser Notice No. 56 describes labeling, certification, testing, and documentation expectations for relevant laser products. It supports asking for documentation; it does not make this article a legal opinion, a classification test, or a finding of product compliance.
Common sample-evaluation mistakes
- Ordering without a scene definition. “Test it outdoors” is not a scene. Record target material, distance band, angle, ambient conditions, mounting, and motion assumptions.
- Choosing an interface after delivery. The host, connection path, and raw-output expectation belong in the RFQ.
- Saving screenshots but not source data. Keep the original output and the configuration/scene notes required to interpret it.
- Turning one observation into a universal claim. A sample test can guide the next evaluation stage; it does not establish range, accuracy, safety, or application performance in every condition.
- Confusing a module with a complete system. Perception, planning, control, and validated response need their own engineering and test evidence.
- Assuming a laser label resolves every project obligation. Preserve model-specific documentation and involve the appropriate compliance owner for the final application.
RFQ and first-bench checklist
| Before requesting a sample | Before expanding the test |
|---|---|
| Name the platform, use case, host OS, working-distance band, and indoor/outdoor context. | Review whether retained data and scene notes answer the original question. |
| State the preferred interface and requested output: depth, point cloud, or both. | List unresolved target, lighting, mounting, motion, and parsing questions. |
| Ask for the applicable documentation, setup resources, and sample-data expectations. | Set project-specific pass, concern, and abort criteria before a vehicle or process test. |
| Plan how the delivery, accessories, power, and cabling will be recorded at receiving. | Keep the source captures, host/configuration record, and review decision together. |
Make the sample request technically reviewable
When you contact Purpleriver about an MRP-LD1 evaluation, include the target platform, application, intended working distance, scene, host system, preferred interface, sample quantity, and expected project timing. Ask for the documents and source-data path your engineering review actually needs.
SPAD LiDAR sample-buy FAQ
What should I include in a SPAD LiDAR sample RFQ?
Include the target platform, application, distance band, indoor/outdoor context, target/lighting conditions to be evaluated, host operating system, preferred interface, requested output, sample quantity, and project timing. Also ask for the documentation needed for the review.
Does a successful bench result prove an obstacle-avoidance system?
No. A module can provide sensor data for evaluation, but perception, planning, controller behavior, vehicle integration, and validated response remain separate system responsibilities.
Why should I record target material and ambient conditions?
SPAD dToF behavior can be influenced by scene and signal conditions. Recording the material, geometry, angle, and illumination makes the observation interpretable and repeatable.
Can I use the published range as my project acceptance threshold?
No. Use exported ranges as a documented baseline for planning. Define your own project-specific acceptance criteria and test the actual scene, target, mounting, motion, and host configuration.
Which MRP-LD1 interface should a first evaluation use?
The exported options are UART, UVC, and UDP. Choose the path your intended host can receive and document, then record the exact configuration used during the evaluation.
What data should we retain from the first sample test?
Keep the source output, host and configuration record, capture order or timestamps, scene notes, target description, mounting/power notes, and a concise observation log.
What laser-related documents should a buyer request?
Request the applicable model-specific label and classification/certification documentation, plus the conditions for the statement. Have the responsible compliance team assess applicability to the final product and market.
When should the team move from a bench to an application test?
Move forward only after the retained sample evidence answers the original host-and-scene question and the team has set application-specific success, concern, and abort criteria.
