IDOCENT (Indoor Digital Orientation Communication and Enabling Navigation Technology) (Phase 2)

Transcription

1 IDOCENT (Indoor Digital Orientation Communication and Enabling Navigation Technology) (Phase 2) December 9 th 2011 Project Facilitator: Dr. John Deller Project Sponsor: Stephen Blosser Team Members Kirk Guotana Management guotanak@msu.edu Vadim Kim Document kimvadim@msu.edu Adam Partlo Webmaster partload@msu.edu Shreyas Thiagarajasubramanian Presentation thiagar3@msu.edu 1

2 Abstract This report describes the development and design for an indoor digital navigation system with the use of a smartphone and external microphones installed inside a building. Previous work on this technology has been completed utilizing existing Wi-Fi access points and determining location based on RF signal strength. Phase II incorporates the use of sound wave transmission from a smartphone to several microphones. The server calculates the user s position and sends this location data to the smartphone device via Wi-Fi. The scope of our testing is limited to campus buildings. 2

3 Acknowledgement ECE design team 2 would like to extend a special thanks to all the people and resources that assisted our project. Thank you to Mr. Stephen Blosser for assisting us in the development of our microphone module, to Greg Motter for educating us on the value of Design for Six Sigma Tools, to Dr. John Deller for helping us prepare for our formal presentations, provide feedback on technical documents, and contribute advice on how to achieve our objectives. Special thanks to our professor, Dr. Michael Shanblatt, for implementing a well-developed curriculum that has set us on track to succeed in this course, and in our future endeavors as professional engineers. 3

4 Table of Contents Abstract... 2 Acknowledgement... 3 Chapter Introduction... 6 Background... 7 Bluetooth... 7 Wi-Fi... 7 High Frequency Sound... 8 Objectives... 9 Chapter Design for Six Sigma Tools Fast Diagram Business Model Criteria for Success Application Chapter Design History Hardware and Software Implementation and Documentation Hardware Software Chapter Testing Procedure Components Phase Phase Phase 3 (Final Testing) Chapter Summary and Conclusion

5 Results Final Cost Final Schedule Future Plans Sound Frequency Multiple Users Security Multiplatform Size Cost Appendix Team Members Kirk Guotana Adam Partlo Vadim Kim Shreyas Thiagarajasubramanian Appendix Literature and website references Programs Used Technical Datasheets Appendix Appendix PSpice Simulation

6 Chapter 1 Introduction Since the first satellite navigation system, known as Transit, was tested and used by the United States Navy in the 1960s, Global Positioning System (GPS) technology has advanced from large scale government use to an at home personal application. Today, navigation or location devices are available for cars, planes, boats, and even cell-phones. GPS uses communication and computing systems which accurately calculates the user s current position and helps them to navigate to their destination. With rapid advancement of GPS technologies, the demand for increased usability and functionality has grown. Consumers now demand a variety of additional features including traffic delays, construction alerts, shorter or faster routes, fewer calculation delays, and increased accuracy. All of these demands are focused on outdoor use, while GPS capabilities inside structures have been limited. Due to the metal framing of most buildings, electronic GPS devices cannot maintain a signal once inside the structure. This drawback creates many complications for locational devices in use today. This is the problem that indoor Digital Orientation Communication and Enabling Navigational Technology (idocent) can solve. 6

7 Background Throughout the history of GPS technology, there is substantial research performed on a variety of different methods for indoor navigation. Several of the early attempts in developing indoor navigation included either Bluetooth or Wi-Fi. Both of these approaches were considered in the development of the idocent Phase II smartphone application. Bluetooth Bluetooth is popular for the use of Personal Area Networks, or PANs where a master and slave relationship is created between two or more devices. The technology has been growing in popularity because of the power efficiency features and ease of use. Nearly all smartphones today contain Bluetooth functionality. Although the technology is widely available, manufacturers who use Bluetooth do not follow a standard because there is not one defined by the Institute of Electrical and Electronics Engineers (IEEE). Since there is no standard, it is not regulated and manufacturers often modify functionality. Also, Bluetooth does not by default offer an easy method of signal strength calculation. In addition, Bluetooth has high security breach risks and it has a low transmitting range. In comparison to Wi-Fi, Bluetooth does not fit the criterion for indoor navigation applications. Wi-Fi Wi-Fi, or Wireless Fidelity, is a standard used today for broadcasting network connectivity. It is defined by IEEE under x. Most commonly, Wi-Fi is used for IP based networking equipment such as personal computers. The advantage of choosing Wi-Fi for a location based service is its high compatibility and frequency of availability. The majority of today s smartphones also have Wi-Fi connectivity. Newer revisions of Wi-Fi broadcast at the 2.4Ghz frequency, allowing for signals to more easily travel through obstructions like doors and walls. Unlike Bluetooth, Wi-Fi incorporates signal strength functions into all the firmware drivers and Application Programming Interfaces (APIs) which are defined by the manufacturers and backed by IEEE. This feature is 7

