A sample that draws a dot on a map does not by itself establish suitability for your deployment. A buyer still needs to compare the sample with the written requirements, intended vehicle or asset, receiving platform and destination-market documents. This guide is written for Telematics providers, fleet-technology companies, GPS/IoT distributors, system integrators and project buyers — not end consumers — as a checklist for that review before a volume decision.
Why "the sample can locate" is not the same as "ready for volume"
A sample that draws a dot on a map shows one observed location event in that setup. It does not by itself establish long-term behavior, vehicle or asset suitability, platform field mapping, or production consistency.
What a bench demo does not prove:
- thermal behavior in the intended enclosure and mounting position;
- cellular behavior on the destination operator and network used for the project;
- the real battery curve under your reporting interval, not the vendor's best-case setting;
- firmware and configuration consistency across the production quantity;
- survival in your actual install environment (vibration, moisture, ignition noise).
A bench or supplier demonstration is one input. The buyer, platform owner, supplier and qualified test provider should assign the remaining checks before committing cash and lead time.
Fix the requirements before you ask for a sample
A sample cannot be "validated" against a spec you have not written. Before any RFQ, lock the actual deployment parameters:
- Asset type — vehicle, trailer, generator, excavator, container, mixed fleet
- Install location — inside cab, engine-bay-adjacent, outdoor IP67, buried in a housing
- Power source — hardwired 12/24V, battery-only, external supply
- Reporting interval — every 30s, 5min, 1h, adaptive on movement
- Destination connectivity — the operator, network, radio technology and bands for the destination country, exact device variant and rollout plan
- Required inputs — only the signals and interfaces the workflow needs; distinguish vehicle-bus data from a physical sensor (fuel may use bus data)
- Platform / API — what your backend actually accepts
- Applicable conformity documents — exact model, radio variant and destination market
- Operating temperature & IP rating — matched to the real environment
Send the same requirement summary to each candidate so their responses can be compared against the same project conditions.
What to check, item by item
LTE bands
Confirm the exact device variant, destination operator and network technology, and obtain the supported bands and coverage conditions for the intended rollout. A regional band list alone does not establish compatibility.
Power
Verify the exact model's input range, sleep draw and protection against the vehicle or asset power conditions. Confirm the result on the intended installation. For vehicle and truck power setups, see our truck tracker notes.
Battery (battery-powered units)
Capacity on paper is not runtime. Ask for the curve at your reporting interval, sleep behavior when stationary, whether it is rechargeable or primary cell, and temperature limits. Do not accept a runtime claim without the conditions attached.
Interface
For machinery, identify only the interfaces the requirements need, confirm they are present on the exact variant and request a current protocol document.
Sensors
For each required input, identify whether it comes from the vehicle bus, a physical sensor or another interface. Confirm the source, wiring or protocol and the receiving field on the exact variant.
Install environment
Ask for test evidence covering the exact model and configuration for ingress protection and match operating temperature to the intended environment. See how install environment drives equipment tracker selection.
Protocol documents: what to actually read
Do not trust a bullet point that says "supports platform X." Read for:
- the transport your platform accepts (MQTT / HTTP / TCP / proprietary);
- a current integration or payload-format document;
- whether device ID registration, data flow, and field mapping are documented end to end.
Compare how fleet platforms accept tracker data.
"Supports your platform" must be verified, not assumed
The buyer or platform owner should run a live or sandbox check: device registration, data flow and field mapping against the intended schema. Ask the supplier for the current protocol and test access needed for that review.
Record the firmware version — and lock it
Record the exact firmware version and build on the reviewed sample. Ask the supplier to state the production version in the purchase order, with any difference documented and re-tested before shipment.
Sample-to-production consistency
Ask which sample type was reviewed and how production changes will be controlled. Choose production samples when the project risk calls for them. Request written confirmation of the agreed configuration, firmware and test criteria.
Certifications: check the file, not the screenshot
Ask for conformity documents identifying the exact model and radio variant. For EU radio equipment, request the manufacturer’s EU Declaration of Conformity. Check which requirements and product configuration the documents cover; ask for notified-body details where that assessment route applies. A sales image of a mark cannot replace this document check.
What to test on a real vehicle or asset
The customer or qualified test provider should install the exact configuration in the intended environment and define the duration and observations with the supplier and platform owner. Possible checks include:
- cold start and time-to-first-fix;
- tunnel / underground garage GNSS loss and reacquisition;
- buffering and upload of records successfully acquired during a cellular-only outage;
- reporting-interval stability over time;
- battery under real use;
- tamper / disconnect behavior.
Record who performed each check, the configuration, conditions and evidence retained.
When to qualify a second supplier
A buyer may qualify a second source when the project risk review identifies a need, for example:
- the first cannot produce cert files on request;
- firmware drifts between sample and production;
- sample-to-production mismatch appears;
- price, lead-time or continuity needs require comparison.
Document the reason for any second-source decision and the conditions that remain open.
Pre-bulk written confirmations to require from the supplier
Put these in writing before the bulk PO:
- exact model, BOM, and firmware version;
- applicable conformity documents for the exact model and target market;
- sample-to-production consistency statement;
- warranty and RMA terms;
- lead time and volume-tier pricing;
- ownership and delivery terms for any custom firmware or configuration;
- the test evidence and platform responsibility agreed for your project.
The role of a sourcing and validation partner
LEXUNYU helps with hardware sourcing and procurement coordination. We help Telematics providers, distributors and integrators explain requirements to Shenzhen suppliers, compare documents and quotes, coordinate samples and clarify open questions. Agree who will perform each test: the buyer or test provider records results, the platform owner checks received data, and the manufacturer supplies conformity documents. See how we compare China GPS tracker suppliers.
Sample Validation Checklist
| # | Check item | Pass / Fail | Evidence to keep |
|---|---|---|---|
| 1 | Requirements spec written before RFQ (asset, install, power, interval, bands, sensors, platform, certs, temp/IP) | ☐ | RFQ document |
| 2 | Destination operator, network, radio technology and bands match the exact device variant and rollout | ☐ | Operator check + variant band document |
| 3 | Exact-model power input and quiescent draw verified against the intended asset | ☐ | Test log |
| 4 | Battery runtime measured at your interval (not vendor best-case) | ☐ | Battery curve |
| 5 | Only required interfaces and inputs are confirmed on the exact variant; current protocol doc available | ☐ | Protocol PDF + source mapping |
| 6 | Each required input source is confirmed (vehicle bus, physical sensor or other interface) | ☐ | Wiring / protocol evidence |
| 7 | Ingress protection evidence for the exact model and configuration and operating temperature match the intended environment | ☐ | Test evidence |
| 8 | Buyer or platform owner verifies registration, data flow and field mapping for the intended platform | ☐ | Test session notes |
| 9 | Firmware version recorded; PO requires same/retested version on production | ☐ | Version string + PO clause |
| 10 | Sample type and need for production-sample review are agreed with the supplier | ☐ | Sample record |
| 11 | Supplier states the agreed BOM, firmware and test criteria for production | ☐ | Written confirmation |
| 12 | Applicable conformity documents obtained for exact model, variant and market | ☐ | Document set |
| 13 | Customer or qualified test provider records the agreed real-environment checks | ☐ | Field test report |
| 14 | Second supplier qualified (or risk accepted in writing) | ☐ | 2nd-source file |
| 15 | Pre-bulk written confirmations record model/BOM/fw/documents/warranty/lead time/custom terms and test responsibility | ☐ | Signed PO + annex |
Before you shortlist a supplier, send us your deployment spec. We help Telematics and fleet-technology teams compare Shenzhen sources, coordinate documents, quotes, samples and open questions, and keep platform and conformity checks assigned to the responsible parties — then you decide.