如何在NFC 4类标签仿真上组织大数据文件

Question

I'm working on an application where I store data on a 4Mbit dataflash and read it out with a smartphone via NFC. To do this I use a NFC frontent (AS3953) and a microcontroller to emulate a Type 4 tag. It would be convenient to split the data into 264 bytes chunks (page-size of flash) and read them out sequentially.

What is then the better structure: one big NDEF file with many records of 264 bytes each, or many single elementary files under one dedicated file?

Thanks for inputs, Andreas

Answer 1

This heavily depends on what you want to achieve with your solution and what platforms you target:

1. You can build an NFC tag that follows the NFC Forum Type 4 tag specification and uses only the NDEF data abstraction layer.

   • Your application will be interoperable with all devices that support reading and writing NDEF messages on NFC Forum Type 4 tags. This includes all current major mobile OS platforms that support NFC and the NFC Web API.
   • You are limited to 65534 bytes of NDEF data (including record headers).
   • You cannot really control how a device reads or writes data from/to the NDEF file. Specifically, even if you segment the file into several NDEF records, there is no means to control in what segments the file will be read/written. (Note that you can control the maximum data field size of APDUs, but there is nothing that prevents an NFC device to read/write even smaller chunks.)
   • An NFC device (eg Android does this) will typically read the whole NDEF message upon scanning the tag in order to perform automatic actions (eg start an app).

2. You can build an NFC tag that follows the NFC Forum Type 4 tag specification and uses a combination of the NDEF data abstraction layer (eg to store information that permits your app to be started automatically and to identify the prorietary protocol) and proprietary data files (as specified in the NFC Forum Type 4 Tag Operation specification).

   • Proprietary data files are not accessible on several platforms (eg Windows Phone 8, NFC Web API). They can be accessed on Android and BlackBerry devices though.
   • Besides the automatic NDEF abstraction that is typically handled by the operating system, you will need to manually implement commands to identify and access the prorietary data files (eg on Android using the IsoDep class).
   • Using those prorietary data files, you could structure your memory to use eg one file per page.
   • You are not limited to 65534 bytes but instead can have several files that have up to 65534 bytes each.
   • An NFC device will typically only read the NDEF file by default when scanning the tag in order to perform automatic actions. Proprietary files will usually be ignored.
   • Instead of using the proprietary files feature of the NFC Forum Type 4 Tag Operation specification, you could just as well create a separate application (under a different DF name/AID) that permits you to access your data memory (either through ISO 7816-4 standardized commands our through custom commands).

3. You can create a completely custom protocol based on ISO 14443/ISO 7816-4.

   • You won't (or only partially) have the capabilities of an NDEF tag (eg triggering of automatic actions, like starting a specific app).
   • Your app will not be compatible to Windows Phone 8 (or any other platform that only permits high-level access to tags through NDEF abstraction).
   • You don't have the protocol overhead introduced by implementing the NFC Forum Type 4 Tag Operation specification.