Functional Specifications - University of...

University of Portland Donald P. Shiley School of Engineering Phone 503 943 73145000 N. Willamette Blvd. Fax 503 943 7316Portland, OR 97203-5798

Final Report

Project WiFi Clock: A digital clock that updates according to the time of a National Time Protocol Server, so that it is always on the correct time.

Team Members:

Rosemary Peters (Spring Team Lead)

Kirby Wigton (Fall Team Lead)

Nate Perkins

Joe Haggberg

Faculty Advisors:

Dr. Aziz Inan

Other Contributers:

Dr. Joseph Hoffbeck

Dr. Tanya Crenshaw

.........

FINAL REPORT REV. 1.0 PAGE IITEAM WELCOME TO WOOP WOOP

Revision HistoryRev. Date Author Reason for Changes

0.1 22 Mar 2012 N. Perkins Completed top-level of Technical Outcomes. Began working on individual component sections.

0.2 29 Mar 2012 N. Perkins Completed Technical Outcomes section.

0.3 31 Mar 2012 N. Perkins Completed half of the Process Outcomes section.

0.4 4 April 2012 N. Perkins Completed Process Outcomes section. Began Introduction.

0.8 5 April 2012 N. Perkins All sections completed, need to add pictures.

0.9 5 April 2012 N. Perkins, R. Peters, K. Wigton, J. Haggberg

Team went over the document as a whole and updated the final report

1.0 20 April 2012 R. Peters, K. Wigton, N. Perkins

Made corrections from v0.9 and updated report for final turn-in.

.........

FINAL REPORT REV. 1.0 PAGE IIITEAM WELCOME TO WOOP WOOP

Table of ContentsIntroduction.....................................................................................................................6

Technical Outcomes........................................................Error! Bookmark not defined.

Top Level..................................................................................................................7

Detailed Components Section....................................................................................8

MPLAB IDE.................................................................................................8

WiFi Module.................................................................................................9

PIC32 Microcontroller (Processor)..............................................................10

I/O Expansion board....................................................................................13

LCD Screen................................................................................................13

Process Outcomes.........................................................................................................15

Assumptions............................................................................................................15

Changes..................................................................................................................15

Milestones...............................................................................................................16

Risks.......................................................................................................................17

Resource Requirements...........................................................................................18

Conclusions...................................................................................................................19

.........

FINAL REPORT REV. 1.0 PAGE IVTEAM WELCOME TO WOOP WOOP

List of FiguresFigure 1. High Level Block Diagram......................................Error! Bookmark not defined.

Figure 2. MRF24WB0MA PICtail WiFi module...................................................................7

Figure 3. PIC Microcontroller on I/O Expansion Board......................................................8

Figure 4. LCD......................................................................................................................8

No table of figures entries found.

Figure 6. WiFi Module Block Diagram. 10Figure 7. WiFi Module to Pick Microcontroller Connections................................................10

Figure 8. General PIC32MX3XX Block Diagram................................................................11

Figure 9. Block Diagram of Processor Core.........................................................................11

Figure 10. Block Diagram of Timing Applications...............................................................12

Figure 11. J10 and J11 on the I/O Expansion board.............................................................13

Figure 12. Block Diagram of LCM-S01602DTR/A.............................................................14

Figure 13. Pin Configuration for LCM-S01602DTR/A.......................................................14

.........

FINAL REPORT REV. 1.0 PAGE VTEAM WELCOME TO WOOP WOOP

List of TablesTable 1. Milestones from Design Document

.........

FINAL REPORT REV. 1.0 PAGE 6TEAM WELCOME TO WOOP WOOP

IntroductionAs part of our senior design course, we designed a WiFi clock that read the time off of a Network Time Protocol (NTP) server and displayed the time to an LCD screen. The clock was designed to be extremely accurate as opposed to standard clocks which tend to become inaccurate over time. To accomplish this, we combined the use of MPLAB, a WiFi module, a PIC microcontroller, and an LCD screen.

Building the WiFi clock involved many ups along with the downs. We were able to complete the hardware quickly, but struggled with the software due to our lack of experience in computer networking and C coding. This caused the connection to an NTP server to be a difficult task for us. The members of our team are all hardware oriented, and this is the reason why the hardware portion of our project was completed quickly without much difficulty. However, we were extremely surprised with how much software was involved in our project. MPLAB was completely new to us, and it was a significant part of the project. This caused us to achieve all of our major milestones except for the connection to an NTP server.

Our team did an excellent job of working together, and being an efficient, organized, and fluid team. Everyone got along well and meeting as a team was easy. We set concrete meeting times which helped us complete our milestones and kept us moving forward as a team. We also did a great job with the hardware component of the project. We were able to have plenty of time to work on MPLAB and the software section.

