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

From Embedded Systems Learning Academy
Jump to: navigation, search
(→‎Team Members & Responsibilities)
(→‎Project Source Code)
 
(162 intermediate revisions by 2 users not shown)
Line 1: Line 1:
−
=== Grading Criteria ===
+
== Hyperintelligent NFC Locker of the Future ==
−
<font color="green">
 
−
*  How well is Software & Hardware Design described?
 
−
*  How well can this report be used to reproduce this project?
 
−
*  Code Quality
 
−
*  Overall Report Quality:
 
−
**  Software Block Diagrams
 
−
**  Hardware Block Diagrams
 
−
**:  Schematic Quality
 
−
**  Quality of technical challenges and solutions adopted.
 
−
</font>
 
−
 
 
−
== Project Title ==
 
  
 
== Abstract ==
 
== Abstract ==
−
This section should be a couple lines to describe what your project does.
+
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 & Introduction ==
−
Show list of your objectives.  This section includes the high level details of your project.  You can write about the various sensors or peripherals you used to get your project completed.
+
=== Objectives ===
 +
The objectives of the Hyperintelligent NFC Locker of the Future include:
 +
#Constructing a fully functional locker system
 +
#Interfacing NFC with the locker system
 +
#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 ===
 
=== Team Members & Responsibilities ===
 
*  Devin Villarosa
 
*  Devin Villarosa
−
**  Driver Development
+
**  Driver Development, System Architecture, Project Manager
 
*  Hien Nguyen
 
*  Hien Nguyen
−
**  Locker Construction
+
**  Locker Construction, Mobile Application Development
 
*  Gregory Pace
 
*  Gregory Pace
−
**  FreeRTOS Software Design
+
**  FreeRTOS Software Design, Networking
  
 
== Schedule ==
 
== Schedule ==
−
Show a simple table or figures that show your scheduled as planned before you started working on the project.  Then in another table column, write down the actual schedule so that readers can see the planned vs. actual goals.  The point of the schedule is for readers to assess how to pace themselves if they are doing a similar project.
 
−
 
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
 
! scope="col"| Week#
 
! scope="col"| Week#
−
! scope="col"| Date
 
 
! scope="col"| Task
 
! scope="col"| Task
−
! scope="col"| Actual
+
! scope="col"| Projected Completion Date
 +
! scope="col"| Actual Completion Date
 +
! scope="col"| Status
 
! scope="col"| Notes
 
! scope="col"| Notes
 
|-
 
|-
 
! scope="row"| 1
 
! scope="row"| 1
 +
| Order Parts
 
| 3/21
 
| 3/21
−
| Order Parts
+
| 3/21
−
| Completed?  Problems Encountered?
+
| Completed
−
|
+
| Some changes to the designs were made and extra parts were ordered after the initial date.
 
|-
 
|-
 
! scope="row"| 2
 
! scope="row"| 2
 +
| NFC Module
 
| 3/28
 
| 3/28
−
| RFID Module
+
|  
−
| Completed?  Problems Encountered?
+
| Incomplete
−
|
+
| Documentation was limited and getting started on the code was difficult
 
|-
 
|-
 
! scope="row"| 3
 
! scope="row"| 3
 +
| Locker Application
 
| 4/4
 
| 4/4
−
| Locker Application
+
| 4/18
−
| Completed?  Problems Encountered?
+
| Completed
−
|
+
| Constructing the locker was fairly quick and simple. However, figuring out how to attach our locking mechanism and place our components in the box took longer than expected.
 
|-
 
|-
 
! scope="row"| 4
 
! scope="row"| 4
 +
| Android Smartphone Application
 
| 4/11
 
| 4/11
−
| Android Smartphone Application
+
| 5/16
−
| Completed?  Problems Encountered?
+
| Complete
−
|
+
| A lot of documentation on NFC applications is provided by Android.
 
|-
 
|-
 
! scope="row"| 5
 
! scope="row"| 5
 +
| Communication Between Phone and Locker
 
| 4/18
 
| 4/18
−
| Android Smartphone Application
+
|  
−
| Completed?  Problems Encountered?
+
| Incomplete
−
|
+
| Phone was able to detect PN532 Module, but was unable to send or receive application data from it.
 
|-
 
|-
 
! scope="row"| 6
 
! scope="row"| 6
 +
| Implementing a Two Locker System
 
| 4/25
 
| 4/25
−
| Android Smartphone Application
+
|  
−
| Completed?  Problems Encountered?
+
| Incomplete
−
|
+
| Actual completion date was pushed back to do difficulties of finishing the NFC module component. Can not be completed without completion of NFC.
 
|-
 
|-
 
! scope="row"| 7
 
! scope="row"| 7
 +
| Reserved to Catch Up
 
| 5/2
 
| 5/2
−
| Communication between phone and locker
 
−
| Completed?  Problems Encountered?
 
 
|
 
|
 +
| Incomplete
 +
| Used time to figure out how to get NFC module to work. Corrected major errors in NFC code. Full packets finally received from PN532.
 
|-
 
|-
 
! scope="row"| 8
 
! scope="row"| 8
 +
| Reserved to Catch Up NFC
 
| 5/9
 
| 5/9
−
| Reserved to catch up
+
|  
−
| Completed?  Problems Encountered?
+
| Incomplete
−
|
+
| Research NFC-DEP protocol to understand information from PN532.
 
|-
 
|-
 
! scope="row"| 9
 
! scope="row"| 9
 +
| Final Tests and Aesthetics, Continue on NFC
 
| 5/16
 
| 5/16
−
| Final Tests and Aesthetics
+
|
−
| Completed?  Problems Encountered?
+
| Incomplete
−
|
+
| Research NFC LLCP, attempted to write code to handle NFC LLCP processing on SJ-One Board.
 
|}
 
|}
  
 
== Parts List & Cost ==
 
