Android nfcA.connect()，nfcA.transceive()，nfcA.setTimeout()和nfcA.getMaxTransceiveLength() [英] Android nfcA.connect(), nfcA.transceive(), nfcA.setTimeout() and nfcA.getMaxTransceiveLength()

问题描述

我有许多新手NfcA问题.在文档和其他地方，似乎没有什么指导在网络上，所以我希望没人介意在这里将一些基本问题拼凑在一起...

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被定义为值为1010b(Ah)的4位短帧(有关详细信息，请参阅NFC论坛数字协议规范和ISO/IEC 14443-3).
3. 被动ACK被定义为标记在一定的时间内完全不发送响应.
4. NACK被定义为值为0x0xb(其中x为0或1)的4位短帧.

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().但是，在连接之前调用该方法几乎没有任何性能开销，因为在fa​​mework API无需调用NFC系统服务的情况下，由famework API处理在封闭标签技术对象上调用isConnected()的情况.因此，在NfcA对象的布尔成员变量上，这比简单的if开销要大得多.

If you receive the Tag handle directly from the NFC system service (through an NFC intent) the tag won't be connected. So unless you use the Tag handle before calling nfca.connect(), I don't see why you would want to call nfca.isConnected() before. However, calling that method before connecting has barely any performance overhead since calling isConnected() on a closed tag technology object will be handled by the famework API without calling into the NFC system service. Hence, it's not much more overhead than a simple if over a boolean member variable of the NfcA object.

我不确定那个.但是，通常会在断开标签技术的连接时重置收发超时.

I'm not sure about that one. However, the transceive timeout is typically reset on disconnecting the tag technology.

否，您一次只能写入一个块.这受NTAG213的WRITE命令的限制，该命令仅支持一个块作为数据输入.

No, you can only write one block at a time. This is limited by the WRITE command of the NTAG213, which only supports one block as data input.

但是，收发缓冲区的大小为253，使您可以使用FAST_READ命令一次读取多个块(NTAG213最多读取62个块，因此最多读取45个块)

However, a transceive buffer size of 253 allows you to use the FAST_READ command to read multiple blocks (up to 62, so up to 45 for the NTAG213) at a time:

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

这篇关于Android nfcA.connect()，nfcA.transceive()，nfcA.setTimeout()和nfcA.getMaxTransceiveLength()的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！