We struggled at times with motivation for the project. At times, our busy schedules got in the way of the project, and we were not able to work hard during some weeks. We also should have been more in tune with our advisor and kept him more involved with our project. He would have been able to offer more suggestions for us on the clock or directed us to the right people.

The first section of this document is the technical outcomes section. This section describes all of the components used in the project and how they electronically work and connect together. The second section describes the process outcomes. This section presents how we were able to communicate as a team and make necessary changes to the project since we wrote the design document. The process outcomes section demonstrates that an engineering project will never be completed exactly as it was originally designed, because some problems and other issues will be encountered while the project is actually being built and implemented.

.........


Technical OutcomesTop Level

Figure 1. High Level Block Diagram

Main Components of the project:

MPLAB IDE: This is the main software component of the project. MPLAB is used to compile all of the coding for the microcontroller. This includes the coding for finding the NTP server required for the WiFi Module to connect to. MPLAB also compiles the code for displaying from the Microcontroller to the LCD display.

WiFi Module: We planned to use a MRF24WB0MA PICtail WiFi module to wirelessly connect to an appropriate NTP server. The WiFi module was to relay with the microcontroller every day to find the NTP server time which was then to be displayed on the LCD.

Figure 2. MRF24WB0MA PICtail WiFi module

PIC32 Microcontroller: All of the coding that is compiled in MPLAB is processed by the microcontroller. The coding that is required for connection to the NTP timestamp is contained in the microcontroller along with the coding to display to the LCD screen.

I/O Expansion board: The I/O Expansion board was used with the PIC Microcontroller. By mounting the PIC onto the board, it was easier to access all of the pins for the microcontroller. The WiFi Module was also plugged directly into the I/O Expansion board.

PIC32 MicrocontrollerWiFi Module LCD Display

MPLAB IDE

.........


Figure 3. PIC Microcontroller on I/O Expansion board

LCD Screen: The LCD Screen will receive the NTP timestamp from the microcontroller to display the correct time on its screen. The LCD operates the same way as described in the Design Document.

Figure 4. LCD

Detailed Components Section

MPLAB IDE

This software is built to work with the PIC microcontroller. It runs on windows to speed up application development and makes debugging the PIC32 much faster. MPLAB IDE also has a single unified graphical user interface for hardware development tools. Upgrading from the software simulator to hardware debugging is easy since MPLAB IDE tools all run on the same user interface. MPLAB allows easy application development, by writing C code, and then building the project. Hardware can then be analyzed by the debugger. The correct C code for our project is code that can connect to the NTP server and code that allows displaying to the LDC screen.

The code in MPLAB IDE was written in C and then run through the C Compiler using the “Build” function. Then it was converted into a combination of ones and zeroes which is the correct code for the PIC32. The code was then tested using the debugger. Once this was completed, the code could then be “burned” into the PIC and displayed on the LCD screen. We succeeded in getting MPLAB to work properly.

.........


A component that was especially helpful during the work with MPLAB was the PIC32MX Starter Kit. This kit was used to ensure that MPLAB would work for us when we first began coding.

WiFi Module

The WiFi Module (MRF24WB0MA) from Microchip Technology Inc. is a low-power, 2.4 GHz, IEEE Std. 802.11-compliant, surface mount module with all associated RF components. The MRF24WB0MA module uses the integrated PCB meander antenna, having 360 degree connection capability. The pin layout for the WiFi Module is seen below in Figure 5.

Figure 5. Pin Diagram of WiFi Module

The MRF24WB0MA module is designed to be used with Microchip’s TCP/IP software stack which is downloadable online. The software stack has an integrated driver that implements the application protocol interface (API) that is used in the modules for command and control, and for management and data packet traffic. An API is a particular set of rules (‘code’) and specifications that software programs can follow to communicate with each other.

The combination of the module and a PIC running the TCP/IP stack results in support for IEEE Standard 802.11 and IP services. This allows the immediate implementation of a wireless web server which our group can use to obtain the NTP timestamp.

The block diagram in Figure 6 represents a MRF24WB0MA module. It interfaces to Microchip’s PIC32 microcontroller through a four-wire serial slave, SPI interface – interrupt, hibernate, reset, power, and ground signals. The module runs on a single supply voltage of nominally 3.3V. The MRF24WB0MA interfaces to Microchip’s PIC32 microprocessor with minimal external components through digital-only connections.

.........


Figure 6. WiFi Module Block Diagram

