Ever forget a dream? Of course you have! You've probably had dreams that you would have loved to remember but forgot it only minutes after waking up. Heck, lately, you've probably even forgotten that you've forgotten your dreams! Well, forget no more with this end-of-dream wake-up-and-write alarm!

What it does

This device, made up of an Arduino and attached microphone connects to your phone at the end of a dream and reminds you to either write or record yourself explaining your dream so that you won't forget it a few minutes later! It's only four easy steps: just power the Arduino, wirelessly connect it to your phone, set the Arduino close to your pillow and go to sleep! It's that easy! When you make noise above a certain threshold, the device will recognize this as an end-of-sleep state and will send several alarms to your phone to wake you up so that you can go back to sleep again.

How I built it

We used an Arduino/Genuino 101 (as it is called), a microphone module for the Arduino, and programmed it using the Arduino IDE on the Intel Curie core. In addition we used Android Studio to build an app that chimes and and notifies the user to wake up and record their dream.

Challenges I ran into

At first, we wanted to use some sort of motion sensor, and we were considering an accelerometer similar to the ones in our phones. However, the only mechanically similar module available at the Hardware lab was a vibration sensor, so we attempted to use that one. Before we could even try out the vibration sensor, the Arduino board we were using was giving us constant problems. The code always timed out when uploading, the COM port the Arduino used kept on disconnecting, and somehow it duplicated the port it rested in, resulting in the need for a total reset of the Arduino, its memory, and IDE application. By far the greatest obstacle we faced was the logical leap from getting the bluetooth signal with the built in BLE module to our central device (android phone) to having our coded app actually recognize that encoded signal to set off our notification and alarm. We never quite completed this task after heavily pursuing two different methods. The first was to use a built in BLE service to "alarm" the phone's hardware directly, but problems with the encryption of the service's signals prevented it from going through smoothly, despite the fact that a similar built in service was able to successfully feed our sound sensor readings to the android phone. The second method was the previously mentioned Android Studio App. After importing bluetooth adapter packages and "characteristic readers", the signals were still not fully recognized by our code.

Accomplishments that I'm proud of

Our main code for conceptually determining when the user has had a dream worked quite well. Using the principles of apps such as SleepCycle, we determined that after an extended period of minimal sound detection (a dreaming REM state), followed by a spike up to a certain level, we would trigger the notification. We did this by decrementing a counter for the sound readings that occurred every 200 ms, and having a conditional that required the level of sound along with a significant amount of readings passing. This was all accomplished in a C Arduino sketch. In addition, the motion sensor graph was scaled and displayed and we were able to utilize third party apps like "RFT Connect" to collect the sound readings ONLY during those exact spikes we wished for. In other words, the first phase of the methodology worked like a charm.

What I learned

We gained a thorough understanding of BLE (Bluetooth low energy) capabilities in Arduino, as well as C functions and the GATT bluetooth ecosystem. This ecosystem sends encoded attributes with certain characteristics from a peripheral device to a central device that can then process and alter those attributes. We also learned of the complexity of integrating an Android App made with Java designed to "trigger" at a certain time with an Arduino system like this. Using the sound sensors and BLE code also showed the importance and place for unsigned vs signed variables.

What's next for Wake-Me-Up Dream Journal

Completion of the alarm triggering process is the next crucial step. Afterwards, more complex and thorough sensors can be implemented, and the ranges of sound can be altered to be more precise, and perhaps be made variable, changing over the course of the night and for every user. In addition the push notification should be able to be tapped to open a collection of journal entries or have voice recording capabilities. Machine learning can be used to learn to filter external noises and only register the noises of the sleeping user.

Share this project: