Difference between revisions of "S14: Hyperintelligent NFC Locker of the Future"

Latest revision as of 23:59, 6 August 2014

Hyperintelligent NFC Locker of the Future

Abstract

The team's idea behind the Hyperintelligent NFC Locker of the Future was to reinvent the currently outdated system of rental lockers. Current rental lockers require a user to input money to release a key and lock the locker. Then, when the user is done with the locker, they use the key to unlock the locker and the key is now stuck there for the next user. The Hyperintelligent NFC Locker of the Future is modernizing this process by using NFC technology from a user's smartphone as the "key" holder.

Objectives & Introduction

Objectives

The objectives of the Hyperintelligent NFC Locker of the Future include:

1. Constructing a fully functional locker system
2. Interfacing NFC with the locker system
3. Allowing our phones to lock or unlock the locker

Introduction

A user of the Hyperintelligent NFC Locker of the Future will walk up to a locker not being used and request a key by placing his/her phone on the NFC module. The key will save to the phone application. After receiving the key, the user can now lock the locker by issuing a lock command with the phone application and saved key. After unlocking the locker, the key will now be erased so the user can't use the lock again unless they go through the process again.

Team Members & Responsibilities

• Devin Villarosa
  • Driver Development, System Architecture, Project Manager
• Hien Nguyen
  • Locker Construction, Mobile Application Development
• Gregory Pace
  • FreeRTOS Software Design, Networking

Schedule

Parts List & Cost

Design & Implementation

Hardware Design

As shown above, the NFC locker system is composed of three uC: Two masters and one shared slave. The two masters drive their independent actuator subsystem, independent NFC module subsystem, and shares the slave.

The masters pull data from its NFC subsystem, and sends the data to the slave. The slave will either accept or reject the password. If the password is verified, the slave will then send information to the master, where the actuator subsystem will either lock or unlock the locker.

Power System Design

The system ranges in using three different voltages: +12V, +5V, and +3.3V. Because these voltages are standard in computer systems, the team used an ATX power supply. The ATX power supply provides a +12V, +5V, and a +3.3V output.

All ATX power supplies has a "safe power-up" feature in which the power supply will not turn on. In order to turn on the ATX power supply, the P.ON wire must be shorted to ground.

Hardware Interface

Actuator Subsystem Interface

An actuator is used as the physical locking mechanism for the locker. An actuator can only extend or retract depending on the direction a PWM signal is given. Because there are only two wires for the actuator, the actuator can only extend or retract, but not both. In order to obtain both functionalities, a motor controller is used. The motor controller that is used has two input signal pins. These input pins allows the PWM signals to flow in both directions. With software, the team used two PWM ports in which PWM port 1 will flow with a duty cycle of 99%, while port 2 has duty cycle of 0%. Depending if the actuator needs to lock or unlock, the two PWM ports are toggled. This allows a change of direction within the actuator

NFC Interface

The NFC module can accept High Speed UART (HSU), I2C, or SPI. Out of those three, SPI was chosen for this implementation. In total, seven wires were used to interface the host processor to the PN532. To power the PN532 we used the 3.3v and ground pins available on the SJSU one board. SPI requires three more wires, and the reset and interrupt pins were the last two. The interrupt pin is optional and is not needed for the PN532 to function. The team used the NFC module's interrupt pin because this software's framework is interrupt driven. The interrupt output tells the uC when it is ready. This will be discussed in more detail under the software implementation section for the PN532.

UART Micro-Controller Interface

Originally, the team wanted to use Ethernet as the networking medium between microcontrollers. Due to time constraints, the team abandoned Ethernet implementation and decided to use UART instead. In this UART implementation, a master uC initiates the communication with the slave. A master uC will send data from the NFC module to the slave uC. The slave will process the data and either send a verification frame or rejection frame to the master which will enable the master to lock or unlock the locker. In this design, two separate UART ports are used. This allows the slave uC to take in data from both masters when they send data concurrently.

Software Design

Original Design of The Locker Key Validation Procedure

NFC Software Design

Communication from the host controller between and the PN532 is done with packets. Each Packet is structured as follows:

Where

• Preamble: The start of a packet form Host to PN532
• Start of Packet: The indicator for the start of every packet
• LEN: Length of the packet data including the TFI
• LCS: Checksum for the Length, LEN + LCS = 0x00
• TFI: Frame identifier, 0xD4 for communication from the host to pn532, 0xD5 for communication from the pn532 to the host
• PD#: Byte of the payload
• DCS: Data checksum, TFI + PDO + PD1 + ... + PDN + DCS = 0x00
• Postamble: Ending byte for the frame.

