Direct answer: Evaluate an RFID sled when the project intentionally separates a host device from the UHF reader and can manage their connection, charging and application responsibilities. Evaluate an integrated RFID mobile computer when one approved device configuration should carry the mobile application and RFID workflow. Confirm host, handle and regional differences before choosing either direction.
Who is this guide for, and what does it decide?
This guide is for RFID solution teams, software companies and integrators comparing the AIDC GO SX sled direction with RX RFID mobile computer directions. It focuses on architecture and deployment rather than unsupported read-range or throughput claims.
An integrated label does not mean every capability is identical across models or configurations. A sled does not guarantee compatibility with any host. Approved configuration, host or UHF-handle differences, interfaces, region and application support must be confirmed for the project. The comparison also does not imply a universal charging, accessory or lifecycle advantage; record those dependencies for the exact evaluated system and preserve them in the final acceptance record.
Decision guide
| Decision area | Direction or question | Evidence to confirm |
|---|---|---|
| System composition | Reader accessory plus a separately approved host device. | Mobile computer with RFID capability in an approved integrated configuration. |
| Application location | Usually on the host, with an explicit reader connection and event handoff. | On the integrated mobile computer, subject to the approved configuration. |
| Dependency | Host fit, connection, charging and lifecycle are part of the solution. | One device lifecycle, while accessories and configuration still require confirmation. |
| Charging and support | Plan for both host and sled power, pairing and replacement relationships. | Plan for the integrated device, battery approach and approved accessories. |
| Change boundary | Host and reader may change independently only if compatibility is revalidated. | Model/configuration changes require application and workflow revalidation. |
| Pilot evidence | Host-reader connection, ergonomics, event recovery and two-part charging. | Application behavior, RFID event handling, ergonomics and integrated charging. |
Where should the RFID and application responsibilities sit?
Draw the physical and software components before comparing form factors. In a sled direction, the host typically owns the user interface and business application while the sled contributes the RFID read event. The connection between them is a solution dependency. In an integrated direction, the mobile application and RFID function are evaluated on one approved device configuration.
The integration layer still owns event translation, queuing and transport where those services are needed. The WMS or customer application owns inventory state, business rules, permissions and acceptance. The device should provide clear feedback, but it should not silently become the authority for the business transaction.
Document which component creates timestamps, location context and user identity. If the host disconnects from a sled or the network is unavailable, the application needs a defined state and recovery path.
What does host dependency change?
A host-dependent design adds a physical, electrical and software relationship. Confirm the exact approved host, attachment or connection method and how the application receives reader events. Do not infer compatibility from shape, operating system family or connector appearance.
Decide who owns host and sled configuration, how the pair is issued to a worker and what happens when one component is replaced. Pairing or connection recovery should be part of the pilot. The asset record should preserve which components were validated together.
A host can provide application flexibility, but every intended change remains subject to compatibility and workflow validation. Avoid describing the architecture as universally modular without evidence for the specific combination.
How should ergonomics and task flow be compared?
Observe the actual read posture, reach, trigger use, screen confirmation and movement between items or zones. A sled-host assembly and an integrated RFID mobile computer can distribute weight and controls differently. Use real tasks and approved configurations rather than general assumptions about comfort.
Include non-read actions: typing, selecting a location, reviewing unexpected tags, carrying the device and setting it down. A suitable direction supports the full event loop, not only the moment of reading.
If a UHF handle or other configuration changes the device, treat that as a separate evaluation variant. Preserve configuration qualifiers in every decision record.
How do charging and support boundaries differ?
A sled architecture requires a plan for both parts. Record how each component charges, how readiness is checked, where spares are stored and whether workers can identify a mismatched or unvalidated pair. Integrated devices simplify the component count but still require an approved battery, charging and accessory plan.
Define support ownership for connection faults, application faults, RFID exceptions and physical damage. Without a clear triage path, a two-part system can create ambiguous incidents. An integrated device can also produce ambiguity if application and reader states are not distinguished in logs and user feedback.
Do not publish a warranty or support response promise that has not been approved. This guide addresses operational ownership only.
What should happen when a component or configuration changes?
Treat host, reader, operating system, application version, reader settings, tags and item set as controlled pilot inputs. A change to any of them can alter the observed workflow and should trigger proportionate revalidation.
Record the approved combination in the project brief and deployment manifest. The record should identify configuration-dependent and region-dependent elements without exposing private supplier mappings or debug information.
Use the SX-32 product page for the approved RFID sled direction and the RX-52 and RX-56 pages for RFID mobile computer directions. Public specifications are the authority for published fields; project suitability remains subject to confirmation.
How should the decision be recorded and revisited?
Record the RFID architecture as a set of responsibilities: the tagged-item event, host or integrated application, connection, operator feedback, charging set and support owner. Note the exact approved configuration and distinguish observed behavior from assumptions about another host, handle or region. An early successful read should not silently approve the full host-dependent or integrated deployment boundary.
Revisit the record when the host device, application release, sled pairing, integrated configuration, UHF handle, tag set, region or charging arrangement changes. Revalidate the affected connection and workflow path with its qualifiers intact. Public RFID and interface fields describe approved options; they do not prove cross-host compatibility or equivalent behavior under an untested configuration.
Provide the software owner with the accepted read and error states, operations with the handling and correction flow, and deployment support with the host, charging and replacement boundaries. Keep unresolved pairing, regional or UHF-handle questions with the project owner. If neither architecture is fully evidenced, state which combined hardware-and-application sample must be tested next rather than assuming interchangeability.
How can candidate directions be compared without changing the brief?
Compare a sled and an integrated RFID mobile computer with the same tagged items, read-zone objective and customer-application outcome. Preserve the real architectural difference: a sled depends on its host, while an integrated direction combines more functions in one device. Observe pairing or startup, normal reads, exceptions, interruption, charging and handover without forcing both options into an artificial single-device test.
Separate mandatory host, application and operational boundaries from preferences and unresolved compatibility questions. Stop a direction if its required host or connection path cannot be confirmed. When both options remain possible, compare component ownership, charging sets, operator handling, application change and replacement impact. Use a combined sample to settle uncertainty; do not invent compatibility or performance values.
Use the approved SX-32, RX-52 and RX-56 pages, their public specifications and technical-reference PDFs for model facts. Retain Host/UHF-handle configuration differences, Optional, Configuration dependent and Region dependent language wherever applicable. The framework exposes architectural responsibilities, but only the exact host and approved RFID configuration can establish the usable project combination.
Quantity and target timing belong in the project context after the host-versus-integrated boundary is documented. They do not prove component availability, pairing support or delivery. Carry the proposed architecture, rejected direction and open host, handle and regional confirmations into the brief. The Contact discussion should confirm those project-specific dependencies rather than reinterpret a catalogue family as a guaranteed system.
When to choose—and when not to choose
When this direction helps
- Choose a sled direction when a separately managed host-reader architecture is intentional and validated.
- Choose an integrated RFID mobile computer direction when one device should carry the approved mobile application and RFID workflow.
- Keep configuration, host and UHF-handle qualifiers visible throughout evaluation.
When to stop and validate
- Do not assume a sled fits or communicates with an unverified host.
- Do not select from claimed range or throughput without configuration-specific evidence.
- Do not treat an integrated device as eliminating application, network or exception-design responsibilities.
What belongs to the device, integration layer and customer application?
| Layer | Primary responsibility | Questions to close |
|---|---|---|
| Device | Capture approved inputs, expose the configured interaction and provide user feedback. | Which model, region, options, settings and accessories are approved? |
| Integration layer | Translate, queue and transport events where the project architecture requires it. | How are retries, mapping, duplicate events and interruption handled? |
| Customer application / WMS / ERP | Own identity, permissions, business rules, authoritative state and transaction acceptance. | What response confirms success and who resolves conflicts? |
| Network and deployment | Provide approved access, authentication, configuration control, charging and operational support. | What happens during interruption, replacement or release change? |
What should be validated in a sample or pilot?
- Validate the exact host-reader or integrated-device configuration.
- Exercise connection loss, application restart, network interruption and event recovery.
- Use representative tags, items, placements, zones and exception cases.
- Observe the complete task, including screen confirmation and non-read input.
- Validate charging, issue, replacement and support triage.
- Record region-dependent and configuration-dependent decisions before approval.
Questions to resolve before confirming a direction
- Which device owns the application and user interface?
- How are reader events transported, validated and acknowledged?
- What happens if host-reader connection or network service is interrupted?
- How will charging and replacement be managed for every component?
- Which exact configuration is approved for the pilot and region?
Sources and methodology
This guide supports a host-dependent RFID sled versus integrated RFID mobile computer decision. It draws model facts from the approved SX-32, RX-52 and RX-56 pages, the public specification library, current technical-reference PDFs and published RFID workflow material. Its comparison centers on host responsibility, application location, handling and charging; it does not publish unverified pairing, range, throughput or regional-availability claims.
Read the comparison table as an architecture worksheet, not as proof that one form works with every host, tag or application. Host/UHF-handle differences and regional or configuration qualifiers must remain visible. Test the intended host, reader configuration, tagged items, error path and charging set together, then ask the supplier or AIDC GO to confirm any compatibility field not present in the approved public sources.