CODEWITHSUNDEEP
androidiosnfcndef
Andy Victors
Andy Victors

Reputation: 405

Cannot read specific NDEF record with iPhone (iOS)

I write a custom content consisting of 3 NDEF records (URL, Custom, Custom) onto a NFC tag. Such a tag is readable by both Android and iOS, no problems.

Now I increase the size of the URL, so naturally only URL NDEF record changes and the NDEF is no longer readable by iOS - receiving empty NDEF record list.

This looks very weird - if I pad the URL to a couple of characters it becomes readable (yet this is not a solution to me as the NDEF content is limited).

Tried with different iPhones (iOS 15, iOS 16). Tag of ISO 15693.

Manually validated NDEF record - all fields look good and consistent. There is an online NDEF checker it also gives no problems.

I am totally lost. Any ideas?

Upvotes: 0

Views: 633

Answers (2)

Papyrus
Papyrus

Reputation: 329

The NFC Forum Type 5 spec (NFCForum-TS-T5T), section 4.3, says:

The T5T_Area (i.e., memory containing the NDEF message) starts with the first byte following the last byte of the CC field. The size of the T5T_Area is defined by the content of the CC field.

So the MLEN does not include the memory occupied by the capability container itself, but includes all other memory available in the tag REGARDLESS OF THS SIZE OF THE NDEF MESSAGE.

What follows after the capability container is usually length bytes as @Andrew points out. However the more complete story is that there is an NDEF TLV (as prescribed by section 4.4 of the NFCForum-TS-T5T. The tag for the NDEF TLV is 0x03, and following that is a single length byte (for lengths <= 254) or 3 bytes indicating a longer (>=255) length. As per the spec:

The length field (L-field) encodes the size of the V-field in bytes. ... If the L-field is present, it may contain one or three bytes: One byte if the length to encode is between 00h and FEh. The value FFh for the first byte encodes a three-byte format. Three bytes if the length to encode is between 00FFh and FFFEh. The three-byte value FFFFFFFh is RFU.

So following the capability container must be a 0x03, followed by the length of the NDEF, followed by the NDEF message itself. Assuming the 3 records in total are < 255 bytes, following the capability container should be:

03 | {single byte length} | record 1 | record 2 | record 3

Upvotes: -1

Andy Victors
Andy Victors

Reputation: 405

Well it required A LOT OF EFFORTS. Hope the related Apple engineer (engineers) will find this question and ask questions to themsselves.

So problem was generally with ISO 15693 tags. Those include additionally so called Capability Container - a 4 byte field at the user address 0x0. This header includes "size of content" expressed in 8-byte chunks. So real size divided by 8. In my case it was 0x12 which meant 0x24 blocks - AND - my content was exactly this size. So technically no specification violation is observed. Yet tags were not readable (specifically, NDEF message not recognized).

I have increased the content size to 1 unit (+8 bytes) and everything started to work.

Upvotes: -1

Related Questions