For SPI communication, a byte with the value of 0x01 must also be sent before the packet when transferring packets from the host controller to the PN532.

Packets from the PN532 to the host controller generally do not include the Preamble byte.

Commands sent form the host controller to the PN532 follow a certain pattern. First the host controller sends a packet to the PN532. Then the PN532 sends an interrupt to the host controller telling it to drive the SPI connection to receive an acknowledgement (or non acknowledgement) from the PN532, indicates that the PN532 has registered the send command as valid (or invalid). The PN532 then interrupts the host controller again much later after the command has finished and the host controller can fetch the result for the command. Using the interrupt is optional, another system can instead constantly poll the status register of the PN532 to see when it is ready to sent the host controller something.

Normal Operation of SPI interface:

When the PN532 is turned on (or after the reset pin is inactivated), the PN532 goes into LowVBat mode. When ever the PN532 is in a low power consumption state (like lovVBat mode), it requires some time before the packet can be sent from the host to the PN532. This can be done in two ways with SPI,

• The host controller asserts the chip select pin and waits some time before sending the packet (one millisecond should be fine).
• The host controller asserts the H_REQ pin and waits for an interrupt from the PN532 to tell the host it is ready for the command (this was not implemented in this design).

Before the PN532 can start NFC, it needs to be configured into what mode it is going to emulate. The host processor needs to send the command SAMConfiguration to put it into the mode the system designer want it to be in. This design puts the PN532 into normal mode which will allow for the peer-to-peer communication needed. The SAMConfiguration command also tells the PN532 to enable the interrupt, but the default value is for it to be on. **If one wants to use the other modes of SAMConfiguration they need to purchase a SAM module and interface it with the PN532**.

To configure the NFC as a target, the TgInitAsTarget command needs to be sent from the host processor to the PN532. This design sets the mode of communication to DEP (Data Exchange Protocol) to enable peer-to-peer communication. A ten byte ID is then needed for the PN532 which can be set but should be randomly generated (for this design it is set). Lastly the general bytes need to contain the NFC magic number (0x46666D) and any LLCP (logic link control protocol) needed to interface the PN532 with an Android phone. Once this command is sent to the PN532 it will go into power down mode until another NFC device starts the NFC initiation sequence. Once this happens the PN532 will interrupt the host processor (and set its status register to indicate it is ready) and the host processor will receive a NFC status (and possible more) from the host processor. The status will indicate whether or not the packet was accepted by the host processor. The TgSetData and TgGetData can be used to send and receive data to and from the initiator NFC and PN532 module.

The protocol used to communicate between two NFC devices is entitled DEP (data exchange protocol). The module supports sending and formatting this protocol, but it still relies on the host processor to do some of the interpreting of the information of this protocol.

NFC-DEP commands

This section is included because trying to find reliable information on these commands took too much time away from the development of our system. These are listed as a quick reference for others to quickly grasp the DEP (data exchange protocol) for implementing a PN532-like device.

ATR_REQ, An attribute request

This command contains the information from an initiator to a target to configure the NFC connection. It contains the 10 byte NFC identification number of the initiator, a 1 byte identification number for a target, the bit rates the initiator can send and receive, the maximum payload supported, and optional general bits that can be used for anything (but Android uses them to setup up NFC LLCP). Each initiator can have up to 15 NFC targets.

ATR_RES, The response to the attribute request.

The same as ATR_REQ except its from a target to the initiator. It sends the same fields (but different values for the bit rates and optional general bits) of the ATR_REQ back to the initiator.

PSL_REQ & PSL_RES, parameter selection request/response

PSL_REQ is used by the initiator to reconfigure the connection, can change the bit rates and payload size. The PSL_RES is sent by the target to agree to the parameter changes.

DEP_REQ & DEP_RES Data exchange protocol request/response

Used for the initiator/target to send data, ack/nack, or request a timeout extension (for when host needs more time to process data)

DSL_REQ & DSL_RES Deselect request/response

Initiator wishes to deactivate a target.

WUP_REQ & WUP_RES Wake-up request/response

An initiator uses this to wake-up a deselected device (for active mode only).

RLS_REQ & RLS_RES Release a target request/response

When an initiator wishes to end the communication with a target.