8 beneficial when using Wi-Fi to determine a location based on signal strength triangulation. High Frequency Sound Considering each technology, previous approaches, and weighing pros and cons of each, our team and sponsor chose to use a high frequency sound signal to determine location in Phase II of idocent. Microphone modules are installed throughout a building designed to receive a high frequency sound signal from a smartphone speaker. One advantage of microphone modules over Wi-Fi hotspots is that they are exclusively dedicated to only receiving sound signals from the idocent application. The user s location is calculated by using the speed of sound and time difference between signal transmission and reception. To communicate between the system and the idocent Phase II application, Ethernet, and Wi-Fi enabled smartphones are used. Figure 1: Diagram of Sound Signal Transmission to Microphone Receiver 8

9 Objectives In addition to basic requirements established from our sponsor, we created more objectives that would improve the project. The system must have audio feedback, as our target users are the visually impaired. Second, it must incorporate smartphones as the primary device. Third, it must accurately locate the user to within ten feet of their actual position. Fourth, the consumer will not require any additional hardware to use idocent Phase II (only software for their smartphone). All hardware and software must be within a reasonable price to not deter organizations from implementing this system. This approach is new and practical in that new microphone modules were created and the system utilizes mobile technology that will be readily available to most users in the near future. The system is also aware of how many microphones are connected. All microphone modules are directly connected to the server via Ethernet. When new modules are installed, the server detects the additional modules. If a microphone module is removed from a building, idocent Phase II will detect its absence and there will be no interruption in operation. The location coordinates of the module are mapped out and uploaded to the server. The functionality of idocent Phase II is very useful to a variety of users. Audible feedback features provide assistance to blind users while a graphical user interface (GUI) provides ease of use to others. idocent Phase II offers a complete navigational package with low cost, easy installation, and potential for future development. 9

10 Chapter 2 Design for Six Sigma Tools Fast Diagram 1 To properly identify end goals and assist with the overall development process, we used Six Sigma design tools. One of the most helpful tools we used was a fast diagram. The purpose of this exercise is to clearly define customer requirements and a way to implement them. The chart is set up that each block is connected to the answer of two questions; the block to the right is the answer of the question How?, and the block to the left is the answer to the question Why?. The main goal of our project is to locate the smartphone. This is done by sending a sound, receiving the sound, send notification of the event to the server, and triangulating the position. The sound is sent by activating the smartphones speaker, which is done by pressing a button on the phone. After sending the notification, the server receives it which is done by activating the Ethernet. Triangulating the position is completed by processing the data received by calculating the delay. Finally, the user will receive the information with their location. These steps are illustrated in Figure 2. 1 Mr. Gregg Motter: Six Sigma Overview lecture notes: 10

11 Figure 2: Fast Diagram 11

12 Business Model This six sigma business model tool describes the rationale of how an organization creates, delivers, and captures value. It is a blue print design consisting of building blocks that would help establish milestones for our product, understanding competition, attracting investors, reducing cost, and attracting employees. It describes and innovates the business and its product. This useful tool can easily illustrate a complete picture of a business from an overall perspective. Figure 3 demonstrates the model for idocent Phase II. Figure 3: Business Model Canvas 12

13 Criteria for Success The main purpose of idocent is to prove that high frequency audio signals are useful in indoor positioning. Therefore, the primary focus is whether our system can accurately locate the signal. A successful outcome consists of demonstrating that a person s location can be calculated within ten feet. As a result, our design is focused on functionality rather than efficiency, with the assumption that future implementations of this project will perform necessary optimizations. Our design revolved around completing this proof of concept within the given timeframe instead of any of cost or size restrictions. A Risk Analysis Diagram was created and followed to make this prototype design achievable, as shown in figure 4 on the following page. 13

14 Figure 4: The figures above shows the risks and likeliness of their occurrence during the design process. Being unable to process the analog signal into a usable digital signal would greatly affect our ability to produce a working prototype. 14

15 Application In Figure 5, the conceptual design illustrates a smartphone device establishing communication via a Wi-Fi or 3G connection with the idocent Phase II server. Upon connection, the phone will automatically access the server and download a map of the building. Once the phone application has loaded completely, there is a button onscreen which, when pressed, will trigger an audio signal to be emitted. Microphones in the area will receive this signal and relays notification to the server. The server assigns time stamps for each microphone module upon receipt of the notification. These time stamps will be used to calculate the smartphone user s location. After calculation, the location coordinates are sent to the smartphone. Figure 5: Map of Microphone Receivers in a Building 15

