Are there different encoding requirements for iOS vs Android?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Are there different encoding requirements for iOS vs Android?

Jump to solution
4,043 Views
rhilyer
Contributor II

I have been working with NFC tags for a while, and have been using the TagWriter app by NXP on Android to encode single NFC tags with a URL. This has worked great when tag quantities are small, but it is not easy to scale. When encoding via the NXP app on Android, the encoded tags work fine on both operating systems.

I now have an NFC printer and a separate USB NFC reader, both of which have been used to encode NFC tags successfully with URLs that work great on Android phones. However, these encoded tags do not register on iOS devices as a URL, but instead it seems they are registering as plain UTF8 data.

When I scan both tags with a 3rd party application, the encoded data appears to be identical. So is there something I am missing? Do iOS devices require an additional step that I don't know about?

Thanks for your help.

1 Solution
3,344 Views
Jonathan_Iglesias
NXP TechSupport
NXP TechSupport

Dear Russell Hilyer

Please check the following I think the problem comes in the TLV , I noticed  that  the Length Value  is 1F which is big. please check the following. please let me explain the  NDEF that should work based on the link you provide. 

 

I tested this on an NTAG 216

NDEF = 030FD1010B5504676F6F676C652E636F6D

 

TLV= 030FD1

 

 

Name

Value

Type

03

Means this contains NDEF Message

Lenght

0F

15 bytes from D1 to 6D

Value 

D1

 Stores the NDEF Message record header

 

NDEF message:

Record Header

D1

Record header
Bit 7 = MB = 1: first record of NDEF message
Bit 6 = ME = 1: last record of NDEF message
Bit 5 = CF = 0: last or only record of chain
Bit 4 = SR = 1: short record length field
Bit 3 = IL = 0: no ID/ID length fields
Bit 2..0 = TNF = 0x1: Type field represents an NFC Forum
well-known type name

Type Length

01

Lenght of the type is 1 byte

Payload length

0B

in this case is 11 bytes from 04 to 6d

Type

55

 it is for "U" this letter tells the type of the NDEF  so the phone knows how should be handled in this case to launch a browser since it is a URI

Payload

04-6D

 

Payload:

04

Https:// if you used for example just Http:// it would be 01 like you used

02-6D

google.com

 

 

 pastedImage_2.pngpastedImage_1.png

 Android                                                                          IOS

As you can see the Terminator is not taken into account in the NDEF of the URI because it is considered as Other TLV which is the end of the chain. 

Most of this values are explained in the NFC Forum  specification, you can find the values for example for https:// and all the variants available  also for other values that are defined by NFC forum, also it is important to mention that the application you use should know how to handle all NDEF so I would recommend the TagInfo  application available in Android and IOS to read the tag and check them, please try this NDEF message and tell me if it worked for you.

 

Have a great day !
BR

 

Jonathan 

View solution in original post

0 Kudos
5 Replies
3,344 Views
Jonathan_Iglesias
NXP TechSupport
NXP TechSupport

Dear Russell Hilyer,

asa you may know IOS only  let customers to read tags, and only tags formatted as NDEF, by this I mean that the TAG complies with NFC Forum regulations,  so if you for example use a DESFire but you have not formatted it as NDEF android can still read it and interact with it since Android is more flexible in this  side and if you use the same DESFire in iPhone it wont do anything cause it is nor prepared to work with  other formats,  so what might be happening here is that the constructions of your NDEF is not correct  if you could send the NDEF stored in the tag to check it also something wrong might be the TLV of the NDEF that is not constructed correclty or the Terminator of the NDEF as well so if you could provide the NDEF stored in your tag using maybe the taginfo application from Android to confirm it, would be very helpful.

BR

Jonathan

0 Kudos
3,344 Views
rhilyer
Contributor II

Jonathan,

Thanks a lot for your reply. I was aware that iOS only accepts NDEF formatted NFC payloads, which makes this issue so much more confusing.

I did notice that there seems to be a problem with the terminator bit when encoding from the printer or USB reader. By default, this bit is not added to the end of the payload, but if I add it manually then the entire payload stops working (for both Android and iOS devices).

The payload data can be seen below (this example is just for https://google.com):

031FD1011B550467676F6F676C652E636F6D

Without the 0xFE terminator, this encoding will work for Android. However, if I add the terminator, the encoding breaks and no device is able to parse it correctly.

Any advice? 

Again, I really appreciate your help with this.

0 Kudos
3,345 Views
Jonathan_Iglesias
NXP TechSupport
NXP TechSupport

Dear Russell Hilyer

Please check the following I think the problem comes in the TLV , I noticed  that  the Length Value  is 1F which is big. please check the following. please let me explain the  NDEF that should work based on the link you provide. 

 

I tested this on an NTAG 216

NDEF = 030FD1010B5504676F6F676C652E636F6D

 

TLV= 030FD1

 

 

Name

Value

Type

03

Means this contains NDEF Message

Lenght

0F

15 bytes from D1 to 6D

Value 

D1

 Stores the NDEF Message record header

 

NDEF message:

Record Header

D1

Record header
Bit 7 = MB = 1: first record of NDEF message
Bit 6 = ME = 1: last record of NDEF message
Bit 5 = CF = 0: last or only record of chain
Bit 4 = SR = 1: short record length field
Bit 3 = IL = 0: no ID/ID length fields
Bit 2..0 = TNF = 0x1: Type field represents an NFC Forum
well-known type name

Type Length

01

Lenght of the type is 1 byte

Payload length

0B

in this case is 11 bytes from 04 to 6d

Type

55

 it is for "U" this letter tells the type of the NDEF  so the phone knows how should be handled in this case to launch a browser since it is a URI

Payload

04-6D

 

Payload:

04

Https:// if you used for example just Http:// it would be 01 like you used

02-6D

google.com

 

 

 pastedImage_2.pngpastedImage_1.png

 Android                                                                          IOS

As you can see the Terminator is not taken into account in the NDEF of the URI because it is considered as Other TLV which is the end of the chain. 

Most of this values are explained in the NFC Forum  specification, you can find the values for example for https:// and all the variants available  also for other values that are defined by NFC forum, also it is important to mention that the application you use should know how to handle all NDEF so I would recommend the TagInfo  application available in Android and IOS to read the tag and check them, please try this NDEF message and tell me if it worked for you.

 

Have a great day !
BR

 

Jonathan 

0 Kudos
3,344 Views
rhilyer
Contributor II

Jonathan,

That worked! I think the problem was my memory allocation. I was declaring that the NDEF message was much longer than it was in order to make sure I had plenty of room for longer URLs.

Strange that Android would not care but iOS would, but I'm glad you were able to identify the problem.

Thanks again for all of your help and your quick responses.

3,343 Views
Jonathan_Iglesias
NXP TechSupport
NXP TechSupport

Hi Russell Hilyer,

Good to know that it worked :smileygrin:

Please let me know if you have more questions.

Have a great day !

BR

Jonathan

0 Kudos