== Parts List & Cost ==
−
Give a simple list of the cost of your project broken down by components. Do not write long stories here.
+
 
 +
{| class="wikitable"
 +
|-
 +
|+ Bill of Materials
 +
! scope="col"|
 +
! scope="col"| Quantity
 +
! scope="col"| Part
 +
! scope="col"| Price Per Unit
 +
|-
 +
! scope="row"| 1
 +
| (3)
 +
| [[SJ_One_Board|SJ One Board]]
 +
| $80
 +
|-
 +
! scope="row"| 2
 +
| (1)
 +
| [//www.homedepot.com/p/Unbranded-1-in-x-12-in-x-8-ft-Select-Pine-Board-HDPR11208/203412642?N=5yc1vZbqmc 1 in. x 12 in. x 8 ft. Select Pine Board]
 +
| $33.46
 +
|-
 +
! scope="row"| 3
 +
| (2)
 +
| [//imall.iteadstudio.com/im130625002.html ITEAD PN532 NFC MODULE]
 +
| $17.00
 +
|-
 +
! scope="row"| 4
 +
| (2)
 +
| [//www.amazon.com/Universal-Heavy-Power-Actuator-hardware/dp/B00BSKTUXO/ref=sr_1_12?ie=UTF8&qid=1398982441&sr=8-12&keywords=linear+actuator Universal Heavy Duty Power Door Lock Actuator Motor 2 Wire 12V]
 +
| $5.13
 +
|-
 +
! scope="row"| 5
 +
| (2)
 +
| [//www.amazon.com/Leegoal-Stepper-Driver-Controller-Module/dp/B008BSGA7K/ref=sr_1_1?ie=UTF8&qid=1398982807&sr=8-1&keywords=motor+controller Leegoal L298N Stepper Motor Driver Controller Board Module]
 +
| $7.50
 +
|-
 +
! scope="row"| 6
 +
| (1)
 +
| [//www.amazon.com/dp/B008MUD9IK/ref=pe_385040_30332190_TE_M3T1_ST1_dp_3 Logisys 480W 240-Pin Dual Fan 20+4 ATX Power Supply PS480D2]
 +
| $13.99
 +
|-
 +
! scope="row"| 7
 +
| (1)
 +
| [//www.tapplastics.com/product/plastics/cut_to_size_plastic/acrylic_sheets_transparent_colors/519 Cast Acrylic]
 +
| $26.51
 +
|}
  
 
== Design & Implementation ==
 
== Design & Implementation ==
−
The design section can go over your hardware and software design. Organize this section using sub-sections that go over your design and implementation.
+
=== Hardware Design ===
 +
[[File:CmpE146 S14 NFCLocker BlockDiagram.jpg|550px]]
 +
 
 +
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====
 +
 
 +
[[File:CmpE146 S14 NFCLocker PowerDiagram.jpg|450px]]
 +
 
 +
{| class="wikitable"
 +
|-
 +
|+ System Powering Table
 +
! scope="col"|
 +
! scope="col"| Submodule
 +
! scope="col"| Voltage Needed
 +
! scope="col"| Voltage Supplier
 +
|-
 +
! scope="row"| 1
 +
| SJOne Board
 +
| +5V
 +
| ATX Power Supply
 +
|-
 +
! scope="row"| 2
 +
| NFC Module
 +
| +3.3V
 +
| SJOne Board
 +
|-
 +
! scope="row"| 3
 +
| Actuator Submodule
 +
| +12V
 +
| ATX Power Supply
 +
|-
 +
|}
 +
 
 +
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.  
  
−
=== Hardware Design ===
+
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.
−
Discuss your hardware design here. Show detailed schematics, and the interface here.
 
  
 
=== Hardware Interface ===
 
=== Hardware Interface ===
−
In this section, you can describe how your hardware communicates, such as which BUSes used.  You can discuss your driver implementation here, such that the '''Software Design''' section is isolated to talk about high level workings rather than inner working of your project.
+
 
 +
====Actuator Subsystem Interface====
 +
[[File:CmpE146 S14 NFCLocker Actuator Submodule.jpg]]
 +
 
 +
 
 +
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====
 +
 
 +
[[File:CmpE146 S14 NFCLocker NFCModule.jpg]]
 +
 
 +
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====
 +
 
 +
[[File:CmpE146 S14 NFCLocker UART.jpg]]
 +
 
 +
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 ===
 
=== Software Design ===
−
Show your software design.  For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level.  Do not show the details of the code.  For example, do not show exact code, but you may show psuedocode and fragments of code. Keep in mind that you are showing DESIGN of your software, not the inner workings of it.
+
[[File:CmpE146 S14 NFCLocker SoftwareFlowchart.jpg|250px|frame|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:
 +
[[File:CmpE146 S14 NFCLocker NFCFrame.jpg|400px|none]]
 +
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:'''
 +
[[File:CmpE146 S14 NFCLocker NFCSPIFRAME.jpg|400px|none]]
 +
 
 +
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 [http://members.nfc-forum.org/specs/spec_list/ 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 [http://members.nfc-forum.org/specs/spec_list/ 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 ====
 +
[[File:CmpE146 S14 NFCLocker PhoneAppFlowChart.jpg|thumb|200px|right|clear|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.
 +
 
 +
{| class="wikitable"
 +
|-
 +
|+ Actuator Module State Table
 +
! scope="col"|
 +
! scope="col"| Actuator State
 +
! scope="col"| Duty Cycle of PWM1
 +
! scope="col"| Duty Cycle of PWM2
 +
 
 +
|-
 +
! scope="row"| 1
 +
| Extend
 +
| 99%
 +
| 0%
 +
|-
 +
! scope="row"| 2
 +
| Retract
 +
| 0%
 +
| 99%
 +
|-
 +
|}
  
 
=== Implementation ===
 
=== Implementation ===
−
This section includes implementation, but again, not the details, just the high level. For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash. You can include sub-sections for each of your component 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====
 +
[[File:CmpE146 S14 NFCLocker PhoneAppScreenshotOne.jpg|200px]]
 +
[[File:CmpE146 S14 NFCLocker PhoneAppScreenshotTwo.jpg|200px]]
 +
 
 +
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====
 +
 
 +
[[File:CmpE146 S14 NFCLocker Software UART.jpg|500px]]
 +
 
 +
 
 +
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 & Technical Challenges ==
−
Describe the challenges of your project.  What advise would you give yourself or someone else if your project can be started from scratch again?
 
−
Make a smooth transition to testing section and described what it took to test your project.
 
  
−
Include sub-sections that list out a problem and solution, such as:
+
=== 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.
  
−
=== My Issue #1 ===
+
==== NFC Module ====
−
Discuss the issue and resolution.
+
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 ==
 
== Conclusion ==
−
Conclude your project here.  You can recap your testing and problems.  You should address the "so what" part here to indicate what you ultimately learnt from this project. How has this project increased your knowledge?
+
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 ===
 
=== Project Video ===
Line 127: Line 351:
  
 
=== Project Source Code ===
 
=== Project Source Code ===
−
Send me your zipped source code and I will upload this to SourceForge and link it for you.
+
*  [https://sourceforge.net/projects/sjsu/files/CmpE244_SJSU_S2014/ Sourceforge source code link]
  
 
== References ==
 
== References ==
 
=== Acknowledgement ===
 
=== Acknowledgement ===
−
Any acknowledgement that you may wish to provide can be included here.
+
We would like to acknowledge Preetpal Kang and Dr. Haluk Özemek.
  
 
=== References Used ===
 
=== References Used ===
−
List any references used in project.
+
# [//www.nxp.com/documents/user_manual/UM10360.pdf LPC176x/5x User Manual]
−
 
+
# [//www.nxp.com/documents/user_manual/141520.pdf PN532 User Manual]
−
=== Appendix ===
+
# [//http://www.ecma-international.org/publications/standards/Ecma-340.htm EMCA Near Field Communication Interface and Protocol]
−
You can list the references you used.
+
# [//http://members.nfc-forum.org/specs/spec_license NFC-Forum Technical Specifications]
 +
# [//developer.android.com/guide/topics/connectivity/nfc/index.html Android Developers Near Field Communication API]

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

Week# Task Projected Completion Date Actual Completion Date Status Notes
1 Order Parts 3/21 3/21 Completed Some changes to the designs were made and extra parts were ordered after the initial date.
2 NFC Module 3/28 Incomplete Documentation was limited and getting started on the code was difficult
3 Locker Application 4/4 4/18 Completed Constructing the locker was fairly quick and simple. However, figuring out how to attach our locking mechanism and place our components in the box took longer than expected.
4 Android Smartphone Application 4/11 5/16 Complete A lot of documentation on NFC applications is provided by Android.
5 Communication Between Phone and Locker 4/18 Incomplete Phone was able to detect PN532 Module, but was unable to send or receive application data from it.
6 Implementing a Two Locker System 4/25 Incomplete Actual completion date was pushed back to do difficulties of finishing the NFC module component. Can not be completed without completion of NFC.
7 Reserved to Catch Up 5/2 Incomplete Used time to figure out how to get NFC module to work. Corrected major errors in NFC code. Full packets finally received from PN532.
8 Reserved to Catch Up NFC 5/9 Incomplete Research NFC-DEP protocol to understand information from PN532.
9 Final Tests and Aesthetics, Continue on NFC 5/16 Incomplete Research NFC LLCP, attempted to write code to handle NFC LLCP processing on SJ-One Board.

Parts List & Cost

Bill of Materials
Quantity Part Price Per Unit
1 (3) SJ One Board $80
2 (1) 1 in. x 12 in. x 8 ft. Select Pine Board $33.46
3 (2) ITEAD PN532 NFC MODULE $17.00
4 (2) Universal Heavy Duty Power Door Lock Actuator Motor 2 Wire 12V $5.13
5 (2) Leegoal L298N Stepper Motor Driver Controller Board Module $7.50
6 (1) Logisys 480W 240-Pin Dual Fan 20+4 ATX Power Supply PS480D2 $13.99
7 (1) Cast Acrylic $26.51

Design & Implementation

Hardware Design

CmpE146 S14 NFCLocker BlockDiagram.jpg

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

CmpE146 S14 NFCLocker PowerDiagram.jpg

System Powering Table
Submodule Voltage Needed Voltage Supplier
1 SJOne Board +5V ATX Power Supply
2 NFC Module +3.3V SJOne Board
3 Actuator Submodule +12V ATX Power Supply

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

CmpE146 S14 NFCLocker Actuator Submodule.jpg


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

CmpE146 S14 NFCLocker NFCModule.jpg

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

CmpE146 S14 NFCLocker UART.jpg

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:

CmpE146 S14 NFCLocker NFCFrame.jpg

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:

CmpE146 S14 NFCLocker NFCSPIFRAME.jpg

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.

Actuator Module State Table
Actuator State Duty Cycle of PWM1 Duty Cycle of PWM2
1 Extend 99% 0%
2 Retract 0% 99%

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

CmpE146 S14 NFCLocker PhoneAppScreenshotOne.jpg CmpE146 S14 NFCLocker PhoneAppScreenshotTwo.jpg

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

CmpE146 S14 NFCLocker Software UART.jpg


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

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
Retrieved from "http://socialledge.com/sjsu/index.php?title=S14:_Hyperintelligent_NFC_Locker_of_the_Future&oldid=9510"