Experiments: Difference between revisions
No edit summary |
|||
Line 125: | Line 125: | ||
All shown results above have the same variables. These variables are: frame length of four minutes, the blue line is an average of the last 5 points, a minimal frequency of 13/60 Hz and a maximal frequency of 27/60 Hz. These variables are determined out of the kalibration stage. (trail and error by comparing the both graphs) | All shown results above have the same variables. These variables are: frame length of four minutes, the blue line is an average of the last 5 points, a minimal frequency of 13/60 Hz and a maximal frequency of 27/60 Hz. These variables are determined out of the kalibration stage. (trail and error by comparing the both graphs) | ||
Revision as of 10:58, 2 April 2016
Back to main page: PRE2015_3_Groep4
Measurement plan
Research question
Is it possible to know in what sleep phase a person is by analyzing the sounds that he/she makes while breathing?
Sub-questions
• What is the best way to measure the sound present in the bedroom?
1) High-frequency recording of the sleep measuring the pitch
2) Low-frequency recording of the sleep measuring the decibel level
• What conclusions can be drawn from the results we encounter?
What has to be done
• Measuring
1) Measure the sounds of multiple persons their bedroom throughout the night.
2) Measuring multiple nights.
3 ) Measuring on a high-frequency sound level as well as on a low-frequency sound level.
• Processing the measuring results
1) Analyzing which method brought us the best results.
2) Determining if it is possible to use the data that we have for future work.
What are we going to use for the measuring
For the measuring of the sound levels, an Arduino is used. This Arduino will be connected to a sound detector. We chose an Arduino Mega with a SparkFun Sound Detector. The results will be stored to be reviewed afterwards.
When and where do we do the measuring
The testing will be done as soon as all the components arrived. The plan is to do as many tests as possible in about one week. Two persons will do the testing at their own home. This way there are twice as much testing results in the same time period.
The sound detector was recommended to us by Ruud van den Bogaert. It is more that suited for our needs, for it has both analogue frequency output and volume level or ‘envelope’ output. It also has a digital output that’s high when the volume rises above a certain threshold, which we won’t use.
Reading data into matlab
First, we wrote a program which will print time, audio and envelope as fast as possible. These outputs will be logged on the computer during the sleep. The time will be in microseconds anywhere between 0 and 2^32, which is about 71 minutes. The audio is a 10-bit value (between 0 and 1023), which will typically be around 510. The envelope is also a 10-bit value which represents the amplitude of the sound. Because the amplitude is very low, this value is typically around 12. See the appendix at the bottom of the page for the Arduino code.
Data pre-processing
During a night, almost ten million lines of data are logged. These data can be analyzed in Matlab. Matlab will first 'repair' the time. Because 71 minutes is the highest value the arduino can print, the time will overflow several times during one night. This has to be fixed by adding 2^32 µs to the time after the value drops. After that, some figures are plotted to verify the logging-proces. In the final script, this will not be done, but we need this to see whether the data is correct and usable in the beginning stage. For example raw input against time and the sample time for each sample, to find discrepancies the sample frequency. In early versions, sample time against serial string length was also plotted, because this has a significant impact on sample time. This figure shows that the sample time increases with string length. A high variating sample time will influence the precision of the measurements. So we'll use a script which gives the output in a constant string lenght. Because of this, the sample time will be much more constant.
Below are some plots of the audio and envelope against time, and the amplitude of both against the frequency.
Removing bad samples
The mean sample time should be around 2000 microseconds. But this isn't always the case. Sometimes, the will be a print error. This can have a lot of different reasons, so it isn't completely preventable. These bad samples can't be processed in the next stages of the script, so it's nessecary to remove these bad samples. The bad samples can be found by analysing the sample time. If the sample time is bigger than two times the mean sample time, it's a abd sample. By removing the bad samples, you've to pay attention that the next line of code will be connect with the previous one. So in most cases, it's nessecary to remove more than one sample. For every print error, around the 30 lines will typically be removed. (maximum time is around 64000 microseconds. 64000/2000=32) <-- NETTER UITLEGGEN. So there will be removed for 0.06 seconds of data, which is neglectible.
Data processing
If the data is acceptable, it will be used to make a graph of the frequency of the respiration. The envelope signal is used. The data is divided into chunks of 4 minutes, these will be called frames. After that, a fourier transform is executed on each frame to get a graph of the frequencies and their amplitudes. Out of this graph, only the frequencies between 13/min and 27/min will be considered. This is done because the frequency of the respiration is between these limits. Out of the remaining frequencies, the frequency with the highest amplitude will be determined for every frame and used as the frequency of respiration for that frame. Now, we can plot the frequency of the respiration throughout the night.
The data is from a real measurement (10-3-2016)
It don't seems to have a clear pattern. But when you plot a sliding average of the last five frames (thick red line), a more clear pattern will appear. This pattern cannot be verified for this specific night, because it was measured without an already existing app.
This plot is from a single night. To get such a plot of every night, we have to measure more nights and try whether this algorithm also works for other nights (calibration-proces). See the appendix below for the Matlab-scripts.
Determining moment of waking up
See the page code for a description of the algorithm. A matlab-script of the code itself can be found in the appendix.
type of alarm
We will make a distinction between two type of alarms. The first alarm is the alarm which will start before the out-and-outer wake up time. This alarm will build op in volume. The first option isn't only a stardart alarm. It also includes the lights and temperature.
The second alarm is the alarm which will start when the out-and-outer wake up time is reached, in the cases the person is still asleep. This alarm will cause a much more abrupt waking up. But the person have to wake up to be on time at his appointment.
Time
The time in the output is the absolute time. This time will be in hours and minutes. for example half past 7 in the morning: 07:30.
Justification of our algoritm
We will check if the measured sleepcycle-graph is right. We will check this by measuring the sleep phase on two several methods at the same time. Of course, one method will be using our own algorithm. The second method will be with an application on our smartphone. The application is named SleepCycle. (see literature for more information about the App and how they measure the sleepphase)
We will analyse several nights below. The graph on the top is from the application SleepCycle and the graph below is from our own algorithm.
Sunday 20 march - Jeroen E.
This night, our own algorihm shows much more tops as the application. But in general, if there's a peak on the graph of the application, there's also an top in our own algorithm. Some of the 'extra peaks' in our algorithm can be explained by the sub-peak in the graph of the application. For example, between 00:00 and 02:00, the line exist out of tree stages. The line isn't a smooth climbing line, but stops climbing for two times. On these times, there are peaks in the graph of our algorithm.
Sunday 20 march - Wesley
Also in this nights are the peaks of both sleepgraphs in most cases on the same place. But the height of the tops aren't equal.
Tuesday 22 march - Jeroen E.
And this night we can give the same analyses as before. In most cases are the peaks on the same place, but the top heights aren't the same.
conclusion
The conclusion is that the graphs roughly show the sleep cycle. But the height of the peaks isn't shown right. The question is, whether we really need the exact height of a top. Probably it's enough to know the positions of the peaks, and therefor the REM sleep, to determine the exact moment of waking up.
All shown results above have the same variables. These variables are: frame length of four minutes, the blue line is an average of the last 5 points, a minimal frequency of 13/60 Hz and a maximal frequency of 27/60 Hz. These variables are determined out of the kalibration stage. (trail and error by comparing the both graphs)