Related Procurement Pages
Jump to
OEM/ODM & customization path for selected devices: align requirements first, then request RFQ for BOM and timelines.
Scope & Delivery Boundaries
What we source & deliver (and what we don’t)
GridRTLS provides the device & data layer for industrial UWB RTLS deployments, serving system integrators and engineering teams who require reliable, integration-ready hardware and clear technical boundaries.
What we provide
- Industrial UWB RTLS hardware: anchors/base stations, tags & wearables, wiring-free beacons, gateways and backhaul accessories.
- Architecture-aware device selection based on target output level (presence / 1D / 2D / multi-floor) and site constraints.
- BOM-oriented quotations aligned with deployment geometry, anchor visibility and communication topology.
- Integration-ready data outputs for customer platforms or third-party RTLS software.
- Documentation packages to support system integration, commissioning and acceptance.
What we do not provide
- No on-site installation, cabling or civil construction.
- No turnkey RTLS platform development or long-term platform operation.
- No end-customer project management or EPC-style delivery.
- No price-comparison or “lowest-cost” factory bidding.
Our role is to help integrators reduce rework, avoid mis-specification, and move from technical requirements to a deliverable RFQ.
Overview
Procurement context, architecture options, and how to proceed
OEM/ODM & Customization on GridRTLS is built for system integrators who need a deployable device & data layer — not for “blank factory bidding”. This page clarifies what can be customized, what inputs we need, and how to keep procurement realistic (cost, lead time, acceptance testing, and integration risk).
In UWB RTLS projects, customization decisions should be made after you confirm two things: (1) your target output level (presence / 1D / 2D / multi-floor), and (2) your communication architecture (wired PoE/Ethernet vs cellular vs gateway relay). Once these are stable, customization can focus on form factor, labeling/private label, deployment workflow, and integration interface alignment.
Customization types we typically support (scope-dependent)
- Branding / private label: logo, nameplate, packaging, quick-start, labeling.
- Device configuration: shipping presets, reporting intervals, identifiers, pairing rules (where supported).
- Mechanical / accessory: mounting accessories, enclosure variants, connectors and cable options (model-dependent).
- Integration alignment: data payload conventions, event fields, device ID rules (integration-facing, not “platform re-build”).
What we do NOT do
- No turnkey on-site installation or construction work.
- No custom “full RTLS platform” development or long-term platform operation.
- No open-ended R&D without defined deliverables, acceptance criteria, and milestones.
To start, use Request an RFQ and mark your request as “Customization” with the scope matrix below. If you want to validate first, request a pilot/sample plan before moving to mass production.
TL;DR
Quick procurement decision points
- Customization should be defined after output level + architecture are confirmed (avoid re-quoting).
- We support private label and selected firmware/config alignment — scope depends on device model
- “OEM/ODM” here means deliverable-focused customization with acceptance criteria, not open-ended R&D.
- Any customization can impact MOQ, lead time, and validation steps; plan a pilot stage.
- Specify integration targets early: device IDs, event fields, payload conventions, and your ingestion pipeline.
- Mechanical changes usually require tooling considerations; treat them as a separate milestone
- If your project includes indoor/outdoor transitions, define how UWB and GNSS/Beidou behaviors should switch.
- If the site cannot access public networks, confirm gateway relay vs local server constraints before any customization.
- For procurement, request deliverables: BOM-oriented quote + documentation pack + acceptance checklist (not just price).
- Keep boundaries clear: we deliver device & data layer + integration-ready outputs; SI handles on-site delivery and platform ops.
Process
A spec-first flow designed for real deployment
1 Confirm Output Level & Acceptance Criteria
Define whether you need presence / 1D / 2D / multi-floor and what “acceptable performance” means in your site conditions. This prevents customization from chasing the wrong target.
2 Lock Communication Architecture
Confirm wired PoE/Ethernet vs cellular vs gateway relay and whether public network access is allowed. Architecture choices affect device selection and integration assumptions.
3 Select Customization Scope (Use the Matrix)
Choose from branding/private label, configuration presets, mechanical/accessory changes, and integration alignment. Keep scope measurable and tied to deliverables.
4 Provide Integration Constraints
Share your integration endpoint expectations: device ID format, event fields, payload naming conventions, and required outputs (raw position, events, or both).
5 Prototype / Sample & Validation
Validate with sample or pilot units. Confirm geometry coverage, NLOS behavior, update rate, and integration parsing before scale-up.
6 Freeze BOM + Compliance Pack
Once pilot passes, freeze the BOM and confirm which documents are required (datasheet, integration docs, test reports if needed, acceptance checklist).
7 Production & Change Control
Start production with version control: hardware revision, firmware version, and packaging/label version. Any change after freeze triggers a controlled re-validation.
Checklists
Use these to avoid missing RFQ inputs and re-quoting
Customization Scope Matrix (Select What You Need)
- Private label: logo / nameplate / packaging / quick-start
- Device identifiers: ID rules / MAC mapping / QR labels
- Shipping presets: reporting interval / power mode / region config (if applicable)
- Mounting accessories: brackets / magnets / cable options (model-dependent)
- Mechanical changes: enclosure variant / connector relocation (tooling milestone)
- Integration alignment: payload field naming / event definitions / timestamp rules
- Special environments: hazardous-area requirement (intrinsically safe / explosion-proof, model-dependent)
- Indoor–outdoor: UWB + GNSS/Beidou switching expectations (if needed)
What We Need From You (To Quote Customization Correctly)
- Target output level (presence / 1D / 2D / multi-floor)
- Architecture: wired vs cellular vs gateway relay (public network allowed?)
- Intended device types and quantities (anchors/tags/wearables/gateway)
- Branding assets: logo files, label text, packaging references
- Integration target: where data goes (your server/platform), required fields
- Acceptance criteria: what tests prove “ready for deployment”
- Timeline: pilot date, production target date, shipping destination
What You Receive (Customization Deliverables)
- Defined customization scope and version plan
- BOM-oriented quotation reflecting customization scope
- Pilot/sample plan and validation checklist
- Integration-facing documentation (payload conventions, ID rules)
- Packaging/label specification for private label
- Change control notes (what triggers re-validation)
FAQ
Answers procurement teams ask before RFQ
What is the difference between OEM and ODM in your context?
OEM/ODM refers to deliverable-focused customization of the device & data layer (branding, configuration, selected firmware/mechanical scope). It does not mean turnkey RTLS platform development or open-ended R&D without acceptance criteria.
Can you do private label / white label?
Yes, private label is typically feasible: logo, label, packaging and documentation branding. Final feasibility depends on the device model and packaging scope.
Can you modify firmware or data payload fields?
We can align selected configuration and payload conventions where supported, especially for integration clarity (IDs, field naming, event definitions). Scope must be defined and tested during pilot.
Will customization affect MOQ and lead time?
Usually yes. Any customization can impact production scheduling and validation steps. MOQ/lead time are confirmed after scope is frozen.
I only need a small change. Do I still need a pilot?
For branding-only changes, a pilot may be optional. For anything affecting device configuration, mechanical parts, or integration behavior, a pilot is strongly recommended to prevent deployment risk.
Can you build a complete RTLS software platform for us?
No. GridRTLS focuses on device & data layer procurement and integration-ready outputs. Platform development and long-term operation should be handled by the SI or platform partner.
Our site cannot access public networks. Can we still proceed?
Yes, but you must confirm gateway relay / local server requirements early. Architecture constraints should be locked before customization scope is finalized.
Can you guarantee accuracy after customization?
Accuracy depends primarily on geometry, anchor visibility, and site conditions (NLOS, metal, machinery). Customization does not replace deployment design and acceptance testing.
Can we customize mounting accessories or enclosures?
Mounting/accessory changes are often possible (model-dependent). Enclosure changes may involve tooling and should be treated as a separate milestone with validation.
What documentation is included for customized orders?
Typical deliverables include BOM-oriented quote, integration notes, and acceptance checklist. Additional documents depend on model and project requirements.
What do you need from us to start customization?
Output level + architecture constraints, device types/quantities, branding assets, integration expectations, and acceptance criteria. Without these, customization often leads to re-quoting.
How do we control changes after production starts?
We recommend version control (hardware/firmware/packaging) and change control. Any scope change after BOM freeze triggers a re-validation plan.