HF RFID and NFC compatibility cannot be decided from the words "13.56 MHz" or "NFC" alone. A useful purchase decision must identify the card or tag, its air-interface technology, the data structure, any access control, the operation the application must complete and the API path available on the candidate device.
This guide is for integrators and project buyers who need a handheld to identify a badge, read an NDEF record, access protected card data or write an approved tag. It explains how to separate those tasks and how to assemble a test that answers the real compatibility question. It does not claim HF or NFC capability for an AIDC GO model without the applicable model document.
Start with the operation, not the frequency label
Write one sentence that describes the required result. "Read the asset number stored in an NDEF text record and compare it with the number printed on the label" is different from "read the card's discovered identifier," and both are different from "authenticate to a protected application and read one file." If writing is required, state which record or memory area changes and who supplies the keys and encoding rules.
Then identify the exact credential or tag. Record the manufacturer, product or chip family, physical form, existing encoding, security state and a sample identifier. A generic name such as access card, library tag or NFC sticker is not enough because products that operate in the same HF band can expose different technologies and data models.
The AIDC GO Products page is a hardware-direction entry, not proof of HF/NFC support. Use Integration & Support to request the option list and interface materials for a named model and region before treating it as a candidate.
Separate the compatibility layers
The first layer is the radio and air interface. Android documents NfcA as NFC-A based on ISO/IEC 14443-3A, NfcB as NFC-B based on ISO/IEC 14443-3B, IsoDep as ISO-DEP based on ISO/IEC 14443-4, and NfcV as NFC-V based on ISO/IEC 15693. The Android NFC technology package exposes these as distinct technologies. Seeing one technology in a device specification does not establish the others.
The next layer is the tag or card protocol and memory model. NXP describes MIFARE DESFire EV3 as using an ISO/IEC 14443 Type A interface and ISO/IEC 14443-4 transmission, with application and security features specific to that product. ST describes the ST25DV04K family as ISO/IEC 15693 and NFC Forum Type 5 with memory areas that can be protected. Both are HF products, but they are not interchangeable test objects.
The data layer comes next. The NFC Forum NDEF specification page describes NDEF as a common application-data format. A tag can support an NFC air interface without holding the NDEF record your application expects. Conversely, successfully parsing an NDEF URI does not establish access to a protected non-NDEF file.
Finally, the application must receive and interpret the result. Android's NFC basics distinguishes NDEF dispatch from technology dispatch. Its advanced NFC guidance notes that non-NDEF work can require technology-specific communication and an application protocol stack. Hardware discovery is therefore only one step in an end-to-end business transaction.
Follow one editorial compatibility decision
Consider an editorial facilities project with two physical samples. Sample A is an NFC Forum Type 5 maintenance label containing an NDEF URI that points to an asset record. Sample B is a MIFARE DESFire EV3 staff credential whose protected application must be authenticated before a file is read. The project wants one handheld application to open the maintenance record and separately confirm a staff entitlement.
For Sample A, the team records the exact tag part, confirms the candidate device reports the expected NFC-V technology, reads the NDEF message, checks the URI against the printed asset identity and verifies that the intended application receives it. If the project must update that URI, the write test uses a non-production sample and the documented access state.
For Sample B, discovering the card or reading a low-level identifier is not acceptance. The application owner must provide the application identifier, command flow, key-management responsibility and expected protected response. The candidate device and software path must complete that operation under the relevant Android and application versions. A result from Sample A cannot fill the evidence gap for Sample B.
This is an editorial example, not a customer deployment or AIDC GO device test. It illustrates why a mixed card population needs a result for each named operation and sample.
Record what each observation proves
| Required operation | Evidence to capture | What the result does not establish |
|---|---|---|
| Discover the tag or card | Exact sample; reported technology list; device and OS build | It does not establish that the required data is readable or meaningful to the application. |
| Read an NDEF record | Record type, payload, read result and receiving application | It does not establish access to protected files or compatibility with a different tag type. |
| Read a low-level identifier | Returned bytes, technology, formatting rule and expected identity | It does not establish that the identifier is stable, authorised as the business key or sufficient for authentication. |
| Access protected application data | Named card application, command path, key owner, success response and negative case | It does not establish access without the same credentials, security state and software version. |
| Write or update approved data | Target memory or record, permissions, before/after content and recovery rule | It does not establish unrestricted write access or safe modification of production credentials. |
Keep the identifier, payload and business record in separate columns. The tag identifier can help distinguish samples, but the application owner decides which value identifies the asset, person or transaction. If a value is reformatted, preserve the byte-order and encoding rule so two applications do not display the same tag differently.
Test the actual application path and access boundary
On Android, collect the technology list exposed for each sample and record whether the application uses NDEF dispatch, technology dispatch, reader mode or a vendor SDK. The Android API can expose a technology without implementing the higher-level business protocol for the application. Where IsoDep.transceive() or another raw exchange is used, the application supplies the protocol commands and error handling.
Build positive and negative cases. A positive case proves the approved sample and credentials can complete the named operation. A negative case might use the same card without valid keys, a similar tag with the wrong data format, an empty NDEF record or an identifier that is not in the business mapping. The application should distinguish "tag not detected," "technology unsupported," "access denied," "payload invalid" and "record not accepted" where those states matter operationally.
Do not test only a loose lab tag. Use the final housing, badge holder, mounting surface and operator movement when they can change presentation. Record antenna position and orientation as observations rather than promising a universal read distance. Use the AIDC Pilot Validation Checklist to place the compatibility cases in the wider project pilot without turning this article into another general checklist.
Bring a bounded compatibility packet to the supplier
Provide the candidate device model and region, Android or other OS version, application package and version, exact card/tag part numbers, required operation for each sample, NDEF or proprietary data definition, key or credential owner, write requirement, physical presentation and expected result. Include non-production samples and a redacted command or interface description where security policy permits.
Ask the supplier to identify the documented HF/NFC hardware option, supported technologies, antenna location, reader/writer limits and the API or SDK applicable to that exact configuration. Ask the application owner to confirm data parsing, authentication, key custody, mapping and business acceptance. Neither party should use a successful tag discovery as a substitute for the other party's evidence.
Then contact AIDC GO with the device direction, deployment country, quantity, sample inventory and open interface questions. A defensible compatibility decision names the sample and operation, closes every layer required by that operation and leaves unsupported card types outside the claim.