16 Chapter 3 Design History We changed the design multiple times throughout the semester. Most notably, we changed the target frequency. Initially, we decided on designing our microphone modules to receive a signal at the upper limit of the human hearing range, which is 20 khz. This consisted in designing the fifth order Butterworth band pass filter design for a center frequency of 20 khz. The results of testing this filter in a proto-board were undesirable. Emitting a 20 khz from a smartphone did not produce a clean signal on the oscilloscope. We determined the source of our problem was that a standard smartphone could not emit a 20 khz signal with high enough amplitudes to be picked up at a minimum distance of 15ft. The maximum distance that we could capture the signal without it blending into the background noise was approximately one foot. Before changing the frequency, we tested the other components to find the ideal frequency. With our focus on picking up the audio signal using an FFT, we decided to test the Atmel 32-bit microcontroller (AT91SAM7X512) that comes built into the Netduino Plus. This test failed due to a limitation on the speed at which it can read the analog to digital converter (ADC). After testing at lower frequencies, we determined that a 1.2 khz signal could be accurately detected. This concludes that the Netduino s ADC samples at approximately 416µs. With these considerations in mind, we decided to adjust the target frequency to 1.05 khz. At this frequency, a signal can be accurately detected up to a distance of 20 feet. This change in frequency resulted in redesigning the band pass filter. With the test circuit assembled on the proto board and using the FFT math function on the oscilloscope we found that noise was being generated by the circuit at this frequency. This noise was amplified along with our signal from the microphone and 16

17 overpowered our signal transmitted from the smartphone at distances over ten feet. We determined that the noise was coming from three possible sources: An op amp, a loose connection in the proto board itself, and/or outside noise coming in through the coupling capacitors. To narrow down the possibilities, we decided to fabricate printed circuit boards (PCBs) and build metal enclosures to shield the circuit from any outside noise and to ensure solid connections. Our next step was to create a prototype system on PCB boards. We designed the boards to leave room to make modifications if needed. We were also able to enclose the four PCB boards into metal enclosures. The first change we made was a decision to add IC sockets to the PCB boards for easy changing of the op amps. The second change was to add a potentiometer to adjust the gain stage of the microphone module. This potentiometer will be mounted to the side of the box so that adjustment can be made after the circuit is fully enclosed. The last change that we made was to modify the software design. We decided to eliminate the FFT function and instead take the average of the 64 sampled ADC readings. Doing this increased the range at which we can detect a sound signal from approximately 10 feet to more than 20 feet. While this increases our chances to recognize false positive sounds such as, someone clapping or screaming, we decided that we did not have the time necessary to perfect the FFT function and complete the rest of the hardware and software design. Therefore, we chose to focus our attention on building a prototype that would prove the concept of sound navigation. Hardware and Software Implementation and Documentation Hardware Server Our server is a Windows laptop running C# code that monitors a communication port. This server has four main functions: it holds the location data of all rooms and microphone modules, receives events from these modules, 17

18 calculates the location of the user, and sends location information back to the phone. This calculation is done based on the location of the microphone modules, the time stamps of when each microphone module relayed an event to the server, and the known speed of sound at room temperature. An event is triggered by a microphone module when it detects an incoming signal of 1.05 khz. Smartphone The smartphone used is a Samsung Focus, running the Windows Phone 7 operating system. This phone was chosen due to our team s expertise on programming in Microsoft s.net framework and one of our team members having one on hand. This phone was used to communicate with the server and microphone modules. The phone communicates over the wireless network with the server and emits a 1.05 khz sound signal to all microphone modules in the area. Router The router used is a D-link 4 port wireless router. This router is used to connect the three microphone modules and the server connected by Ethernet for speed and reliability. The router also accepts one wireless connection from the smartphone. It has been configured to use static Internet Protocol (IP) addresses, to ensure that our system s components can reliably communicate with each other. Microphone Module The microphone module consists of five main parts: the input, band pass filter, amplifier, microcontroller, and power supply. 18

19 Input The input to the microphone module is the CMB-6544PF, an electret condenser microphone. This microphone changes the sound wave transmitted from the smartphone into a usable analog signal. Figure 6: CMB-6544PF Band Pass Filter The band pass filter designed is a fifth order Butterworth band pass filter with a center frequency of 1.05 khz. This filter is used to attenuate as many background noises as possible, while allowing the center frequency to pass through. Fifth order means that the slope of the magnitude bode plot will decrease by 100 db s per decade above and below the center frequency. The op amps chosen for this design was the LF411 due to it having a low input noise voltage and current, large gain bandwidth product (GBP), and wide output voltage swing. Amplifier The inverting amplifier is used to increase the low analog signal propagated from the microphone, through the band pass filter, and to the amplifier. The op amp chosen for this design is an OPA134, which was chosen to its even lower noise voltage and even larger GBP when compared to the LF411. Figure 7: OPA134 Microcontroller The microcontroller used in our design is the Netduino Plus, which main purpose is to detect a 1.05 khz sound signal from the smartphone and send acknowledgment of this to the server. The Netduino Plus was 19