Figure 7 shows a simplified example connection between a Microchip PIC MCU and the module. Something that wasn’t taken into account at the time of the design document was the need for an I/O Expansion board that the WiFi module needed to plug into. The I/O Expansion board allows for power to be given to the WiFi module and for a connection to the PIC32.

The information that we obtained from our design document was very accurate as far as how the WiFi module works. The idea behind the WiFi module was correct at the time.

Figure 7. WiFi Module to PIC Microcontroller Connections

PIC32 Microcontroller (Processor)

The PIC connects to an I/O Expansion Board that also holds the WiFi module. The PIC contains the code for retrieving and displaying the data from the NTP timestamp. The I/O Expansion board contains the proper additional pins for the PIC to connect to the WiFi and the

.........


LCD screen. These functions depend on which peripheral features are on the device. Below, in Figure 8 is a general block diagram of the core and peripheral modules in the PIC32MX3XX family of devices.

Figure 8. General PIC32MX3XX Block Diagram

The MIPS32® M4K® Processor Core is the heart of the PIC32MX3XX family processor. The CPU fetches instructions, decodes each instruction, fetches source operands, executes each instruction and writes the results of instruction execution to the proper destinations. Figure 6 below shows the breakdown of the processor core.

Figure 9. Block Diagram of Processor Core

.........


The MIPS32® M4K® Processor Core execution unit implements a load/store architecture with single-cycle ALU operations (logical, shift, add, subtract) and an autonomous multiply/divide unit. The core contains multiple 32-bit general purpose registers used for integer operations and address calculation.

PIC32MX3XX microcontrollers provide 4 GB of unified virtual memory address space. All memory regions including program, data memory, SFRs and Configuration registers reside in this address space at their respective unique addresses. The program and data memories can be optionally partitioned into user and kernel memories. In addition, the data memory can be made executable, allowing PIC32MX3XX to execute from data memory. PIC32MX3XX devices contain an internal program Flash memory for executing user code.

The clock we built was programmed through MPLAB using the RTSP (Run-Time Self Programming) mode. RTSP is performed by software executing from either Flash or RAM memory. RTSP techniques are described in this chapter.

For running a clock when internet connection is unobtainable, the PIC32MX RTCC module is intended for applications in which accurate time must be maintained for extended periods of time with minimal or no CPU intervention. Low-power optimization provides extended battery lifetime while keeping track of time. The following are some of the key features of this module:

• Time: Hours, Minutes and Seconds; 24-Hour Format (Military Time); provides Calendar: Weekday, Date, Month and Year

Figure 10. Block Diagram of Timing Applications

There were no problems getting the PIC Microcontroller to run properly using the design document. No major or even minor changes were needed except for the need of an I/O expansion board since all the proper pin connections weren’t directly on the PIC.

.........


I/O Expansion board:

The I/O Expansion board was used as a bridge between the PIC Microcontroller, WiFi Module, and the LCD screen.

The Starter Kit I/O Expansion Board provided full access to microcontroller signals, additional debug headers, and connection of PICtail Plus daughter cards. Microcontroller signals were available for attaching prototype circuits or monitoring signals with logic probes. Headers were provided for connecting JTAG tools or Microchip tools using the 2-wire (ICSP) interface. The starter kits could be used to provide power to the I/O Expansion Board. The amount of power is determined by the drive capability of the USB port connected to the Starter Board's debugger at connector J1. If additional power was required, we could have connected an optional 9V power supply (#AC16203) to the I/O Expansion Board.

Mounting the PIC onto the board made it easier to access all of the pins for the microcontroller. The WiFi Module was also plugged directly into the I/O Expansion board via a serial port. We connected the LCD screen to the Parallel Master Port on the I/O Expansion board in order to have the PIC microcontroller “talk” to the LCD about what message to display. The wires were connected to pins on J10 and J11 (see figure 11).

Figure 11. J10 and J11 on the I/O Expansion board

LCD Screen

The LCM-S01602DTR/A from Digi-Key Corporation is 16x2 Character LCD Module. An LCD (Liquid Crystal Display) screen is an electronic display module and find a wide range of applications. A 16x2 LCD display is basic module. We preferred this module over a seven segment display or multi segment LEDs because LCDs are economical, easily programmable and have no limitation of displaying special and custom characters

.........


(unlike in seven segments) or animations. In this case, the LCD display will be used to display NTP time. Figure 12 is a block diagram of the LCD Module.

Figure 12. Block Diagram of LCM-S01602DTR/A

