Conclusions

Overall, we met almost all of our expectations and stuck to the design plan we initially set up. We achieved a working and accurate clock that had an alarm that would go off at the set time or a time signaled by the sleep cycle system. The alarm would produce a very obnoxious noise that would force the person to get up. The display was nice and clean cut and had simple and easy controls. The touch screen controls worked well and allowed the user to easily change real time, alarm time and turn the alarm on or off. The EEG reading system was able to read data and package it on board the PIC32. The sleep cycle analysis system was able to make some sort of determination about the sleep state the user was in and wake them up if it was a light state. In addition, to use the EEG system requires nothing but putting on the headset when you go to sleep. Once the headset is on, the system will take care of everything automatically. In addition, if the user does not want to use the EEG system, they can opt out of putting the headset on and the system will act just as a normal alarm clock.

To create this system we used a lot of support from the Microchip documentation. A lot of the peripherals (like RTC and UART) required us to read up about. In addition, we used a lot of support on many websites for the MindFlex hack. We based our code for the EEG reading sub-system off of a github project which we will link in the References section on this page.  Besides that, we didn’t really reuse code or anyone else’s design.  One small thing we did use was some code that we found off a public forum that allowed us to easily convert integer values to their BCD equivalent.

We don’t have any plans to do future work on this project, however we do have an idea of what we would do if we did continue to work. Firstly, we would like to get a more accurate clock. Although our system was fairly accurate, if we were to use this in a real world application, our error margin would be far too great. Secondly, we would like implement the dimming feature completely. We believe it is important to have if it is being used at night as the backlight can very bright and disruptive to a sleeping user. Lastly, we would like to further our research on the EEG response in sleep cycles and possibly obtain better sensors to record EEG data. From there, we could make a more accurate estimation of sleep cycles of a user and perhaps make a more effective product.

Group Member Tasks

Richard– Primarily worked on setting up the touch screen controls for the lcd display. Creating the different interactions between the controls and display. Setting up the RTC and the alarm systems. Setting up the controls for the RTC and the Alarm. Helped to put everything together.

Jae-Researched a lot of information on the sleep cycle states. Researched on EEG responses in different sleep states. Worked on dimming features. Helped to put everything together.

Kyle– Worked on implementing EEG reading. Worked on sleep cycle analysis system. Worked on audio generation. Worked on integrating sleep cycle system with alarm system. Helped to put everything together.

*it is important to note that although we all had separate tasks, we were always willing to help each other on tasks and did help to work on each other’s parts of the project.

References

Existing Solutions

MindFlex EEG Hack Support 

Sleep Cycle and EEG Research

Microchip Support

Reflections

Kyle- I learned a lot of really awesome things doing this project. I learned a lot of great technical knowledge but I won’t focus on that as much in this reflection.To begin, I’d say the whole project planning and design process was a great learning experience. Having to find a problem, develop a solution and then figure out how you would go about building the solution is a great way to give me structure in figuring out a way I would do something like this in the future. Moving on to design, I got a chance to learn what worked in our design/project planning phase and what did not. Something I think that worked really well was breaking up our system into clear and definite sub-system. Throughout the whole process it was very easy to determine what feature or process should be grouped with what sub-system and it made it much easier to tackle the big problem at hand. This is something I will definitely do in future design processes. I think what did not work so well was figuring out how much time it would take for us to accomplish what we set out to do. I was originally planning on doing the whole project with just Jae and myself, however I’m very lucky Richard hopped on board as well because there is no way me and Jae would have been able to do it ourselves. In the future, I’ll be sure to even over-estimate how long it will take me to accomplish something. One of the biggest problems I faced was not knowing enough about the EEG portion of the project. I feel like the project we chose, detecting sleep states using EEG, was ambitious because it was way outside our field of study. Although we did a lot of research, I still felt limited in my understanding, which is perhaps is a result of the incomplete nature of the field of study in itself. Either way, in the future I’ll be careful about which topics I pick to do projects on. I want to create things that are neat but are still useful. I’ll likely conduct more research on a project like this before I begin building it.

Jae-I learned from the project that working in groups, especially when we are working on different sub-tasks of the project, can be challenging if we don’t keep track of each other’s code using systems such as Github or SVN. Not having to manually combine code and knowing what changes were made in what order could have helped us save time and fix many errors. I also learned that I can’t always expect my code to work (even if it worked on my part) with someone else’s code because they could have some minor differences. I was able to seen this problem specifically from my experience trying to get the backlighting to work with the final version of the code. One of the biggest mistakes we made was waiting until the day before the demo to combine the dimming code. That’s when I faced my biggest problem because backlight setting function that should have worked ended up being buggy, and we didn’t have enough time to figure out why. I was not able to adapt to it due to lack of time because we assumed that our code would all work together. In the future, I would definitely recommend to my group that we use a sub-version control system and that we plan ahead to allow ourselves more time in case of errors and bugs because I know that if we did that for this project it would have been much more successful and we would have found the errors very quickly.

Richard- I learned a ton of different things throughout the project. I think that one of the most important things I learned throughout the project was figuring out your realistic expectations and then doing your planning based on those realistic expectations however you should also always assume that something will go wrong. The biggest problem I faced during the project was dealing with the real time clock. It was really a hassle to deal with as the documentation was a little sparse and any issues that I had to deal with I either had to come up with by myself or finding some type of answer on google. I adapted to it by just doing many different tests based on what came through on google and different testing. I just knew that if I just kept working with it, eventually I would find a solution that would work with our project. In the future I will approach design by preferably setting expectations a little low so that you would be able to still fulfill expectations even when things go wrong. This will allow you to fulfill expectations and still be able to fix any complications that end up showing up during the design process.

Page Directory