20 chosen due to its Ethernet capabilities and the programming language being similar to that of the server and phone. Power Supply A power supply was needed that would give us, +15VDC, -15VDC, +5VDC, +12VDC, and be capable of supplying a minimum of 350 ma. The P25A14E-R1B was chosen for this task. This power supply will produce +15VDC, -15VDC, and 5VDC at 500 ma, 300 ma, and 2.5 A respectively. The only voltage remaining is the 12VDC which could draw up to 200 ma of the 350 ma that was needed. To accomplish this, we designed a simple circuit as shown by its block diagram below. The main component is the LM340, a 12V voltage regulator. The capacitors are used to reduce the amount of ripple voltage. Software Programming Programming Language All of the software in this design is implemented in C#. The Windows Phone 7, Netduino Plus, and the Server all make use of the.net Framework. This is a framework designed by Microsoft that eases development for multiple platforms, enabling use of the same programming language and similar functionality across all of them. Client Server Communication The clients (Netduino, phone) and the server use the TCP/IP protocol to communicate with each other. Communication happens through the use of sockets. The client opens a socket with the server s IP Address hardcoded to , and the destination port is set to 80. The server monitors all communications coming in on port 80 and 20

21 performs actions based on the message received. If the message is from a phone, it sends a response granting permission for the phone to emit the audio signal. If the message is from a Netduino, the server executes its location calculation algorithm. Location Calculation Upon receiving an audio signal, each microphone module relays a message to the server with its Mac Address. The server uses this unique identifier and a hardcoded list of corresponding locations to store each module s location. In addition, it will record the time stamp of each module s message. Upon receipt of two such messages, the server will begin its calculation of the user s location. This algorithm utilizes the differences in time between the messages, the location of each microphone module, and the speed of sound to calculate the user s position. The algorithm is described below: X = micdistances[1] - micdistances[0]; T = timestamps[1] - timestamps[0]; timedistance = X / speedofsound; userposition = (timedistance - T) * speedofsound; micdistances[0] : location of the first microphone to send the message. micdistances[1]: location of the second microphone to send the message. X: difference between the microphone modules locations. T: difference between the time stamps of the microphones messages. speedofsound: the speed of sound timedistance: time it takes for sound to travel from the first microphone module to the second. 21

22 userposition: the location of the user. Given the time it takes for sound to travel from one microphone to the other, and the actual recorded time difference between the messages received, the position of the user between the microphones can be calculated. 22

23 Chapter 4 Testing Procedure Testing was done on each component during the construction of the system to verify functionality. Once the system was constructed, we tested and modified the completed design with our objective in mind. Components - Power Board - Microphone - Netduino Adapter Board - Band Pass Filter - Netduino FFT code - Client/Server communication (Netduino, Phone, and PC) Phase 1 The first phase of testing focused on each individual components. Power Board The power board was designed to take an input of +15V, -15V, 5V and a ground from an external AC-DC power supply through a 5pin din plug. The board was built to output the four inputs along with +12V. We tested each individual input using an Agilent DC power supply and multimeter to verify the expected output voltages. 23

24 Microphone We tested the microphone s functionality by attaching an oscilloscope probe and sending an audio signal from the smartphone. This was useful for both verifying its functionality and gauging its range. The oscilloscope gave us information on the sensitivity and frequency response of the microphone. Netduino Adapter Board The adapter board was tested to verify that it would properly connect to all the inputs and outputs on the Netduino. We tested that the traces on the board were all connected and that the pins functioned properly. Band Pass Filter The band pass filter was designed in PSPICE and simulated before being constructed. PSPICE allowed us to quickly change resistor/capacitor values and observe the circuit s behavior. Once we settled on a circuit design through PSPICE, the actual filter was constructed on a proto-board. This was tested using a function generator as the input, and reading its output on an oscilloscope. We then varied the frequency on the function generator to determine the frequency at which we had maximum gain and verified that the gain quickly decreased on either side of the center frequency. The circuit was verified again using this method after being fabricated onto a printed circuit board. Netduino Fast Fourier Transform Having written the code for the Fast Fourier Transform on the Netduino, we used a function generator to test its responsiveness. We attached the function generator s output as a digital input on the Netduino and ran the code with appropriate breakpoints set. This allowed us to debug the code, and see its behavior given various inputs from the function generator. Initially, this procedure revealed that the FFT may not work properly on the Netduino due to 24

25 the fact that it is a managed code environment, thus not offering the speeds required to perform the FFT accurately. As a result, we reduced our target frequency to be compatible with the Netduino s lower sampling rate. Using this new frequency, the code functioned as designed. Client/Server Communication The Netduino, phone, and PC are all connected to the same router. We first created the Netduino s client application, which communicates directly to the PC s IP Address using Sockets. Once we established that this works, we created server-side code for the PC for it to receive the Netduino s input and perform certain behaviors. This too was tested by repeatedly running the system. Once the Netduino/PC communication was established, we created the phone application to communicate with the PC through TCP/IP. Again, we verified this functionality and modified the server to support communication with the phone as well. Phase 2 Our second phase of testing involved connecting multiple components together. Instead of the function generator, the phone was used to generate a 1.05 khz signal, which would be received by microphone. The microphone s output was then fed directly into the band pass filter, which was then connected to the Netduino. Running the FFT on the Netduino revealed that there is noise present while testing with the microphone. In addition, the signal has very little gain, making our target frequency of 1.05 khz hard to distinguish. Increasing the gain by modifying the band pass filter increased our range, but there was still a large amount of noise in the system, rendering the FFT unreliable. With our deadline in mind, we chose to waive the FFT entirely. Instead, we decided to take an average of the volume of sounds heard at all frequencies, and trigger an event only if that average was high enough. Basically, we are relying on the band 25

