Hybrid positioning terminals that fuse UWB + GNSS RTK (optional IMU) for accurate indoor-outdoor tracking. Built for industrial integrators.
GridRTLS supplies fusion positioning terminals designed to bridge
indoor UWB positioning and outdoor GNSS-based location into a continuous, usable data stream.
This category focuses on where and how positioning data is fused and output,
not on anchor deployment or platform logic.
In hybrid indoor–outdoor projects, the challenge is rarely sensor availability,
but how positioning sources are combined and delivered in a predictable way.
Fusion terminals act as the boundary device between positioning sources
(UWB, GNSS, inertial inputs) and the customer’s platform.
The goal is not “perfect fusion”, but stable handover, clear data ownership,
and well-defined output behavior so downstream systems can make reliable decisions.
We primarily work with system integrators and engineering teams
building hybrid positioning systems across factories, yards, tunnels, ports,
and large infrastructure sites where indoor and outdoor positioning must coexist.
If your project requires continuous positioning across indoor and outdoor zones,
this page is intended to help you define fusion responsibility, data outputs,
and RFQ inputs, and move toward an RFQ-ready fusion terminal configuration.
Fusion behavior is defined at the terminal level, avoiding ambiguity between device, gateway, and platform responsibilities.
Designed to support predictable handover between UWB and GNSS zones rather than continuous re-calculation.
Outputs are structured for third-party RTLS or location platforms without locking customers into a specific stack.
Supports simultaneous UWB and GNSS inputs without unstable switching behavior.
Configuration remains consistent across multiple terminals in large sites.
Specify whether the terminal outputs raw sources, fused position, or normalized events.
Define how and where transitions occur (zones, triggers, confidence thresholds).
Coordinate system, timestamps, update rate, and event definitions.
Acceptable delay during handover impacts fusion strategy and buffering.
Protocol, data schema, and downstream platform expectations.
Indoor/outdoor placement, temperature range, vibration, enclosure requirements.
Number of terminals and how configuration is replicated across deployments.
For fusion positioning terminals, customization usually focuses on
data behavior and interface alignment rather than physical form.
We recommend fixing fusion responsibility early and keeping customization
limited to parameters that do not affect system stability.
OEM/ODM scope may include interface definitions, output filtering,
enclosure adjustments, and controlled firmware parameters.
Deep fusion-logic changes should be confirmed early, as they directly affect
system validation and long-term maintainability.
Field definitions, coordinate system, event structure.
Transition thresholds, confidence rules
TCP/UDP/MQTT or custom protocol alignment
Indoor/outdoor installation requirements
Alignment of UWB and GNSS timestamps
Consistent rollout across multiple terminals
Fusion positioning terminals should be treated as system boundary components.
They define where sensor data becomes positioning output, but do not replace
the customer’s platform logic.
Common solution patterns where this category is typically used.
Where this category is most commonly deployed.
Evidence that matters to SI teams: how we lock BOMs, keep batch consistency, and ship integration-ready hardware.
pcat_factory_photos to show real installation proof.
Indoor/outdoor installation and temperature range confirmation.
Designed for industrial electromagnetic environments.
Acceptable clock drift and alignment limits defined per project.
Batch traceability supports efficient replacement.
It defines how multiple positioning sources are combined and delivered, without owning platform logic.
It can output fused data or normalized events, depending on project definition.
The terminal handles boundary-level fusion; platform handles business logic.
Based on predefined triggers and confidence thresholds agreed at RFQ stage.
No. GNSS/RTK is used when outdoor accuracy and continuity require it.
Fusion adds minimal latency when properly configured; acceptable limits should be defined early.
Yes. Interfaces are designed for platform-agnostic integration.
Configuration presets and batch control keep fusion logic consistent.
Clarify fusion responsibility, output format, and transition behavior before RFQ.<br /> This helps SI teams lock fusion terminal configuration early and avoid redesign later.<br />
Share your site layout and accuracy needs--we'll suggest a practical setup.