Supplier qualification for technical buyers
A solid-state LiDAR manufacturer can provide a promising first sample without yet giving a buyer a stable engineering baseline. Before paying for a second sample, a UAV or robotics team should be able to match the sample ID, firmware/build information, test record, interface example, and declared changes to one reviewable evidence packet.
Quick answer
Ask for four things together: the exact sample and document revision, a test record with stated conditions, representative depth or point-cloud data with a field description, and a written notice of anything that changed since the earlier sample. If one part cannot be tied to the same baseline, treat the follow-on sample as a fresh evaluation—not proof that the first result still applies.
Why a second sample needs an engineering baseline
A first sample answers a narrow question: can this particular unit be powered, mounted, and observed in a defined test? A follow-on sample adds a different question: is the buyer still looking at the same engineering baseline, or at an untracked combination of hardware, firmware, optics, and documentation? That distinction matters whenever a program is comparing results across dates, teams, or test locations.
For a technical buyer, “baseline” does not need to mean a heavy certification process. It can be a short, controlled package: sample identifier; hardware and firmware revision; current data-format note; test-record identifier; and a change statement. The point is traceability. A result should be readable later without guessing which unit, settings, target, ambient condition, or output convention produced it.
That approach is consistent with the question behind NIST’s guidance on evaluating and expressing measurement uncertainty: a number becomes more useful when its measurement definition and context are stated. This is not a claim that a module has a particular uncertainty. It is a buyer’s reason to request the conditions and revision attached to a supplier result.
It also prevents a common handoff failure: a data example looks good on one laptop, but its axes, units, timestamps, confidence fields, or parser assumptions are not captured for the team that must continue the work. Start with the project’s acceptance question, then request the evidence needed to reproduce that question.
The four-part supplier evidence decision table
| Evidence part | Ask the manufacturer to identify | What the buyer can decide | What it does not prove |
|---|---|---|---|
| Published specification | Document revision, sample configuration, and the conditions associated with a stated value. | Whether the listed envelope is worth evaluating for the project. | Application-specific usable range, controller behavior, or complete-system safety. |
| Test record | Target type, distance, angle, ambient condition, operating mode, repetitions, result definition, and record revision. | Whether a result can be compared with the buyer’s own planned test. | That the result transfers unchanged to a different target, mount, host, or environment. |
| Data handoff | Representative capture, field dictionary, units, coordinate convention, timestamp behavior, and parser/example revision. | Whether the host team can scope an integration trial. | Native compatibility with an untested SDK, flight stack, middleware, or application. |
| Change notice | What changed, what did not change, affected sample IDs, effective date, and evidence that should be repeated. | Whether sample two may be compared with sample one or needs a fresh test plan. | That a change is harmless without project-specific review. |
The table is intentionally conservative. It keeps an evaluation team from converting a supplier document into a claim the document never made. For broader screening criteria, see our solid-state LiDAR selection scorecard.
MRP-LD1 published facts: turn a listing into questions
The MRP-LD1 Drone LiDAR Sensor product page is the product-fact source for this example. The values below are listed product information, not project acceptance results. They help a buyer form precise questions for the manufacturer and plan an evaluation.
| Listed MRP-LD1 parameter | Published value | Useful follow-on-sample question |
|---|---|---|
| Ranging / scanning principle | dToF / SPAD | Which hardware, firmware, and data-protocol revisions apply to this sample? |
| Illumination | 940 nm VCSEL | Which optical configuration and safety-label revision is represented in the supplied test record? |
| Listed range | Indoor 0.5–25 m; outdoor 0.2–8 m | What target, angle, ambient condition, and result definition accompany the relevant record? |
| Field of view | 60° (H) × 45° (V) | Which mechanical datum and mounting orientation were used when the field was documented? |
| Resolution / frame rate | 40 × 30 at 10 fps | What does each delivered field mean, and how are timing and confidence represented in the chosen output? |
| Interfaces | UART, UVC, UDP | Which interface, format note, example capture, and host-side parser revision belong together? |
| Electrical / mechanical listing | 5 V; 1.2 W; 8 g | Does this sample’s drawing and harness guidance match the evidence packet revision? |
| Operating temperature | -20 to 60 °C | Which listed condition was used for the evidence being reviewed, and what project test remains necessary? |
| Software support | Windows, ARM, Linux, Android | Which documented example and version should the buyer use for a first host trial? |
The page also lists Class 1 (FDA Recognized Eye-Safe) laser safety. A buyer should ask for the current product documentation applicable to the evaluated configuration; that listing should not be stretched into a claim about a complete aircraft, robot, mounting arrangement, or use case.
What a solid-state LiDAR manufacturer should put in a second-sample packet
1. One revision map
Ask for a single page that connects the sample serial or lot identifier, hardware revision, firmware/build identifier, protocol/document revision, and the date supplied. If a field is unavailable, have that limitation stated. A transparent unknown is safer than an assumed match.
2. A context-rich optical evidence record
A useful record names the target and geometry, not simply “passed.” It should say how distance was referenced, how the target was placed, the ambient condition, which output was evaluated, and what result was calculated. The buyer can then decide whether to repeat that case with the intended mounting angle and material. The related quality inspection notes for solid-state LiDAR modules can help frame incoming checks without replacing an application test.
3. A data sample that can be parsed
Request a short representative capture from the selected transport plus a concise field description. Point-cloud handoff deserves particular care: the OGC LAS specification describes an open common format for LiDAR point-cloud interchange. It is a useful reference for asking about data organization, but it does not mean every sensor natively produces LAS. Confirm the actual native output, any conversion step, axes, units, and metadata for this project.
4. A written change notice
For sample two, request a short statement that names any change since the prior sample: hardware, firmware, optical assembly, output fields, calibration procedure, enclosure, or documentation. The goal is not to force a supplier to disclose proprietary design detail. It is to let the buyer decide which acceptance cases must be repeated.
Interface and data handoff: prove the path before promising behavior
MRP-LD1 lists UART, UVC, and UDP. Those are interface options, not a guarantee that every host already understands every payload. First choose the output the program actually needs: a depth image for a quick scene check, point-cloud data for a geometric workflow, or a lower-level transport for an embedded parser. Then ask for the current packet or stream description, a capture from the same revision family, and an example that demonstrates only the claimed handoff.
Use the site’s UART, UVC, or UDP interface guide to compare the transport choices, then validate the actual project path. For a point-cloud review, the point-cloud dataset evaluation guide is a practical companion. Neither guide establishes a driver, message type, latency, or flight-controller compatibility for a specific integration.
A clean handoff test can be modest: power the sample according to its supplied guidance, collect a bounded capture, preserve the sample and document revisions in the file name or test note, decode it with the documented example, and record what fields are present. If the first reader needs undocumented assumptions, stop and resolve the contract before expanding the trial.
Illustrative case: deciding whether a compact-UAV sample can move to test two
Scenario, not a customer result: a small UAV team receives an MRP-LD1 evaluation sample for a planned low-altitude sensing study. The team does not claim obstacle avoidance, altitude hold, or compatibility with its flight controller. It first records the sample ID, the listed 60° × 45° field of view, the selected UART/UVC/UDP path, and the intended bracket orientation.
Before requesting a second unit, the team asks for the revision map, a representative capture, the current format note, and a concise change statement. It repeats only its own defined bench and mounted-data checks against the follow-on sample. If the baseline matches, the team can compare its records carefully. If firmware, payload fields, or the optical configuration differ, it opens a new test entry rather than calling the two results equivalent.
This is a controlled purchasing decision, not a claim that any module will make a UAV safe. The same discipline also applies to robotics, industrial inspection, and AR/VR prototypes: preserve what changed before interpreting what the next test means.
Common mistakes that hide a supplier-baseline problem
- Comparing brochures, not configurations. A listed field of view or range does not identify the revision that produced a supplied data file.
- Accepting a screenshot as a data contract. Ask for a representative capture and enough field information for a second engineer to parse it.
- Assuming “supported platform” means ready-made application compatibility. Treat listed Windows, ARM, Linux, and Android support as a reason to request the relevant current documentation, then test the project host.
- Ignoring a small change notice. A minor-looking firmware or output-field change may alter which project checks must be repeated.
- Turning a module listing into a system-safety conclusion. Keep the sensor evidence, host logic, mounting, environment, and response validation separate.
RFQ checklist: questions to send before sample two
- Please identify the sample ID, hardware revision, firmware/build identifier, and current document/protocol revision.
- Please state whether any optical, hardware, firmware, output, calibration, enclosure, or documentation item changed from the prior sample.
- Please provide a test record relevant to the listed value being reviewed, including target, geometry, ambient condition, output, and result definition.
- Please provide one representative capture and a field/packet description for the selected UART, UVC, or UDP handoff.
- Please identify units, axes, timestamps, confidence or validity fields, and any host-side example relevant to that capture.
- Please identify which listed MRP-LD1 configuration the current product documentation and safety statement apply to.
- Please state what should be repeated by the buyer after a declared change.
- Please confirm the channel for current manuals, SDK resources, sample data, and technical questions.
Build an evidence-first sample request
Purpleriver’s documentation resources and the MRP-LD1 product information can support an evaluation conversation. When you are ready, contact Purpleriver about an evaluation with your platform, working distance, environment, preferred interface, host system, and the evidence you need to review.