26 pass filter to make sure only signals of approximately 1.05 khz get through to the Netduino, which measures only the signal s volume. This proved to be an effective and reliable method of detecting our input in a controlled environment. Phase 3 (Final Testing) Once all the components were assembled, we began testing as a complete system. At this point, we had a working microphone module which was capable of detecting a signal at 1.05 khz, at a range of approximately 15 feet. We also had communication established between the Netduino, the phone, and the server. Our final testing setup took place in a hallway and involved a series configuration of three microphone modules spaced 25 feet apart. A user would stand at various locations in this setup and trigger the 1.05 khz signal to be emitted from the smartphone. Initially, we were testing to verify that each microphone module was capable of receiving the signal, and whether the server was capable of receiving multiple communications in very short amounts of time. After this was verified, we tested with the location calculations made by the server. Upon receipt of these signals, the server would now record their time stamps and calculate the user s location. If only one microphone relayed a message to the server, then the user is said to be within 10 feet of that microphone which was our initial design accuracy goal. The system did work, but carried with it a large amount of error. On average, the error was about 15 feet. Our goal was to locate a user within 10 feet of their actual position, and our result using this method falls just short of that. However, when the method of locating the user is changed to one where only the first microphone to receive the signal is considered, we can more accurately locate the user. In this system, none of the sources of error (transmission delay, time stamps, etc.) are involved only a confirmation as to whether a signal was received or not. If a signal was received, we can say that the user was within a certain range of that microphone. This is a much more 26

27 simplistic system which would require the deployment of many more microphone modules. If there were more resources available, this would be a more viable option. 27

28 Chapter 5 Summary and Conclusion At the beginning of our project, we had many ideas for how the final design would work and the functionality it would have. With these ideas in mind, we began the process and started purchasing parts, building filters and testing the system. Throughout this process, we ran into many barriers that caused us to re-evaluate our goals and re-establish the criteria for a successful outcome. Our main objective as a team while working on idocent has been to provide a tool to assist the visually impaired. In conclusion, we have a prototype that has the potential to achieve this goal. Our first step in developing idocent Phase II was to learn about phase I. During the first few weeks, as a team, we researched all the information regarding the first phase of idocent. The team that worked on Phase I posted all of their information on the previous semesters course site. 2 We used their proposal, final report, and proposal presentation video to understand their objective and the progress they made. We learned that Phase I made use of the available Wi-Fi routers inside buildings to triangulate a user s location based on the signal strength. This was done on an android powered smartphone with an application containing the hallway layout. In Phase II, a similar application is used to send out an audio signal that will be received by microphone modules. Results The final design proved that high frequency audio signal can be used for indoor navigation. A smartphone application has been created to emit an audio signal and receive location coordinates from a server. The server is able to locate the user within ten feet of their actual position. To fully achieve the goal of assisting the visually impaired, audio feedback should be implemented in future designs

29 Final Cost Final Cost of idocent Phase 2 Part Quantity Cost Total Part Cost Ethernet Cables 4 $3.54 $14.16 Microphones 8 $1.05 $8.40 Netduino Plus 3 $59.95 $ Op-Amps 15 $2.85 $42.75 Power Supply 3 $41.71 $ Miscellaneous Electrical Components $27.33 $27.33 PCB Fab 12 $0.00 $0 Router 1 $0.00 $0 Server Space 1 $0.00 $0 Windows Phone 1 $0.00 $0 Total $ Budget Allowance Team 2 Allowance $ $ Cost of Parts $ $ Remaining Budget $ Figure 8: Final Cost 29

