RoadTest: NTAG I²C plus Arduino-compatible Development kit
Author: gordonmx
Creation date:
Evaluation Type: Development Boards & Tools
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?: Nordic Semi has some intro dev kit for NFC
What were the biggest problems encountered?: Trying to piece together the available documentation for the complete demo
Detailed Review:
First off, I would like to thank NXP and Element 14 for the opportunity to evaluate the NTAG I²C plus Arduino-compatible Dev Kit (“the Kit”).
Summary Conclusion –
NOTE: Before I start my review, as many of you already know, NXP has been around for a while. Can anyone tell me what the characters in NXP’s name stands for? See the end of the “Summary Conclusion” for the answer.
As mentioned in the body of my review, the NTAG I²C plus Arduino-compatible Dev Kit (OM23221ARD) isn’t really a “complete” dev kit, but a Arduino shield that requires an Arduino-based single board computer (SBC) or control board. The review kit, which I would more likely label the “NTAG I²C plus Arduino-compatible Dev Kit – PLUS”, included both assemblies, but if you wanted to purchase “the Kit” you would need to supply your own compatible controller. Both the controller and shield is available through NXP distributors. The Arduino controller supplied with the review kit, and used in this review, is the NXP/Freescale FRDM-KW41Z. Most of the available documentation is targeted to a set of different NFC evaluation kits for which, unfortunately, the shield setup and operation is only minimally covered. The other NFC kits included in the documentation appear to have more functionality and tools to evaluate the NTAG I²C plus
After you get past the short comings of the documentation, the product works very well. The system is very sensitive to alignment between the shield and my readers, but may be related to my Android devices. During my evaluation, both devices had to touch or be within a few millimeters to connect, far short of the expected 10 cm (~4 inches) for RFID/NFC frequencies. But the NTAG I²C plus is a NFC Type-2 Forum device suitable for embedded cards (i.e. day passes, event ticketing, etc.) or low valve transactions, where contact may be acceptable.
The eclipse-based IDE was easy to install and use. The FRDM-KW41Z has a built-in open source serial and debug adapter (openSDAv2.2) using a dedicated on-board Kinetis K20 family MCU making it easy to download the software examples. The software examples were easy to load and understand. In addition, NXP has an application note for using the Android Studio IDE to help in modifying your phone app, if necessary. It was nice to see the extent of NXP documentation, but with NXP history with RFID/NFC design, I expected a little better documentation and cross referencing.
Pros –
Cons –
Overall the design is workable and I would recommend the NXP NTAG I2C Plus development kit if you would like to explore a NFC Type 2 forum design.
Useful Documents Links-
NOTE: Logging in to the respective websites may be required to access some of the documents.
Element 14 RoadTest Website
Element 14: Essentials Learning Module - Wireless Protocol III: Near Field Communication (NFC)
https://www.element14.com/community/docs/DOC-91382/l/element14-essentials-wireless-protocol-iii
NFC Forum – Type 2 Tag Operation Ver. 1.2 Technical Specification http://members.nfc-forum.org/specs/spec_list/
OM23221ARD: NTAG I²C plus Kit for Arduino Pinout https://www.nxp.com/products/identification-and-security/nfc/nfc-tags-for-electronics/ntag-ic-iplus-i-kit-for-arduino-pinout:OM23221ARD
NT3H2111/NT3H2211, NTAG I²C plus, NFC Forum Type 2 Tag compliant IC with I²C interface datasheet
http://www.nxp.com/documents/data_sheet/NT3H2111_2211.pdf
NTAG I²C plus Explorer Kit and Android Demo user manual http://nxp.com/documents/user_manual/UM10966.pdf
NTAG Antenna Design Guide, Rev. 1.8 https://www.nxp.com/docs/en/application-note/AN11276.zip
Montena Technical Note - TN14, Near field / far field
https://www.montena.com/fileadmin/technology_tests/documents/technical_notes/TN14_Near_field.pdf
Mobile Knowledge NXP NTAG I2C plus – Your entryway to NFC Product Support Package
NXP Technical – TN00042 NTAG I2C Plus FAQ
https://www.nxp.com/docs/en/engineering-bulletin/TN00042.pdf
NXP NTAG I²C plus Explorer Kit - Program and Debug Start-up https://www.nxp.com/docs/en/user-guide/UM10945.pdf
NXP OM29110 NFC's SBC Interface Boards User Manual https://www.nxp.com/docs/en/user-guide/UM10956.pdf
NXP NTAG I²C plus Explorer Kit - Android Demo https://www.nxp.com/docs/en/user-guide/UM10966.pdf
NXP NTAG I²C plus Demo Android App Developer Start-Up Guide
https://www.nxp.com/docs/en/user-guide/UM10989.pdf
NXP/Freescale FRDM-KW41Z Website www.nxp.com/FRDM-KW41Z
NXP/Freescale FRDM-KW41Z Freedom Development Board User’s Guide
https://www.nxp.com/webapp/Download?colCode=FRDMKW41ZUG
NXP/Freescale FRDM-KW41Z Quick Start Guide https://www.nxp.com/webapp/Download?colCode=FRDMKW41ZQRG
Answer to today’s question: NXP stands for Next EXPerience (formerly Philips Semiconductors)
Part I – A Little History…
Before digging into details of “dev kit”, let’s start with a little history. NXP has played a major role in the development and implementation in the area of both Radio Frequency Identification (RFID) and Near Field Communication (NFC). What does RFID have to do with NFC? As you will see, quite a lot as they both use reflected power to communicate between devices. Although the ideas was passed around earlier (~1973), the first use of the term RFID was first documented in a patent in 1983 by Charles Walton. The concept included an interrogator (reader) and reflector (tag). Tags could be either passive (no power) or active (self-powered), although the earliest tags were passive. These tags were more RF tags rather than RFID tags since they exchanged little if any information and are still in use today. The simplest tag is composed of an antenna; with more complex tags include integrated electronics.
Before I go any further, what is reflected power communication? In a RF/RFID system the reader transmits a burst of low frequency energy. The given frequency is in the Reactive Near (Rayleigh) or less than wavelength/2Pi range, resulting in a primary electromagnetic inductive (H-field) power transfer. Similar to how power transformer work, both the reader and the tag contain small loop antennas for transferring the energy between each other. Because the frequency is so low, the reader and the tag must be close to each other.
How the communication between the reader and a tag works is when the reader sends a burst of magnetic energy to the tag, the tag’s loop antenna picks up the field and converts it to an electrical signal. According to Faraday's law of induction, the eddy current generated in the tag’s loop generating a back EMF that can be picked up by the reader. By modulating either the field from the reader or the tag’s loop current information can be transferred.
Back to the early RF tags which were basically wire loop antenna tuned to resonate at a specific frequency. When a tag was near to a reader, the reader energy burst would trigger the tag’s tuned circuit resulting in a burst of energy at its resonance. This was the only information transferred. When this inexpensive tag was inserted in another device (i.e. book, etc.) it becomes part of an electronic article surveillance system still in use today in many stores top guard against shoplifting (i.e. Beep, beep, beep). But one problem with these early tags is there inability to tell you what was being taken. This bought about changes to include product and system specific information into a 96-bit data string for today’s modern RFID. To process this data, integrated circuits and power control system were added to the tags, all at an increasing cost per unit.
All these improvements were great for tasks like inventory or process control within closed areas, but what about our personal data with unlimited the variables. Security was also an issue with anyone within touch could download your personal tag. Here’s where NFC comes in.
Part II – The Unpacking: 8^) with a little 8^(
Welcome to the first part of many of my evaluation of the NTAG I²C plus Arduino-compatible Dev Kit (OM23221ARD). I have read many different views on the value and/or importance of the unpacking segment, but I feel it is important because it is often our first glimpse into what to expect in the product and support.
I’m excited to road test the NTAG I²C plus kit, not just because of NXP’s expertise and extensive experience in the field of RFID and NFC, but the increase of low frequency data transfer applications. An added bonus is to work with the Freescale side of NXP and the Freedom FRDM-KW41Z, for which I hadn’t had the opportunity since acquired by NXP. Both the dev/eval kit and Freedom board are currently available through Element 14 for ~$17 and $153, respectively.
The shipping box arrived undamaged, always a good sign, and well packed. The actual components included in the carton were the NTAG I²C plus Arduino-compatible Dev Kit (“the Kit”) and the NXP/Freescale FRDM-KW41Z, Arduino controller. Although the individual packages were not damaged, the only internal padding was a small piece of bubble wrap. The smaller box is the dev kit.
As mentioned earlier, the review components I received included 2 dev kits with the following content:
1) NXP NTAG I2C Plus Kit For Arduino Pinout Arduino Shield (OM23221ARD):
1 – OM29110ARD, Arduino Interface (also referred to as the NFC SBC Interface) Board, Rev 1
1 – OM23221, NTAG I2C Plus Kit Board, Rev 1
2) NXP/Freescale Freedom Development Board (FRDM-KW41Z)*
2 – FRDM-KW41Z, Arduino Compatible Single Board Computer (SBC)
2 – USB Type A to USB Micro cables
1 – FRDM-KW41Z Quick Start Guide
*NOTE: For the operation and evaluation of “the Kit” only 1 FRDM-KW41Z SBC was needed. Although the SBC box listed quantity of 1, the box actually contained 2 set of boards, as stated on the NXP website.
Aside from the SBC quick start guide, the instructions for obtaining additional resources are shown on the back of each box.
NOTE: Although the kit contains all the materials required to run the evaluation, neither product boxes or downloaded documentation outline what was included in each kit.
Now for a few of the drawback I have observed with the initial unpackaging. As we have all seen with every dev/eval/demo kit produced for the last 10 years, all documentations are available only through download. However it would be nice for a kit to include a packing list to verify its content (see note above) and include a list of additional components needed to verify the kit. NXP is no different, but there is a lot of information online which seems to not be very well tied together. For example, the user guide actually covers 3 different versions of the NTAG I2C plus kit. The Arduino shield portion is only a small part of the manual and I found myself digging through pages trying to find out how to get started.
For the information (i.e. User’s Guide, etc.) concerning the Freedom SBC, the link from the quick start guide (see “Useful Document Links” section) is very helpful. However, the link for the dev kit is incorrect on the box (www.nxp.com/demoboard/OM23221ARD). Even the name and description had changed and I spent a great deal of time tracking down the correct information. See “Useful Document Links” section for correct links.
Part III – Connecting and Powering Up the Kit:
At this time I normally power up the kit to get a feel for whether the unit will show any sign of life. The power LED (LED2) turned on, but it appeared no program examples were preloaded, well maybe. But in hindsight I shouldn’t have expected much since the kit as a whole isn’t really one but 2 independent kits with no preloaded software apps. I should note that since 2 SBCs were included I tried both with slightly different results. As noted above, the first SBC only had the power LED lit, but the second one (from the hidden compartment) also had the user application LEDs (LED3 and LED4) flashing, as specified in the quick start guide. So the first SBC may have had something preload, but the documentation fails to mention any details. The rest of my evaluation included only the first SBC. The next step would be to install the IDE, then program the SBC. All the coding for the actual shield is done through the programming of the SBC.
Part IV - Software Installation:
Two software programs are used by the dev kit. The hardware is programmed through NXP’s MCUXpresso SDK Builder, an Eclipse-based IDE. Interestingly, the main dev kit app note, UM10966, NTAGH I2C Plus Explorer Kit – Android Demo, doesn’t even mention the IDE. The app note does list 3 firmware projects/programs that is used in the demo in Section 3.2, “Software Components”, but doesn’t show how to open, build, or upload the code to the IDE or SBC. More about this later.
The second program is the Android app which is covered better in app note UM10989, “NTAG I2C plus Android app Developer start-up guide”. The note outlines the use of Android Studio, v2.2.3 or later, to create the app and therefore will not be detailed further in this review. The Android source code can be found at www.nxp.com in SW3648.zip, “NTAG I²C Demo Android App Source code (REV 1.1)”, although once again the link in the documentation is bad so you will have to run a search on their website.
Back to the MCUXpresso SDK Builder/IDE. Although the main app note for the dev kit does not reference the IDE, the installation and setup is mentioned in 2 other related notes, UM10950, “Start-up Guide for FRDM-KW41Z Evaluation Board Bluetooth Paring{sic} example with NTAG I2C plus” and UM10945, ”NXP NTAG I²C plus Explorer Kit - Program and Debug Start-up” user manual. Neither app note is referenced under the OM23221ARD web link. Even though it is intended for a slightly different application, I will be referring to the first note because of the additional useful information for setting up the software. The installation of software requires two steps; 1) the actual installation of the basic IDE and 2) the setup (configuring/building & importing) of the SDK. Using the example shown for BLE pairing, a completely different application, the software should easily load, compile and upload the demo firmware also found at NXP’s website in SW3647.zip, “Explorer Board firmware C Source files (REV 1.0)”. Using UM10989, Sections 2.1.1 thru 2.1.2, install the IDE. NOTE: You will need to have an NXP account to download and install the software. If you already have an account, but haven’t logged on in a while, your account may be deactivated like mine was. In that case you will need to go to the NXP community page to request re-activation, which can take a few days.
Basic IDE Installation -
Go to https://mcuxpresso.nxp.com/en/welcome, select the “Software and Tools” tab and then click “Learn More”.
You will be redirected to the MCUXpresso IDE website where you can download the latest user guide and software.
One of the benefits of the MCUXpresso IDE is support for Windows, Linux and Mac operating systems. Select your specific OS and continue download, then start the install.
During the last steps of install, the popup may seem to lock up, but it does free up after a few minutes. Just trust.
I installed the IDE on my Windows 7 Pro laptop. Depending how tight you firewall security settings are you may receive the following popup when the IDE initially starts up. Just click the “Allow access” button.
Adding the SDK Configuration-
Start the build and import a SDK for your specific SBC by going back to https://mcuxpresso.nxp.com/en/welcome website clicking “Select Development Board”. This will redirect you to the Select Development Board page. Select the FRDM-KW41Z dev board from the drop down list, then press “Build MCUXpresso SDK” button. Note: This detail is also covered in UM10989, Sections 2.1.3 thru 2.1.4.
From the SDK Builder page, select “Add software component” under “Select Optional Middleware”. From the pop-up window you can select or deselect many different features to add (or not) to your SDK. For our demo, you will need to specify the NTAG I2C middleware and the FreeRTOS OS support. Since you may want to try other features in the future you may want to add additional support such as BLE, Thread and 802.15.4 support as shown below, but it is not necessary for our demo.
Don’t forget to save your changes, then review your configuration and press “Request Build”
After you SDK has built, you can download your SDK archive (includes documentation and project code examples).
Copy the SDK .zip archive file to your project directory and then open your MCUXpresso IDE
Then set your workspace directory
Once the IDE opens, drag the SDK zip file into the “Installed SDKs” panel of the IDE
Respond [OK] to the confirmation pop-up
The SDK should now be successfully added to your IDE configuration. To install the example project code, click “Import SDK example(s)…” under “Create or import a project”, then pick your dev board and desired example to try, as shown below.
Finally your example projects will appear in the projects tab of the IDE
Now that was both smooth and easy!!
Checking for Dev Kit to Host PC Connection –
Before continuing, if you haven’t, attach the OM23221ARD, NTAG I2C Plus Kit For Arduino Pinout, board to the FRDM-KW41Z target SBC, then plug the Micro USB cable end into the FRDM-KW41Z board and the USB type A cable end into your host PC.
At this time it may be a little helpful in checking that the dev board is setup correctly on your host PC. The IDE uses a virtual USB disk drive setup through the OpenSDA interface to upload the firmware to the SBC. When the dev board is connected to the host PC, the virtual drive should appear as shown below.
The device manager directory tree is shown below.
In my case, the PC will communicate to the kit through a USB-to-Serial connection, JLink CDC UART Port. A virtual disk drive is also created to drop compiled HEX files into. If these devices do not get created on your PC, check for other driver solutions or let me know.
Opening the Demo Project, Compiling and Uploading -
Once again, the process for opening the demo project, building the code, then uploading it to the target board is not mentioned in the main demo app note, so I will use a modified procedure from the UM10989 app note.
Under the project tab of the IDE, expand the explorer demo project directory. Under the source directory, open the ntag_i2c_explorer_demo.com file. Click “Build” under the Quickstart panel and you should see the compiling process output appear in the console window to the right.
After the build finished, the firmware can be uploaded to the SBC by clicking “Debug” under the Quickstart panel, prompt the following pop-up window to appear. You can suppress this window in the future, but for now press “Accept”. At completion the console window should display “SEGGER J-Link GDB Server V6.40 - Terminal output channel”.
The software has been uploaded, but since we are running in debug, you must press F8 to resume operation. You can also resume, suspend or terminate operation from the main “Run” drop down menu. That’s it and now we’re really to run some tests.
NOTE: The above section outlines the build of the NTAG I2C Plus demo example firmware. Another example is supplied through the SDK zip file, the LED blink program. Although I have verified the functionality of this program, the details are not included in this review. The compiling and operation of the program is similar to that of the demo example and should be easy to complete following the procedure used for the demo program.
Part IV – Testing the Board:
Now for some fun stuff, but first a word of discovery. In submitting the application for the RoadTest one of the questions included is whether I had the equipment needed to complete my tests and write the review. My respond was yes, but after starting my test I discovered that the Samsung Galaxy J3 Prime (2017) did not support NFC. This was a surprise since most newer phones do. Anyway I did manage to dig up an older phone, Samsung Galaxy Avant (2014 – Android 4.4.2/KitKat and tablet, ASUS/Google Nexus 7 (2012 – Android 5.1.1/Lollipop) that supports earlier versions of NFC. As you can see from the picture below, the phone (on the left) has seen better days with its crack screen, but still seems to make NFC connections. Experimenting with each device has shown the most sensitivity area of the phone is located about 2” from the lower back of the unit and for the tablet about 2” from the top. In both devices, the vertical locations are down the center of the units. On the tablet, the NFC antenna is located on the removal back cover.
As I’ve mentioned in my summary, my main focus in evaluating a product is whether it does was it says it does and how well are the instructions (i.e. User Guide and app notes) written to get you there. Well, to beat a dead horse, the documentation is so disorganized and piecemeal that I’m going to have to resort to my very last method of demonstrate, a video. If you have seen any of my videos you will know why.
Most of the tests are driven by the Android NTAG I2C Demo app which is divided into 4 segments: 1) Demo, 2) NDEF, 3) Speed and 4) Config. Each segment is shown below as screenshots from the Android app following the startup screen
The screenshot on the left is the startup flash screen. The image on the right is the prompt screen while wait for the tag to connect. All these screens can be customized using Android Studio per NXP app note UM10989.
NOTE: During the NFC demo, if an error occurs in the transfer of data, the red user LED on the SBC will flash. It will continue to flash until the error has been corrected.
DEMO
Phone Tablet
The Demo page shows the status of the tag connection. Although not clear in the screenshot, the transfer arrow will continually change direction between the device and tag during a stable connection. When no connection is established the transfer status is “non”. Some features, such as temperature, are not supported on the OM23221ARD dev board. As shown above, the energy harvesting voltage (EHV), as detected by the NT3H2x11 chip on the dev board, is part of the information transfers during communication link. While the phone/tablet was stably mount next to the dev board, the EHV often varied from .2 to .8V. When a stable connection is present, touching one of the color panels under “Board configuration” on the Android device will cause the corresponding color LED on the SBC to light, as well as the Android icon to change color. Finally, you can break the NFC connection from the dev kit by tapping the NFC icon.
NDEF
Phone Tablet
Phone Tablet
NDEF (NFC Data Exchange Format) is a binary message format to exchange application-defined payloads between NFC Forum Devices or to store payloads on an NFC Forum Tag. A payload is described by a type, a length and an optional identifier encoded in an NDEF record structure. (https://nfcpy.readthedocs.io/en/latest/topics/ndef.html)
This is the way to exchange text and/or data between the host and the tag. There are 4 different record formats; Text, Uniform Resource Identifier (URI), Bluetooth (BT) and Smart Poster (SP). The default content of the tag is shown in the upper 2 screenshots representing the read page. As you can from the write page, you can customize the information and format. The read/write performance data is also shown on NDEF page. The sufficient difference in speed, especially for writes, is reflective of the internal hardware of the differences between my phone and tablet.
SPEED
Phone Tablet Tablet – 76 Byte Transfer Tablet – 652 Byte Transfer
As implied, the speed demo displays the transfer speed both from and to the NFC and the Android devices by way of the host MCU through its I2C interface connection. The setup for the test allow for different size 64 byte “payloads” and internal memory destinations (i.e. SRAM or EEPROM). As noted from the NDEF tests, the phone seems to perform faster transfers, which may be the cause of the “Phone sends too fast or Tag was lost” message. The results are repeatable.
CONFIG
Phone Tablet
Results - Read tag memory Read Session Registers Read/Write Config Registers
The configuration menu is primarily intended as a utility to explore and modify the settings of the NTAG I2C plus chip increasing the flexibility of the demo. The “Reset” button returns the tag to its default settings. The “Read tag memory” button the tag memory content in hex and ASCII formats. The “Read Session Registers” icon displays current status of the tag. Finally, the “Read/Write Config Registers” button allows the user to read and modify the tag configuration settings. Before attempting to modify the configuration of the tag, you might want to check out the NFC Forum website, as well as the NT3H2211 datasheet (see “Useful Documents Links” section).
NOTE: Unlike some bootloaders, OpenSDA, for this application, set the firmware upload in volatile memory on the SBC. If power is removed all programs and configuration memory is lost unless stored in EEPROM.
SCREEN PROTECTION
Screen Unprotected Screen Protected Password Selection
One additional feature of the demo is screen protection. The state of protection is indicated by the lock icon in the upper right hand corner of the screen, as indicated above. When the icon is touched, the select password panel appears with a password selection and the current protection state. The above image shows the status as “Protected”.
OTHER STUFF
The source code for the demo programs, both SBC and Android based, is quite extensive and is not included in this review. The most relative code for the demo can be found in the NFC library which is available by downloading the SW3647.zip file or by using the SDK Builder app. This and the Android source code (SW3648.zip) can be found on NXP’s website.
The I2C signal contacts are easily accessible on the top of the shield board.
What I didn’t try (much)
I was interested in see how quickly the energy harvesting amplitude dropped off with distance between the Android and dev board, but although I did try, I would lose connection altogether at distances greater than 1/2 cm. I was hoping for connectivity of at least 5 cm, but this may also be due to the older Android device capabilities.
What’s next?
I’m interested in trying newer Android devices to extend my sensitivity measurements.
Please let me know if I missed something in my review or if you have any questions. Also please pardon my typos.
Gordon Margulieux
Meridian, ID USA
