Jump to
Submit an RFQ with site constraints and target output level. This page is designed to prevent re-quoting and missing inputs.
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
This RFQ page is designed to prevent re-quoting. UWB RTLS procurement fails most often not because of price, but because key constraints are missing: output level, site layout, anchor visibility conditions, and communication architecture.
GridRTLS provides the device & data layer for system integrators and engineering teams: anchors/beacons, tags/wearables, gateways/backhaul accessories, and integration-ready outputs. We do not provide on-site installation or turnkey platform development.
How to get an accurate quote (fast)
- Choose your target output level: presence / 1D / 2D / multi-floor.
- Confirm architecture constraints: wired PoE/Ethernet vs cellular vs gateway relay (public network allowed?).
- Provide quantities by device type (anchors, tags/wearables, beacons, gateway accessories).
- Attach a floor plan if available (PDF/CAD). If not, provide site dimensions and ceiling height.
If you need OEM/ODM or customization, mark it clearly and reference the required scope (branding / configuration presets / mechanical / integration alignment). We will quote based on deliverables, not vague commitments.
TL;DR
Quick procurement decision points
- RFQ should start from output level + architecture constraints, not from “accuracy marketing claims.”
- Floor plan (or at least site dimensions + ceiling height) reduces risk and speeds BOM estimation.
- For 2D positioning, anchor geometry and tag visibility are critical; NLOS and metal environments must be considered.
- Choose backhaul: wired PoE/Ethernet, cellular (4G/5G), or gateway relay when public network access is restricted.
- Provide quantity ranges per device type (anchors / wearables / beacons / gateways) — it affects production planning.
- Specify integration target: what data format / events your platform expects.
- If you require pilot first, define pilot zones and success criteria.
- If customization is required, define scope and acceptance criteria upfront to avoid re-quoting.
Process
A spec-first flow designed for real deployment
1 Confirm Output Level
Specify whether you need presence detection, 1D corridor tracking, 2D positioning, or multi-floor. This determines minimum infrastructure assumptions and BOM sizing.
2 Lock Communication Architecture
Choose wired PoE/Ethernet, cellular (4G/5G), or gateway relay (if public network is not allowed). This affects device selection and integration assumptions.
3 Provide Site Constraints
Share floor plan (preferred). If unavailable, provide site dimensions, ceiling height, and key zones (hazard zones, restricted areas, tunnels/corridors).
4 Provide Quantities by Device Type
Provide quantity range for anchors/base stations, tags/wearables, beacons, gateway accessories, and any terminals. Mention pilot quantity vs production quantity if applicable.
5 Define Integration Output
Tell us what your platform expects: raw positions, events, or both. Share device ID rules and any required fields.
6 Confirm Deliverables & Timeline
Confirm your expected deliverables (BOM-oriented quote + documentation pack + acceptance checklist) and target delivery window (pilot date / production window).
Checklists
Use these to avoid missing RFQ inputs and re-quoting
RFQ Inputs (Send These for an Accurate Quote)
- Target output level: presence / 1D / 2D / multi-floor
- Site layout: floor plan (CAD/PDF) or site dimensions
- Ceiling height + mounting constraints (wall/ceiling/pole)
- Environment notes: metal density, machinery, tunnels/corridors, NLOS concerns
- Architecture constraint: wired PoE/Ethernet available? cellular allowed? gateway relay required?
- Device list + quantity range: anchors/base stations, tags/wearables, beacons, gateway accessories
- Update rate expectation (slow people tracking vs fast vehicle safety)
- Indoor/outdoor boundary requirement (hybrid/fusion needed?)
- Integration target: platform type + required outputs (raw positions/events)
- Timeline: pilot start date + production target window
- Any hazardous-area compliance requirement (if applicable)
Pilot / Evaluation Plan (If You Want a Proof Before Production)
- Pilot area definition: which zones and approximate area size
- Success criteria: coverage, update rate, event logic, integration output format
- Pilot quantity: how many anchors and tags/wearables
- Validation steps: site survey, calibration/commissioning checklist, acceptance checklist
- Timeline: pilot delivery date and evaluation duration
- Who performs on-site work: SI/partner team (GridRTLS does not do on-site construction)
Customization Flag (If OEM/ODM Is Needed)
- Branding/private label (logo, label, packaging)
- Device configuration presets (IDs, reporting intervals, region settings if applicable)
- Mechanical/accessory changes (mounting accessories, connectors; tooling milestone if needed)
- Integration alignment (payload fields, naming conventions, event definitions)
- Acceptance criteria for customization (what proves “done”)
- Change control plan (how to handle revisions after BOM freeze)
RFQ Inputs
Recommended fields to speed up quoting
- Target output level (presence / 1D / 2D / multi-floor) (required)
- Site layout or floor plan (if available)
- Indoor / outdoor or hybrid requirement (required)
- Preferred communication architecture (wired PoE / cellular / gateway)
- Estimated quantity per device type (required)
- Integration platform or RTLS software
What You Will Receive
Deliverables beyond “just a quote”
- Recommended device configuration & architecture
- BOM-oriented quotation
- Integration and deployment notes
- Acceptance checklist
RFQ Form
Paste your form shortcode into ACF if needed
FAQ
Answers procurement teams ask before RFQ
What is the fastest way to get an accurate RFQ response?
Provide output level + architecture constraints + quantity ranges. A floor plan (CAD/PDF) accelerates anchor layout estimation and reduces re-quoting.
Do I need a floor plan to get a quote?
It’s recommended but not mandatory. If you don’t have one, provide site dimensions, ceiling height, and key zones. A floor plan is required for accurate layout and pilot planning.
What architecture options can you quote?
We can align device selection and quotation for wired PoE/Ethernet deployments, cellular backhaul scenarios, and gateway relay architectures (when public network access is restricted).
What should I submit for quantity?
Provide quantity range by device type: anchors/base stations, tags/wearables, wiring-free beacons, gateway accessories, and any terminals. Separate pilot quantity and production quantity if applicable.
We only need zone entry/exit, not precise coordinates. Can we reduce cost?
Yes. Presence detection or simpler output levels may reduce infrastructure requirements. Specify your output level so the BOM matches your real needs.
Can you guarantee accuracy from RFQ alone?
No. UWB RTLS performance depends on geometry, anchor visibility, and site conditions (NLOS, metal, machinery). RFQ provides a BOM-oriented path; pilot validation confirms real performance.
Our site can’t access the public network. Is that a problem?
Not necessarily. Confirm whether you need gateway relay to a local server/cloud server. This must be clarified early because it affects architecture and device selection.
What integration information do you need?
Tell us whether you need raw positions, events, or both; what ID format your platform uses; and any required fields. This reduces integration ambiguity.
Do you provide on-site installation or civil work?
No. GridRTLS provides device & data layer sourcing and integration-ready outputs. On-site installation and construction are handled by the SI/partner team.
What deliverables should I expect after RFQ?
Typically: recommended device configuration & architecture, BOM-oriented quotation, integration/deployment notes, and acceptance checklist (scope-dependent).
Can I start with a pilot before mass production?
Yes. Define pilot zones, success criteria, pilot quantities, and timeline. A pilot helps confirm coverage and integration before production scale-up.
If I need OEM/ODM or customization, what should I include in RFQ?
Mark it clearly and specify scope (branding / configuration presets / mechanical / integration alignment) plus acceptance criteria. Undefined customization usually causes re-quoting.
Do you quote “turnkey RTLS platform + hardware”?
No. Our focus is the device & data layer for integrators. Platform development and long-term operation are outside scope.