30 Final Schedule Name Duration Start Finish Predecessors Resource Names 1 Deliverables 2 Proposal 3 Pre-pre-proposal 12 days 9/2/11 8:00 AM 9/19/11 5:00 PM Team 4 Pre-proposal 10 days 9/19/11 8:00 AM 9/30/11 5:00 PM 3 Team 5 Final Proposal 17 days 9/30/11 8:00 AM 10/22/11 5:00 PM 4 Team 6 Webpage Online 7 Update with project information 54 days 10/1/11 8:00 AM 12/14/11 5:00 PM Adam 8 Add pictures of individual members and team 4 days 9/30/11 8:00 AM 10/5/11 5:00 PM Adam 9 Gantt Chart 25 days 9/2/11 8:00 AM 10/6/11 5:00 PM Kirk 10 Professional Self Assessment Paper 1 day 11/30/11 8:00 AM 11/30/11 5:00 PM Team 11 Application Notes 14 days 10/26/11 8:00 AM 11/14/11 5:00 PM Team 12 Design Issues Paper 16 days 10/31/11 8:00 AM 11/21/11 5:00 PM Team 13 Oral Presentation 14 Practice 1 day 10/14/11 8:00 AM 10/14/11 5:00 PM Team 15 Present 1 day 10/17/11 8:00 AM 10/17/11 5:00 PM Team 16 Technical Presentation 1 day 11/14/11 8:00 AM 11/14/11 5:00 PM Shreyas 17 Progress Report 18 1st Report 5 days 10/24/11 8:00 AM 10/28/11 5:00 PM Team 19 2nd Report 5 days 11/14/11 8:00 AM 11/18/11 5:00 PM Team 20 Engineering Notebook 1 day 10/24/11 8:00 AM 10/24/11 5:00 PM Team 21 Design Day Program Vadim 22 Project Progress 71 days 9/2/11 8:00 AM 12/9/11 5:00 PM Team 23 Parts 15 days 9/2/11 8:00 AM 9/22/11 5:00 PM 24 Mics 3 days 9/2/11 8:00 AM 9/6/11 5:00 PM Adam 25 BandPass Filter 3 days 9/7/11 8:00 AM 9/9/11 5:00 PM 24 Adam, Vadim 26 Audio Amplifier 3 days 9/12/11 8:00 AM 9/14/11 5:00 PM 25 Adam 27 MicroProcessor 3 days 9/15/11 8:00 AM 9/19/11 5:00 PM 26 Shreyas 28 Router 3 days 9/20/11 8:00 AM 9/22/11 5:00 PM 27 Kirk 29 Testing 56 days 9/23/11 8:00 AM 12/9/11 5:00 PM 30 Build Prototype 17 days 9/23/11 8:00 AM 10/17/11 5:00 PM 28 Adam, Kirk, Vadim 31 Test First Prototype in Lab 10 days 10/18/11 8:00 AM 10/31/11 5:00 PM 30 Kirk, Adam 32 Project Demonstration 5 days 11/1/11 8:00 AM 11/7/11 5:00 PM 31 Team 33 Test in realistic setting 23 days 11/8/11 8:00 AM 12/8/11 5:00 PM 32 Team 34 Design Day 1 day 12/9/11 8:00 AM 12/9/11 5:00 PM 33 Team 35 Meetings 36 With Sponser 37 Contact Stephen Blosser 1 day 9/12/11 8:00 AM 9/12/11 5:00 PM Team 38 During Group Meeting 1 day 9/19/11 8:00 AM 9/19/11 5:00 PM Team 39 With Faculity Advisor 40 Contact Jack Deller 1 day 9/9/11 8:00 AM 9/9/11 5:00 PM Team 41 Pre-proposal 1 day 9/26/11 8:00 AM 9/26/11 5:00 PM Team 42 During Group Meeting 1 day 10/3/11 8:00 AM 10/3/11 5:00 PM Team 43 2nd Project Demonstration 5 days 11/14/11 8:00 AM 11/18/11 5:00 PM Team 44 Group Meetings 45 Every Monday 61 days 9/12/11 8:00 AM 12/5/11 5:00 PM Team 46 Every Friday 61 days 9/16/11 8:00 AM 12/9/11 5:00 PM Team Figure 9: Final Schedule 30

31 Figure 10: Gantt Chart 31

32 Future Plans idocent Phase II is an experimental concept to locate the source of a high frequency audio signal. While working on idocent, our team had many suggestions as to how the system can be improved. Sound Frequency This system will typically be used in public areas where noise will be present. The most notable noise will be human conservation. Currently, our system is designed to pick up a signal of 1.05 khz. Due to the human voice falling between 100 Hz and 5 khz, during testing, a lot of ambient noise was picked up outside of our target signal. Also, depending on age, humans can hear sounds ranging from 20Hz to 20 khz. A frequency between this range can be an annoyance for others and also for the user. For future design, the system should be designed for a higher frequency that will be out of the human speech and hearing range. Multiple Users The system is currently designed for one user to send a sound signal and receive a location. idocent Phase II will need to be able to accommodate multiple users. To achieve this, there are a few possible solutions. 1) Set up a waiting list. The user sends a signal and the server places that user in a queue. The server will continue to only locate one user at a time, but will provide a way to acknowledge and respond to others users. 2) Set up different frequencies for each user. This will give each user a unique frequency and allow for multiple users simultaneously. Security Security is an issue that should be addressed before this system is put into use. Sound signals have a huge vulnerability in that they can be easily intercepted and reproduced. Our design focus was on functionality in a controlled environment. Before 32

33 installing in a public area, all possible misuses must be considered and protected against. Presently, there are no security measures to ensure that the proper and intended functionality will be guaranteed. Multiplatform One of the best features of idocent is that no additional equipment is required for the user. The smartphone application can easily be downloaded and function in a matter of minutes. The current application was programmed to only work on a windows phone. To accommodate all types of smartphones, the application needs to be programmed to work across multiple mobile platforms. This way, every type of phone will be able to use the system. Size The prototype system contains three microphone modules, a central server, and a router. Each microphone module consists of a Netduino microprocessor, power board, microphone board, and a filter board. This design should be made more compact. For the future, all the components could be combined into one. Cost Along with the size, the cost of the Netduino is high. The Netduino has many features that are not required for the functionality of the microphone module. Another microprocessor should be designed for the specific application of receiving and converting an analog high frequency audio signal to digital along with Ethernet capabilities. 33

