Experiments: Difference between revisions

From Control Systems Technology Group
Jump to navigation Jump to search
Line 78: Line 78:
== Justification of our algoritm ==
== Justification of our algoritm ==


We will check if the measured sleepcycle-graph is right. We will check this by measuring the sleepphase on two several methods at the same time. One method is or course with our own algortim. The second method will be with the 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)




Line 84: Line 84:
'''Problems with this justification'''
'''Problems with this justification'''


There are some problems with this justification. When we're measuring a whole night, the logging of the data stops after exact 3 hours in the case of Jeroen E., and after exact 4 hours in the case of Wesley. We're sure that the computer is the problem of this stop. Namely, when you swipe once over the touchpad, the logging will start for another three hours. (we've tested this). We've searching on the internet for solutions, but withour any result. Also the ICT-service at the TUe doen't know the problem.  
There are some problems with this justification. When we're measuring a whole night, the logging of the data stops after exact 3 hours in the case of Jeroen E., and after exact 4 hours in the case of Wesley. We're sure that the laptop is causing this. Namely, when you swipe once over the touchpad, the logging will continue for another three hours (we've tested this). We've been searching on the internet for solutions, but without any result. Also the Notebook Service Center at the TU/e campus didn't know the problem existed and has no solution.  
Now, we're trying to measure a whole night with old laptops we have at home. More information later.
Now, we're trying to measure a whole night with other/old laptops we have at home. More information later.




''The graph of 6.5 hours above is from Jeroen V., but he cannot measure with his arduino and phone at the same time. His phone cannot measure the sleepphase.''
''The graph of 6.5 hours above is from Jeroen V., but he cannot measure with his arduino and phone at the same time. His phone cannot measure the sleepphase.''


So due to this problem, we don't have a measurement of a whole night. We only have a part of the night. We will discuss this results below with the aid of some makeshift figures.  
So due to this problem, we don't have a verifiable measurement of a whole night. We only have part of a few nights. We will discuss this results below with the aid of some makeshift figures.  


'''Thursday 16 march - Wesley'''
'''Thursday 16 march - Wesley'''


This night, Wesley has measured the first four hours of his sleep with the arduino. When comparing the graph of the smartphone and the graph from the own measurement, we detect tops on the same time. After 1-2 hours is in both graphs a top shown. And also after 4 hours is in both graphs a top shown.  
This night, Wesley has measured the first four hours of his sleep with the arduino. When comparing the graph of the smartphone and the graph from our own measurements, we detect high values at the same times in both figures. After 1-2 hours you can see a maximum in both graphs, and again after 4 hours.  


[[File:wesley16-3-2016.png]]
[[File:wesley16-3-2016.png]]
Line 100: Line 100:
'''Friday 17 march - Jeroen E.'''
'''Friday 17 march - Jeroen E.'''


This night, Jeroen E. has measured first the first three hours. And during the night he was woken up. (around 4:15) He swiped over the touchpad, so another three hours of measurements starts. when comparing the graphs, the tops are again quite on the same time. But in this plot, the height of the tops aren't the same.  
This night, Jeroen E. has measured the first three hours. And during the night he woke up. (around 4:15) He swiped over the touchpad, so another three hours of measurements started from there. when comparing the graphs, the peaks are once again almost on the same time. But in this plot, the height of this peaks isn´t the same.  


[[File:Jeroen17-3-2016.png]]
[[File:Jeroen17-3-2016.png]]


'''Saterday 18 march - Jeroen E.'''
'''Saturday 18 march - Jeroen E.'''


This night, Jeroen E. has measured the first three hours. And around 8:20 he is woken up and has swiped over the touchpad, so the measurements starts again.  
This night, Jeroen E. has measured the first three hours. And another 90 minutes after 8:20.  
When comparing the graphs, our measurements shows clear tops. But not all of these tops are shown in the graph of the application. The top after 0.5 hour and 1.5 hour isn't shown on the graph of the application. The other two tops are in both graphs.  
When comparing the graphs, our measurements shows clear peaks. But not all of these are shown in the graph of the application. The peak after 0.5 hour isn't visible in the application and the peak after 1.5 hour is arguable. The other two peaks are in both graphs. at 2.8 hours and 4 hours in our graph.


[[File:Jeroen 18-3-2016.png]]
[[File:Jeroen 18-3-2016.png]]
Line 114: Line 114:
''' preliminary conclusion'''
''' preliminary conclusion'''


The preliminary conclusion is that the algorithm detects the tops. But the height of the top isn't shown right. It's the question if we realy need the exact height of a top. Probably it's enough to know the positions of the tops to determine the exact moment of waking up.  
The preliminary 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.  


But this conclusion isn't complete in our opinion. We will first compare a some whole night.
But this conclusion isn't complete in our opinion. We will first attempt to measure and compare some full nights.


== Determining moment of waking up ==
== Determining moment of waking up ==

Revision as of 18:31, 19 March 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 app, this will not be done, but we need this to see whether the data is correct and usable. 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.

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

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.

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)


Problems with this justification

There are some problems with this justification. When we're measuring a whole night, the logging of the data stops after exact 3 hours in the case of Jeroen E., and after exact 4 hours in the case of Wesley. We're sure that the laptop is causing this. Namely, when you swipe once over the touchpad, the logging will continue for another three hours (we've tested this). We've been searching on the internet for solutions, but without any result. Also the Notebook Service Center at the TU/e campus didn't know the problem existed and has no solution. Now, we're trying to measure a whole night with other/old laptops we have at home. More information later.


The graph of 6.5 hours above is from Jeroen V., but he cannot measure with his arduino and phone at the same time. His phone cannot measure the sleepphase.

So due to this problem, we don't have a verifiable measurement of a whole night. We only have part of a few nights. We will discuss this results below with the aid of some makeshift figures.

Thursday 16 march - Wesley

This night, Wesley has measured the first four hours of his sleep with the arduino. When comparing the graph of the smartphone and the graph from our own measurements, we detect high values at the same times in both figures. After 1-2 hours you can see a maximum in both graphs, and again after 4 hours.

Wesley16-3-2016.png

Friday 17 march - Jeroen E.

This night, Jeroen E. has measured the first three hours. And during the night he woke up. (around 4:15) He swiped over the touchpad, so another three hours of measurements started from there. when comparing the graphs, the peaks are once again almost on the same time. But in this plot, the height of this peaks isn´t the same.

Jeroen17-3-2016.png

Saturday 18 march - Jeroen E.

This night, Jeroen E. has measured the first three hours. And another 90 minutes after 8:20. When comparing the graphs, our measurements shows clear peaks. But not all of these are shown in the graph of the application. The peak after 0.5 hour isn't visible in the application and the peak after 1.5 hour is arguable. The other two peaks are in both graphs. at 2.8 hours and 4 hours in our graph.

Jeroen 18-3-2016.png


preliminary conclusion

The preliminary 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.

But this conclusion isn't complete in our opinion. We will first attempt to measure and compare some full nights.

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.

The output of this matlab-script is in the form 'Start alarm (number of alarm) at (time) hour'. For example: Start alarm 1 at 6.35 hour.

number 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 is scaled from 0.0 to 1.0. So half past one is 1.50.

Improvement of parts done previous week

The arduino-code is improved. Now we use a code which generates a constant sample frequency around 470 Hz. This is done by sending a string with a constant lenght. See the appendix for the new arduino-code.

Because of this new constant lenght, we'd to change the matlab-scripts. So the new matlab scripts are also uploaded in the appendix.

Appendix

Arduino-code:

Workingvarfreq.JPG


Matlab-scripts:

This script will transfer compact data into graphs of analysing the data and the Arduino code:

File:Fourier.m

This script will use the output of the script above to make a graph of the frequency of the respiration during a night:

File:Ademhaling.m

This script will give the best moment(s) of waking up.

File:Wake up.m