Android nfcA.connect()、nfcA.transceive()、nfcA.setTimeout() 和 nfcA.getMaxTransceiveLength()

Android nfcA.connect(), nfcA.transceive(), nfcA.setTimeout() and nfcA.getMaxTransceiveLength()(Android nfcA.connect()、nfcA.transceive()、nfcA.setTimeout() 和 nfcA.getMaxTransceiveLength())

问题描述

我有许多 NfcA 新手问题.docs 和其他地方似乎对此几乎没有指导在网络上，所以我希望没有人介意我在这里将一些基本问题串在一起......

I have a a number of newbie NfcA questions. There seems to be little guidance on this in the docs and elsewhere on the web, so I hope no-one minds me stringing a few basic questions together here...

我正在使用 nfcA.transceive() 将数据写入到我的 NTAG213 标签，如下所示:

I am using nfcA.transceive() to write data to my NTAG213 tag like this:

    byte[] result = nfcA.transceive(new byte[] {
            (byte)0xA2,  // WRITE
            (byte)(pageNum & 0x0ff),
            myData[0], myData[1], myData[2], myData[3]
    });

1. result 数组是值 10 的单个字节.这是什么意思，我应该注意哪些其他值?

1. The result array is a single byte of value 10. What does this mean and what other values should I look out for?

我也使用相同的方法从我的 NTAG213 标签中读取数据:

I am also using the same method to read data from my NTAG213 tags:

    byte[] result = nfcA.transceive(new byte[] {
            (byte)0x30,  // READ
            (byte)(pageNum & 0x0ff)
    });

2. 我希望这会返回 4 个字节的用户数据(即对应于我的 pageNum 的 4 个字节)，但它返回了 16 个字节.为什么会这样?

2. I expected this to return 4 bytes of user data (i.e., the 4 bytes that correspond to my pageNum), but it returned 16 bytes. Why is that the case?

3. 在调用 nfcA.connect() 之前检查 nfcA.isConnected() 是否是一种好习惯，如果是，是这样做可能会产生任何重大的性能损失吗?(我问，因为我已经看到了来自有信誉的来源的代码示例.)

3. Is it good practise to check nfcA.isConnected() before calling nfcA.connect() and, if so, is there likely to be any sigificant performance penalty in doing so? (I ask as I have seen code examples from reputable sources of both.)

4.在nfcA.connect()之前还是之后调用nfcA.setTimeout()更好?

4. Is it better to call nfcA.setTimeout() before or after nfcA.connect()?

5. 对于我的 NTAG213 标签 nfcA.getMaxTransceiveLength() 返回 253.这真的意味着我最多可以写入 251 个字节的用户数据(加上另外 2 个字节)字节)，如果是这样，那是可取的还是用单独的 nfcA.transceive() 调用编写每一页(4 个字节)更好?

5. For my NTAG213 tags nfcA.getMaxTransceiveLength() returns 253. Does that really mean I can write up to 251 bytes of user data (plus the 2 other bytes) in one go and, if so, is that advisable or is it better to write each page (4 bytes) with separate nfcA.transceive() calls?

推荐答案

1.WRITE 命令的结果数组是值 10 的单个字节.这是什么意思以及我应该注意哪些其他值?

值 10(十六进制的 Ah 或二进制表示的 1010b)是显式 ACK，当没有返回数据的命令成功时返回确认.

1. The result array for a WRITE command is a single byte of value 10. What does this mean and what other values should I look out for?

The value 10 (Ah in hexadecimal or 1010b in binary representation) is an explicit ACK, an acknowledgement returned when a command that returns no data succeeds.

可能的值是实际数据、ACK、被动 ACK 或 NACK.这些由 NFC 论坛数字协议规范和 NFC 论坛类型 2 标签操作规范定义.

The possible values are actual data, ACK, passive ACK, or NACK. These are defined by the NFC Forum Digital Protocol specification and by the NFC Forum Type 2 Tag Operation specification.

1. 如果希望命令在成功时返回实际数据，则返回数据而不是显式 ACK 值.
2. ACK 定义为 4 位短帧(有关详细信息，请参阅 NFC 论坛数字协议规范和 ISO/IEC 14443-3)，值为 1010b (Ah).
3. 被动 ACK 定义为标签在特定超时内根本不发送响应.
4. NACK 定义为 4 位短帧，值为 0x0xb(其中 x 为 0 或 1).

NTAG213/215/216 产品数据表对可能的 NACK 值进行了更具体的说明:

The NTAG213/215/216 product data sheet is a bit more specific on possible NACK values:

1. 0000b (0h) 表示命令参数无效.
2. 0001b (1h) 表示奇偶校验或 CRC 错误.
3. 0100b (4h) 表示无效的身份验证计数器溢出.
4. 0101b (5h) 表示 EEPROM 写入错误.

除了上述之外，一些设备上的 NFC 堆栈实现没有正确地将 NACK 响应传播到应用程序.相反，它们要么抛出 TagLostException，要么返回 null.同样，您可能(?)得到一个指示被动 ACK 的 TagLostException.

In addition to the above, the NFC stack implementations on some devices do not properly propagate NACK responses to the app. Instead they either throw a TagLostException or return null. Similarly, you might(?) get a TagLostException indicating a passive ACK.

因此，您通常会检查以下收发方法的结果(除非您发送预期会导致被动 ACK 的命令):

Thus, you would typically check the result of the transceive method for the following (unless you send a command that is expected to result in a passive ACK):

try {
   response = nfca.transceive(command);
   if (response == null) {
       // either communication to the tag was lost or a NACK was received
   } else if ((response.length == 1) && ((response[0] & 0x00A) != 0x00A)) {
       // NACK response according to Digital Protocol/T2TOP
   } else {
       // success: response contains ACK or actual data
   }
} catch (TagLostException e) {
   // either communication to the tag was lost or a NACK was received
}

2.我希望 READ 方法返回 4 个字节的用户数据(即对应于我的 pageNum 的 4 个字节)，但它返回了 16 个字节.为什么会这样?

READ 命令被定义为返回从指定块号开始的 4 个数据块(在 NFC 论坛类型 2 标签操作规范中).因此，如果您发送块 4 的 READ 命令，您将获得块 4、5、6 和 7 的数据.

2. I expected the READ method to to return 4 bytes of user data (i.e. the 4 bytes that correspond to my pageNum), but it returned 16 bytes. Why is that the case?

The READ command is defined to return 4 blocks of data starting with the specified block number (in the NFC Forum Type 2 Tag Operation specification). Thus, if you send a READ command for block 4, you get the data of blocks 4, 5, 6, and 7.

如果您直接从 NFC 系统服务(通过 NFC 意图)接收 Tag 句柄，则不会连接标签.因此，除非您在调用 nfca.connect() 之前使用 Tag 句柄，否则我不明白您为什么要调用 nfca.isConnected()之前.但是，在连接之前调用该方法几乎没有任何性能开销，因为在封闭标签技术对象上调用 isConnected() 将由 famework API 处理，而无需调用 NFC 系统服务.因此，它的开销并不比简单的 if 在 NfcA 对象的布尔成员变量上增加多少.

int firstBlockNum = 0;
int lastBlockNum = 42;
byte[] result = nfcA.transceive(new byte[] {
        (byte)0x3A,  // FAST_READ
        (byte)(firstBlockNum & 0x0ff),
        (byte)(lastBlockNum & 0x0ff),
});