Week Eight Overview (05/20/2015- 05/27/2015)
This week we need to finalize our code and prepare for the practice presentation next week. We have been working hard to perfect the code in order for it to consistently work. This has been a struggle due to the fact that we have to dismantle and reset the breadboard every time we meet.
Week Eight Class Time (05/20/2015)
We decided to make some modifications to our circuit and code. At first, we decided to use multiple LED lights. We coded that the first LED light would flash when the alarm threshold was reached and 1 is added to the counter. Then, we coded that the second LED light would flash when the counter met a certain number before the timer ran out.
Week Seven Overview (05/13/2015-05/20/2015)
With the deadline approaching quickly, we have several tasks to complete for this week. We need to continue and hopefully finish our code for the device, start writing the final report and begin rehearsing for our final presentation.
Week Seven Class Time (05/13/2015)
Class was used to get work done. We divided up into groups to tackle all of our upcoming deliverables. Half of us continued to program and work on our code. We are still trying to decipher between loud sounds and alarms. This has to due with problems with the code constantly restarting the counter. The rest of the team decided to start on the final report. The final report could not be completed since our final deliverable is not completed, but this will allow us time for next class to start preparing for our final presentation.
Week Six Overview (05/06/2015-05/13/2015)
Now that we have a provisional code to detect sound and generate the LED light to flash, our goal is to develop the code to recognize when the sound detected is an alarm. We plan to do this by allowing the code to recognize when a sound is at a certain frequency and repeated at this frequency for a given time, that sound is an alarm.
Week Six Class Time (05/06/2015)
Our main concern for this class was to continue programming. We are still trying to figure out how to program a code to recognize if the sound detected is an alarm. We messed with our program a bit, changing around the different thresholds. This can be seen through the figure below. Our code's thresholds are based off of standard alarm frequencies and pitches we have researched online. However, we have been testing our code with different alarms from different apps from our phones. Our code is nowhere near perfect yet, but we plan to continue to keep working and refining our code over the next coming weeks.
Week Five Overview (04/29/2015-05/06/2015)
This week we need to finalize our code and prepare for the practice presentation next week. We have been working hard to perfect the code in order for it to consistently work. This has been a struggle due to the fact that we have to dismantle and reset the breadboard every time we meet.
Week Eight Class Time (05/20/2015)
We decided to make some modifications to our circuit and code. At first, we decided to use multiple LED lights. We coded that the first LED light would flash when the alarm threshold was reached and 1 is added to the counter. Then, we coded that the second LED light would flash when the counter met a certain number before the timer ran out.
![]() |
This is a picture of our circuit with multiple LED lights. |
We then tried to use an LCD screen to display the counter number, when the device is counting and when the alarm is detected. We were skeptical of being able to make this work, but knew we had the multiple LED lights to fall back on. However, we were able to get the LCD screen to work and are using the screen in addition to the LED light.
![]() |
This is a picture of our circuit using the LCD screen. |
With the deadline approaching quickly, we have several tasks to complete for this week. We need to continue and hopefully finish our code for the device, start writing the final report and begin rehearsing for our final presentation.
Week Seven Class Time (05/13/2015)
Class was used to get work done. We divided up into groups to tackle all of our upcoming deliverables. Half of us continued to program and work on our code. We are still trying to decipher between loud sounds and alarms. This has to due with problems with the code constantly restarting the counter. The rest of the team decided to start on the final report. The final report could not be completed since our final deliverable is not completed, but this will allow us time for next class to start preparing for our final presentation.
![]() |
This is our Arduino board. We are working on programming it. |
Now that we have a provisional code to detect sound and generate the LED light to flash, our goal is to develop the code to recognize when the sound detected is an alarm. We plan to do this by allowing the code to recognize when a sound is at a certain frequency and repeated at this frequency for a given time, that sound is an alarm.
Week Six Class Time (05/06/2015)
Our main concern for this class was to continue programming. We are still trying to figure out how to program a code to recognize if the sound detected is an alarm. We messed with our program a bit, changing around the different thresholds. This can be seen through the figure below. Our code's thresholds are based off of standard alarm frequencies and pitches we have researched online. However, we have been testing our code with different alarms from different apps from our phones. Our code is nowhere near perfect yet, but we plan to continue to keep working and refining our code over the next coming weeks.
![]() |
This is a screenshot of our updated code. A few of the thresholds have been changed in accordance of detecting alarm frequencies.
|
Our main focus for this week is programming. Our prototype
involves a good amount of programming with the Arduino and microphone. We hope
to start a basic program of having the microphone pick up sound and generate an
LED light to flash.
Week Five Outside Meeting (05/05/2015)
In our meeting, we continued to program for the prototype. Right
now, our code has the microphone listen for a loud noise. When the microphone
detects sound, 1 is added to a counter and a timer is started. If the timer
reaches zero, the counter is reset to zero. If the counter goes over the threshold,
an LED light flashes. This can be seen in the figure below.![]() |
Week Five Class Time (04/29/2015)
We received all our needed materials; an Arduino
microcomputer, a microphone, LED lights, a breadboard and wires. However, we ordered
some additional wires for use. A few of us downloaded the Arduino program. We are
in the process of learning how to use the program and we started gathering
ideas for how to code. In class, we were
able to wire the Arduino and microphone to the breadboard to receive audio
input and LED light output. Meanwhile, others were working on developing the
CAD design of the alarm clock case in order to be 3-D printed. The front and back of the case can be seen in thee figures below. We plan to have a meeting sometime this
week to continue programming and further our progress on the prototype.
![]() |
This is a CAD design of the front of the alarm case.
|
![]() |
This is a CAD design of the back of the alarm case.
|
The main goal for this week was making a detailed plan for how we are exactly going to make this prototype. We got the materials that we need and are working on assembling a working prototype.
Week Four Class Time (04/22/2015)
We showed our block diagram to Dr. Allen and he made some influential contributions to our systems. A photo of the diagram can be seen below in the figure. The input to our system is sound. This sound is from either an alarm clock or fire alarm. The next system we need to have is a sound detector. Next, we need a sound interpreter to distinguish the alarming noise from regular noise. We do not want the device to go off for every little sound. We are going to do this by either letting it distinguish the duration of the alarm or the amplitude of the alarm from other sounds. Next, we will need an alert system to alert the user that there is an alarm going off. We will do this by either using vibration or an LED light. We also discussed the materials we are going to need. We need an Arduino microcomputer, a microphone, and either some type of vibrating device or LED light. We also discussed the possibility of purchasing an alarm clock interface so the device itself can be an alarm clock. We will decide this later on since it is an accessory to the actual device.
![]() |
This a picture of our block diagram. The purpose of our block diagram is to represents the inputs and outputs of our system.
|
Now that we have a concrete plan, audience, and direction, we need to come up with a way to make all of this happen. We spent a lot of time discussing the possibilities of our project. We were debating on whether or not the device should just pick up fire alarms, alarm clocks, or both. Then we discussed the possibility of our device being a fire detecting device or alarm clock in itself. We have a lot of decisions to make in the upcoming week to get our project started. We will need to decide what is the smartest, most efficient way to make this alarm system possible and helpful to the user.
Week Three Class Time (04/15/2015)
This week's class time was very valuable. Everyone pitched their ideas and proposals to the class. Then, the class offered feedback to each group. We liked the idea of this because although each individual group is working on their own specific project, it feels as though we can all help each other out in one, collective group effort to engineer some awesome human assistance devices. This exercise took up the majority of the class. For the remainder of the class, we worked on creating a block diagram for the systems of our device. We will upload a photo of the block diagram in an upcoming weekly post.
Week Two Overview (04/08/2015-04/15/2015)
We were happy to welcome a new group member, Jake, to the team this week. We got him up to date with our progress and finally solidified a direction we plan on taking. We decided to make our audience the hearing impaired. As anyone could imagine, notifying a hearing impaired person in the case of an emergency can create a plethora of issues. Also, we imagine that although something already exists, deaf people need to use some sort of specialized alarm clock to wake them up every morning. Our plan is to create a device that can detect loud alarming noises, such as a fire alarm or an alarm clock, and notify the hearing impaired person. We want this device to be mobile so it will be accessible and useful to them in all scenarios. We also worked on and submitted our project proposal this week, which goes more into depth about our direction, plans, and budget for the overall project.
Week Two Class Time (04/08/2015)
We had individual meetings with Dr. Allen to discuss our direction thus far. He gave us a lot of helpful insight. We decided to make a device for the hearing impaired. That is our audience. The problem we have to conquer is that with being hearing impaired, they often are not alerted when there is an emergency or alarm. We will make a device to aid this issue. Our device will somehow alert someone when there is an emergency or an alarm going off either visually or using vibration.
Week One Overview (04/01/2015-04/08/2015)
During week one, we spent a lot of time brainstorming for the project. In order to come up with an idea, we decided it would be best to first establish a problem and a targeted audience. After this has been decided, we then will come up with a project proposal. Our brainstorming process will have to lead into the beginning of week two since we have not solidified a concrete idea yet. Some directions we have been considering taking include a reverse microwave and an alarm clock for the hearing impaired.
Week One Outside Meeting (04/07/2015)
We had our first meeting at Race Learning Terrace. We had a difficult time thinking of a specific problem, probably because there are just too many. We used the internet to spark some ideas. After scrolling through tons of threads on Reddit and looking at lists of "problems with every day objects," we realized it would be easier to help people with a specific disability rather than trying to appeal to the masses. Most of the other ideas we came across were way out of reach for us. Either we did not have the knowledge or the money to make some of the ideas feasible. We have still not come up with a concrete idea, but we are understanding the steps we are going to have to take better, which is a step in a positive direction.
Week One Class Time (04/01/2105)
During our first class meeting, we spent most of the time watching the "ArchiTECHS Challenge." In this video, a group of engineers were challenged to come up with innovative technology to aid firefighters. They were given a strict 48 hour time limit. Their main goals were to design something that can help manage the firefighter's equipment in high-rise buildings and to design something that can help evacuate people from a building. Even though we are not specifically designing a prototype for firefighters, the engineers in the video demonstrated some important skills that will influence our group and project. When brainstorming, they would think of some really abstract, far-fetched ideas, but no one ever shot them down. They all were very respectful of everyone's ideas. They made prototypes and tested them to see how successful they were. Also, they went out on the scene and talked to firefighters directly to get a firsthand view of what they were dealing with. They had a method to their plan that we will try to mimic. First, they identified a problem. Then, they came up with a design goal. They solidified their criteria, requirements, and constraints of their project. Then, they went through with their project. We will use this same method to get our project started. We then got into our groups and discussed some ideas we had for the last ten minutes of class. We plan on meeting up sometime this week to further discuss our ideas.
No comments:
Post a Comment