Check compatibility at five levels
Start by describing the task, such as checking apparel stock with an existing handheld reader or opening a product link on the intended smartphone. Then check the following five levels separately, so that detecting a tag over the air is not mistaken for acceptance of the complete project.
- Frequency band and deployment region: Is the reader's regional version and configuration suitable for the project location?
- Air interface protocol: Do the reader and tag support the same protocol required for the task?
- Operations and memory: Are the required read, write and verification operations and associated commands supported?
- Data format: Does the output match the specified identifiers, content and encoding rules?
- Software and workflow: Can the application associate the data with the correct item and perform the intended operation?
Start with accurate information about your existing equipment
Record the reader's full model number, regional version, firmware, antenna and connection method, along with the application, operating system and SDK versions. A shortened model name, appearance or a claim that a device 'supports RFID' is no substitute for its documentation. List the tag protocol, chip documentation and required features, then confirm them separately with the reader and tag suppliers.
NFC operates at 13.56 MHz, but that does not make every HF tag at the same frequency suitable for the intended smartphone. Check the specific tag technology, data format and application support. For UHF projects, check the protocols supported by the reader and tag and the reader's regional configuration for the deployment country. The same frequency band or power settings cannot be assumed suitable for every region.
- Confirmed information: Save the datasheet and equipment manual for the exact model, including their revision dates.
- Information still unclear: Mark it 'to be confirmed' and provide the equipment model and workflow requirements instead of assuming compatibility.
Verify reading, writing and the meaning of the data separately
Compliance with a protocol standard does not mean that every optional command has been implemented. If the project requires writing, access to a specific memory area or locking, check support in the reader, tag and software for each requirement. Detecting a tag does not verify those operations.
For smartphone interactions, check the required NDEF content and the page or application actually opened on the intended phone. For UHF, check the EPC or other data required by the system, the encoding scheme and the mapping to individual items. The communication protocol and data format are separate checks; a screenshot showing that a tag was read is not enough.
- Expected data: Record test identifiers or content examples approved for the workflow, together with the required format.
- Actual data: Record the memory area read, raw output and verification results, then check that they correspond to the correct item.
- Expected action: Verify the complete operation required by the project, such as an inventory update or opening a page.
Verify the workflow with samples attached to actual items
First check an individual sample within a defined test area. Then test hanging, folded, packaged or stacked items, or neighbouring items, as required by the actual task. Record the mounting material, position, orientation, reading position and equipment settings so that the next test can be reproduced.
GS1 TIPP focuses on the performance of tagged items. On-site procurement tests should likewise evaluate the tag installed on the actual item. The project record suggestions below are not a TIPP laboratory test procedure. Both parties need to agree on sample quantities, test runs and acceptance thresholds.
- Samples: Identifier, revision, chip or protocol documentation, mounting material and position.
- Equipment: Reader, firmware, antenna, regional configuration, application and operating system versions.
- Procedure: Target area, reading position, orientation, item arrangement, test runs and steps.
- Results: Expected and actual data, workflow actions, missed reads, reads from outside the intended area and exception handling.
Use the symptom to decide what to check next
These are troubleshooting directions, not definitive diagnoses. Change one recorded condition at a time and repeat the same procedure. Share the issue and original results with the reader or tag supplier.
- No reads: Check the technology, protocol, reader's regional settings, equipment status and actual mounting conditions.
- Tag detected but content does not match: Check the memory area read, written content, data format and item mapping.
- Correct data but no application action: Check the connection, application configuration, interface handling and business records.
- Intermittent missed reads or reads from outside the intended area: Check tag placement, item arrangement, antenna, reading area and operating steps.
Turn confirmed results into a procurement record
Save the approved sample revision, model documentation, equipment settings, artwork, encoding examples, mounting method, test steps and acceptance criteria. Purchasing, technical teams and suppliers should work from the same record, so tags are not selected again for production based only on appearance.
After a change to the chip, tag construction, dimensions, mounting position, reader firmware or software, check which requirements are affected before deciding what to retest. When requesting a quotation, attach the equipment model, deployment country, data examples and sample record to your existing procurement checklist. Keep unknown parameters marked 'to be confirmed'.
Sources
Frequently asked questions
Are readers and tags at the same frequency always compatible?
Frequency alone is not enough. Check the specific communication protocol, required operations, data format, reader's regional version and application support. Then verify the complete task with samples installed as intended.
Why can I read a UID or EPC but still not use it in my system?
Detecting a tag, reading the data required by the workflow and completing a system operation are different steps. Save the actual output and check the memory area read, encoding format, item mapping and application processing. Reading an identifier does not establish that the system is integrated.
Is testing the maximum read range enough for sample acceptance?
Test the actual mounting conditions and complete workflow, and agree on the target reading area and how missed reads and reads from outside that area will be assessed. Sample quantities, test runs and acceptance thresholds depend on the project.
Is verification needed after changing the chip or reader firmware?
First assess how the change affects protocols, commands, data, equipment configuration and the application. Then retest the affected areas. Save the new revision and test records rather than assuming that the previous compatibility conclusion still applies.