The PN532 incorporates these DEP commands its own commands, but doesn't explain these DEP commands at all in its user guide. It took too much time for this team to search for these commands and understand their meaning. This is only a brief explanation of DEP. To see the full requirements listing for DEP, download the NFC Digital Protocol Technical Specification at NFC-Forum and look at section 16.

NFC LLCP

This was the crippling roadblock for implementing an Android driven locker system.

In order to send data between and Android phone and the PN532 the host processor needs to process the packets on the LLCP (logic link control protocol) level. LLCP is modeled after the OSI layer-2 protocol of 802.2. It's there to enable reliable data transfer by providing connection and connectionless transport. This team did not have enough time to implement LLCP due to the work needed to do so. The NFC-Forum gives a good explanation of NFC LLCP from its website. Download the NFC Logical Link Control Protocol (LLCP) Technical Specification from NFC-Forum to get a good idea on how to implement NFC LLCP.

If one wishes to implement any NFC device into an embedded system, they should check out http://nfc-forum.org/ and http://www.ecma-international.org/ for more information on the protocols. The PN532 user guide expects its readers to understand much of the protocols of NFC, and these links should provide resources into understanding them. If this team had known where to look for this information, it might have been possible to complet the NFC LLCP code needed and enable communication between an Android phone and the SJ-One board.

Phone Application Software Design

Android NFC Phone Test Application

The team decided to use the Android platform for our phone application since two of the members had a Samsung Galaxy S4 which made testing on the NFC module much easier. The application's main design principle is simplicity. It's important for the application to be quick and easy to use because a user would want to be able to lock or unlock his/her locker as quickly as possible. The flow of the application begins when you start up the application. The first thing that occurs is that the application will enter the idle state until the user enters a password. After entering a password, the password will then be saved into the application. The phone is actively checking for an NFC device and will keep looping until a device is found. When the user is ready to place the phone near the NFC module, the application will then detect the NFC module and send the password to the module. After sending the password, the phone application then goes back to idle and waits for the next password to be entered. It is up to the module to figure out if the password is correct and what action to take if so.

UART Communication Software Design

The locker system has multiple masters and one slave. In order to implement this design, multiple UART lines are used. The slave acts as a databank of passwords for the masters to communicate with. Because multiple masters may access the slave concurrently, the slave must be able to context switch to perform concurrent password checks.

Actuator Sub module Software Design

For this actuator's submodule, PWM is needed to control the actuator's state (either extending or retracting). PWM is composed of a frequency and duty cycle. Because the actuator submodule has an "on" or "off" state, the duty cycles used are either 99% (max) or 0% (min). Additionally, a specific frequency is not important for this module

As shown in the hardware implementation of the actuator sub module, in order to extend or retract the actuator, 2 PWM outputs are needed. Each PWM output is connected to the motor controller's inputs. The motor controller inputs dictates the direction of the signal. In order to extend, one PWM1 output must be active, while PWM2 output must be off. Likewise, in order to retract, PWM2 output must be active, while PWM1 output is off.

Implementation

NFC Implementation

The SJ-One Board used SPI communication to configure and retrieve data from the PN532. The module we purchased came with an antenna built into the PCB allowing the PN532 to communicate with another NFC device. This team got as far as configuring the PN532 into target mode and having the Android initialize the NFC connection to the system. The phone could detect the PN532 but could not establish a connection because the SJ-One board could not handle the NFC LLCP commands the phone was sending. If this team managed to write the code to have NFC LLCP commands processed by the SJ-One board, this system would have been able to transfer data from the phone to the board (and vise versa).

Phone Application Software Implementation

The Android application was relatively easy to implement due to the vast amount of community support for developers. As seen above in the screenshot of the phone application, you can clearly see the simplicity of the application which was one of the design principles. There is a textfield where a user can enter his/her password to open the locker and then hit the save password button. After hitting the save password button, the password is then stored into a string. After the phone detects an NFC device, it uses the Android NFC API to create an NDEF (NFC Data Exchange Format) message that is now ready to be sent. As seen in the screenshot above, when an NFC device is detected, the phone application will display on the screen "Touch to beam". After touching the application, it will now send the password to the NFC module on the locker. The microcontroller on the locker will now decide the next action.

UART Communication Software Implementation

