dREM plans to create a mobile app that allows the user to effortlessly achieve a lucid dreaming experience through smartphone sensors.
In terms of the user interface design there are not many more things to improve. We are happy with the visual layout and simplicity but looking into the future, especially when considering that it will all need to be coded, we are trying to make the app as simple and strait forward as possible – making it easier both for the user and the coder. On the other prototype we have also been making progress trying to quantify what values will actually be relevant when determining when to use the trigger. Unfortunately regarding heart rate we discovered that it is highly variable among different people. This means it will need to be on a case by case basis and cannot rely on any base assumptions for the heart rate. On the more positive side however, we learned a lot about breathing patterns in different states of sleep, and the efficiency with which a microphone can detect the volume and strength of a breath. In REM, the minute ventilation is 6.46+-0.29 as compared to 7.24+- 0.39 in other stages. We would be using the process of spirometry to take measurements using breath. We are still working to find data on the amount of movement during sleep – which can also be difficult from the loose definition of movement. As we move forward, we will need to specifically define this and find the variable that it is most closely correlated to. One other discovery we made was the cycle of REM sleep. Typically in 90 minute cycles, REM happens for about 20 minutes but gets progressively longer after each cycle. This can be extremely helpful in setting up parameters for when the sensors are going to actually be sensing and expecting the individual to be in REM. There is still a lot of research to be done, but what we have found so far has been extremely helpful and relevant to our goal.
An idea that we have been entertaining also is contacting the various companies that already have programs for breath detection as well as movement. If we were able to get parts of their code, we believe this would make much less work for the programmer on our side, so we are also going to reach out to these companies. Hopefully they will understand the project and recognize that we are in no way any type of competition but rather using their technology to serve another purpose.
When we tried to take an honest look at where Ben and I were in the project and where we needed to go next, our answer was simple. Find a coder. This so far has been the largest hurdle to overcome for our project, because we both feel we cannot test our new ideas fully until there is a physical prototype, not figurative, to collect data.
Previously, to champion this issue, Ben and I had the help of Joel to reach out to some of his students. Considering we got zero feed back, Ben and I are going to take our coder-recruitment approach to the next level. After the approval of Joel, Ben and I are planning to walk into his advanced computer programming classes and give an elevator pitch to the students. We are hoping we may get some bites. If so, we plan to take said student out to lunch to further persuade them and bring them up to date on our project to evaluate if they are willing.
That being said, Joel recommended before we approach a potential coder that we have a detailed, straight forward pseudo code completed to help the student visualize what we want and to help minimize the amount of time he has to spend on design aspects.
In regards to level 3, we took its advice and integrated the waterfall model to help us list specific set of actions where each step has to be completed before moving on. Incidentally, this is very indicative on the various levels within the Kickbox itself. Although, Level 3 said that waterfalls don't work well for maker projects and we didn't follow it to a T, it helped Ben and I focus on a specific task within the framework of a project where we constantly have ideas being born or aspects we want to look more into.
Our first waterfall objective was to determine which factors that effect sleep and can be measured to add to our app prototype. To do so, Ben and I went to the Burlington Sleep Institute and got in touch with a sleep technician to help answer our questions. As a result, using the first phase of iterative design, we wrote pseudo code for the code we would need to be created by someone savvy in computer science. We plan to test our pseudo code by asking Joel, our computer science genius sponsor. Afterwards, we will go back and improve it. Ben and I definitely had to come to terms that our first pseudo code wasn't going to be perfect or pretty. So we began the build phase by asking "What absolutely has to be there right now". As seen in the image, we have the inclusion of all the major sleep functions would aim to measure with sensors. When we wanted to test our pseudo code, we noticed that it wasn't in the format of a smart device. So to solve this problem we used a method our sponsor suggested by creating note cards, which simulate the shape of an iPhone and draw the screen and once a button is pressed you make a new note card of what the options/screen would look like.
Upon first seeing the kickbox, we were excited to see the cards and to "level up". What we initially liked was how the process was broken down into do-able steps with realistic goals. It can be a little overwhelming figuring out which aspect of our project we wanted to do first but the step by step cards were very useful to give us more of a direction. The level 1 card was helpful because it really made us think about the motivation for the project. Though we differed in exactly what we wanted to get out of the project, it was ultimately beneficial to initiate this conversation and to get on the same (and most important) page. In regards to card 2, we enjoyed the outside the box advice regarding the ideate stage. Moreover, the accountability of completing specific tasks before moving on to another level was a great way to ensure discrete progress. As an example of a (2a.) activity, we want to share some findings from our trend spotting efforts. This activity was fun, because it quickly led us to new information that we have not otherwise learned about, because it is new and not present within more establish research sources we have already sifted through. Specifically, we learned about how an air conditioner, commonly known to be positive for maintaining a comfortable sleep temperature, can actually negatively impact sleep positions and depth of sleep when airflow is directed at a human body. This is only a portion of new sleep trends we took note of.
One of the largest goals that dRem has within the context of Kickbox is learning more about the specific variables that affect sleep and how we may be able to manipulate/record using the existing infrastructure of smart devices. Here is a short-hand list created that includes new variables we otherwise were not aware of before Kickbox related research.
1) Body temperature
Homeostatic set point lower than when awake
Not regulated. No sweating or shivering.
Lower than when awake
More than Non-REM. Coughing may be suppressed.
3) Brain activity
Lower than when awake
Motor and sensory areas have more activity than during Non-REM
4) Blood pressure
Lower than when awake
Higher than in Non-REM
5) Heart rate
Slower than when awake
Higher than in Non-REM
6) Muscle tone
Same as when awake
None in major skeletal muscles
7) Sympathetic nervous system activity
Lower than when awake
Higher than when awake
Overall, our initial experience with Kickbox has been positive as it encourages even more time be spent on our project of interest.
Friday, February 17th
At 12:30 PM, Ben and I met Josh, our Kickbox mentor, in the MakerHub to get him on board with dRem and to discuss the inner workings of our project. We began with a summary of what dRem is, the work we have already completed, and our primary goals for this semester. Josh appeared to enjoy our idea and was excited to help out in any way. We discussed why he is working at the MakerHub and what he enjoys most, such as metal and wood working.
After exchanging pleasantries, Josh asked more questions about the specific framework of how our prototype and ideated app would work. Lastly, we spoke on how Josh may contribute, which may be providing contacts within the MakerHub or other departments on who could help. Overall, the meeting went well.
--Ben & Randy out