A 16x2 LCD means the LCD can display 16 characters per line and there are 2 lines. This LCD has two registers: Command and Data. The RS pin selects Command Register when low and selects the data register when it is high. A command is an instruction given to LCD to do a predefined task like initializing it, clearing its screen, setting the cursor position, and controlling display. The Data Register stores the data to be displayed on the LCD. The R/W pin reads data from the register when it is high and writes data to the register when it is low. The data is the ASCII value of the character to be displayed on the LCD. We will write to the register the time to be displayed on the LCD module. Figure 9 is a pin configuration.

Something that came up after the design document was completed was that the LCD screen would only work after a potentiometer was placed between a VCC wire and ground. The potentiometer allowed for the backlight of the LCD screen to display properly. Once the potentiometer got above the LCD threshold voltage, the intensity of the LCD lighting would increase. This was the only difference from the design document portion on the LCD.

.........


Figure 13. Pin Configuration for LCM-S01602DTR/A

Process Outcomes

Assumptions

The main assumption and mistake that was made on this project was that the team expected the connection to the NTP server to be much easier than it actually was. Not being a software oriented team, we should have looked into this more than we did and we should have thought about the consequences of not being experienced with networking and C coding. What we should have done in this case is speak to a computer science professor about how difficult it could be to connect to an NTP server so we could get an estimate on the amount of time it may have taken.

Another assumption that we made was that we believed the UP network would be easy to access and we would have no difficulties with the IS department. We had no idea that UP internet had so many obstacles. What we should have done to prevent this is get in touch with IS much earlier and ask them about the best way to get access to quality internet at UP, or we should have used a home network with much more freedom over the internet. The reason we decided against the use of a home network was our customer, Dr. Hoffbeck, specifically requested our clock to work with the UP network.

An assumption that we are still following is that the WiFi module and the PIC are communicating. That cannot be known for certain until we obtain the code for NTP and are able to wirelessly connect to the NTP server. This brings upon a final assumption. We believed that all the parts would work together properly when we ordered them despite our lack of experience in microcontrollers and WiFi modules. This assumption happened to be correct. All of the parts ended up working properly and fit together after we purchased the I/O expansion board and a PICtail for the WiFi module. Beforehand, we assumed that we could simply wire the components together but this was not the case. Without the I/O expansion board, we could have been interchanging parts constantly, trying to get the correct fits. Fortunately, all of the equipment fit together perfectly and this made the hardware easy for the group.

.........


The component heating and cooling that was discussed in our assumptions turned out to be a non-factor in the project. The clock has never been on long enough to have a problem with how hot the components are. It seems that the clock is not heating up much while it is turned on.

Changes

The design document turned out to be very accurate. We implemented nearly all of the design that we had planned before winter break. Some things that we had not taken of were the potentiometer for the LCD screen that was discussed and the I/O expansion board and PICtail for the WiFi module that need to be added in order to have all of the proper pins for the WiFi module and the LCD screen.

A simple change that we made was to use a simple 9V battery to run the clock instead of plugging into the wall. We found out that it is very easy to use a battery on the clock using the plug in options on the I/O expansion board. We were able to put a switch on the clock as well as a means to save battery power and to keep the components from frying. The battery-powered clock is much more efficient and economical than a using a wall socket since this makes the clock portable as well as energy saving since a battery uses much less electricity than the wall socket would.

Moreover, when we first started our project, we were planning on reading in the atomic time from a website. After research, we found a time protocol called Network Time Protocol (NTP). We realized that our campus has an NTP time server which we could access to retrieve the time by giving the IS department the MAC Address of our WiFi Module. This would be far simpler than retrieving the time from a website. However, the NTP time retrieval is not as accurate as the atomic time; wireless retrieval will create a slight offset of a few milliseconds. We talked to our customer about the switch we wanted to make from the atomic to NTP timestamp. He was OK with us using NTP time since the difference in time between the NTP and atomic time is very slight and not noticeable to the end user.

Finally, we had planned on being able to check for daylight savings time changes on the clock, but our clock design implementation was not complete by the time daylight savings came into effect. So time wise, checking for daylight savings time changes became impossible.

Milestones

Number Description Completion Date

1 Complete Functional Specifications 9/30/112 Update Func. Specs. With Design Changes 10/9/113 Determine Exact Parts to Purchase 10/15/114 Present October Program Review 10/28/11

.........


5 Complete Microchip Tutorial 11/4/116 Find Viable NTP Server to Use 11/5/117 Finish Design Rough Draft 11/11/118 Complete Final Budget 11/12/119 Complete Project Design 11/19/1110 Present November Program Review 12/2/1111 Peer Evaluations and Turn In Lab Notebooks 12/5/1112 Complete Code Between WiFi Module and PIC 2/3/1213 Perform Daylight Savings Time Test 3/11/1214 Complete Project Assembly 3/23/1215 Complete Final Report 4/13/1216 Complete Founder’s Day Presentation 4/17/12