The system consists a master and a slave. There are two components within this password structure: The locker ID(1 byte) and the NFC password(4bytes). Once the master uC has received the NFC data, it sends the password structure to the slave. The slave is predefined with an array of passwords. The slave will search the array of passwords. If the slave finds a matching password, it will send a verification byte to the master uC. If it does not find a password, the slave will send a rejection byte. After receive the verification or rejection byte, the master uC will then toggle its actuator to lock or unlock the locker. Additionally, in this implementation, there are multiple slaves with its independent UART Buses. Because more than one slave that may want to communicate to with the slave uC concurrently, the slave uses FreeRTOS to context switch. This will allow the slave to process the passwords concurrently.

Actuator Software Implementation

Testing & Technical Challenges

Testing

Android Application

The first set of testing was dedicated to the Android application because it was one of the first task completed and that could be tested on its own. In order to test our application, we just used another Android phone to receive the NDEF message being sent. We were able to successfully validate our phone application when we were able to send and receive our "locker password" between two NFC-capable phones.

NFC Module

Testing the NFC Module required an NFC enabled phone. It would act as the initiator and would be brought to the NFC module after the PN532 was set as a target. The resultant packets sent from the PN532 to the host processor were then output to a computer via USB. The output was then presented to us for analysis with the application Hercules.

Locking System

To test our locking system, we hooked up our microcontrollers, motor driver controller boards, and actuators. The actuators were then toggled to show the functionality of the locking system.

Technical Challenges

NFC Module

The most difficult part of this project was to get the NFC module to work as intended. Connecting everything was straightforward since everything was labeled on the NFC module. However, figuring out how to actually integrate the NFC module into our locker system was extremely difficult because it requires a deep and existing knowledge of NFC. In addition to just NFC knowledge, there was a lot of overhead because we had to also know about networking. Trying to get the NFC module to work took extensive hours of reading the datasheet and researching online about what was being read.

Ethernet

Initially, our goal for the networking portion of our locker system was to use Ethernet. This is because Ethernet provides high speed, long range, and the ability to expand if we were to add additional lockers. However, after working on integrating the Ethernet module into our system, we discovered that there was too much overhead for the scope of our project. We decided that it would be best to just use UART for this project, but Ethernet would definitely be something we would use if we wanted to improve our project.

Android Application

At first, developing the Android application was slightly difficult because none of the team members had any experience in developing a phone application. However, after reading the Android Developers page and using Google to find the answer to other questions, the phone application started developing nicely. The Android Developers page had an excellent guide to NFC basics. Using Google search, we were able to find out how to properly integrate a textfield and button into our application.

System Implementation and Time Constraints

All submodules of the locker system functions independently (with the exception of NFC), but putting all of the submodules together into one system was a failure due to time constraints. We failed to put everything together, because we did not identify how difficult it will be to finish the NFC module. We were able to create initial communication with the NFC module and phone, which led us to believe that we were almost finished. After weeks of research, and numerous attempts to finish the NFC module, we then realized that there was a lot more to complete for the NFC module to communicate with the Android phone. We wanted to finish the NFC module, because the entire system is based on the NFC application, but we found this problem too late. Because we diverted all of our attention on finishing the NFC module, we did not have time to put the entire locker system together. We realized that we spent the majority of our time on researching on NFC. This project will need at least 6 full months to complete in order to get a fully functional system

Conclusion

Coming into this project we didn't expect NFC to be nearly as complicated as it was, and the lack of knowledge about it hindered the development in this project. The PN532 does a good job of doing much of the work for NFC specific protocol and physical layers. Unfortunately in order to interface with the Android phone we would need to fully implement the NFC LLCP standard, which we learned about too late. We were unable to access the full data sheet for the PN532 but we were able to access the user guide. Unfortunately the actual protocols were referred to by their acronyms, and finding the documentation to give the description of these protocols took time. After taking the time to understand these protocols we were able to generate responses from the phone but were unable to understand the data that was sent to us. It took more time to discover that LLCP was required to communicate to an Android device. By the time we finished researching LLCP, we were out of time for the project.

Ultimately, our project idea might have been a bit too ambitious for our scope of knowledge. Working with the NFC module required an extensive knowledge of NFC and networking. In addition, there is not much documentation or community help with regards to NFC as compared to making the Android application.

Project Video

Upload a video of your project and post the link here.

Project Source Code

• Sourceforge source code link

References

Acknowledgement

We would like to acknowledge Preetpal Kang and Dr. Haluk Özemek.

References Used

1. LPC176x/5x User Manual
2. PN532 User Manual
3. EMCA Near Field Communication Interface and Protocol
4. NFC-Forum Technical Specifications
5. Android Developers Near Field Communication API