** Indeffed (slang): Used to describe a user, account, or IP address that is indefinitely blocked or banned from certain or all actions.
1.0 Introduction
We all know the drill. We arrive, smile at the receptionist and in a friendly voice explain that you’re So-n-So from Company X-Y-Z and have a meeting with Mr. or Ms. You-Know-Who. The receptionist then dutifully instructs you to fill in your details in the Visitor’s Book and then once your meeting is confirmed you would be issued with a Visitors pass etc.
Now, unfortunately, with the introduction of General Data Protection Regulation (GDPR) the opportunity to peruse through the list of names while filling in your details is no longer possible. What a killjoy!
So, what is the alternative to writing in your name and company details countless times in visitor books, which now have to be GDPR compliant?
Well, I’m not the first to look at this problem. You only have to search online for “Visitor Management Systems”, or other similar search terms, to find a range of self service kiosks and touch screen devices (or software for Android tablets or iPads) to essentially do the same thing, which is to provide a GDPR compliant system that allows you to manually enter in your name and company details countless times.
Enter the NFC-based Office Sign-In System for non-iNDEF’ed Visitors... a sort-of “fast-track” visitor sign-in process, for visitors that happen to have an NTAG Type 2 card with their VCard details stored on it or have a modern cellular smart-phone with NFC and BLE capabilities.
The new electronic Visitor's Sign-In interface is made up of three key modules:
- An NXP NFC PN7150 Controller - this provides three tasks:
- Reads NDEF messages from NFC Tags
- Writes NDEF text type messages to NFC enabled phones
- Writes Access Codes to MIFARE cards (for purpose of a pseudo access control system)
- A Cypress PSoc 4 BLE module - this provides one task:
- a secure means of connecting with an App on a smart-phone to transfer information
- An ESP8266 WiFi module - this provides one task:
- a wireless means of connecting to an Office LAN for the purposes of communicating with a back-end server
2.0 Exploiting NDEF Messages (RTD’s) with NXP’s PN7150 NFC Controller Library
First, let me briefly explain what I know about NFC NDEF (for sake of completeness).
Image Source attributed to: By Erik Hubers - Own work, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=37867764
As can be seen in the above diagram by Erik Hubers, the creation and handling of NDEF messages is all in the Application Layer and NDEF messages can only be stored on NFC tags or cards that are formatted to store these formats. Not all tags and cards have the same data storage capacity so it is up to the developer to check first to ensure that the tag or card is suitable. The total amount of vCard data, for example, can be quite large therefore requiring an NFC Tag Type 2 or better.
Using a description found on Wikipedia, NFC Data Exchange Format (NDEF) is a common data format that can store and transport items ranging from any MIME-typed object to ultra-short Signature-based Record Type Definition (RTD) documents, such as URLs, for example.
The NFC Forum added a Simple NDEF Exchange Protocol (SNEP) to the spec to allow sending and receiving messages between two NFC devices.
According to the NFC global forum, “The Simple NDEF Exchange Protocol (SNEP) allows an application on an NFC-enabled device to exchange NFC Data Exchange Format (NDEF) messages with another NFC Forum device when operating in NFC Forum peer-to-peer mode. The protocol makes use of the Logical Link Control Protocol (LLCP) connection-oriented transport mode to provide a reliable data exchange.”
An NFC Record Type Definition (RTD) essentially specifies the format and rules for building standard record type definitions based on the NDEF data format. The NFC-Forum has four specific NDEF Record Type Definitions RTDs, namely:
- Text: used to store text strings in multiple languages. A derivative of the Text RTD would be the implementation of the vCard format.
- URI: used to store Uniform Resource Identifiers (URI).
- “Smart Poster”: combines URI and Test RTD’s put URLs, SMSs or phone numbers on an NFC tag.
- Generic Control now deprecated and superseded by “Verb”: used to encode generic and carrier-specific supported services, such as Bluetooth or WLAN, which can then be used to implement a Connection Handover to seamlessly implement a specific task.
For those who want to know more, I suggest reading Adafruit's learning page on the NDEF format for further insight.
Now, let’s move onto the NXP PN7150 NFC Controller (otherwise referred to as PN7150).
2.1 PN7150 NFC Controller Library
For those who are unfamiliar with the PN7150, I recommend reading the recent road test reviews. As mentioned in my review, once you overcome the initial learning curve problems, the PN7150 works rather well and is very versatile – all thanks to the NXP library that is available for use with this module.
So how does the PN7150 library handle NDEF?
Let' start with the primary function called from main(), which is task_nfc():
Depending on the precompiler settings, this function will first register callback functions to handle NDEF message push, if P2P_SUPPORT is defined and NDEF message pull functionality. if P2P_SUPPORT or RW_SUPPORT is defined.
It then runs through a number of functions to initialise and then waits until a device is detected. Then when a Discovery Notification is received, this function will respond depending on what precompiler settings were defined.
For our application, only P2P_SUPPORT and RW_SUPPORT is required, so any card reader presented to the PN7150, which is associated with CARDEMU_SUPPORT, will get ignored.
So, for example, if a NFC enabled phone is presented to the PN7150 the function NxpNci_ProcessP2pMode() will be called first (to handle NCI protocol data packets) before moving onto the next function call task_nfc_reader() if RW_SUPPORT is enabled, while if a MIFARE card or a NFC Tag, for example, is presented then only the function task_nfc_reader() will be called as with cards only RW_SUPPORT applies.
As NDEF is related to read and write or pull and push functionality, it is worth looking at the callback functions in more detail.
As shown in the diagram above, the PN7150 library has placeholders for all the key NDEF message types within the Pull Options callback function and also provides us with the ability to set and send messages to P2P supported devices via the SetMessage function and the Push Option function.
This is exactly what I need for my Office Visitors Book application.
3.0 Showcasing my first NDEF use-case: WiFi Provisioning (getting connected)
In my opinion, getting a WiFi-based device connected to the Internet via WLAN, when installing the remote device, remains a “thorn in the side” for anyone developing IoT systems as there is no foolproof solution out there. You only have to browse on any IoT product forum or FAQ’s to see that “how to connect to wifi” is up there in the top-5 list of most common queries.
So, as a mini-project, I decided to use NFC NDEF as a way to connect my Visitors Book Control device onto my chosen Wi-Fi based Wireless Local Area Network (WLAN).
To achieve this goal, I used an NFC TAG (Type 2) to store my WiFi Network details. These details were written to the tag using NXP’s NFC TagWriter App, which is available for free download via Google Play app store.
The process, as illustrated here using NXP App screenshots, to choose the WiFi network details, enter the password and then save the dataset and write to an NFC tag is pretty straightforward:
Then all I do is present the NFC tag to the PN7150 controller and the WiFi details are collected and these are then transferred to my ESP8266 via UART.
Here’s a short video demonstrating how this is done. As you will notice in the demo video, I now have the library ported across and working on a Cypress PSoC 4 BLE module which is plugged into CY8CKIT-042-BLE-Pioneer baseboard.
4.0 Next steps
This project is a system based Proof of Concept, which focuses on firmware and logic rather than hardware design. If fact, as they are no buttons or screens, all that needs careful consideration going forward would be where to position the NFC antenna within an enclosure. For this project it does not really add value to push the three development modules inside a box and so I plan to leave as is.
The next phase of the project will be to capture the vCard information or as will be demonstrated show a derived hybrid BLE method using a smartphone, which in my opinion, is better suited for office visitors and pre-arranged meetings etc.
Then, once the visitor’s details have been checked, there is the final stage, which is to use the PN7150 to write to a MIFARE card (this is used merely for demo purposes) an access code for an office access control system (which is outside the scope of this project).
To read part 2 of the NOVSIS project, CLICK HERE.
Top Comments