Table 1. Milestones from Design Document

All of our milestones due before winter break were met easily. The team did a great job staying on time with the schedule and working together. Things were going smoothly and the team was completing their documents effectively. One reason for this was that there were no problems encountered with the actual building yet, so there were no serious obstacles in our progress before winter break.

After winter break, we began to fall behind on our milestones. We also realized that we didn’t put in place enough milestones – the ones we had were too general. The team completed the hardware a little earlier than expected, so we began to slow down in late January and early February. This resulted in the team falling slightly behind to complete our PIC to WiFi connection. These tasks were completed around late February due to complications with MPLAB and broken USB ports on the computer that we were using in the senior design project lab that we did not foreseen. MPLAB was difficult for the team to figure out because it involved many different files and startup programs for its proper operation. Our team’s lack of software experience was blatantly obvious as we fumbled through different files that may or may not have been good fits for MPLAB. Eventually, we were able to build programs on MPLAB and get it to work. We did this by changing some settings in MPLAB under the build function.

The hardware was assembled quickly in late January, so that was not a problem. After working for a month on connecting the WiFi module to the internet, we were still unable to do so by Founders day on April 17. We ran into several issues in trying to create this connection. The main issue involved our working with Information Services. Although we gave the department the MAC address of our WiFi module in November and we had internet access, it was very limited internet access. It was impossible for our WiFi module to connect to the NTP server with all the restrictions placed upon it when entered into the system. After gaining full administrative access, we also ran into a problem with a low WiFi signal in the senior design lab. Dr. Crenshaw had been a huge help for us throughout our trying to gain an internet connection, but she was only available at limited times.

.........


Risks

The biggest risk was the WiFi module failing to access the server. The team predicted that this would be a low-risk issue, but it turned out to be the risk that ultimately led to the project not being completed according to our design. We underestimated this risk and did not expect this to be a problem, but it became the biggest challenge we faced.

Another risk that we took into account was a situation in which the NTP server we were going to read the time from went down causing the clock to become inaccurate. We were unable to get to this point of the project and had a new plan for what we would do if the NTP server was down. The PIC microcontroller has a built in oscillator that would be able to keep a clock time until the NTP server was able to get back on track.

The third risk we considered was a situation in which the components would not communicate properly. This ended up not being an issue after we purchased the I/O Expansion board for our PIC Microcontroller. The PIC Microcontroller plugged directly into the I/O Expansion board and the WiFi module with the PICTail did as well. Our LCD needed to be wired to the board using the Parallel Master Port. All the components were correctly wired together and we had no serious hardware problems.

Overall, the risk that was the most severe was the failure to get the WiFi module to connect to a server. We put a lot of time and effort into getting a connection, but we were unable to fix the problem. Time should have been put in earlier to try and solve this problem.

Resource Requirements

We spent 399.75 man hours on our project. We thought designed the project to be simple so that it would not get in the way of our busy schedules. In March, when we began to try and get a WiFi connection, we had to meet far more often and put in a significant amount of work compared to the time when we were focused on hardware. If we had gotten the WiFi to work as planned, we would have spent much less time on it and would have had much more free time. This is a perfect example of needing to plan for three times as much work as was originally thought.

We kept a low budget and were able to purchase everything necessary for the project. A couple of items needed to be added to the budget. These were the I/O expansion board for the PIC and a 9V battery supply to power up the board. These items were fairly cheap so our total cost still ended up under the total available budget. We spent a total of $166.22.

The facilities that were provided to us were adequate except the broken USB ports on computer 15092. The lab on the third floor was especially helpful as we were able to have our own station and plenty of space to operate with.

.........


.........


ConclusionsTeam Welcome to Woop Woop completed all of our objectives, with the exception of getting an internet connection. With the information that we have, we should have been able to make a connection.

Even though we were unable to connect to the internet, we still learned a lot from this project. The team had hardly any software experience yet we took on a project that was software intensive. Now we have developed new skills in computer networking and C coding that we may eventually use throughout our careers.

Next time that any of the team is faced with a similar situation, we will need to take into account problems that we may face with greater caution. We were ill prepared for a situation where we could not get an internet connection. We would advise future teams to allot more time for their project than they plan on using, because we ultimately ran out of time. We would also recommend that groups do not get involved with a project that is not in their area of expertise, especially if you do not enjoy the other discipline. This created a stressful project at the end of the term which caused us not to complete the WiFi portion of the clock.

Functional Specifications - University of...

Documents

Transcript of Functional Specifications - University of...