Experiments: Difference between revisions

From Control Systems Technology Group
Jump to navigation Jump to search
Line 88: Line 88:
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 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)


In the figure below are shown the results of three nights. The left and middle nights are measured on sunday night the 20th of march by respectively Jeroen Ermers and Wesley van de Broek. the right night is measured on wednesday the 23 of march.  
In the figure below are shown the results of three nights. The left and middle nights are measured on sunday night the 20th of march by respectively Jeroen Ermers and Wesley van de Broek. The right night is measured on wednesday the 23 of march.





Revision as of 13:46, 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.

Sample-time.jpg

Below are some plots of the audio and envelope against time, and the amplitude of both against the frequency.

Audio-envelope.jpg

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.

Frequency-respiration.jpg 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.

Frequency-respiration-sliding-average.jpg

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.

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)

In the figure below are shown the results of three nights. The left and middle nights are measured on sunday night the 20th of march by respectively Jeroen Ermers and Wesley van de Broek. The right night is measured on wednesday the 23 of march.


Validation sleepphase.png


In general, our own algorihm shows much more tops as the application. But in most cases, 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, on the left night 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.

The different heights of the peaks in the application aren't the same as in our own measurements in most cases. In our own measurements are the peaks mostly on the same height, while the tops in the application are variating a lot.

Another remark is the little delay in the thick blue line. The thick blue line is namely an average of the last 5 frames. This lead to a little delay, because the level of the thick blue line is also based on the data measured a few minutes ago. But in our imagnation, the thick blue line is nessecary to determine the best wake-up moment. It is namely nessecary to plot an average line of the raw data. And when you're processing the data realtime, it isn't possible to look forward, so the only possibility is to look to the points a few minutes ago to make an averige line.

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 realy 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. So we realize that our algorithm doesn't describe the sleepphase perfectly, but the algorithm describes the sleepphase good enough to determine the best moment of waking up.

Remark All shown results in the figure 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)