34 Appendix 1 Team Members Kirk Guotana The technical work I was responsible for included designing a power supply for the microphone modules, creating Gerber files through Diptrace to create a printed circuit board (PCB), and testing all the hardware. Before I could begin work on the power supply, the parts for the microphone module needed to be determined. From there I would know what voltages and how much current would be needed to power the system. Working with the team, we started from the microphone and worked towards the Netduino choosing the parts. The first part was the microphone (CMB-6544PF), which required +5V. The microphone connects to a Butterworth filter and amplifier, which has four LM741 and one OPA134 op-amps requiring +15V and -15V to power. The filter then connects to the Netduino microprocessor which requires +12V. After determining the voltages needed (+5V, +15V, -15V, +12V), I researched online to find a design that would output these voltages from a standard 120 volt AC source. I had built and tested one design that would step down and invert 120 AC to +15 DC. Per suggestion from our sponsor, we decided to purchase a supply online containing +15V,-15V and +5V. From there, I designed a step down circuit that would take the +15V and output +12V. Having little experience in designing a PCB, I had to learn the Diptrace software from the beginning. I spent an afternoon learning how to input components to the board, and how to properly layout the traces. It was a tricky process placing all the components on the board and having everything traced together without overlapping. In designing circuits, I am familiar with building in a 3D environment. From this project, I learned how to convert our breadboard design onto a 2D circuit board. Diptrace has an auto trace feature that works well for the initial setup, but requires modifications for ease of soldering. When we received all the PCB s, I spent some time visually inspecting each trace. Then, I soldered the first prototype of the power board together. The next step was to electrically test for open and short circuits. Starting with the power board, I first tested to see that all the ground traces were connected. Next, I plugged in the three input powers, one at a time, and tested that the proper voltages were read at the output. After re-soldering a few cold solder joints, the power boards functioned as designed. The one board that gave us the most trouble in testing was the microphone module. Some of the issues include the -15V being shorted to ground, the signal not properly being amplified, and incorrectly sized coupling capacitor at the input stage of the amplifier. We modified the board with IC sockets and a potentiometer for easy modifications during testing. 34

35 Adam Partlo perform the FFT. The technical impact I had on our project was introducing the overall system design to the rest of my team members. This original design consisted of all the same main components that we have implemented in our final design with one variation. After extensive research into finding a microprocessor that met all of our requirements, I found that all of them needed a debugging interface that would put us over the budget allotted to us. Shreyas found the Netduino Plus, which has a microcontroller and Ethernet capabilities built into the board. The Netduino Plus also has many other features that we will not be using in our design. I attempted to program an 18F4550 PIC microcontroller to run a FFT on the output received from the microphone module. I found that the PIC controller did not have the memory required to I was responsible for designing, building, and testing the microphone modules. The microphone module consists of four major components: microphone, band pass filter, amplifier, and Netduino. I researched the various different types of microphones to find the best candidate for the design. The next component I needed to design was the band pass filter. For this, I chose to design a fifth order Butterworth band pass filter with a center frequency of 20 khz. When decisions were made by the team to change our target frequency, I then had to modify the band pass filter to 10 khz. After testing failed for 10 khz, I redesigned for our final target frequency of 1.05 khz. Each time, I first tested the design running a PSpice simulation of the circuit to verify it behaved as expected. Next, I built and tested the design on a proto board. The next component was an amplifier, which I chose to design an inverting amplifier with a variable gain. After building and testing each component separately, I then tested them as a complete system. The next major task was to take these components and move them from the proto board to PCBs. To do this, I used Diptrace to draw the schematic and convert this directly to a PCB. Diptrace came with a small learning curve and within a few hours I was very familiar with the features necessary to complete our boards. Once the boards were milled by the ECE shop, I inspected the boards for shorted traces. I then assisted Kirk and Vadim in assembling and testing the boards to ensure they worked correctly. 35

36 During this project I assisted Adam and Kirk with designing and Vadim Kim assembling the microphone module components. Due to many design and objective changes throughout the semester, several elements of idocent Phase II were redesigned. Designing the filter which would fit our project environment was one of the most challenging tasks. During this time, I became familiar with the Butterworth filter and learned some of the benefits of using it. The biggest advantage is that it has a very flat magnitude response in the pass-band, which is ideal for our system design. Our microphone module must pass 1.05 khz transmitted signal while eliminating all the low/high frequency noises. A fifth order band-pass filter was chosen due to a -100dB slope change in the stop-band region. In the process I was able to assist Adam in calculating resistance and capacitor values based on Butterworth fifth order filter and required pass-band frequencies. I assisted Kirk with design of the power supply for microphone modules. At first, we were going to use two 9V batteries as our primary power source and power over Ethernet as our secondary source. Through testing, we concluded that batteries were a poor option because they do not maintain consistent power over long periods of time. Therefore we decide to purchase a power supply that would convert AC to DC, output +15V, -15V, 5V, and could be directly plugged into each microphone module via a 5 pin connector. By using this power supply, our module became more compact, saved time, and eliminated the issue of a short circuit due to an unexpected power surge. Kirk and I picked a LM340 transistor and calculated the capacitor and diode values needed to step down our +15V, 350mA input power supply to produce +12 V, 200mA at the output. Additionally, I implemented a heat sink to the LM340 to prevent overheating. After the PCB boards were designed, the next step was to solder and test the Netduino adapters, power supply, filter circuit, and amplifiers. It took a lot of time to solder each component to the PCB board due to the small circuit design. After soldering, intense testing of every side of the circuit and each sub-system was performed before it was assembled together and connected to the power supply. This reduced the risk of shorting one or more of the system components due to an open or short circuit. Once every circuit board was assembled and tested I designed an enclosure design for each module. I decided that using a metal box would work the best, because it would eliminate outside frequencies interfering with our system. Also, sheet metal is easy to cut and bend to construct the box shape enclosure with appropriate openings for the power supply, microphone, potentiometer, and Ethernet. 36

37 Shreyas Thiagarajasubramanian My technical contribution to this project revolved around its software aspect. I implemented the communication protocol between the devices in our system. The design consists of three main components: A smartphone, the three microphone modules, and the server. Software needed to be written for each component to enable intercommunication. In addition, an algorithm needed to be developed to calculate the user s position. Having experience with Microsoft s.net framework, I proposed that we use the Netduino Plus as our microcontroller and Windows Phone 7 as our smartphone platform. The Netduino can be programmed using C#, and utilizes many of the.net libraries that I have experience utilizing on other platforms. In addition, it allows for step-by-step debugging of code and is relatively cheap when compared to similar microcontrollers. Once this was decided, I began work on a smartphone application to emit an audio signal of a desired frequency. Initially, the software worked, and we realized early on that the smartphone hardware was not capable of outputting a high frequency signal. We then decided to change the target frequency to 1.05 khz. I worked with Adam on porting an FFT code in C for the PIC18F4550 microcontroller to the Netduino in C#. This process had many problems. Certain features of C were not available in C#, and pins for the PIC18F4550 were referenced in the code that did not exist on the Netduino. I assisted Adam in testing whether the smartphone s audio signal is picked up and properly processed by the microphone module. Once the microphone module was able to receive and identify our smartphone s emitted signal, I began work on the network communications between each component of the design. Originally, we planned on using a remote server to process events in our design and calculate the user s position. However, due to possible network transmission delays which could throw off our readings, I changed the system to facilitate all communications on a local router. Instead of a remote machine, a laptop would be connected to the same router as the Netduino in the system and would function as our local server. Intercommunication between devices (Netduino, smartphone, and server) was implemented using TCP/IP socket programming. I tied the system s various parts together. This involved connecting the smartphone s audio signal code, the Netduino s FFT code, all of the networking code, and the server s location calculation algorithm in accordance with our design s communication protocol. Finally, I created a user interface for the smartphone app to make it user friendly. 37

38 Appendix 2 Literature and website references "Duplicating the Human Voice." InetDaemon.Com. Web. 20 Nov < "Frequency Hearing Ranges in Dogs and Other Species." Louisiana State University. Web. Sept < "IEEE-SA -IEEE Get 802 Program." The IEEE Standards Association. Web. 15 Sept < "Netduino Plus: Tech Specs." Netduino: Home. Web. Nov < Patil, Abhishek Pramod. "Performance of Bluetooth Technologies and Their Applications to Location Sensing." Web. Oct < Programs Used DipTrace - Professional Schematic & PCB Design Software. Web. Nov < "Microsoft Visual Studio Express." Web. Nov < Technical Datasheets "ARM-Based Flash MCU." Atmel. Web. Nov < "Audio Operational Amplifiers." Texas Instruments. Web. Oct < "Electret Condenser Microphone." CUI. Web. Sept < 6544PF_Datasheet.pdf?fileID=7582>. "LF 411 Operational Amplifier." National Semiconductor. Web. Oct < "P 25 A-T AC-DC Triple Output." Mean Well. Web. Nov < 38

39 Appendix 3 Figure 11: Microphone Module Schematic 39

40 Figure 12: Microphone Module PCB 40

41 Figure 13: Power Board Schematic 41

42 Figure 14: Power Board PCB Figure 15: Netduino Adapter PCB Figure 17: Microphone PCB 42

43 Appendix 4 PSpice Simulation BandPass Filter 1.05Khz Center Frequency Vmic 15 0 AC 1 R K R K R K R K R K R K R K R K R K R K C U C U C U C U C U C U C U C U C U C U VP VP X LF411 X LF411 X LF411 X LF411.LIB ECE402.LIB.AC DEC K.PROBE.END 43